之前说完了ingress，service，这篇我们说一下deployment。
那么什么是Deployment呢？
一个管理 Pod 副本的无状态应用控制器。在创建Deployment的时候会创建一个pod，你声明期望状态（几个副本、用什么镜像），它持续对比实际状态并自动调和到一致。
那么Deployment解决了什么问题呢？
| 死穴 | 裸 Pod 的下场 | Deployment 的解法 |
|---|---|---|
| Pod 挂了没人管 | 应用下线，等人手工重建 | 自动重建，副本数永远维持 |
| 扩缩容麻烦 | 想加 5 个副本要手写 5 份 YAML | 改一个数字 replicas: 5，自动补齐 |
| 升级要停机 | 删旧建新，中间服务中断 | 滚动更新，新旧交替全程可用 |
那么我们接下来看一个Deployment的模板
apiVersion:apps/v1kind:Deploymentmetadata:name:webspec:replicas:3# 期望副本数selector:# 认领 Pod 的标签matchLabels:app:webstrategy:# 更新策略type:RollingUpdaterollingUpdate:maxSurge:1maxUnavailable:0template:# Pod 模板metadata:labels:app:web# 必须和 selector 一致spec:containers:-name:nginximage:nginx:1.28ports:-containerPort:80resources:requests:{cpu:100m,memory:128Mi}limits:{cpu:500m,memory:256Mi}readinessProbe:# Ready 才进 EndpointshttpGet:{path:/,port:80}这个是一个基础的yaml文件
他的整体结构：三层嵌套
Deployment (外层:管理策略)└─ spec.template (中层:Pod 模板)└─ spec.containers (内层:容器定义)每一层管不同的事：
| 层 | 管什么 |
|---|---|
| Deployment 层 | 几个副本、怎么更新、认领哪些 Pod |
| template 层 | Pod 长什么样（标签、规格） |
| containers 层 | 容器跑什么镜像、什么端口、多少资源 |
第一层：Deployment 的管理策略
replicas: 3 — 期望副本数
就是说我们要一直保持三个pod。
这就是调和循环：控制器持续对比期望 vs 实际，不一致就操作到一致。
spec:replicas:3selector:matchLabels:app:webstrategy:type:RollingUpdaterollingUpdate:maxSurge:1maxUnavailable:0第二层：Pod 模板
template:metadata:labels:app:webspec:containers:-...Deployment ──(selector: app=web)──→ 认领所有 label 含 app=web 的 Pod
第三层：容器定义
-name:nginximage:nginx:1.28ports:-containerPort:80resources:requests:{cpu:100m,memory:128Mi}limits:{cpu:500m,memory:256Mi}readinessProbe:httpGet:{path:/,port:80}ports.containerPort: 80
声明容器监听 80。注意它只是声明，不产生任何网络效果——真正决定流量的是 Service 的 targetPort。这里写 80 是给人看的，也方便 Service 用名字引用端口。
resources — 资源请求和上限
requests:cpu 100m,mem 128Mi ← 调度器按这个找节点limits:cpu 500m,mem 256Mi ← 容器最多用这么多readinessProbe — 就绪探针
readinessProbe:httpGet:{path:/,port:80}kubelet 定期发 GET http://PodIP:80/ ，返回 200 = 就绪。
