安全、RBAC 与 Helm 包管理

• Audit 与 stage 概念
• 各 stage 的触发时机
• 选择 stage 的考量

Audit（审计）记录 API 请求，按 stage 分阶段记录。RequestReceived：请求到达 apiserver、尚未处理时触发（只有请求元数据，无响应）。ResponseStarted：响应头开始发送时触发（可能没有完整响应，适合流式请求）。ResponseComplete：响应完整发送后触发（最完整，含请求与响应）。Panic：apiserver 处理请求时 panic（异常）时触发。默认 stage 是 ResponseComplete。选择 stage 时，RequestReceived 最早但无响应，ResponseComplete 最完整但开销大。Audit policy 中按规则指定要记录的 stage。

核心是"按请求处理阶段记录"。ResponseComplete 最常用，流式请求用 ResponseStarted。

• managedFields 的含义
• omitManagedFields 作用
• 日志精简

managedFields 是对象 metadata 中记录哪些组件/用户管理哪些字段的信息（server-side apply 使用），可能很大且冗余。omitManagedFields: true 在审计日志中省略 managedFields 字段，减小日志体积、提升可读性、避免敏感信息。它作用于审计策略（policy）或 audit 配置。默认 false（保留）。开启后审计日志不含 metadata.managedFields。

核心是"审计日志省略 managedFields 以减小体积"。适合日志量大、不需要 apply 元数据时。

• 各 verb 的含义
• get/list/watch 差异
• update/patch 差异

RBAC verbs 对应 API 操作：get（读取单个对象）、list（列出集合）、watch（监听变化流）、create（创建）、update（整体替换）、patch（局部更新）、delete（删除单个）、deletecollection（批量删除）。get/list/watch 是读操作，create/update/patch/delete 是写操作。update 需完整对象（整体替换），patch 只提交变更（JSON patch/merge patch），权限更细。设计中应最小权限授予：只读用 get/list/watch，慎用写 verb。注意 get 与 list 独立，某些资源需同时授权。

核心是"读/写 verb 的职责与最小权限"。update 与 patch 语义不同，deletecollection 是批量删除。

• mutating webhook 调用时机
• 失败策略（failurePolicy）
• 补丁合并

mutating admission webhook 在请求对象被持久化前、validation 之后调用，用于修改（注入默认值、sidecar 等）。调用流程：请求到达 apiserver → 经过内置 admission → mutating webhook（外部 HTTP 服务）返回补丁（JSONPatch）→ apiserver 应用补丁 → 后续 validating 校验 → 持久化。failurePolicy：Ignore（webhook 失败则忽略，继续）或 Fail（失败则拒绝请求），admissionregistration.k8s.io/v1 默认 Fail。补丁合并：webhook 返回 JSONPatch 列表，apiserver 合并到对象。多个 mutating webhook 按顺序执行，后执行的基于前一个结果。

核心是"mutating 在持久化前修改对象 + failurePolicy 控制失败 + JSONPatch 合并"。

• audit policy 规则
• 后端存储（log/webhook）
• 动态重载

审计日志配置：1）编写 audit policy（rules 定义对各资源/verb 的 audit level：None/Metadata/Request/RequestResponse）；2）apiserver 用 --audit-policy-file 指定策略、--audit-log-path 指定日志后端（也支持 webhook 后端发送到外部）；3）配置日志轮转（--audit-log-maxsize 等）。动态重载：apiserver 支持 audit policy 的动态重载——修改策略文件后向 apiserver 发送 SIGHUP 信号即可重新加载，无需重启进程。审计日志用于安全审计、合规、排障。

核心是"policy 定义级别 + log/webhook 后端 + 轮转"。level 决定记录内容量。

• roleRef 指向 ClusterRole
• 命名空间内复用
• 与 ClusterRoleBinding 的区别

