第1章 声明的诞生：写出第一份Deployment YAML
第1章 声明的诞生：写出第一份 Deployment YAML
章节摘要：本章跟着一条线走——电商平台订单服务 orders-api 要从八台手工维护的服务器搬进 Kubernetes 集群，第一步不是敲命令，而是把它"翻译"成一份 Deployment YAML。这一章讲清两件事：为什么 Kubernetes 选择让你声明结果而不是书写步骤；一份 Deployment 声明的每个字段分别在替你说什么话。
一条主线
故事的主角是一段跑了三年的订单服务代码。过去每次发布，运维同学要在八台机器上逐台执行十几条命令：停旧进程、备份配置、替换二进制、改防火墙、起进程、看日志。命令式操作在机器少时可靠，机器一多就成了风险本身——第八台机器漏执行一条命令，没有任何系统会替你发现。
Kubernetes 给出的解法是把"我要什么"写成声明：副本数 3、镜像版本 1.4.2、对外端口 8080。至于副本放在哪台机器、怎么拉镜像、挂了怎么补，全部交给集群。本章的起点，就是把订单服务整理成这样一份Deployment YAML；它的终点，是这份声明第一次通过 kubectl 进入集群。
先看一张对照图，感受两种工作方式的根本差异：
图 1-1：命令式逐步执行与声明式最终一致
沿途站点
本章三节，对应"想清楚、写出来、落下去"三步：
- 1.1 为什么是声明式：从运维的重复劳动出发，理解容器编排要解决的四个问题（自愈、复制、调度、升级），并认识控制平面与工作节点的分工。这一节回答"凭什么信它"。
- 1.2 解剖一份 Deployment 声明：逐行读 orders-api 的第一版 YAML，弄清 metadata、labels、selector、template 之间的呼应关系。这一节回答"每个字段在替你说什么"。
- 1.3 Pod：声明的最小落地单元：Deployment 最终落地为一组 Pod。这一节讲 Pod 里到底装了什么、多容器怎么共享网络、状态如何流转，为第3章的调度与探针打底。
三节的依赖关系是单向的：没有 1.1 的动机，1.2 的字段只是语法；没有 1.3 的 Pod 认知，第3章"调度器在调什么"就会落空。
图 1-2：一份 Deployment 声明的内部结构
拐点与结论
本章的认知拐点在 1.2 节中段：selector 与 template 里 labels 必须严丝合缝，这是初学者最容易写错也最值得写对的一处。想通它，你就理解了 Kubernetes 的管理方式——不是靠名字记住了哪些 Pod，而是靠标签动态圈定势力范围。副本换了、重建了、漂移到别的节点了，这份归属关系依然成立。
结论一句话：Deployment 不是"一个应用"，而是"一份持续生效的意图"。写完它，旅程才刚刚开始。
读完你应该
- 能举出命令式运维的三个具体风险，并对应说明声明式如何化解；
- 独立写出一份包含 labels、selector、template 的最小可用 Deployment YAML；
- 说清 Deployment 与 Pod 的关系：前者是意图，后者是意图的实体化；
- 解释 Pod 内多容器共享网络命名空间的含义，以及 sidecar 模式的适用场景；
- 读懂 kubectl get 与 describe 输出中的关键状态列。
下一章的接力
第1章结束时，这份声明还只是你机器上的一个文本文件。第2章将跟着它穿过 API Server 的受理窗口：认证验明正身、RBAC 判定权限、准入控制器做最后修订，最终写入 etcd 账本。声明从"纸面"进入"集群记忆"的那一瞬，就是下一章的入口。