Deployment是最常用、最稳妥的多副本部署方式，但必须配齐replicas、selector.matchLabels和template.metadata.labels三者一致，并配置livenessProbe与readinessProbe健康探针，否则无法保障真实可用性。
直接说结论：用 Deployment 是最常用、最稳妥的多副本部署方式，但必须配合 replicas、selector 和健康检查才能真正可靠。
为什么不能只写 replicas: 3 就完事？
很多初学者写完 YAML 就 kubectl apply，结果发现 Pod 起不来，或者起得来但服务不可用。根本原因在于：replicas 只控制数量，不保证可用性。
- 没有
livenessProbe或readinessProbe，Kubernetes 不知道容器是否真“活”着，可能把流量导给卡死的 Pod -
selector和template.metadata.labels不匹配，Deployment 就管不住这些副本，状态显示AVAILABLE: 0 - 镜像拉取失败、端口冲突、资源不足等底层问题，会被
replicas字段完全掩盖，需要看kubectl describe deployment和kubectl get pods才能定位
Deployment 必须配齐的三个关键字段
一个最小可用的多副本 Deployment，这三项缺一不可：
-
replicas：声明期望副本数，比如3；它不是“启动 3 个”，而是“持续维持 3 个正常运行的 Pod” -
selector.matchLabels：定义 Deployment 用什么标签去“认领”自己的 Pod，比如app: nginx -
template.metadata.labels：Pod 模板里必须包含和上面完全一致的标签，否则 Deployment 视而不见
漏掉任意一项，kubectl get deployments 可能显示 READY 0/3，但不会报错——这是最隐蔽的坑。
Kubernetes Skills
下载
针对 Kubernetes 仪表板和 Web UI 的浏览器自动化。适用于与 Kubernetes Dashboard、Grafana、ArgoCD UI 或其他 Web 界面交互。需要设置 MCP_BROWSER_ENABLED=true。
什么时候不该用 Deployment 做多副本？
不是所有“多个实例”都适合 Deployment：
- 有状态服务（如 MySQL、Redis 主从）：副本之间有身份、顺序、网络标识依赖，必须用
StatefulSet，否则数据混乱或脑裂 - 需要固定主机绑定或共享本地存储：
Deployment的 Pod 会漂移，应结合nodeSelector或tolerations控制，但不如DaemonSet明确 - 每个节点只跑一个副本（比如日志采集器）：直接用
DaemonSet，比硬配podAntiAffinity更简洁、更确定
强行用 Deployment 部署有状态应用，后期扩容缩容会触发不可控的数据迁移或连接中断。
副本分散部署的关键：别只靠运气
Kubernetes 默认调度器不保证副本分散。两个副本跑到同一节点上，节点宕机就全挂——这不是小概率事件，是默认行为。
- 用
podAntiAffinity是最直接解法，但注意：topologyKey: "kubernetes.io/hostname"才表示“不同节点”，别错写成failure-domain.beta.kubernetes.io/zone（那是跨可用区） - 硬性策略
requiredDuringSchedulingIgnoredDuringExecution要求集群节点数 ≥ 副本数，否则 Pod 卡在Pending状态，查kubectl describe pod才能看到调度失败原因 - 软性策略
preferredDuringSchedulingIgnoredDuringExecution不保底，测试环境可以先用，生产环境慎用
真正上线前，务必执行 kubectl get pods -o wide 看实际分布，别只信 READY 列数字。
