3. 安装与部署：使用 Helm 安装 Kyverno、配置高可用、验证部署状态
本章聚焦于生产级 Kyverno 部署的完整流程。你将掌握使用 Helm 图表安装 Kyverno、配置高可用模式以及验证集群状态的核心技能。正确的安装与配置是后续策略生效的基础，尤其在高风险变更控制场景中，部署的稳定性直接决定安全基线的可靠性。
3.1 环境准备与 Helm 仓库配置
在安装 Kyverno 之前，请确保你的 Kubernetes 集群满足以下最低要求：
| 组件 | 最低版本 | 说明 |
|---|---|---|
| Kubernetes | v1.26+ | 支持 Validating/MutatingAdmissionPolicy |
| Helm | v3.8+ | 支持 OCI 仓库与依赖管理 |
| 集群资源 | 4 vCPU / 8 GB 内存 | 高可用模式建议 3 节点 |
| 存储类 | 支持 ReadWriteMany | 用于 Webhook 证书持久化（可选） |
添加 Kyverno 官方 Helm 仓库并更新索引：
helm repo add kyverno https://kyverno.github.io/kyverno/
helm repo update3.2 高可用部署配置
Kyverno 的高可用模式通过多副本部署和领导者选举实现。以下配置确保策略评估在任意节点故障时仍能持续运行。
创建自定义 values 文件 kyverno-ha-values.yaml：
replicaCount: 3
podDisruptionBudget:
enabled: true
minAvailable: 2
highAvailability:
enabled: true
replicas: 3
webhooks:
replicas: 3
features:
reports:
enabled: true
replicas: 3
config:
resourceFilters:
- '[Event,*,*]'
- '[*,kube-system,*]'
- '[*,kube-public,*]'
- '[*,kube-node-lease,*]'
extraArgs:
- --autogenInternals=true
- --webhookTimeout=10replicaCount: 3— 核心控制器副本数，保证领导者选举容错podDisruptionBudget.minAvailable: 2— 确保至少 2 个 Pod 可用webhooks.replicas: 3— Webhook 组件独立扩展，避免单点features.reports.replicas: 3— 报告生成器高可用，用于审计日志
执行安装命令：
helm install kyverno kyverno/kyverno \
--namespace kyverno \
--create-namespace \
--values kyverno-ha-values.yaml \
--version 3.2.63.3 部署架构与组件关系
下图展示了 Kyverno 高可用部署的核心组件及其交互关系：
3.4 验证部署状态
安装完成后，执行以下验证步骤确保所有组件正常运行：
- 检查命名空间与 Pod 状态
kubectl get pods -n kyverno -o wide预期输出应显示 3 个 Webhook Pod、3 个 Controller Pod 和 3 个 Report Pod，全部处于 Running 状态。
- 验证 Webhook 注册
kubectl get validatingwebhookconfigurations -l app.kubernetes.io/instance=kyverno
kubectl get mutatingwebhookconfigurations -l app.kubernetes.io/instance=kyverno应返回至少 2 个 Webhook 配置，名称包含 kyverno-resource-validating-webhook 和 kyverno-resource-mutating-webhook。
- 测试策略生效
创建一个简单的测试策略验证准入控制是否正常工作：
cat <尝试创建一个没有 team 标签的命名空间，应被拒绝：
kubectl create ns test-no-label预期返回错误：Error from server: admission webhook "validate.kyverno.svc" denied the request: Namespace must have label 'team'
kyverno-webhook 服务的 Endpoints 是否正常。使用 kubectl get endpoints -n kyverno kyverno-webhook 确认所有 Pod IP 已注册。若 Endpoints 为空，可能是网络策略或 CNI 插件阻止了通信。
3.5 高可用验证与故障模拟
为了验证高可用配置的有效性，建议执行以下故障模拟：
| 测试场景 | 操作步骤 | 预期结果 |
|---|---|---|
| 单 Pod 故障 | kubectl delete pod -n kyverno <pod-name> |
新 Pod 自动重建，策略评估无中断 |
| 节点故障 | 封锁一个节点：kubectl cordon <node> |
Pod 迁移到其他节点，Webhook 持续响应 |
| 领导者选举 | 查看 Controller 日志：kubectl logs -n kyverno -l app.kubernetes.io/name=kyverno --tail=50 |
日志显示领导者选举事件，无重复处理 |
下图展示了高可用模式下领导者选举的流程：
3.6 升级与回滚策略
在生产环境中，升级 Kyverno 需要遵循以下步骤以确保策略连续性：
- 备份当前配置
kubectl get clusterpolicy -o yaml > cluster-policies-backup.yaml
helm get values kyverno -n kyverno > values-backup.yaml- 执行升级
helm upgrade kyverno kyverno/kyverno \
--namespace kyverno \
--values kyverno-ha-values.yaml \
--version 3.3.0- 回滚操作
helm rollback kyverno 1 -n kyverno- 升级前检查 Changelog 中的 API 变更，避免策略语法不兼容
- 先在非生产环境验证升级流程
- 升级期间 Webhook 可能短暂不可用，建议在维护窗口执行
- 保留至少 2 个历史版本：
helm history kyverno -n kyverno
3.7 监控与告警配置
为保障 Kyverno 高可用部署的持续健康，建议集成以下监控指标：
| 指标名称 | 类型 | 告警阈值 | 说明 |
|---|---|---|---|
kyverno_admission_requests_total |
Counter | 突增 > 500% | 检测异常流量 |
kyverno_admission_webhook_latency_seconds |
Histogram | P99 > 5s | Webhook 响应延迟 |
kyverno_controller_leader_election_status |
Gauge | 值 != 1 | 领导者选举异常 |
kyverno_policy_rule_info_total |
Gauge | 突降 > 50% | 策略规则丢失 |
使用 Prometheus Operator 的 ServiceMonitor 自动发现 Kyverno 指标端点：
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: kyverno-monitor
namespace: kyverno
spec:
selector:
matchLabels:
app.kubernetes.io/instance: kyverno
endpoints:
- port: metrics
interval: 30s- 确认所有 Pod 的
ready状态为1/1 - 验证 Webhook 证书未过期：
kubectl get secret -n kyverno kyverno-webhook-certs -o jsonpath='{.data.tls\.crt}' | base64 -d | openssl x509 -noout -dates - 测试策略执行延迟是否在预期范围内
- 确认日志无持续错误：
kubectl logs -n kyverno -l app.kubernetes.io/name=kyverno --tail=100 | grep -i error
至此，你已经完成了 Kyverno 的高可用部署与验证。下一阶段将进入策略编写与安全基线覆盖的实战内容。