RoleBinding 通过 roleRef 引用 ClusterRole 时，只在该命名空间内生效（ClusterRole 的权限被限定到该命名空间）。这样多个命名空间可复用同一个 ClusterRole 的权限定义，只需在各命名空间创建 RoleBinding。roleRef 是固定的（kind: ClusterRole + name + apiGroup），指向的 ClusterRole 可被多个 RoleBinding 引用。ClusterRoleBinding 则把 ClusterRole 应用到整个集群（跨命名空间）。复用避免了重复定义权限。

核心是"RoleBinding 引用 ClusterRole 限定在命名空间"。跨命名空间复用通过多个 RoleBinding。

• aggregationRule 原理
• 通过 labelSelector 合并
• 动态聚合

Role aggregation（聚合）允许一个 ClusterRole 通过 aggregationRule 的 labelSelector 自动合并所有匹配 label 的 ClusterRole 的规则。当某 ClusterRole 带匹配 label 时，其规则被聚合到聚合 ClusterRole 中。例如定义一个聚合 ClusterRole，labelSelector 匹配"rbac.authorization.k8s.io/aggregate-to-view: true"，所有带该 label 的 ClusterRole 的规则自动合并，实现规则的模块化与动态扩展。添加新 ClusterRole 无需改聚合对象。

核心是"labelSelector 动态合并多个 ClusterRole 规则"。用于预定义角色（如 view/edit）的扩展。

• impersonate 权限
• 模拟用户/组
• 审计与排障

impersonate（模拟）权限允许一个用户以另一个用户/组/ServiceAccount 的身份发请求，用于排障与审计：管理员可模拟某用户查看其权限范围内能看到的资源，验证 RBAC 配置。授予 impersonate 权限需在 ClusterRole 中给 users/groups/serviceaccounts 资源加 impersonate verb。使用 kubectl --as=username --as-group=group 模拟。这相比冒用凭据更安全，且审计日志会记录真实用户与模拟用户。用于验证权限、诊断权限不足问题。

核心是"impersonate 模拟身份 + 审计记录真实与模拟用户"。用于排障与权限验证。

• dependencies 声明
• 子 chart 复用
• 打包与更新

Helm chart 可在 Chart.yaml 的 dependencies 字段声明依赖的子 chart（名称、版本、仓库、条件）。执行 helm dependency update 下载子 chart 到 charts/ 目录（或通过 repository 引用）。子 chart 通过 values 前缀（--set subchart.x）或 values.yaml 中 subchart: 段覆盖 values。依赖可实现组件复用（如共用 redis、ingress 等）。条件启用（condition）与别名（alias）控制依赖加载。依赖图嵌套，打包时一并带入。

核心是"Chart.yaml 声明依赖 + 子 chart values 覆盖复用"。用于组件化组合。

• helm test 机制
• 测试 Pod 定义
• CI 集成

helm test 通过 chart 中 templates/tests/ 下的测试 Pod 运行验证（如检查服务可用、数据库连接）。helm test <release> 运行这些测试 Pod 并报告 PASS/FAIL。工程实践：1）在 chart 中定义测试 Pod（hooks 为 test）；2）CI 中先 helm lint 校验语法、helm template 渲染检查、helm install --dry-run 验证；3）安装后跑 helm test；4）用 helm unittest 或 kubeconform 做单元/校验。CI 集成使 chart 变更可验证。

核心是"helm test 运行测试 Pod + lint/template 校验集成 CI"。测试随 chart 打包。

• values 来源
• 优先级顺序
• 合并规则

Helm values 覆盖优先级从低到高：1）chart 内 values.yaml（默认值）；2）父 chart 的 values；3）-f/--values 指定的用户 values 文件（按顺序，后者覆盖前者）；4）--set 命令行参数（最高优先级）。注意：--set-file 与 --set-json 也属命令行。优先级高的覆盖低的。合并时是深合并（deep merge），子值按 key 合并。同一设置在多个来源时，最高优先级生效。

核心是"values.yaml < 用户 values < --set"。--set 最高。

• hook 类型与时机
• hook 资源的注解
• 失败处理

