2. OPA 部署模式：Sidecar、独立服务与 Admission Controller 集成

在云原生与灾备合规场景中，OPA（Open Policy Agent）的部署模式直接决定了策略执行的延迟、可用性、审计链路完整性以及集群资源的占用。本章从灾备合规视角出发，系统对比三种主流部署模式：Sidecar 模式、独立服务模式以及Admission Controller 集成模式，并给出每种模式在镜像拉取安全扫描与灾备合规配置中的适用建议。

2.1 三种部署模式概述

2.2 Sidecar 模式：本地策略执行与灾备隔离

Sidecar 模式将 OPA 作为独立容器与业务容器部署在同一个 Pod 中。OPA 通过本地 Unix Socket 或 localhost 端口提供服务，业务容器在拉取镜像前调用 OPA 进行策略评估。

• 优点：策略执行延迟极低（本地调用）；故障域隔离（单个 Pod 的 OPA 故障不影响其他 Pod）；适合边缘节点或离线灾备场景。
• 缺点：策略更新需要重新注入或热加载；每个 Pod 额外消耗资源（约 20-50MB 内存）；策略审计日志分散在各 Pod 中，需额外采集。
• 灾备合规适配：在灾备站点，Sidecar 可缓存策略 Bundle，即使控制面中断也能继续执行本地策略。

# OPA Sidecar 注入示例（使用 annotation 触发）
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-with-opa
  annotations:
    sidecar.opapolicy.io/inject: "true"
spec:
  template:
    spec:
      containers:
      - name: app
        image: myapp:latest
      - name: opa-sidecar
        image: openpolicyagent/opa:latest
        args:
          - "run"
          - "--server"
          - "--addr=localhost:8181"
          - "--bundle=/bundle"
        volumeMounts:
        - name: opa-bundle
          mountPath: /bundle
      volumes:
      - name: opa-bundle
        configMap:
          name: opa-policies

2.3 独立服务模式：集中策略管理与灾备切换

独立服务模式将 OPA 部署为集群内的独立 Service，所有需要策略评估的组件（如 CI/CD 流水线、镜像扫描器、Kubelet）通过 REST API 调用 OPA。该模式天然支持多副本与负载均衡，适合灾备场景下的流量切换。

• 优点：策略集中管理，审计日志统一输出；支持水平扩展（HPA）；灾备切换只需修改 DNS 或 Service 端点。
• 缺点：增加网络延迟（通常 <5ms）；OPA 服务故障会影响所有依赖方；需要额外的服务发现与健康检查。
• 灾备合规适配：可部署主备两套 OPA 服务，通过 Global Load Balancer 实现跨集群策略执行。

# OPA 独立服务 Deployment 示例
apiVersion: apps/v1
kind: Deployment
metadata:
  name: opa-server
  labels:
    app: opa
spec:
  replicas: 3
  selector:
    matchLabels:
      app: opa
  template:
    metadata:
      labels:
        app: opa
    spec:
      containers:
      - name: opa
        image: openpolicyagent/opa:latest
        args:
          - "run"
          - "--server"
          - "--addr=:8181"
          - "--log-level=info"
          - "--log-format=json"
        ports:
        - containerPort: 8181
        readinessProbe:
          httpGet:
            path: /health
            port: 8181
---
apiVersion: v1
kind: Service
metadata:
  name: opa-service
spec:
  selector:
    app: opa
  ports:
  - port: 8181
    targetPort: 8181

2.4 Admission Controller 集成：原生强制准入

OPA 通过 ValidatingAdmissionWebhook 或 MutatingAdmissionWebhook 与 Kubernetes API Server 集成。当创建、更新或删除资源时，API Server 将请求发送给 OPA 进行评估，只有通过策略的资源才会被持久化。这是镜像拉取安全扫描中最关键的强制点。

• 优点：原生拦截所有资源变更，无法绕过；策略失败直接拒绝请求，保证合规；审计日志与 API Server 审计集成。
• 缺点：Webhook 延迟会影响集群整体响应；OPA 故障可能导致整个集群不可用（需配置 failurePolicy）；证书管理与 Webhook 配置较复杂。
• 灾备合规适配：必须配置 failurePolicy: Fail 或 Ignore 的灾备策略；建议部署多副本 OPA 并启用 readinessGate。

# OPA Admission Controller Webhook 配置示例
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: opa-validating-webhook
webhooks:
- name: opa.admission.example.com
  clientConfig:
    service:
      name: opa-service
      namespace: opa
      path: /v1/admit
    caBundle: <base64-encoded-ca-cert>
  rules:
  - operations: ["CREATE", "UPDATE"]
    apiGroups: ["*"]
    apiVersions: ["*"]
    resources: ["pods", "deployments"]
  failurePolicy: Fail
  sideEffects: None
  admissionReviewVersions: ["v1"]

2.5 三种模式对比与选型建议

2.6 镜像拉取安全扫描中的部署模式选择

在镜像拉取安全扫描的灾备合规配置中，三种模式各有侧重：

• Admission Controller 模式：在 Pod 创建时拦截，调用镜像扫描服务（如 Trivy、Clair）检查镜像漏洞与签名，未通过则拒绝创建。这是最推荐的强制准入方式。
• Sidecar 模式：在 Pod 启动后，Sidecar 容器先于业务容器启动，执行镜像完整性校验与运行时策略检查。适合需要离线策略执行的灾备场景。
• 独立服务模式：作为镜像扫描策略的决策中心，接收来自 CI/CD、Kubelet 或 Admission Controller 的查询请求，返回策略评估结果。