kubernetes通过deployment协同多副本、健康探针、滚动更新、反亲和调度及集群高可用架构实现应用高可用：设置replicas≥3并分散节点，配置livenessprobe与readinessprobe，启用rollingupdate策略，结合podantiaffinity和topologyspreadconstraints跨区打散，依赖多master与etcd集群保障控制平面稳定。
要让应用在 Kubernetes 上真正高可用，单靠 Deployment 本身不够，它只是实现高可用的关键一环——负责无状态应用的弹性伸缩、滚动更新和故障自愈。真正的高可用需要 Deployment 与集群架构、健康检查、资源约束等协同配合。
Deployment 本身如何支撑高可用
Deployment 不直接管理 Pod，而是通过 ReplicaSet 控制副本数量，并保障 Pod 始终处于期望状态。当某个 Pod 异常退出，Deployment Controller 会自动拉起新 Pod 补足副本数，这是服务不中断的基础。
- 设置 replicas ≥ 2，避免单点失效；生产环境建议至少 3 个副本，分散在不同节点上
- 使用 RollingUpdate 策略，配合
maxUnavailable: 0和maxSurge: 1，确保升级过程中始终有完整服务能力 - 配置 revisionHistoryLimit（如设为 10），保留足够历史版本，便于快速回滚
- 启用 progressDeadlineSeconds（如 600 秒），防止卡住的部署无限等待，触发失败告警
必须搭配的健康探针
没有探针的 Deployment 就像没装刹车的车——副本数对了，但流量可能打到还没就绪或已僵死的容器上。
-
readinessProbe 决定 Pod 是否加入 Service 的 endpoints：路径
/actuator/health/readiness、initialDelaySeconds: 30、periodSeconds: 5是常见合理值 -
livenessProbe 决定是否重启容器：路径
/actuator/health/liveness、initialDelaySeconds: 60（留出启动时间）、failureThreshold: 3防止误杀 - 两个探针的
port必须与容器实际监听端口一致，且路径需由应用真实暴露
跨节点与跨可用区调度保障
即使副本数达标，如果所有 Pod 都挤在同一个节点或同一可用区，节点宕机或机房故障仍会导致服务中断。
- 利用 PodAntiAffinity 规则，强制相同 label 的 Pod 尽量不调度到同一节点
- 结合 topologySpreadConstraints，按
topologyKey: topology.kubernetes.io/zone均匀打散到多个可用区 - Worker 节点本身需跨物理机、跨机架甚至跨机房部署，这是集群层前提
与集群高可用能力联动
Deployment 运行依赖控制平面稳定。若 Master 全挂，Deployment Controller 停摆，新故障无法恢复。
- 集群必须是多 Master 架构（≥3），通过负载均衡暴露统一 API 地址
- etcd 至少 3 节点集群部署，开启
election-timeout和heartbeat-interval优化选举响应 - 为关键 Deployment 配置 PodDisruptionBudget（PDB），例如
minAvailable: 2，防止运维操作（如节点驱逐）导致副本低于可用底线