Helm hook 通过资源注解 helm.sh/hook 指定执行时机，如 pre-install、post-install、pre-upgrade、post-upgrade、pre-delete、post-delete、test 等。hook 资源在对应阶段创建/删除，不参与 release 的生命周期管理。失败处理：hook 失败会导致 Helm 操作失败，可通过 helm.sh/hook-delete-policy（before-hook-creation、hook-succeeded、hook-failed）控制删除时机，helm.sh/hook-weight 控制 hook 执行顺序（负数在前）。hook 用于数据库迁移、初始化等一次性任务。

核心是"注解指定 hook 时机 + weight 排序 + delete-policy 清理"。hook 失败使操作失败。

• rollback 机制
• 版本切换
• 限制

helm rollback <release> <revision> 将 release 回滚到指定版本。机制：Helm 保存每个 release 版本（revision）的渲染清单，rollback 就是重新安装旧版本的清单（用旧 revision 的 values 与模板），通过 helm 的存储（Secret）重建。限制：rollback 需要该 revision 的清单仍存在（release 历史未清理）；回滚会重新创建资源，可能导致资源重建（如 Deployment 滚动）；无法回滚到被删除的历史；回滚过程本身会生成新 revision。通过 --history-max 控制保留版本数。

核心是"rollback 用旧 revision 清单重新渲染安装"。依赖 release 历史存储。

• lookup 函数
• 运行时查询
• 共享配置的陷阱

Helm 模板的 lookup 函数在渲染时查询集群中的对象（运行时查询），用于获取其他 release 或命名空间的资源。陷阱：1）依赖集群状态，模板渲染与集群状态耦合，dry-run 或离线渲染时 lookup 返回空，导致渲染结果不一致；2）lookup 查到的对象可能是旧的/未就绪的，产生竞态；3）跨 release 共享配置时，若被引用对象未就绪或顺序不对，模板出错；4）权限：lookup 需要相应 RBAC，权限不足时查询失败或返回空。因此应谨慎使用 lookup，避免把模板渲染与集群运行时状态强耦合。

核心是"lookup 运行时查询集群导致渲染不确定"。dry-run/离线时结果不可靠。

• 各 audit level 含义
• 记录内容
• 选择考量

audit level 决定审计日志记录的内容。None：不记录该请求（无日志）。Metadata：只记录请求元数据（user、resource、verb、response code），不记录请求/响应体，体积小。Request：记录元数据 + 请求体（不含响应体）。RequestResponse：记录元数据 + 请求体 + 响应体，最完整但体积大。选择考量：Metadata 用于审计谁做了什么；Request/RequestResponse 用于详细排障与安全分析，但消耗存储与性能。通常高敏感操作用高 level，普通操作用 Metadata 或 None。

核心是"level 决定记录深度"。从 None 到 RequestResponse 内容递增。

• Kyverno 策略类型
• validate/mutate/generate
• 策略应用

Kyverno 是 Kubernetes 原生策略引擎，用 CRD 定义策略。validate：校验资源是否符合规则（如强制标签、禁止特权容器），不符合则拒绝或告警。mutate：修改资源（注入默认值、sidecar、安全上下文），通过 admission webhook 应用。generate：根据策略生成新资源（如 Namespace 创建时自动生成 ResourceQuota、NetworkPolicy）。策略以 ClusterPolicy/Policy 定义，可在校验或生成中声明式管理资源，符合 GitOps 理念。

核心是"validate 校验、mutate 修改、generate 生成"。Kyverno 用 CRD 声明策略。

• background scan 概念
• 存量资源校验
• 报告生成

Kyverno 的 background scan 在后台定期扫描集群中已有的（存量）资源，对不符合策略的资源执行校验并生成报告（PolicyReport/ClusterPolicyReport），而不只是拦截新请求。它让策略对存量资源生效，识别既有违规。scan 通过 informer 监听资源并执行 validate 策略，将结果写入报告（含违规项、严重级别）。可用于合规审计与存量治理。默认开启，可通过 background: false 关闭。

核心是"后台扫描存量资源 + 生成 PolicyReport"。用于审计存量违规。

• ConstraintTemplate 结构
• Rego 策略
• 生成 Constraint CRD

