3. 环境准备：Kubernetes集群搭建与Kyverno安装
本章是课程实战的基石。我们将使用 Kind（Kubernetes in Docker）快速搭建本地集群，并通过 Helm 安装 Kyverno，最后验证所有核心组件的运行状态。这套环境将贯穿后续所有策略编写与基线核验实验。
3.1 环境概览与工具选型
为降低学习门槛并保证实验可重复性，我们选择以下工具链：
| 组件 | 版本建议 | 用途 |
|---|---|---|
| Docker | 24.x+ | 容器运行时，Kind 依赖 |
| Kind | v0.20+ | 本地 Kubernetes 集群（节点以容器运行） |
| kubectl | 匹配集群版本 | 与集群交互的命令行工具 |
| Helm | v3.12+ | Kubernetes 包管理器，用于安装 Kyverno |
| Kyverno | v1.11+ | Kubernetes 原生策略引擎 |
选型理由： Kind 相比 Minikube 启动更快、资源占用更低，且支持多节点集群模拟，适合 CI/CD 环境下的策略验证。Helm 则提供了声明式的 Kyverno 安装与升级方式。
3.2 搭建 Kind 集群
首先，确保 Docker 已安装并运行。然后创建一个包含 1 个控制平面节点 + 2 个 Worker 节点 的集群，以模拟生产环境的多节点拓扑。
步骤 1：创建集群配置文件
cat <<EOF | kind create cluster --name kyverno-demo --config=-
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
- role: worker
- role: worker
EOF步骤 2：验证集群状态
kubectl cluster-info --context kind-kyverno-demo
kubectl get nodes -o wide预期输出应显示 3 个节点均为 Ready 状态，且 Kubernetes 版本一致。
常见问题： 如果节点长时间处于
NotReady 状态，请检查 Docker 资源限制（建议分配 4GB+ 内存）或重新拉取 Kind 镜像。
3.3 安装 Kyverno
Kyverno 作为 Admission Webhook 运行，推荐使用 Helm 安装以简化配置管理。以下是两种安装方式对比：
| 安装方式 | 优点 | 适用场景 |
|---|---|---|
| Helm Chart | 参数化配置、版本管理、一键升级 | 生产环境、持续交付 |
| YAML 清单 | 无依赖、离线部署 | 离线环境、快速验证 |
使用 Helm 安装（推荐）：
# 添加 Kyverno Helm 仓库
helm repo add kyverno https://kyverno.github.io/kyverno/
helm repo update
# 安装 Kyverno 到 kyverno 命名空间
helm install kyverno kyverno/kyverno \
--namespace kyverno \
--create-namespace \
--set admissionController.replicas=2 \
--set backgroundController.replicas=1 \
--set cleanupController.replicas=1
注意： 生产环境建议将
admissionController.replicas 设置为至少 2 以保证高可用。本地实验环境可保持默认值 1 以节省资源。
3.4 验证安装状态与核心组件
安装完成后，需要验证以下三个关键维度：
- Pod 运行状态 — 所有控制器 Pod 应处于
Running状态 - Webhook 注册 — MutatingWebhookConfiguration 和 ValidatingWebhookConfiguration 已创建
- CRD 可用性 — ClusterPolicy / Policy 等自定义资源已注册
验证命令：
# 1. 检查 Pod
kubectl get pods -n kyverno
# 2. 检查 Webhook
kubectl get mutatingwebhookconfiguration -l webhook.kyverno.io/managed-by=kyverno
kubectl get validatingwebhookconfiguration -l webhook.kyverno.io/managed-by=kyverno
# 3. 检查 CRD
kubectl get crd | grep kyverno预期输出应包含以下核心组件：
| 组件名称 | Pod 数量 | 功能描述 |
|---|---|---|
| kyverno-admission-controller | 2 | 处理资源创建/更新时的策略准入检查 |
| kyverno-background-controller | 1 | 执行后台扫描与周期性策略评估 |
| kyverno-cleanup-controller | 1 | 管理资源清理与 TTL 策略 |
| kyverno-reports-controller | 1 | 生成策略报告与审计日志 |
3.5 快速健康检查脚本
为方便后续章节快速验证环境，建议保存以下健康检查脚本：
#!/bin/bash
# kyverno-healthcheck.sh
echo "=== Kyverno 环境健康检查 ==="
echo -e "\n[1/4] 检查命名空间与 Pod"
kubectl get ns kyverno &>/dev/null || { echo "❌ kyverno 命名空间不存在"; exit 1; }
kubectl get pods -n kyverno | grep -v "Running" | grep -v "NAME" && { echo "❌ 存在非 Running 状态的 Pod"; exit 1; } || echo "✅ 所有 Pod 运行正常"
echo -e "\n[2/4] 检查 Webhook 配置"
kubectl get mutatingwebhookconfiguration -l webhook.kyverno.io/managed-by=kyverno &>/dev/null && echo "✅ MutatingWebhook 已注册" || echo "❌ MutatingWebhook 缺失"
kubectl get validatingwebhookconfiguration -l webhook.kyverno.io/managed-by=kyverno &>/dev/null && echo "✅ ValidatingWebhook 已注册" || echo "❌ ValidatingWebhook 缺失"
echo -e "\n[3/4] 检查 CRD"
kubectl get crd | grep -q "clusterpolicies.kyverno.io" && echo "✅ ClusterPolicy CRD 存在" || echo "❌ ClusterPolicy CRD 缺失"
kubectl get crd | grep -q "policies.kyverno.io" && echo "✅ Policy CRD 存在" || echo "❌ Policy CRD 缺失"
echo -e "\n[4/4] 检查 API 可用性"
kubectl api-resources --api-group=kyverno.io &>/dev/null && echo "✅ Kyverno API 组可用" || echo "❌ Kyverno API 组不可用"
echo -e "\n=== 健康检查完成 ==="
最佳实践： 将上述脚本保存为
kyverno-healthcheck.sh 并赋予执行权限（chmod +x），每次实验前运行一次，确保环境处于干净状态。
3.6 环境清理与重置
当实验完成或需要重置环境时，执行以下命令：
# 卸载 Kyverno（保留 CRD 以便重新安装）
helm uninstall kyverno -n kyverno
# 彻底删除集群
kind delete cluster --name kyverno-demo
# 重新创建集群并安装 Kyverno（按 3.2 和 3.3 步骤重复）