2. 基础概念：容器运行时（Runtime）与容器编排（Orchestration）的核心区别
在深入配置漂移检测之前，必须厘清两个最常被混淆的基础概念：容器运行时（Container Runtime）与容器编排（Container Orchestration）。它们是容器化基础设施中职责完全不同的两个层次，理解其边界是设计自动化流水线的前提。
2.1 职责边界：单机执行 vs. 集群调度
| 维度 | 容器运行时（Runtime） | 容器编排（Orchestration） |
|---|---|---|
| 核心职责 | 在单台主机上创建、启动、停止容器进程 | 在集群中调度、部署、伸缩、管理容器生命周期 |
| 操作对象 | 容器（Container）、镜像（Image）、挂载点 | Pod、Service、Deployment、Namespace |
| 网络模型 | 单机网络栈（veth pair、bridge） | 跨主机覆盖网络（CNI 插件） |
| 存储视角 | 本地层、卷挂载 | 持久卷声明（PVC）、分布式存储 |
| 配置漂移范围 | 主机级：runc 配置、cgroup 参数、seccomp 策略 | 集群级：资源配额、调度策略、网络策略、RBAC |
| 典型组件 | containerd、CRI-O、Docker Engine | Kubernetes、Nomad、Docker Swarm |
关键认知：运行时负责“能不能跑”，编排负责“跑在哪、跑多少、怎么恢复”。配置漂移检测必须同时覆盖这两个层面，但检测手段和恢复策略完全不同。
2.2 架构分层：从 OCI 到 K8s 的调用链
下图展示了从编排层到运行时层的标准调用链路，以及各层可能发生的配置漂移点。
2.3 配置漂移视角下的核心差异
从自动化流水线检测与恢复的角度，运行时与编排的差异体现在以下三个关键维度：
- 配置作用域
- 运行时配置：作用于单台主机，例如
/etc/containerd/config.toml、/etc/docker/daemon.json。 - 编排配置：作用于整个集群，例如
kube-system命名空间下的 ConfigMap、Deployment 的spec.template.spec.containers[].securityContext。
- 运行时配置：作用于单台主机，例如
- 变更频率
- 运行时配置：相对稳定，通常在节点初始化或版本升级时变更。
- 编排配置：高频动态变更，应用发布、扩缩容、策略更新都会触发。
- 恢复难度
- 运行时配置漂移：需要节点级修复，可能涉及重启 containerd 或 kubelet，影响节点上所有 Pod。
- 编排配置漂移：可以通过声明式回滚（
kubectl rollout undo）或 GitOps 自动同步恢复，影响范围可控。
⚠️ 常见误区：很多团队只关注编排层的配置漂移（如 Deployment 副本数变化），却忽略了运行时层的配置漂移（如 seccomp 策略被篡改、cgroup 驱动被切换）。后者往往更隐蔽，且可能导致安全逃逸或性能退化。
2.4 典型场景对比：谁在管什么？
| 场景 | 运行时负责 | 编排负责 |
|---|---|---|
| 容器启动失败 | 检查 OCI 运行时配置、镜像拉取策略 | 检查资源限制、调度约束、重启策略 |
| 网络不通 | 检查 CNI 插件是否加载、端口映射 | 检查 Service/Ingress 配置、网络策略 |
| 安全策略失效 | 检查 seccomp/AppArmor 配置文件 | 检查 PodSecurityPolicy / OPA 策略 |
| 资源争抢 | 检查 cgroup 参数、CPU 管理器策略 | 检查 LimitRange、ResourceQuota、QoS 等级 |
2.5 自动化流水线中的关注点
在设计配置漂移检测与恢复流水线时，必须为运行时和编排分别建立检测基线：
- 运行时基线：使用
containerd config dump、docker info --format '{{json .}}'等命令定期采集节点级配置，与黄金镜像中的基准配置进行 diff。 - 编排基线：通过 Kubernetes 的
kubectl diff或 GitOps 工具（Argo CD、Flux）对比集群实际状态与 Git 仓库中的声明式配置。
💡 实践建议：在流水线中为运行时和编排分别设置独立的检测阶段。运行时检测放在节点初始化或升级后，编排检测放在每次部署前。两者不可互相替代。