OPA Gatekeeper 用 ConstraintTemplate 定义策略模板：它包含 CRD 定义（spec.crd.spec.names 生成新的 Constraint CRD）与 Rego 策略（spec.targets.rego 定义校验逻辑）。创建 ConstraintTemplate 后，Gatekeeper 自动生成对应的 Constraint CRD（如 RequiredLabels）。然后创建 Constraint 实例（CRD 的对象）应用策略到具体资源，Gatekeeper 通过 admission webhook 校验。v1beta 的 CRD 生成与 Rego 校验是策略定制的核心。

核心是"ConstraintTemplate 定义模板并生成 Constraint CRD，Constraint 实例应用策略"。Rego 是校验逻辑。

• Gatekeeper 审计机制
• 周期检查
• 违规上报

Gatekeeper 的审计组件周期性（默认 60 秒，可配置）扫描集群现有资源，对每个资源评估已应用的 Constraint，收集违规，并写入对应 Constraint 的 status.violations 字段与审计结果。审计只是记录，不拦截（admission 才拦截）。管理员可通过 kubectl get <constraint> 查看 violations，或配合 Gatekeeper 的审计日志/报告。审计用于发现存量违规，与 admission 拦截互补。

核心是"周期扫描存量资源 + 写 violations 到 status"。审计不拦截，admission 拦截。

• PSP 移除
• Pod Security Admission
• 准入控制器

PodSecurityPolicy（PSP）在 Kubernetes 1.25 被移除。替代方案是 Pod Security Admission（PSA）：内置准入控制器，通过命名空间标签（pod-security.kubernetes.io/enforce/audit/warn）应用 Pod Security Standards（privileged/baseline/restricted）三个级别。PSA 是内置的，无需部署 webhook，通过命名空间标签控制策略级别与模式。相比 PSP 的复杂 CRD，PSA 用标签声明式、更简单。其他第三方替代：OPA Gatekeeper、Kyverno 等策略引擎。PSA 作为默认基线，第三方用于复杂策略。

核心是"PSP 后被 PSA 取代，用命名空间标签应用安全标准"。内置准入控制器。

• enforce 模式
• audit 模式
• warn 模式

Pod Security Admission 有三种模式，通过命名空间标签设置。enforce：拒绝创建违反策略的 Pod（admission 拦截），保证不运行违规 Pod。audit：记录违规到审计日志（不阻止），用于评估现状。warn：向用户返回警告（不阻止）。可通过标签 pod-security.kubernetes.io/enforce/audit/warn 分别设置各级别与模式。三种模式可组合（如 enforce=baseline，warn=restricted）。适用于渐进式启用的安全基线。

核心是"enforce 拒绝、audit 记录、warn 警告"。三种模式可配不同级别。

• 三个级别
• 各级别限制
• 选择

Pod Security Standards 定义三个策略级别。privileged：最宽松，无限制（允许特权容器、hostNetwork 等），用于系统组件。baseline：限制已知危险能力（禁用特权提升、hostPath、hostNetwork 等），允许常见非特权工作负载。restricted：最严格，在 baseline 基础上强制非 root、readOnlyRootFilesystem、seccomp RuntimeDefault、禁止 escalation 等，符合安全最佳实践。级别递增，restricted 限制最多。多租户隔离建议 restricted，普通应用 baseline。

核心是"privileged 无限制、baseline 限制危险能力、restricted 最严格"。restricted 强制非 root 等。

• Pod 级 securityContext
• 容器级 securityContext
• 覆盖规则

PodSecurityContext 设置 Pod 级安全上下文（runAsUser、runAsGroup、fsGroup、seccompProfile、SELinux 等），应用于所有容器。container securityContext 设置单个容器的安全上下文（runAsUser、capabilities、privileged、readOnlyRootFilesystem 等）。优先级：容器级 securityContext 覆盖 Pod 级（同名字段以容器级为准）。SeccompProfile 等可两者都设，容器级覆盖。capabilities 只能容器级设置（Pod 级无）。设计时按需设置，容器级更细。

