最简可用Deployment YAML只需定义镜像、端口、副本数：apiVersion必须为apps/v1，selector.matchLabels与template.metadata.labels键值严格一致，containerPort仅作Service targetPort匹配依据，不自动暴露端口。
直接上手部署 Web 应用，Deployment + Service 就够用；Ingress、ConfigMap、HPA 等属于按需叠加项，别一上来就堆全套。
怎么写最简可用的 Deployment YAML
核心是定义清楚三件事：镜像、端口、副本数。其他字段如 resources、livenessProbe 可后续补，初期不填也能跑起来。
-
apiVersion: apps/v1必须写对，旧版extensions/v1beta1在 v1.25+ 已废弃 -
selector.matchLabels和template.metadata.labels的键值必须完全一致，否则kubectl apply不报错但 Pod 启不来 -
containerPort只是声明，不等于自动暴露——它只为Service的targetPort提供匹配依据 - 示例中用
nginx:1.25.5是因该版本在 2025 年后仍被广泛验证兼容，避免用latest引发不可控更新
Service 暴露端口时常见连不通问题
Pod 能 Running，但 curl -v http://<service-ip>:80 超时，90% 出在 Service 配置和网络插件协同上。
-
spec.selector必须与 Deployment 中的template.metadata.labels完全匹配，一个空格都不能多 - 用
ClusterIP类型时，只能集群内访问；想本地测试，改用NodePort或kubectl port-forward - 如果用了 Flannel，确保
pod-network-cidr和kubeadm init时传入的一致，否则 DNS 解析失败、Service IP 不可达 - 检查
kubectl get endpoints <service-name>，输出为空说明 selector 没匹配到任何 Pod
滚动更新和回滚怎么实操才稳
别等线上炸了再试命令，更新前先确认 revisionHistoryLimit 设了（默认 10），否则 rollout history 查不到旧版本。
- 触发更新：
kubectl set image deployment/web-app nginx=nginx:1.26.0，比重写 YAML 更快 - 观察进度：
kubectl rollout status deployment/web-app，卡住时看kubectl describe deployment里 Events - 回滚到上一版：
kubectl rollout undo deployment/web-app；指定某 revision：kubectl rollout undo deployment/web-app --to-revision=3 - 注意：回滚不会还原
replicas数量或 label 变更，只还原镜像和容器配置
真正容易被忽略的是健康检查探针。没配 livenessProbe 时，容器假死但 Pod 状态仍是 Running，流量照常打进来；而 readinessProbe 缺失会导致新 Pod 还没 ready 就被加入 Service 的 endpoints —— 这类问题在线上往往要等用户反馈才暴露。
