📚 课程目录第1章课程导论

1. 课程导论：为什么需要关注 Helm 部署中的 DNS 故障与控制平面隔离问题

在云原生生产环境中，Helm 作为 Kubernetes 的包管理工具，承担着应用定义、安装、升级和回滚的核心职责。然而，许多团队在将 Helm 从开发环境迁移到生产环境时，会遭遇两类隐蔽但破坏性极强的故障：DNS 解析中断与控制平面组件间的非预期耦合。这两类问题如果不在 Helm Chart 设计阶段进行故障域划分，往往会在集群规模扩张或网络抖动时引发级联故障。

1.1 生产环境中的真实故障场景

以下两个案例分别对应 DNS 故障和控制平面隔离缺失的典型表现：

故障类型	场景描述	影响范围	根因
DNS 故障	CoreDNS Pod 因节点资源竞争被 OOMKill，导致集群内所有 Service 域名解析超时	全集群 80% 以上的微服务无法互相发现，业务接口大面积 503	Helm Chart 未配置 `dnsPolicy` 兜底策略，且未将 DNS 组件部署在独立资源池
控制平面耦合	Helm 安装的 Prometheus Operator 直接修改了 `kube-system` 命名空间下的 `kube-controller-manager` 配置	集群节点注册异常，新 Pod 无法调度至新增节点	Chart 中的 RBAC 规则未做命名空间隔离，导致控制平面组件被外部应用误操作

关键认知：Helm 的模板渲染能力虽然强大，但它默认不会对目标集群的故障域做任何假设。Chart 开发者必须显式声明 DNS 策略、控制平面访问边界和资源隔离边界，否则一次简单的 CoreDNS 滚动更新就可能演变为全集群瘫痪。

1.2 DNS 故障：Helm 部署中最容易被忽视的依赖

Kubernetes 集群内部的服务发现几乎完全依赖 DNS 解析。Helm 在安装、升级、回滚和测试阶段，均可能触发 DNS 调用：

Chart 中的 helm test 钩子：测试 Pod 通常通过 Service 域名访问被测应用，DNS 故障会导致测试假失败。
Webhook 回调：部分 Chart 会注册 MutatingWebhookConfiguration，API Server 需要解析 Webhook Service 的域名，DNS 中断将阻塞所有资源创建。
跨命名空间依赖：Helm 编排的微服务之间通过 <service>.<namespace>.svc.cluster.local 通信，DNS 故障直接切断服务拓扑。

下图展示了 Helm 部署流程中 DNS 解析的关键路径：

1.3 控制平面隔离：防止 Helm 操作越界

控制平面组件（kube-apiserver、kube-controller-manager、kube-scheduler、etcd）是集群的“大脑”。Helm Chart 如果缺乏控制平面隔离意识，可能通过以下方式侵入控制平面：

RBAC 权限过宽：Chart 中的 ServiceAccount 被授予 cluster-admin 角色，可以修改控制平面组件的配置。
命名空间污染：将业务 Pod 部署到 kube-system 命名空间，与系统组件混部，资源竞争导致控制平面不稳定。
直接操作 etcd：部分 Chart 通过 Job 或 InitContainer 直接访问 etcd 端口，绕过 API Server 的鉴权和审计。

下图展示了控制平面与业务平面之间理想的隔离边界：

1.4 故障域划分的核心收益

在 Helm Chart 设计阶段主动进行故障域划分，可以带来以下可量化的收益：

维度	未划分故障域	划分故障域后
DNS 故障影响半径	全集群服务发现中断，所有微服务不可用	仅受影响命名空间内的服务降级，其他命名空间正常
控制平面稳定性	业务应用误操作导致控制平面组件重启	控制平面完全隔离，业务变更不影响系统组件
Helm 操作成功率	DNS 超时导致 helm install/upgrade 失败率 > 30%	通过本地 DNS 缓存和重试策略，失败率降至 < 1%
故障恢复时间（MTTR）	需要人工排查 DNS 链和控制平面日志，平均 45 分钟	通过预定义的隔离策略和健康检查，自动恢复 < 5 分钟

课程目标：本课程将系统性地讲解如何在 Helm Chart 中通过 dnsPolicy、topologySpreadConstraints、NetworkPolicy、RBAC 最小权限原则以及控制平面专用节点池等机制，实现 DNS 故障域与控制平面的有效隔离。你将学会设计出即使 CoreDNS 宕机也能保持核心功能可用的弹性 Chart。