核心是"容器级覆盖 Pod 级"。capabilities 仅容器级。

• PriorityClass 定义优先级
• 抢占触发条件
• 优雅终止

PriorityClass 定义 Pod 的优先级（value 越大越优先）。当高优先级 Pod 无法调度时，scheduler 触发抢占（preemption）：驱逐低优先级 Pod 释放资源，让高优先级 Pod 调度。低优先级 Pod 被抢占时优雅终止（按 terminationGracePeriodSeconds）。PreemptionPolicy 控制抢占行为：Never 禁用抢占（高优先级 Pod 排队等待），PreemptLowerPriority（默认）允许抢占。抢占是自愿中断，受 PDB 约束。用于保障关键工作负载。

核心是"高优先级抢占低优先级 + PreemptionPolicy 控制是否抢占"。抢占受 PDB 约束。

• ResourceQuota 命名空间级配额
• LimitRange 每容器默认/约束
• 配合治理

ResourceQuota 限制命名空间内所有资源的总量（CPU、内存、Pod 数、PVC 数等 hard limit），防止命名空间耗尽集群资源。LimitRange 为命名空间内的容器设置资源约束：默认 requests/limits、最小/最大限制，保证每个容器有合理资源。二者配合：ResourceQuota 管总量，LimitRange 管单容器，实现命名空间资源治理。LimitRange 还可设置持久卷声明大小范围。

核心是"ResourceQuota 管总量、LimitRange 管单容器约束"。二者配合治理。

• descheduler 原理
• 常见策略
• 场景

descheduler 是调度器补充，主动驱逐已调度 Pod 以重新平衡（重新调度）。解决调度漂移：1）节点负载不均（LowNodeUtilization/HighNodeUtilization 策略驱逐高负载节点 Pod 到低负载节点）；2）同 Deployment Pod 聚集（PodTopologySpread 策略打散）；3）污点节点驱逐（Taint/RemovePodsViolatingNodeTaints 驱逐不满足污点容忍的 Pod）；4）长时运行节点碎片整理（RemovePodsViolatingTopologySpread、LongLifeTime 等）。descheduler 是 DaemonSet/Deployment 运行，通过策略驱逐 Pod 使其重新调度，但需注意 PDB 与优雅终止。

核心是"主动驱逐失衡 Pod 重新平衡"。descheduler 不直接调度，通过驱逐触发重新调度。

• QoS 等级判定
• 驱逐顺序
• OOM 评分

QoS 分为三类：Guaranteed（requests==limits 且所有容器设置）、Burstable（部分容器设置 requests/limits）、BestEffort（无任何设置）。kubelet 节点压力驱逐时按 QoS 顺序：BestEffort 先被驱逐，其次 Burstable（按 usage 超限程度），Guaranteed 最后（且仅当超过 limits 才被驱逐）。OOM 评分（oom_score_adj）也按 QoS 设置：Guaranteed 最低（不易被杀）、BestEffort 最高（易被杀）。因此 Guaranteed 工作负载最稳定。

核心是"QoS 决定驱逐与 OOM 优先级"。Guaranteed 最稳定。

• values 文件按环境
• 覆盖策略
• 环境隔离

用 Helm 实现多环境：1）为每个环境准备 values 文件（values-dev.yaml、values-staging.yaml、values-prod.yaml），用 -f 指定环境 values，覆盖默认值；2）用 --set 覆盖关键差异（replica、image tag、ingress host）；3）模板中用条件（targetEnvironment 或 if 判断）控制环境专属资源；4）每个环境用不同命名空间/release 名隔离。部署时通过 helm install -f values-prod.yaml 应用。结合 GitOps（Argo CD/Flux）按环境分支管理。

核心是"多 values 文件 + 条件模板 + 命名空间隔离"。按环境覆盖。

• 防止命名空间耗尽
• FairShare 与 DominantResourceShare
• 调度公平性

