Kubernetes容器编排与管理实战

Kubernetes容器编排与管理实战：一次部署的声明之旅

Kubernetes 容器编排教程导读：为什么同样是发布应用，有人要通宵守着服务器逐台改配置、重启进程，有人却只需把声明交给集群就去休息？这本实战教程不按名词字典的顺序背概念，而是跟随电商平台订单服务 orders-api 的部署声明走完全程：看它被 kubectl 提交、经 API Server 受理、登记进 etcd、由调度器选址、被 kubelet 拉起容器、交由探针接管，再经历滚动更新、服务暴露、配置与存储注入，最终在日志、指标与排障中闭环。声明式、控制循环、自愈，是贯穿全程的关键词——读完这本教程，你自然会答得上：机器坏掉之后，凭什么副本还能自动补齐？

从一次深夜发布说起

凌晨一点，某电商平台的运维同学第七次登上生产服务器：拉代码、改配置、重启进程、逐台检查。八台机器，八遍操作，任何一步手滑都可能让第二天早高峰炸出事故单。后来他把同样的应用搬上 Kubernetes，整个发布动作收敛成一句话：把一份描述"我要 3 个订单服务副本"的 YAML 交给集群。机器坏了副本会自动补，版本升级会逐个换、不中断服务，流量入口稳定不变。

这份 YAML，就是本教程的主角。它在 Kubernetes 里叫"声明"：你声明期望的结果，不书写达成结果的每一步命令；集群里的各组件自行分工，把现状推向你声明的样子。理解了这份声明的旅程，就看懂了 Kubernetes 的骨架与灵魂。

全册知识地图：一份声明的七个驿站

下面这张图是全册的行程单。上半部分是控制平面（受理、登记、调度决策），下半部分是工作节点（拉起容器、运行探针），右侧是声明进入稳态之后的延伸议题。七章依次对应声明旅程的七段路，前一章的终点就是后一章的起点。

图 0-1：orders-api 声明的全旅程知识地图

七章行程表

阅读前提与实验环境

你只需要基础的 Linux 命令行经验和对容器的一点了解（会拉镜像、能看懂镜像与容器的区别即可）。每一章的实验都在本地单节点集群上可复现：用 minikube 或 kind 起一个练习集群，装好 kubectl，跟着各节的命令逐条敲。书中命令均注明预期输出，方便你对账；YAML 中的镜像名、副本数、端口都可替换为你自己的应用。

各节的代码约定：YAML 用于声明，kubectl 命令用于观察与干预，输出片段用于核对状态。三者交替出现，正好对应"声明、观察、对账"的工作节奏。

读完后你应当能够

• 说清声明式与命令式的差别，并解释 Kubernetes 为什么选择声明式；
• 独立写出带探针、资源请求、配置挂载的 Deployment 并完成滚动更新与回滚；
• 描述一次 kubectl apply 之后，声明在 API Server、etcd、调度器、kubelet 之间的流转路径；
• 为工作负载配置 Service、Ingress 与 NetworkPolicy，让流量进出有序；
• 按排障手册定位 Pod 起不来、探针失败、调度挂起等常见故障；
• 用 Helm 或 GitOps 的思路，把一份声明复制成一百个环境的配置。

旅程从第1章开始：先弄明白，为什么"写清楚想要什么"会比"写清楚每一步怎么做"更可靠。