1. 课程导入与生产环境认知
很多工程师第一次把 Kubernetes 用进生产，都会经历一个相似的落差：在测试集群里，一条 kubectl apply 就能把应用跑起来，滚动更新、扩缩容、服务发现都显得顺理成章；可一旦承载真实业务流量，问题就变成了另一副面孔——节点突然 NotReady、Pod 被驱逐、镜像拉取超时、Ingress 502、etcd 延迟升高、控制面 API 响应变慢。这些现象背后，往往不是"Kubernetes 不会用"，而是"没有按生产标准去设计和治理"。
本课程面向公有云上的 Kubernetes 生产实践，核心目标不是再讲一遍 Pod、Deployment、Service 的用法，而是回答一个更实际的问题：当集群承载真实业务、面对真实故障和真实成本压力时，我们如何让它稳定、可观测、可恢复、可演进。
公有云 Kubernetes 的四个核心挑战
与自建机房相比，公有云 Kubernetes 把底层 IaaS 的弹性、网络、存储、负载均衡都抽象成了 API，这带来了便利，也带来了新的复杂度。生产实践中，挑战主要集中在四个方面。
第一，控制面的稳定性边界。托管集群虽然由云厂商保障 etcd 和控制面组件的高可用，但 API Server 的请求压力、准入 Webhook 的阻塞、CRD 数量膨胀、大规模 List-Watch 风暴，仍然会由使用者的行为触发。一个写得不好的 MutatingWebhook，可能让整个集群的 Pod 创建全部超时。
第二，节点与工作负载的可靠性。节点是会被回收的——竞价实例、缩容、宿主机维护、磁盘打满、内核 OOM，都会让节点在毫无预告的情况下消失。工作负载必须假设"节点随时会走"，通过副本数、反亲和、PodDisruptionBudget、优雅终止来保证业务不中断。
第三，网络与流量的可观测性。公有云 VPC 网络、容器网络插件、Service、Ingress、负载均衡器层层叠加，一次请求可能穿过 5～6 个转发点。当出现偶发超时或 5xx 时，如果没有清晰的链路视图和指标，排查会变成"猜谜"。
第四，成本与资源的匹配。云上资源是按量计费的，Requests 设置过大导致节点利用率长期低于 30%，或者 HPA 配置不当导致频繁扩缩容，都会直接反映在账单上。可靠性治理必须同时考虑成本约束。
可靠性治理的目标与衡量方式
可靠性不是"永不出故障"，而是"故障发生时，影响可控、恢复可预期"。在生产实践中，我们通常用几个可量化的目标来约束治理工作：
- 可用性目标（SLO）：例如核心服务月度可用性 99.95%，对应每月约 21 分钟不可用预算。
- 恢复时间目标（RTO）：单节点故障后，业务恢复时间不超过 60 秒。
- 数据恢复点目标（RPO）：有状态服务的数据丢失窗口不超过 5 分钟。
- 变更失败率：发布导致的故障占比控制在 15% 以内，并可通过灰度与回滚快速收敛。
这些目标不是写在文档里的口号，而是要落到具体的配置和流程上：副本数、探针、PDB、资源配额、监控告警、发布策略、演练机制。本课程后续章节会逐一展开。
课程整体学习路径
整个课程按"认知—建设—治理—演练"的主线组织，共 30 章，大致分为五个阶段：
- 生产环境认知与准备（第 1～4 章）：理解生产与测试的差异，搭建贴近生产的实验环境，明确集群架构与命名规范。
- 工作负载与调度可靠性（第 5～10 章）：副本、探针、资源、亲和、PDB、优雅终止、优先级与抢占。
- 网络、存储与流量治理（第 11～17 章）：CNI、Service、Ingress、网关、DNS、持久化存储与有状态服务。
- 可观测性与故障排查（第 18～24 章）：指标、日志、链路、事件、告警、典型故障树与排障方法。
- 变更、演练与成本治理（第 25～30 章）：发布策略、混沌演练、容量规划、成本优化与治理体系落地。
下面这张图展示了本课程从"环境准备"到"治理闭环"的整体路径，以及每个阶段的核心产出物，便于你在学习过程中随时定位自己所处的位置。
实战环境准备
为了让后续章节的配置、命令和排障过程可以直接复现，建议准备一套贴近生产的实验环境。这里给出一个可参考的最小配置，属于教学示例，具体规格可根据自己的云账号和预算调整。
| 项目 | 建议配置 | 说明 |
|---|---|---|
| 托管集群 | 1 个控制面 + 3 个工作节点 | 节点规格 4 vCPU / 8 GiB，便于观察调度与驱逐 |
| 节点池 | 1 个按量节点池 + 1 个竞价节点池 | 用于验证节点回收与工作负载迁移 |
| 网络插件 | 云厂商 CNI 或 Calico | 需支持 NetworkPolicy |
| 存储 | 1 个云盘 StorageClass + 1 个 NAS StorageClass | 分别验证块存储与共享存储 |
| 可观测 | Prometheus + Grafana + Loki | 指标、日志、告警基础链路 |
| 工具 | kubectl、helm、k9s、stern | 日常操作与排障 |
环境就绪后，建议先做一次基线检查，确认集群处于可观测、可操作的状态：
# 查看节点状态与版本
kubectl get nodes -o wide
# 查看系统组件健康
kubectl get pods -n kube-system
# 查看集群事件，确认无异常驱逐或调度失败
kubectl get events -A --sort-by=.lastTimestamp | tail -n 20
# 查看资源分配情况，确认 Requests 与 Allocatable 的比例
kubectl describe node <node-name> | grep -A 8 "Allocated resources"如果 Allocated resources 中 CPU Requests 已经超过 70%，说明节点余量偏紧，后续做滚动更新或故障迁移时容易触发调度失败，需要提前扩容或调整 Requests。这类"先看基线、再谈治理"的习惯，会贯穿整个课程。