2. 架构设计原则

云原生运行基线的核验架构并非凭空构建，而是建立在四大核心设计原则之上。这些原则共同定义了系统如何描述期望状态、如何保证环境一致性、如何持续纠偏以及如何容忍分布式延迟。理解这些原则，是设计可观测、可自愈、可审计的核验体系的前提。

2.1 不可变基础设施（Immutable Infrastructure）

传统运维中，服务器被视为“可变”的宠物——SSH登录、打补丁、升级包，每次变更都会引入配置漂移。不可变基础设施则要求：任何运行实例一旦部署，就不再修改。更新通过替换整个实例（新镜像、新容器）完成，而非原地修补。

下表总结了可变与不可变模式在核验维度的关键差异：

在核验架构中，不可变基础设施直接简化了“运行时环境一致性”的校验逻辑。核验器只需维护一份黄金镜像清单，并定期比对集群中所有 Pod 的镜像 SHA256 值是否在清单内。

# 核验伪代码：检查 Pod 镜像是否属于基线清单
baseline_images = {"nginx:1.25-alpine@sha256:abc...", "envoy:1.28@sha256:def..."}
for pod in get_all_running_pods():
    if pod.image not in baseline_images:
        alert("非基线镜像运行中: " + pod.name)

2.2 声明式API（Declarative API）

声明式API要求用户描述期望的最终状态，而非执行步骤。系统负责将当前状态驱动至期望状态。Kubernetes 的 spec 字段就是最典型的声明式设计。

对于核验架构，声明式API提供了两个关键能力：

• 期望状态可审计： 所有基线要求（如“所有容器必须设置 CPU Limit”、“所有 Service 必须启用 mTLS”）都可以建模为 CRD（Custom Resource Definition）对象，存储在 etcd 中，形成不可篡改的审计轨迹。
• 核验逻辑可复用： 核验控制器只需监听这些 CRD 对象，当基线要求变更时，自动触发重新核验，无需手动触发脚本。

以下是一个基线核验 CRD 的声明式示例：

apiVersion: baseline.cloudnative.io/v1
kind: SecurityBaseline
metadata:
  name: pod-security-strict
spec:
  targetSelector:
    matchNamespaces:
      - production
  rules:
    - name: "禁止特权容器"
      check: "container.securityContext.privileged == false"
      severity: Critical
    - name: "必须设置只读根文件系统"
      check: "container.securityContext.readOnlyRootFilesystem == true"
      severity: High

2.3 控制循环（Control Loop）与最终一致性（Eventual Consistency）

控制循环是云原生系统的“心脏”。它持续执行“观察 → 分析 → 行动”的闭环。最终一致性则承认：在分布式系统中，状态无法瞬间同步，系统允许短暂的不一致，但保证在有限时间内收敛至期望状态。

核验架构中的控制循环设计如下：

1. 观察（Observe）： 通过 API Server 监听或 Prometheus 拉取，获取集群当前运行时状态（Pod 配置、网络策略、资源用量）。
2. 分析（Analyze）： 将当前状态与基线 CRD 中定义的期望状态进行比对，生成差异报告（Diff Report）。
3. 行动（Act）： 根据差异严重程度执行不同动作：记录审计日志、触发告警、自动修复（如驱逐非基线 Pod）、或阻塞变更（通过准入 Webhook）。

下图展示了核验控制循环的完整流程：

最终一致性在核验架构中的体现：当 SRE 更新基线规则（如“新增禁止 hostNetwork”），集群中已运行的 Pod 不会立即被驱逐。核验控制器会在下一轮控制循环中检测到差异，并根据规则中的 remediationAction 字段决定是否自动修复。这个延迟窗口是设计时需明确接受的。

2.4 四大原则的协同关系

不可变基础设施、声明式API、控制循环与最终一致性并非孤立原则，它们在核验架构中形成互补：

下图展示了四大原则如何共同支撑核验架构的整体能力：