3. 安装与部署：使用 Helm 安装 Kyverno、配置高可用、验证组件运行状态

在生产环境中部署 Kyverno 时，推荐使用 Helm 进行声明式安装，并结合高可用配置确保策略引擎的稳定性。本章将完整演示从 Helm 仓库添加、命名空间创建、高可用参数配置到组件运行状态验证的全流程。

3.1 环境准备与 Helm 仓库配置

在安装 Kyverno 之前，需要确保集群满足以下最低版本要求，并完成 Helm 仓库的添加与更新。

组件	最低版本要求	推荐版本
Kubernetes	1.22	1.27+
Helm	3.8	3.12+
Kyverno	1.9	1.11+

执行以下命令添加 Kyverno 官方 Helm 仓库并更新索引：

helm repo add kyverno https://kyverno.github.io/kyverno/
helm repo update

3.2 使用 Helm 安装 Kyverno（单副本模式）

首先创建一个专用的命名空间 kyverno，然后使用 Helm 安装 Kyverno。以下命令将部署默认配置的单副本实例：

kubectl create namespace kyverno

helm install kyverno kyverno/kyverno \
  --namespace kyverno \
  --create-namespace \
  --version 3.1.0

安装完成后，Kyverno 会创建以下核心资源：

• Deployment/kyverno-admission-controller：准入控制器，处理 AdmissionReview 请求。
• Deployment/kyverno-reports-controller：报告控制器，生成策略执行报告。
• Deployment/kyverno-background-controller：后台控制器，处理定时扫描与清理任务。
• Service/kyverno-svc：准入 Webhook 服务，暴露给 API Server 调用。
• ConfigMap/kyverno：全局配置，包含 Webhook 超时、排除命名空间等参数。

3.3 配置高可用部署

生产环境必须启用高可用模式，避免单点故障导致策略评估中断。高可用部署需要调整副本数、反亲和性策略以及资源配额。

3.3.1 高可用参数清单

参数路径	值	说明
replicaCount	3	每个控制器至少 3 个副本
podAntiAffinity	preferred	优先将 Pod 调度到不同节点
topologySpreadConstraints	maxSkew=1	跨可用区均匀分布
resources.requests.cpu	500m	每个副本 CPU 预留
resources.requests.memory	512Mi	每个副本内存预留
webhookTimeoutSeconds	10	Webhook 超时时间（秒）

3.3.2 使用 values.yaml 部署高可用实例

创建 kyverno-ha-values.yaml 文件，写入以下配置：

replicaCount: 3

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

topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: topology.kubernetes.io/zone
    whenUnsatisfiable: ScheduleAnyway

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

webhookTimeoutSeconds: 10

执行升级安装：

helm upgrade kyverno kyverno/kyverno \
  --namespace kyverno \
  -f kyverno-ha-values.yaml

3.4 验证组件运行状态

安装完成后，需要从多个维度验证 Kyverno 组件是否正常运行。

3.4.1 检查 Pod 状态

kubectl get pods -n kyverno -o wide

预期输出应显示所有 Pod 处于 Running 状态，且 READY 列为 1/1。如果存在 CrashLoopBackOff 或 Pending，请检查资源限制或节点污点。

3.4.2 验证 Webhook 注册

kubectl get validatingwebhookconfigurations -l webhook.kyverno.io/managed-by=kyverno
kubectl get mutatingwebhookconfigurations -l webhook.kyverno.io/managed-by=kyverno

应至少返回两个 Webhook 配置：一个用于验证（Validating），一个用于变更（Mutating）。

3.4.3 检查 Kyverno 日志

kubectl logs -n kyverno -l app.kubernetes.io/name=kyverno --tail=50

日志中不应出现 ERROR 或 FATAL 级别信息。正常启动日志应包含：

• "Starting controller-runtime manager"
• "Registering webhook"
• "Starting informers"

3.4.4 运行快速功能测试

创建一个测试命名空间并应用一条简单的策略，验证准入控制是否生效：

kubectl create ns test-kyverno

cat <<EOF | kubectl apply -f -
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-ns-labels
spec:
  validationFailureAction: Audit
  rules:
    - name: check-labels
      match:
        any:
          - resources:
              kinds:
                - Namespace
      validate:
        message: "Namespace must have label 'purpose'"
        pattern:
          metadata:
            labels:
              purpose: "?*"
EOF

创建不带标签的命名空间，观察 Kyverno 是否生成报告：

kubectl create ns no-label-ns
kubectl get policyreport -A | grep require-ns-labels

如果返回了 fail 或 warn 条目，说明 Kyverno 已成功拦截并评估了该请求。

3.5 组件架构与请求处理流程

下图展示了 Kyverno 三个核心控制器之间的协作关系，以及准入请求的处理路径：

3.6 常见安装问题与排查

问题现象	可能原因	解决方案
Pod 一直处于 Pending 状态	节点资源不足或存在污点	检查 kubectl describe pod 中的 Events，添加 tolerations 或扩容节点
Webhook 注册失败，API Server 报 connection refused	Service 端口未正确暴露或网络策略阻止	确认 kyverno-svc 的 Endpoints 是否就绪，检查 NetworkPolicy
策略评估超时（AdmissionReview 返回 500）	webhookTimeoutSeconds 设置过短或策略规则复杂	增大超时时间至 10-15 秒，优化策略中的 JMESPath 表达式
高可用部署后部分 Pod 调度到同一节点	节点数不足或 podAntiAffinity 未生效	增加节点数，或将 preferred 改为 required