4. 环境搭建：Kubernetes集群准备、Helm安装Gatekeeper、验证部署状态

本章聚焦于从零搭建 OPA Gatekeeper 策略引擎的运行环境。我们将依次完成 Kubernetes 集群的快速准备、使用 Helm 包管理器安装 Gatekeeper，以及通过多种手段验证部署状态。一个稳定、可复现的环境是后续策略开发与基线核验的基础。

4.1 环境概览与前置条件

在开始操作前，请确保满足以下最低资源要求与工具版本。本课程所有操作均基于以下已验证的环境组合。

4.2 Kubernetes 集群快速准备

我们使用 kind 创建一个包含 1 个控制平面节点和 2 个工作节点的集群。以下配置启用了必要的 API 特性门控，确保 Gatekeeper 的 Webhook 正常工作。

# 1. 创建 kind 配置文件：kind-config.yaml
cat <<EOF > kind-config.yaml
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
  - role: control-plane
  - role: worker
  - role: worker
EOF

# 2. 创建集群
kind create cluster --name gatekeeper-demo --config kind-config.yaml

# 3. 验证集群状态
kubectl cluster-info --context kind-gatekeeper-demo
kubectl get nodes -o wide

集群就绪后，确认 kubectl 上下文已正确切换至新集群。输出应显示三个节点均为 Ready 状态。

4.3 使用 Helm 安装 Gatekeeper

Helm 是部署 Gatekeeper 最推荐的方式。它自动处理 CRD 安装、组件依赖和版本管理。我们使用官方 Chart 仓库进行安装。

4.3.1 添加 Helm 仓库并更新

# 添加 Gatekeeper 官方 Helm 仓库
helm repo add gatekeeper https://open-policy-agent.github.io/gatekeeper/charts

# 更新本地仓库索引
helm repo update

4.3.2 安装 Gatekeeper

以下命令将 Gatekeeper 安装至 gatekeeper-system 命名空间，并启用审计与 Webhook 组件。

# 安装 Gatekeeper
helm install gatekeeper gatekeeper/gatekeeper \
    --namespace gatekeeper-system \
    --create-namespace \
    --set auditInterval=60 \
    --set logLevel=INFO \
    --set replicas=2

# 查看安装状态
helm status gatekeeper -n gatekeeper-system

4.4 验证部署状态

安装完成后，需要从 Pod、Service、Webhook 和 CRD 四个维度验证 Gatekeeper 是否正常运行。

4.4.1 检查 Pod 与 Service

# 查看所有 Pod 是否 Running
kubectl get pods -n gatekeeper-system -o wide

# 查看 Service 与 Endpoints
kubectl get svc -n gatekeeper-system
kubectl get endpoints -n gatekeeper-system

预期输出应包含 gatekeeper-audit 和 gatekeeper-controller-manager 两类 Pod，且所有 Pod 的 STATUS 为 Running。Service 应暴露 gatekeeper-webhook-service 的 443 端口。

4.4.2 检查 ValidatingWebhookConfiguration

# 查看 Webhook 配置
kubectl get validatingwebhookconfiguration gatekeeper-validating-webhook-configuration -o yaml

确认 Webhook 配置中 clientConfig.service 指向正确的命名空间和 Service 名称，且 rules 包含需要拦截的资源操作（如 CREATE、UPDATE）。

4.4.3 检查 CRD 是否就绪

# 列出所有 Gatekeeper 相关的 CRD
kubectl get crd | grep gatekeeper.sh

核心 CRD 包括：

• constrainttemplates.gatekeeper.sh：定义策略模板。
• constraints.gatekeeper.sh：定义具体策略实例。
• providers.gatekeeper.sh：外部数据提供者（可选）。

所有 CRD 应处于 ESTABLISHED 状态。

4.5 部署架构与组件关系

下图展示了 Gatekeeper 在 Kubernetes 集群中的核心组件及其交互关系。理解此架构有助于后续策略调试与故障排查。

4.6 快速健康检查脚本

以下脚本可用于一键验证 Gatekeeper 部署状态，适合集成到 CI/CD 或日常巡检中。

#!/bin/bash
# gatekeeper-healthcheck.sh

NAMESPACE="gatekeeper-system"
EXPECTED_PODS=3  # 根据 replicas 调整

echo "=== Gatekeeper 健康检查 ==="

# 1. 检查命名空间是否存在
kubectl get namespace $NAMESPACE &>/dev/null
if [ $? -ne 0 ]; then
    echo "[FAIL] 命名空间 $NAMESPACE 不存在"
    exit 1
fi
echo "[PASS] 命名空间 $NAMESPACE 存在"

# 2. 检查所有 Pod 是否 Running
RUNNING_PODS=$(kubectl get pods -n $NAMESPACE --field-selector=status.phase=Running --no-headers | wc -l)
if [ "$RUNNING_PODS" -lt "$EXPECTED_PODS" ]; then
    echo "[FAIL] 预期 $EXPECTED_PODS 个 Running Pod，实际 $RUNNING_PODS"
    kubectl get pods -n $NAMESPACE
    exit 1
fi
echo "[PASS] 所有 Pod 处于 Running 状态 ($RUNNING_PODS)"

# 3. 检查 Webhook Service 是否存在
kubectl get svc gatekeeper-webhook-service -n $NAMESPACE &>/dev/null
if [ $? -ne 0 ]; then
    echo "[FAIL] Webhook Service 不存在"
    exit 1
fi
echo "[PASS] Webhook Service 存在"

# 4. 检查核心 CRD
for crd in constrainttemplates.gatekeeper.sh constraints.gatekeeper.sh; do
    kubectl get crd $crd &>/dev/null
    if [ $? -ne 0 ]; then
        echo "[FAIL] CRD $crd 未就绪"
        exit 1
    fi
done
echo "[PASS] 核心 CRD 已就绪"

echo "=== Gatekeeper 部署健康 ==="

4.7 环境验证总结

完成以上步骤后，你的 Kubernetes 集群已具备运行 OPA Gatekeeper 策略引擎的完整能力。下表总结了各组件验证的关键指标。

环境搭建完成后，下一阶段将进入策略模板开发与基线核验规则的编写。确保当前环境稳定可靠，是后续所有策略实验的前提。