3. Kyverno安装与部署

3.1 部署方式概览与选型对比

Kyverno 作为 Kubernetes 原生的策略引擎，支持多种部署方式。在生产环境中，选择正确的部署策略直接影响到集群的稳定性、策略生效延迟以及运维复杂度。下表对比了三种主流部署方式的核心差异：

3.2 Helm 安装：标准生产流程

Helm 是部署 Kyverno 最推荐的方式。以下步骤适用于 Kubernetes v1.23+ 集群，并已配置好 Helm v3。

3.2.1 添加 Helm 仓库与版本锁定

# 添加 Kyverno 官方 Helm 仓库
helm repo add kyverno https://kyverno.github.io/kyverno/
helm repo update

# 查询可用版本，锁定生产版本
helm search repo kyverno/kyverno --versions --devel | head -5

3.2.2 生产级 values 配置

创建一个专用的 values-production.yaml 文件，覆盖关键参数：

# values-production.yaml
replicaCount: 3
podDisruptionBudget:
  enabled: true
  minAvailable: 2

resources:
  limits:
    cpu: 1000m
    memory: 1Gi
  requests:
    cpu: 500m
    memory: 512Mi

config:
  webhookTimeout: 10
  generateSuccessEvents: false

features:
  reports:
    enabled: true
  policyException:
    enabled: true

serviceMonitor:
  enabled: true
  namespace: monitoring

affinity:
  podAntiAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
    - weight: 100
      podAffinityTerm:
        labelSelector:
          matchExpressions:
          - key: app.kubernetes.io/name
            operator: In
            values:
            - kyverno
        topologyKey: kubernetes.io/hostname

3.2.3 执行安装

helm install kyverno kyverno/kyverno \
  --namespace kyverno \
  --create-namespace \
  --values values-production.yaml \
  --version 3.2.6 \
  --wait

3.3 Kustomize 部署：GitOps 原生集成

对于已经采用 Kustomize 进行资源管理的团队，可以直接从 Kyverno 官方发布的 Kustomize 资源部署。这种方式更易于与 ArgoCD 等 GitOps 工具集成。

3.3.1 基础部署结构

# kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

namespace: kyverno

resources:
- https://github.com/kyverno/kyverno/releases/download/v3.2.6/install.yaml

patches:
# 调整副本数为 3
- target:
    kind: Deployment
    name: kyverno
  patch: |-
    - op: replace
      path: /spec/replicas
      value: 3

# 添加资源限制
- target:
    kind: Deployment
    name: kyverno
  patch: |-
    - op: add
      path: /spec/template/spec/containers/0/resources
      value:
        limits:
          cpu: "1"
          memory: 1Gi
        requests:
          cpu: 500m
          memory: 512Mi

3.3.2 多环境 Overlay 策略

3.4 生产环境最佳实践

以下实践基于多个生产集群的运维经验总结，涵盖资源规划、安全加固与可观测性。

3.4.1 资源规划与限流

• CPU 与内存基线： 每个 Kyverno Pod 至少分配 500m CPU / 512Mi 内存，建议上限为 1 CPU / 1Gi 内存。
• Webhook 超时设置： 默认超时为 10 秒，对于包含复杂 CEL 表达式的策略，建议调整为 15-20 秒。
• 并发请求控制： 通过 --webhookParallelism 参数控制并发处理数，默认 10，高负载集群可调整为 20。

3.4.2 安全加固清单

3.4.3 可观测性集成

Kyverno 原生暴露 Prometheus 指标，建议在 values 中开启 ServiceMonitor：

# 关键指标清单
kyverno_policy_rule_info_total        # 策略规则总数
kyverno_policy_results_total          # 策略执行结果（pass/fail/error）
kyverno_admission_requests_total      # 准入请求总数
kyverno_admission_latency_seconds     # 准入延迟分布

3.5 高可用配置

Kyverno 的高可用设计围绕 多副本 + Pod 反亲和 + PodDisruptionBudget 三个核心维度展开。下图展示了生产环境的高可用部署架构：

3.5.1 关键高可用参数配置

# 高可用核心配置片段
replicaCount: 3
podDisruptionBudget:
  enabled: true
  minAvailable: 2

affinity:
  podAntiAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
    - weight: 100
      podAffinityTerm:
        labelSelector:
          matchExpressions:
          - key: app.kubernetes.io/name
            operator: In
            values:
            - kyverno
        topologyKey: topology.kubernetes.io/zone   # 跨可用区调度

topologySpreadConstraints:
- maxSkew: 1
  topologyKey: kubernetes.io/hostname
  whenUnsatisfiable: DoNotSchedule
  labelSelector:
    matchLabels:
      app.kubernetes.io/name: kyverno

3.5.2 Leader 选举机制

Kyverno 使用 Kubernetes 原生 Leader 选举机制（基于 ConfigMap 或 Lease 对象）来协调多个副本。只有 Leader 副本处理变更请求，其他副本处于热备状态。当 Leader 宕机时，选举会在 15 秒内完成切换，期间 webhook 调用会重试，不会导致策略执行失败。

3.6 部署验证与健康检查

完成部署后，执行以下验证步骤确保系统正常运行：

1. Pod 状态检查： kubectl get pods -n kyverno -o wide，确认所有 Pod 处于 Running 状态且分布在不同的节点。
2. Webhook 注入验证： kubectl get validatingwebhookconfigurations -o yaml | grep "kyverno"，确认 webhook 配置存在且 clientConfig 指向正确的 Service。
3. 策略执行测试： 创建一个测试命名空间并应用一条简单的 disallow-latest-tag 策略，验证 Kyverno 能够正常拦截和允许资源。
4. 指标端点检查： kubectl port-forward -n kyverno svc/kyverno-svc 8000:8000，访问 localhost:8000/metrics 确认 Prometheus 指标正常暴露。