3.2 Deployment：一份播种计划书

本节摘要：Deployment 是无状态应用的日常播种主力：它持有"株数与品种"的期望，经 ReplicaSet 保证株数，经滚动机制保证换品种不断流。本节完成绿荫书屋网页的正式下种，走通 apply、查苗、扩缩容、看事件的完整闭环，并拆解 Deployment、ReplicaSet、Pod 的三层关系。

动手：种下绿荫书屋的网页

事故夜之后，书屋团队学的第一课是：别再裸种。正式的播种计划长这样：


# 播种计划：田里常驻三株网页苗
apiVersion: apps/v1
kind: Deployment              # 单据类型：播种计划
metadata:
  name: greenlib-web
spec:
  replicas: 3                 # 期望株数
  strategy:
    type: RollingUpdate       # 换品种时滚动进行（默认值，写明是为了显眼）
  selector:
    matchLabels:
      app: greenlib-web       # 计划认苗规则：只认带这块牌的
  template:                   # 苗的模板（每株都按这里长）
    metadata:
      labels:
        app: greenlib-web     # 苗牌必须与 selector 对上
    spec:
      containers:
        - name: web
          image: greenlib/web:0.9.1
          ports:
            - containerPort: 8080

三个关键部位划一下重点：replicas 是株数期望；selector 是认苗规则，计划只对"带这块苗牌的苗"负责；template 是苗的模具，株数补齐时照此翻模。苗牌与认苗规则必须严格对上，对不上时 API Server 会当场拒收单子——这是新手清单报错的第一名。

交单与查苗：


kubectl apply -f web-deployment.yaml
# deployment.apps/greenlib-web created

kubectl get deployments
# NAME          READY   UP-TO-DATE   AVAILABLE   AGE
# greenlib-web  3/3     3            3           2m
# 三株期望 三株就绪 没有落后版本 三株可用

kubectl get pods -l app=greenlib-web
# NAME                           READY   STATUS    RESTARTS   AGE
# greenlib-web-7d9b6c5f4-8xzqm   1/1     Running   0          2m
# greenlib-web-7d9b6c5f4-mn2pv   1/1     Running   0          2m
# greenlib-web-7d9b6c5f4-qk8te   1/1     Running   0          2m
# 观察点：Pod 名的中段 7d9b6c5f4 是 ReplicaSet 的指纹，下一小节解释

计划之下还有一层保底

kubectl get all 时你会看到一个名叫 greenlib-web-7d9b6c5f4 的 ReplicaSet，夹在 Deployment 与 Pod 中间。这层"隔代管理"分工明确：

Deployment 管"种什么版本"：持有模具与策略，换版本时指挥新旧两个 ReplicaSet 此消彼长。
ReplicaSet 管"有几株"：盯着自己的认苗规则数苗，缺一补一。
Pod 是苗本身，被 ReplicaSet 认领与补种。

图：三层结构与一次补苗

为什么中间要隔这一层？留给一个思想实验：假如 Deployment 直接管 Pod，换版本时它得一边停旧苗一边起新苗，账要记得极细。有了 ReplicaSet 这层，换版本就变成"新版本建一个新 ReplicaSet，旧版本 ReplicaSet 缩到零"，株数始终由各自的数苗员兜底。第七章滚动更新的全部戏剧，都在这两组数苗员的一涨一消之间。

闭环的另外三步

扩苗。 周年庆活动要来了，临时加到五株：


kubectl scale deployment greenlib-web --replicas=5
# deployment.apps/greenlib-web scaled

kubectl get pods -l app=greenlib-web -w
# 按下 w 后持续观察：新两株从 Pending 到 ContainerCreating 再到 Running
# greenlib-web-7d9b6c5f4-pq9wa   0/1   Pending   0   0s
# greenlib-web-7d9b6c5f4-pq9wa   1/1   Running   0   6s
# （按 Ctrl 加 C 退出观察）

看苗的档案。 想知道一株苗为何迟迟不活，先看它的档案与事件：


kubectl describe pod greenlib-web-7d9b6c5f4-pq9wa
# 输出节选（Events 段是重点）：
# Events:
#   Type    Reason     Message
#   Normal  Scheduled  Successfully assigned to node-2
#   Normal  Pulling    Pulling image "greenlib/web:0.9.1"
#   Normal  Created    Created container web
#   Normal  Started    Started container web
# 若此处出现 FailedScheduling，说明无地可选，常见原因是额度不够（第七章）

删苗看自愈。 亲手拔掉一株，验证园丁在场：


kubectl delete pod greenlib-web-7d9b6c5f4-pq9wa
# pod "greenlib-web-7d9b6c5f4-pq9wa" deleted

kubectl get pods -l app=greenlib-web
# 注意名单里冒出一个新名字后缀的苗，AGE 只有几秒——这就是补种
# greenlib-web-7d9b6c5f4-v7c2rd   1/1   Running   0   9s

四步走完，绿荫书屋网页在田里站稳了：期望三株（现在五株）、缺苗自动补、扩苗一条命令。事故夜里最痛的那两页，翻过去了。

⚠️ 常见坑：直接 kubectl edit 或 scale 改出来的改动，下次 apply 同名清单时可能被覆盖回 YAML 里的值。口径要统一：临时调整用命令无妨，长期状态请改清单再 apply，让台账始终有据可查。

本节要点回顾

Deployment 持有模具与策略，ReplicaSet 负责数苗，Pod 是苗，三层各司其职
selector 与 template 的苗牌必须一致，否则清单直接被拒收
扩缩容就是改 replicas，观察过程靠 -w 参数持续 watch
describe 的事件段是苗情的病历首页，排错第一站
命令式改动与清单口径要统一，避免"改了又被 apply 覆盖"的糊涂账
下一节解决"田里种多了怎么管"：Namespace 划田，Label 认苗

作者与出处

原作者：灏天文库

来源：灏天文库

整理：灏天文库整理

由灏天文库平台收录，内容或由平台用户上传，仅供学习交流