deployment是kubernetes官方为无状态应用定义的唯一推荐控制器,它通过replicaset确保副本数恒定,支持滚动更新、版本回滚、自动重建与历史追踪,而裸pod和手动replicaset均缺失这些关键能力。

直接用 Deployment,别绕弯子。它不是“可选方案”,而是 Kubernetes 官方为无状态应用定义的唯一推荐控制器——其他方式(比如裸 Pod、手动 ReplicaSet)会丢掉滚动更新、自动回滚、健康驱逐、历史版本追踪等关键能力。
为什么必须用 Deployment 而不是裸 Pod 或 ReplicaSet
裸 Pod 没有自愈能力:节点宕机后不会重建;ReplicaSet 虽能保副本数,但不支持声明式更新和版本管理。只有 Deployment 同时满足:
- 通过底层
ReplicaSet确保replicas数量恒定 - 每次
kubectl apply -f修改spec.template(如镜像、环境变量),自动触发新ReplicaSet创建 + 旧ReplicaSet缩容 - 所有历史
ReplicaSet默认保留(可通过revisionHistoryLimit控制),支持kubectl rollout undo -
Pod的label必须严格匹配spec.selector.matchLabels,否则创建失败并报错error: invalid spec.selector: field is immutable
Deployment YAML 最小可用模板长什么样
以下是最简但生产可用的 Deployment 清单,去掉了注释和非必需字段,可直接 kubectl apply -f:
针对 Kubernetes 仪表板和 Web UI 的浏览器自动化。适用于与 Kubernetes Dashboard、Grafana、ArgoCD UI 或其他 Web 界面交互。需要设置 MCP_BROWSER_ENABLED=true。
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-app
spec:
replicas: 2
selector:
matchLabels:
app: nginx-app
template:
metadata:
labels:
app: nginx-app
spec:
containers:
- name: nginx
image: nginx:1.25
ports:
- containerPort: 80
注意几个硬性要求:
-
apiVersion必须是apps/v1(v1beta1已在 v1.26+ 被移除) -
selector.matchLabels和template.metadata.labels必须完全一致,否则kubectl apply会拒绝 - 不能省略
ports字段——虽然不写也能跑,但后续配Service时容易因端口名缺失导致流量转发失败
部署后怎么验证和日常操作
部署只是第一步,真正要盯住的是实际运行态是否符合预期:
- 查 Pod 是否就绪:
kubectl get pods -l app=nginx-app,确认READY列为1/1且STATUS是Running - 查滚动更新进度:
kubectl rollout status deployment/nginx-app,卡住时会显示Waiting for deployment "nginx-app" rollout to finish - 触发一次镜像升级:
kubectl set image deployment/nginx-app nginx=nginx:1.26,观察新旧ReplicaSet数量变化 - 回滚到上一版:
kubectl rollout undo deployment/nginx-app,默认回退到revision=1,也可指定--to-revision=2
最容易被忽略的是:Deployment 自身不暴露服务,必须搭配 Service(或 Ingress)才能被访问。漏掉这步,Pod 全跑起来了也收不到请求。










