3. 安装与部署:使用Helm安装Kyverno、配置高可用、验证安装状态
本章聚焦于在生产环境中使用 Helm 包管理器安装 Kyverno,配置其高可用模式,并完成安装后的状态验证。正确的部署是后续策略审计与合规巡检的基础,尤其在高可用配置上,需要确保策略引擎在控制面节点故障时仍能持续提供服务。
3.1 环境准备与前置检查
在安装 Kyverno 之前,请确认集群满足以下最低要求。不满足条件的集群可能导致安装失败或运行时异常。
| 检查项 | 最低要求 | 推荐生产环境 |
|---|---|---|
| Kubernetes 版本 | v1.24+ | v1.28+ |
| Helm 版本 | v3.8+ | v3.14+ |
| 可用节点数 | 1 个 worker 节点 | 3 个以上 worker 节点 |
| 集群 DNS | CoreDNS 正常运行 | CoreDNS 高可用 |
| 存储后端(高可用模式) | 不要求 | 支持 ReadWriteMany 的 PV |
helm 客户端并配置了正确的 kubeconfig 上下文。建议在专用的运维节点或跳板机上执行安装命令。
3.2 使用 Helm 安装 Kyverno
Kyverno 官方维护的 Helm Chart 位于 kyverno/kyverno 仓库。推荐的做法是先添加仓库,再使用自定义 values 文件进行安装,以便后续升级和配置管理。
3.2.1 添加 Helm 仓库
helm repo add kyverno https://kyverno.github.io/kyverno/
helm repo update
3.2.2 创建自定义 values 文件
创建一个名为 kyverno-values.yaml 的文件,用于覆盖默认配置。以下是一个面向生产环境的基准配置,包含了高可用和资源限制的关键参数。
# kyverno-values.yaml
replicaCount: 3
podDisruptionBudget:
enabled: true
minAvailable: 2
resources:
limits:
cpu: 1000m
memory: 1Gi
requests:
cpu: 500m
memory: 512Mi
serviceMonitor:
enabled: true
namespace: monitoring
webhooks:
failurePolicy: Fail
config:
resourceFilters:
- '[Event,*,*]'
- '[*,kube-system,*]'
- '[*,kube-public,*]'
- '[*,kube-node-lease,*]'
- '[Node,*,*]'
replicaCount: 3:启动 3 个副本,实现高可用。podDisruptionBudget:确保在节点维护期间至少保留 2 个 Pod 可用。webhooks.failurePolicy: Fail:当 Kyverno 不可用时,阻止资源创建,避免绕过策略。config.resourceFilters:排除系统命名空间和事件,减少不必要的 Webhook 调用。
3.2.3 执行安装命令
helm install kyverno kyverno/kyverno \
--namespace kyverno \
--create-namespace \
--values kyverno-values.yaml \
--wait
安装完成后,Helm 会输出一条成功消息。使用 --wait 参数会等待所有 Pod 进入 Ready 状态后再返回。
3.3 配置高可用架构
Kyverno 的高可用部署主要依赖多副本、Pod 反亲和性以及可选的持久化存储。下图展示了 3 副本 Kyverno 在集群中的部署拓扑。
3.3.1 启用 Pod 反亲和性
为了将 Pod 分散到不同节点,可以在 values 文件中添加反亲和性配置:
affinity:
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 100
podAffinityTerm:
labelSelector:
matchExpressions:
- key: app.kubernetes.io/name
operator: In
values:
- kyverno
topologyKey: kubernetes.io/hostname
3.3.2 配置持久化存储(可选)
对于需要持久化 Webhook 配置的场景,可以启用 PVC:
persistence:
enabled: true
storageClass: "nfs-client"
accessMode: ReadWriteMany
size: 1Gi
persistence.enabled 设置为 false。Kyverno 在无持久化存储时仍可正常工作,但重启后 Webhook 配置会重新从 API Server 同步。
3.4 验证安装状态
安装完成后,需要从多个维度验证 Kyverno 是否正常运行。以下是一套完整的验证流程。
3.4.1 检查 Pod 状态
kubectl get pods -n kyverno -o wide
预期输出应显示 3 个 kyverno Pod 处于 Running 状态,且分布在不同的节点上。
3.4.2 检查 Service 与 Endpoints
kubectl get svc -n kyverno
kubectl get endpoints -n kyverno
确认 kyverno-svc 的 Endpoints 列表包含所有 3 个 Pod 的 IP 地址。
3.4.3 检查 Webhook 配置
kubectl get validatingwebhookconfigurations -l webhook.kyverno.io/managed-by=kyverno
kubectl get mutatingwebhookconfigurations -l webhook.kyverno.io/managed-by=kyverno
应返回至少一个 ValidatingWebhookConfiguration 和一个 MutatingWebhookConfiguration。
3.4.4 验证策略引擎响应
创建一个测试命名空间并应用一条简单的策略,验证 Kyverno 是否能够正确拦截和响应:
kubectl create ns test-kyverno
cat <
如果策略状态显示 READY: true,说明 Kyverno 引擎正常工作。
3.4.5 检查高可用故障转移
模拟一个节点故障,验证 Kyverno 是否能够自动恢复:
# 选择一个 Kyverno Pod 所在的节点
NODE=$(kubectl get pod -n kyverno -o jsonpath='{.items[0].spec.nodeName}')
echo "Cordoning node: $NODE"
kubectl cordon $NODE
# 删除该节点上的 Kyverno Pod
POD=$(kubectl get pod -n kyverno -o jsonpath='{.items[0].metadata.name}')
kubectl delete pod -n kyverno $POD --grace-period=0 --force
# 等待新 Pod 调度到其他节点
sleep 30
kubectl get pods -n kyverno -o wide
# 恢复节点
kubectl uncordon $NODE
在故障转移过程中,Kyverno 的 Webhook 服务不应中断。可以通过持续创建资源来验证服务的连续性。
3.5 安装后配置清单
以下清单总结了安装完成后需要确认的配置项,建议将其作为运维交接的检查点。
| 检查项 | 预期状态 | 验证命令 |
|---|---|---|
| Pod 副本数 | 3/3 Running | kubectl get pods -n kyverno |
| Pod 分布 | 分布在 ≥2 个节点 | kubectl get pods -n kyverno -o wide |
| Service Endpoints | 3 个 Endpoints | kubectl get endpoints -n kyverno |
| Webhook 配置 | Validating + Mutating 各 ≥1 | kubectl get validatingwebhookconfigurations |
| 策略引擎状态 | ClusterPolicy READY: true | kubectl get clusterpolicy |
| PodDisruptionBudget | minAvailable: 2 | kubectl get pdb -n kyverno |