3. 环境准备：Kubernetes集群搭建（Minikube/Kind）、安装Gatekeeper（Helm/YAML）、验证安装状态

本章是课程的基础环境搭建环节。你将完成两阶段操作：首先在本地快速拉起一个Kubernetes集群（Minikube或Kind二选一），然后通过Helm或YAML方式安装OPA Gatekeeper，最后通过一系列验证命令确认集群与Gatekeeper均处于可用状态。所有后续章节的变更门禁策略都将运行在这个环境之上。

3.1 集群搭建：Minikube vs Kind 选型对比

本地开发环境推荐使用Minikube或Kind。两者都能在单机上创建符合CNCF标准的Kubernetes集群，但在资源消耗、启动速度、网络模型和适用场景上存在差异。下表从关键维度进行对比，帮助你根据自身硬件条件做出选择。

对比维度 Minikube Kind (Kubernetes in Docker)
底层技术 虚拟机（Hypervisor）或Docker驱动 Docker容器作为节点
启动速度 较慢（约2-5分钟，依赖镜像拉取） 较快（约30秒-2分钟）
资源占用 较高（默认2核CPU、2GB内存） 较低（默认共享宿主机内核）
网络模型 独立IP，LoadBalancer支持较好 节点共享宿主机网络，需额外端口映射
持久化存储 内置CSI驱动，支持PV/PVC 需手动配置hostPath或local卷
适用场景 完整功能测试、Ingress/LB验证 CI/CD流水线、快速迭代、资源受限环境
推荐选择：如果你的宿主机内存≥8GB且希望体验更完整的Kubernetes网络特性，选择Minikube；如果主要用于Gatekeeper策略开发和CI集成，且希望启动更快、资源占用更低，选择Kind。本课程后续操作同时兼容两种集群。

3.2 使用Minikube搭建集群

以下步骤以Minikube v1.32+和Docker驱动为例。确保已安装Docker和kubectl。

  1. 启动集群：指定驱动、cri和资源配额。
minikube start \
  --driver=docker \
  --cpus=2 \
  --memory=4096 \
  --kubernetes-version=v1.28.3 \
  --cri=containerd
  1. 验证集群状态：确认节点和核心组件就绪。
kubectl cluster-info
kubectl get nodes -o wide
kubectl get pods -n kube-system
  1. 启用必要插件（可选，用于后续Ingress测试）。
minikube addons enable ingress
minikube addons enable metrics-server

3.3 使用Kind搭建集群

Kind通过YAML配置文件定义集群拓扑。以下配置创建一个包含1个控制平面节点和2个工作节点的集群。

  1. 创建配置文件 kind-config.yaml：
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
  - role: control-plane
    extraPortMappings:
      - containerPort: 30080
        hostPort: 30080
  - role: worker
  - role: worker
  1. 创建集群：
kind create cluster --config kind-config.yaml --name gatekeeper-cluster
  1. 验证集群：
kubectl cluster-info --context kind-gatekeeper-cluster
kubectl get nodes
kubectl get pods -A
注意：Kind集群的kubeconfig上下文名称格式为 kind-<集群名称>。后续所有kubectl操作需指定正确的上下文，或通过 kubectl config use-context kind-gatekeeper-cluster 切换。

3.4 安装Gatekeeper：Helm vs YAML 方式

Gatekeeper的安装推荐使用Helm Chart，便于版本管理和参数定制。YAML方式适用于离线环境或需要精确控制资源清单的场景。两种方式的核心步骤对比如下：

安装方式 命令/文件 版本管理 自定义参数 卸载复杂度
Helm helm install gatekeeper gatekeeper/gatekeeper 自动管理Chart版本 通过values.yaml或--set 低（helm uninstall）
YAML kubectl apply -f gatekeeper.yaml 手动管理YAML版本 需手动编辑YAML 中（需删除多个资源）

3.4.1 使用Helm安装（推荐）

  1. 添加Gatekeeper Helm仓库：
helm repo add gatekeeper https://open-policy-agent.github.io/gatekeeper/charts
helm repo update
  1. 安装Gatekeeper（指定命名空间和版本）：
helm install gatekeeper gatekeeper/gatekeeper \
  --namespace gatekeeper-system \
  --create-namespace \
  --version 3.16.0 \
  --set replicas=1 \
  --set auditInterval=60
  1. 验证Helm Release状态：
helm list -n gatekeeper-system
helm status gatekeeper -n gatekeeper-system