防止单命名空间耗尽集群资源：用 ResourceQuota 限制命名空间总量、LimitRange 限制单容器、节点亲和/taint 隔离、按部门/环境划分命名空间。调度公平性：FairShare（公平分享）按请求的资源比例分配，避免某个命名空间霸占资源；DominantResourceShare（主导资源公平，DRF）基于每个实体相对最占用的资源（主导资源）做公平分配，多资源场景下保证公平。Kubernetes 的 scheduler 通过 PriorityClass、配额、descheduler 等缓解不公平，但真正的多租户公平调度需插件/配额机制。

核心是"配额防耗尽 + DRF 等公平调度算法"。多资源公平用主导资源分配。

• Tiller 移除
• 客户端-服务端模型变化
• 安全与多租户

Helm 2 使用 Tiller（集群内服务端组件），Tiller 拥有集群级权限，存在安全风险（需向 Tiller 授权，多租户难隔离）。Helm 3 移除 Tiller，helm 客户端直接通过 kubeconfig 与 API Server 交互，release 存储在集群的 Secret 中。这带来：1）权限由用户自己的 kubeconfig/RBAC 决定，无需 Tiller 的集群级权限；2）多租户更安全（每个用户用自己的权限，release 按命名空间隔离）；3）无 Tiller 后门，消除 Tiller 攻击面。但 release 信息存 Secret，需注意 Secret 权限。

核心是"移除 Tiller，客户端直接用 kubeconfig + release 存 Secret"。提升安全与多租户隔离。

• chart version
• appVersion
• 升级策略

chart 的 version 是 chart 自身的版本（Chart.yaml 的 version），用于 Helm 依赖解析与 release 版本管理；appVersion 是 chart 打包的应用版本（如应用的镜像版本），提供信息但不强制对应。两者独立：chart 版本变化表示模板/打包变化，appVersion 变化表示应用版本。升级策略：chart 版本用 SemVer，升级时更新 chart version 使依赖能解析；appVersion 用于展示与标记应用版本。升级应用时更新 appVersion 与镜像 tag，升级 chart 逻辑时更新 chart version。

核心是"chart version 管 chart 打包，appVersion 管应用版本"。两者独立。

• 动态生成 RBAC
• 按 values 控制
• 最小权限校验

Helm chart 的 RBAC 模板通过 values 控制生成：如 rbac.create 开关决定是否创建 RBAC，rbac.clusterRole 决定 Role 还是 ClusterRole，rbac.rules 定义规则列表。模板中用 {{- if .Values.rbac.create }} 条件渲染，用 {{- range .Values.rbac.rules }} 生成 rules。最小权限设计：默认只授予 chart 运行所需的最小 verbs/resources，用 values 显式配置，避免授予过高权限。校验：用 kubectl auth can-i 验证、lint 检查，确保 ClusterRole 权限最小。

核心是"values 条件渲染 RBAC + 最小权限规则"。模板条件生成 Role/ClusterRole。

• Helm 特点
• Kustomize 特点
• 选型与混合

Helm 是模板化包管理，擅长打包、版本管理、依赖、回滚、渲染（template），适合分发应用与复杂配置。Kustomize 是原生 Kubernetes 的声明式配置定制（overlay），基于 base 与 patch 叠加，无模板语言，适合流水线精简与 GitOps（kubectl apply -k）。选型：需要分发/版本/依赖用 Helm；需要简单叠加定制用 Kustomize。混合使用：Helm 渲染出 base，再用 Kustomize 叠加环境差异（Helm+kustomize 插件），或用 Kustomize 引用 Helm chart 输出。Argo CD 支持两者结合。

核心是"Helm 模板分发 vs Kustomize 声明式叠加"。可混合使用。

• values 覆盖隔离
• 命名空间 RBAC
• chart 依赖供应链风险

多租户隔离：values 覆盖隔离各租户配置（每租户独立 values 文件/命名空间）；命名空间 RBAC 限制各租户只能访问自己命名空间（Role/RoleBinding），避免跨租户权限；release 按命名空间隔离（Helm 3 release 存命名空间 Secret）。供应链风险：chart 依赖（dependencies）可能引入恶意/过期依赖，需验证 chart 来源（签名、registry 校验）、锁定依赖版本、供应链扫描（镜像与 chart）、避免使用不受信任的 repo。用 helm dependency update 后校验，限制 repo 白名单。

