之前说完了ingressservice这篇我们说一下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 层几个副本、怎么更新、认领哪些 Podtemplate 层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: appweb)──→ 认领所有 label 含 appweb 的 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 就绪。