3.4.2 使用YAML安装（备选）

  1. 下载最新Gatekeeper部署YAML：
curl -sL https://raw.githubusercontent.com/open-policy-agent/gatekeeper/v3.16.0/deploy/gatekeeper.yaml -o gatekeeper.yaml
  1. 应用YAML到集群：
kubectl apply -f gatekeeper.yaml
  1. 确认资源创建：
kubectl get all -n gatekeeper-system
kubectl get crd | grep gatekeeper

3.5 验证安装状态

安装完成后，必须执行以下四步验证，确保Gatekeeper的核心组件正常运行、API资源已注册、Webhook配置生效、以及审计功能可用。

验证清单：
  • Pod状态：所有Pod处于Running状态，且就绪探针通过。
  • CRD注册：至少包含 constrainttemplates、constraints、providers 等核心CRD。
  • Webhook配置：ValidatingWebhookConfiguration和MutatingWebhookConfiguration已创建。
  • 审计端点：Gatekeeper审计Pod能够正常访问并输出审计结果。

3.5.1 验证Pod与Service

kubectl get pods -n gatekeeper-system -o wide
kubectl get svc -n gatekeeper-system
kubectl describe pod -n gatekeeper-system -l app=gatekeeper

预期输出：gatekeeper-controller-manager Pod的READY列为1/1，STATUS为Running；gatekeeper-audit Pod同样处于Running状态。

3.5.2 验证CRD与Webhook

kubectl get crd | grep gatekeeper.sh
kubectl get validatingwebhookconfiguration gatekeeper-validating-webhook-configuration -o yaml | head -20
kubectl get mutatingwebhookconfiguration gatekeeper-mutating-webhook-configuration -o yaml | head -20

核心CRD列表应包含：

  • assign.mutations.gatekeeper.sh
  • assignmetadata.mutations.gatekeeper.sh
  • constrainttemplates.templates.gatekeeper.sh
  • constraints.constraints.gatekeeper.sh
  • providers.externaldata.gatekeeper.sh

3.5.3 验证审计功能

Gatekeeper默认每60秒执行一次集群审计。通过查看审计Pod日志确认其正常工作：

AUDIT_POD=$(kubectl get pod -n gatekeeper-system -l app=gatekeeper-audit -o jsonpath='{.items[0].metadata.name}')
kubectl logs -n gatekeeper-system $AUDIT_POD --tail=20

日志中应包含类似 audit process completed 或 violations found: 0 的信息，表明审计循环已启动。

3.6 环境准备总览图

下图展示了从宿主机到Gatekeeper完整部署的组件关系与数据流。你可以将此图作为后续章节的参考拓扑。

环境准备总览：宿主机 → Kubernetes集群 → Gatekeeper 宿主机（Docker / Hypervisor） Minikube 或 Kind 进程 CPU: 2核 | 内存: 4GB | 磁盘: 20GB Kubernetes 集群（v1.28） 控制平面 kube-apiserver etcd / scheduler Worker 节点 1 kubelet kube-proxy Worker 节点 2 kubelet kube-proxy OPA Gatekeeper（v3.16.0） Controller Manager Webhook 处理 约束缓存 Audit 周期性集群审计 违规报告 CRD / Webhook ConstraintTemplate ValidatingWebhook 说明：宿主机通过Docker驱动运行Minikube或Kind，集群内部署Gatekeeper的三个核心组件，共同构成变更门禁的基础设施。

3.7 环境就绪检查清单

完成上述所有步骤后，请逐项核对以下清单，确保环境100%就绪：

检查项 验证命令 预期结果
集群节点状态 kubectl get nodes 所有节点状态为 Ready
Gatekeeper命名空间 kubectl get ns gatekeeper-system 命名空间存在且状态 Active
Gatekeeper Pod kubectl get pods -n gatekeeper-system controller-manager 和 audit Pod 均为 Running
核心CRD kubectl get crd | grep gatekeeper.sh 至少包含 constrainttemplates 和 constraints
Webhook配置 kubectl get validatingwebhookconfiguration gatekeeper-validating-webhook-configuration 存在
审计日志 kubectl logs -n gatekeeper-system <audit-pod> 包含 audit process completed 信息
下一步提示：环境就绪后，你将在第4章学习如何编写第一条ConstraintTemplate，并创建约束来拒绝特权容器。建议保留当前终端窗口，后续操作将直接复用此集群。
← 上一章 📖 返回目录 下一章 →