容器编排如何保障稳定性
在现代应用部署中，服务动不动就几十个容器同时跑，谁也保不准哪个容器突然“罢工”。比如你早上刚泡好咖啡，准备开工，结果用户反馈下单功能卡住了。一查，是支付服务的某个容器挂了。这时候，靠人工一个个重启？太慢了。容器编排系统就是来解决这种问题的。
自动恢复异常实例
像 Kubernetes 这类编排工具，会持续监控每个容器的运行状态。一旦发现某个容器进程崩溃或健康检查失败，它不会坐视不管，而是立刻拉起一个新的实例替换掉故障的。这个过程对用户几乎是无感的。比如下面这个 Pod 的健康检查配置：
livenessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 30
periodSeconds: 10每10秒检查一次服务健康状态，连续失败就重启，避免问题积累。
滚动更新避免服务中断
发新版本最怕“一更全挂”。容器编排支持滚动更新策略，先停一部分旧实例，启动对应的新实例，确认没问题再继续。比如你有个电商应用正在大促，这时候上线新功能，编排系统会控制节奏，确保始终有足够多的正常实例对外提供服务。
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 1
maxSurge: 1最多允许一个实例不可用，最多额外启动一个新实例，平滑过渡。
资源限制防“捣乱”
有些服务写得不够收敛，内存越吃越多，最后拖垮整个节点。编排系统可以在部署时设定资源上限，比如给某个服务最多用512Mi内存：
resources:
limits:
memory: "512Mi"
cpu: "500m"一旦超限，容器会被强制终止并重启，防止它影响同节点的其他服务。
多副本与负载均衡
单个容器终究脆弱，编排系统允许你声明需要几个副本同时运行。比如设置 replicas: 3，即使其中一个宿主机断电，另外两个还能撑住流量。配合内置的服务发现和负载均衡，请求能自动转发到健康的实例上。
就像便利店开了三家分店，哪怕其中一家临时关门打扫，顾客也能去另外两家买到东西，生意照常。
调度优化提升可用性
编排系统在分配容器时会考虑节点负载、资源余量甚至物理位置。比如避免把所有副本都塞在同一台物理机上，万一机器宕机，全军覆没。通过反亲和性配置，可以强制分散部署：
affinity:
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 100
podAffinityTerm:
labelSelector:
matchExpressions:
- key: app
operator: In
values:
- my-app
topologyKey: kubernetes.io/hostname这样即使某台主机出问题，其他主机上的副本仍能维持服务运转。