核心是"命名空间隔离 + RBAC 限制 + chart 依赖供应链治理"。多租户需关注依赖可信。

• helm lint 检查
• values schema 校验
• helm template 渲染检查

模板安全：1）helm lint 校验模板语法与最佳实践；2）values.schema.json 定义 values 的 schema（类型、必填、约束），helm install 时校验，防止错误值；3）helm template 渲染检查输出（dry-run），验证渲染结果，防止配置漂移；4）防止模板注入：避免在模板中注入未转义用户输入（使用 quote/ternary 等），限制敏感值；5）CI 中用 lint + schema + template + 渲染对比基线，防止漂移。配置漂移指渲染结果与预期不符，通过校验与基线对比预防。

核心是"lint + schema + template 渲染检查 + 转义防注入"。防止错误配置与漂移。

• crds 目录
• CRD 安装与升级
• 特殊限制

Helm chart 的 crds/ 目录存放 CRD 清单，helm install 时先安装 CRD，helm upgrade 时不会更新 crds/ 中的 CRD（Helm 不管理 CRD 升级，避免破坏已有 CR）。因此 CRD 升级需单独处理：手动 kubectl apply 或依赖 Operator 的 CRD 升级机制。crds/ 的 CRD 不参与 release 生命周期（不随 uninstall 删除）。特殊处理：CRD 变更需手动升级，且需保证与现有 CR 兼容；用 helm show crds 查看。Helm 不负责 CRD 版本迁移。

核心是"crds/ 在 install 时安装，upgrade 不更新 CRD"。CRD 升级需手动。

• ResourceQuota scope
• PriorityClass 配合
• 高优保障

ResourceQuota 的 scope（如 BestEffort、NotBestEffort、PriorityClass）可针对不同 QoS/优先级设置配额。通过 scopeSelector 指定 PriorityClass，可为高优工作负载单独设置配额与保障。例如：无 scope 的配额限制命名空间总量，另一条带 scopeSelector（priorityClassName=high）的配额给高优 Pod 预留资源，防止被低优 Pod 挤占。PriorityClass 配合使高优工作负载在配额内优先保障，避免资源耗尽。

核心是"scopeSelector 按优先级/ QoS 分配额 + 高优预留"。保障高优工作负载。

• helm template
• helm install
• GitOps 集成

GitOps 中，helm template 只渲染清单到 stdout（不触达集群），可作为 GitOps 的渲染步骤，把渲染结果提交/比较，适合 Argo CD 的"渲染并 apply"模式（Argo 用 helm template 或直接管理 release）。helm install 直接安装到集群并管理 release 状态（存储到 Secret）。取舍：GitOps 强调声明式与可审计，常用 helm template 生成清单纳入 Git 或由 Argo CD 渲染；helm install 适合交互式/非 GitOps 管理。Argo CD 支持两种（helm template 渲染或 helm release 跟踪）。模板渲染更可审计，install 便于回滚。

核心是"template 渲染不触集群，install 直接管理 release"。GitOps 常用 template 渲染。

• ChartMuseum/Harbor 搭建
• 推送与拉取
• 权限控制

私有 Helm 仓库可用 ChartMuseum（轻量）或 Harbor（企业级，含镜像/Helm 仓库、RBAC、扫描）。搭建：部署 ChartMuseum 或 Harbor 并配置 Helm 仓库。推送：helm repo add 后用 helm push（或 helm cm-push）上传 chart。拉取：helm repo add myrepo <url> 后 helm install。权限控制：Harbor 支持项目级 RBAC（不同用户对仓库的推送/拉取权限）、LDAP/OIDC 集成、镜像扫描；ChartMuseum 用 basic auth 或 token。企业用 Harbor 做版本管理与权限隔离。

核心是"部署仓库 + helm push/pull + RBAC 权限控制"。Harbor 功能更全。