大家好！这是Kyverno大师指南的第三部分，致力于Kubernetes的安全和运营稳定性。🛡️
上次我们简要介绍了使用Helm进行基本安装和values.yaml优化的皮毛。今天，我们将深入探讨在生产环境(Production)中绝不能忽视的最重要主题：“Kyverno高可用性(HA)配置和资源分配策略”。🚀
Kyverno不仅仅是一个简单的工具，它是集群的“网关”。您知道吗，如果这个网关崩溃，整个集群可能会瘫痪？只需投入10分钟，就能让您的集群拥有铜墙铁壁般的防御！
🏗️ 1. 为什么Kyverno必须具备高可用性(HA)？
Kyverno作为Kubernetes的Admission Webhook运行。这意味着什么？
当用户执行kubectl apply时，API服务器会询问Kyverno：“我可以部署这个吗？”如果此时Kyverno Pod宕机或无法响应，会发生什么？
- 在Fail Close设置下： 为安全起见，所有资源创建都将被阻止。（服务无法部署！🔥）
- 在Fail Open设置下： 资源将在没有安全检查的情况下部署，使集群面临风险。
因此，部署多个Kyverno实例以实现HA（高可用性）配置不是一个选项，而是必需的。
👥 2. 副本配置策略：3的法则
在生产环境中，建议至少配置3个副本。
为什么是3个而不是2个？ 🧐
- 升级期间的可用性： 在更新一个副本时，如果另一个副本出现问题，必须保留最后一个备用。
- 维持法定人数(Quorum)： 在分布式系统中，奇数个副本有利于实现稳定的共识和负载均衡。
values.yaml 配置示例：
YAML
replicaCount: 3📍 3. Pod 分散策略：“不要把所有鸡蛋放在一个篮子里”
如果您部署了3个副本，但恰好这3个副本都部署在同一个工作节点(Node)上，会怎样？一旦该节点宕机，Kyverno也将全军覆没。为了防止这种情况，您必须使用Topology Spread Constraints。
- 目标： 将Kyverno Pod分散到不同的节点，甚至不同的可用区(AZ)！
- 效果： 即使特定节点或区域发生故障，服务也能保持运行。
values.yaml 配置示例：
YAML
topologySpreadConstraints:
- maxSkew: 1
topologyKey: kubernetes.io/hostname
whenUnsatisfiable: DoNotSchedule
labelSelector:
matchLabels:
app.kubernetes.io/instance: kyverno⚡ 4. 资源分配(Resource Allocation)：“既不要饿着，也不要让它暴饮暴食”
Kyverno会拦截并检查集群中的所有API请求。随着集群规模的扩大，Kyverno使用的CPU和内存也会增加。
① Requests & Limits 设置 🔋
您需要为Kyverno提供稳定的运行空间。
- CPU： 策略检查时计算密集，设置过低会导致API响应速度变慢。（延迟增加）
- Memory： 集群中的资源越多，Kyverno用于缓存的内存就越多。请预留充足的内存，以避免成为OOM（内存不足）杀手的目标。
② 实际推荐配置（针对中小型集群）
YAML
admissionController:
container:
resources:
requests:
cpu: 100m
memory: 256Mi
limits:
cpu: 500m
memory: 512Mi提示：对于大型集群，应考虑将内存增加到1Gi或更多。
🛡️ 5. 安全机制：PDB (Pod Disruption Budget)
在集群维护或节点更换操作期间，Kubernetes会将Pod迁移到其他节点（驱逐）。为了防止Kyverno Pods同时全部终止的灾难性情况，需要设置PDB。
- 功能： 强制执行“在任何情况下，Kyverno Pod必须至少有N个以上处于运行状态！”的规则。
values.yaml 配置示例：
YAML
podDisruptionBudget:
minAvailable: 1 # 至少保留一个！🚦 6. Webhook 超时调整
此设置决定了API服务器将等待Kyverno响应多长时间。
- 太短： 在网络延迟时，正常的请求也可能被拒绝。
- 太长： 如果Kyverno出现问题，整个集群的API响应会变慢，导致用户感到沮丧。
通常，15秒左右是最合适的折衷方案。
💾 附录：生产环境的综合values.yaml示例
这是一个实用的配置文件，它整合了上面讨论的所有设置：高可用性(HA)、资源分配、分散策略和PDB。将其保存为my-values.yaml并使用。
YAML
# =========================================================
# Kyverno 生产就绪配置
# =========================================================
# 1. 副本配置 (确保高可用性)
replicaCount: 3
# 2. Pod中断预算 (确保维护期间的可用性)
podDisruptionBudget:
minAvailable: 1
# 3. Pod 分散策略 (应对节点故障)
# 物理分散Pod，防止它们集中在特定节点上。
topologySpreadConstraints:
- maxSkew: 1
topologyKey: kubernetes.io/hostname
whenUnsatisfiable: DoNotSchedule
labelSelector:
matchLabels:
app.kubernetes.io/instance: kyverno
# 4. 资源分配 (性能与稳定性优化)
# 根据集群规模调整以下数值。
admissionController:
container:
resources:
requests:
cpu: 100m
memory: 256Mi
limits:
cpu: 500m
memory: 512Mi
# 5. Webhook 超时和重试设置
# 设置为15秒，以防止因网络延迟导致的误报。
webhook:
timeoutSeconds: 15
# 6. 后台扫描控制器 (监控已部署的资源)
backgroundController:
resources:
requests:
cpu: 50m
memory: 64Mi
limits:
cpu: 200m
memory: 128Mi
# 7. 资源清理控制器 (激活清理策略)
cleanupController:
enabled: true
resources:
requests:
cpu: 50m
memory: 64Mi
# 8. 启用监控
# 如果安装了Prometheus，可以收集指标。
metricsService:
enabled: true🚀 设置应用方法
准备好上述配置文件后，在终端中执行以下命令将其应用到集群。
Bash
# 如果命名空间不存在则创建
kubectl create namespace kyverno --dry-run=client -o yaml | kubectl apply -f -
# 通过Helm安装和更新
helm upgrade --install kyverno kyverno/kyverno
--namespace kyverno
--values my-values.yaml💡 安装后最终检查列表
- [ ] 使用kubectl get pod -n kyverno命令检查3个Pod是否在不同的节点上运行。
- [ ] 使用kubectl get pdb -n kyverno命令检查PDB是否已正确创建。
- [ ] 通过kubectl logs检查Webhook注册过程中是否存在TLS错误。
🔍 安装后验证 – “我的Kyverno真的健康吗？”
Helm安装命令成功并不意味着所有配置都已完美完成。您必须执行以下3项检查，以确保Kyverno作为集群的网关正常运行。
① CRD(Custom Resource Definitions) 确认
Kyverno使用多个自定义资源来定义策略。通过以下命令检查所有Kyverno相关的CRD是否已成功创建。
Bash
kubectl get crd | grep kyverno主要CRD列表：
- clusterpolicies.kyverno.io: 应用于整个集群的策略
- policies.kyverno.io: 应用于特定命名空间的策略
- policyreports.kyverno.io: 记录策略合规性的报告
- admissionreports.kyverno.io: 包含资源创建时检查结果的报告
② Admission Webhook 状态检查 🔗
Kyverno通过Webhook与Kubernetes API服务器通信。如果此连接中断，策略将无法应用。
Bash
# 验证 Mutating Webhook
kubectl get mutatingwebhookconfigurations | grep kyverno
# 验证 Validating Webhook
kubectl get validatingwebhookconfigurations | grep kyverno输出结果应显示类似kyverno-resource-mutating-webhook-cfg的条目，并且AGE应与安装时间一致。
③ 系统组件和可用性确认 🚦
确认在values.yaml中配置的3个副本是否已正确部署到不同的节点并处于Running状态。
Bash
# 检查所有Kyverno相关Pod的状态
kubectl get pods -n kyverno -o wide
# 检查服务状态 (特别是Metrics端口8000)
kubectl get svc -n kyverno使用-o wide选项直接目视确认每个Pod是否部署在不同的NODE上（即是否应用了Topology Spread）非常重要。
🛠️ 故障排除：状态不佳时(NotReady)
如果Pod未处于Running状态或发生Webhook错误，请检查以下日志。
Bash
# 实时查看特定Pod的日志
kubectl logs -f -n kyverno -l app.kubernetes.io/instance=kyverno- 大多数原因： 很可能是由于TLS证书颁发错误、资源分配不足（OOM）或节点间网络通信受阻（安全组/网络策略）造成的。
##
🌟 总结：稳定的安全始于基础设施设计！
将Kyverno配置为高可用性不仅仅是安装一个安全工具，更是设计整个集群稳定性的过程。
- 维护3个或更多副本，
- 通过Topology Spread应对物理故障，以及
- 通过PDB和适当的资源分配确保内部稳定性。
只有打下如此坚实的基础，即使以后添加复杂的策略，集群也不会动摇。💪
希望今天的指南能帮助您愉快地运营Kubernetes！
如有任何疑问，请随时在评论中留言！😊
发表回复