从入门到真正敢把业务放在 K8s 上跑中间隔着一条叫“高可用”的河。很多人用 Deployment 部署完服务觉得副本数调成 3 就万事大吉结果一次节点宕机、一次滚动发布业务就把用户给得罪了。真正的生产环境里Deployment 的高级用法和 StatefulSet 的正确落地才是决定你半夜会不会被报警电话吵醒的关键。这篇是 K8s 系列第九篇咱们不聊基础概念直接讲实战Deployment 怎么才算真正配好了高可用以及有状态应用比如 Kafka、Redis 集群为什么必须靠 StatefulSet 才能撑住场面。内容偏运维和架构视角K8s 老手能拿走几段 YAML 和排障思路正在往生产环境迁移的团队也能从中找到适合自己业务的落地路径。1. Deployment 进阶高可用不止是“多副本”1.1 影响高可用的第一件事不是副本数是“调度打散”我接触过不少团队Deployment 副本数写得漂漂亮亮replicas: 3结果一看 Pod 分布三个实例全挤在同一台 worker 节点上。这种部署方式等于把鸡蛋全放在一个篮子里节点一挂整个服务的请求量瞬间归零。K8s 的调度器确实有默认的打散策略但它只在“同一 Deployment 的多个副本尽量不落在同一节点”这个层面做有限保证并不会综合考虑地域、机架、故障域等维度。生产环境里只依赖默认策略远远不够。要真正把高可用做扎实核心是让 Pod 在拓扑维度上打散。这里有两个手段我最常用一个是 topologySpreadConstraints另一个是 podAntiAffinity。前者更现代可以按“节点”“可用区”这类 topologyKey 来控制分布后者是传统做法用反亲和性把同一应用的副本推开。给你看我实际用在生产环境的一段配置affinity: podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 podAffinityTerm: labelSelector: matchLabels: app: order-service topologyKey: kubernetes.io/hostname topologySpreadConstraints: - maxSkew: 1 topologyKey: kubernetes.io/hostname whenUnsatisfiable: DoNotSchedule labelSelector: matchLabels: app: order-servicemaxSkew: 1 的含义是任意两个节点上的 Pod 数量差不能超过 1whenUnsatisfiable 设为 DoNotSchedule 表示如果无法满足就直接不调度这样集群资源不足时新增 Pod 会处于 Pending 状态而不是硬塞到同一节点。我见过有人把它设成 ScheduleAnyway结果打散效果直接被架空了还是要根据业务容忍度来选择。如果你在多可用区比如 AWS 的 us-east-1a、1b、1c部署topologyKey 要换成“topology.kubernetes.io/zone”ensemble 才能跨可用区容灾。单节点打散能防节点故障跨可用区打散才能防机房级别故障这俩都不该省。1.2 别小看优雅关停滚动更新和节点排水时最容易掉链子Deployment 高可用里另一个藏着坑的地方是 Pod 终止流程。我发现很多生产事故不是发生在流量高峰而是发生在发布和节点维护的时候。K8s 默认删除 Pod 会先把它标记为 Terminating然后发 SIGTERM 给主进程等它做完收尾再强制杀掉。如果主进程不处理 SIGTERM、或者处理得太快请求就会大量报错。解决这个问题的关键在 Pod 里配置生命周期钩子和优雅终止时间。preStop hook 可以在 SIGTERM 之前先跑一段脚本用来通知注册中心摘除节点、等待存量请求处理完。terminationGracePeriodSeconds 则控制 K8s 最多等多久超过之后发 SIGKILL。生产环境里我是这么设计的lifecycle: preStop: exec: command: - /bin/sh - -c - | echo draining from service discovery... sleep 5 curl -X POST http://localhost:8080/actuator/shutdown terminationGracePeriodSeconds: 60sleep 5 的目的是给负载均衡器一点时间让它把新请求调度到别的副本上。注意这个值不能乱加我见过有人直接 sleep 120结果 Deployment 每次更新都像乌龟爬发布延迟变成事故。合理的做法是让 sleep 时间略大于负载均衡的健康检查间隔一般 5~10 秒足够。还有一个细节如果服务用的是 gRPC 长连接K8s 默认不会主动断开存量连接因此你还需要在 preStop 里调用一个接口让连接优雅关闭。这个坑不实际踩过很难提前想到。1.3 滚动升级策略maxSurge 和 maxUnavailable 的黄金比例Deployment 的滚动更新策略里有三个重要参数maxSurge、maxUnavailable、minReadySeconds。很多人根本不动它们全部用默认值结果发布时老实例全退、新实例全起中间两秒服务直接不可用。maxSurge 表示允许超出期望副本数的新 Pod 数量maxUnavailable 表示允许不可用的旧 Pod 数量。生产环境我常用的组合是strategy: type: RollingUpdate rollingUpdate: maxSurge: 1 maxUnavailable: 0用这个组合新 Pod 先拉起一个等它 Ready然后才终止一个旧 Pod保证整个发布过程永远不会出现可用副本数为零的时刻。代价是发布期间节点资源消耗会多一份副本的量需要在集群容量上留有余量。maxSurge 也可以设成百分比比如 25%。我个人的经验是对于核心链路服务明确用数字 1 更可控对于副本数本来就很大的服务比如 20 个副本用 25% 更灵活。minReadySeconds 同样值得设置它让新 Pod 至少 Ready 多少秒之后才被认定为可用。推荐至少设 30 秒避免主进程刚起来还没完成初始化就被拉入流量池。有些 Java 应用启动时间超过 1 分钟那这个值要相应调大。配合 readinessProbe 和 minReadySeconds才能真正做到“Ready 了才接流量”。2. StatefulSet 为什么存在稳定身份、稳定存储、有序操作2.1 无状态应用和有状态应用的差别到底在哪很多初学者对 Deployment 和 StatefulSet 的区别一脸懵。其实一句话就能讲明白Deployment 假设应用实例长一个样谁死了谁顶上新 Pod 和旧 Pod 完全等价StatefulSet 则假设每个实例有自己独立的身份和存储一个好的给另一个好的不能随便替换。用员工来类比Deployment 像是临时工岗位张三走了李四来工作内容完全一样工牌换不换无所谓StatefulSet 像是核心研发岗位每个人都有专属工位、专属电脑、专属账号换一个人就得把工位和电脑都保住。有状态服务不能像无状态服务那样随便漂移它需要固定的网络标识方便客户端记住你也需要固定的存储卷比如数据库文件不能临时换位置。我最早开始用 StatefulSet 是为了在 K8s 里搭 Kafka。Kafka 每个 broker 都有 broker.id而且数据分区分片的位置和 broker 一一对应。如果我用 Deployment 部署Pod 每次重建 IP 都会变broker 之间的通信地址就会失效集群直接崩掉。后来改 StatefulSet每个 Pod 有固定的名字和固定的网络标识broker.id 可以按序号固定数据盘也按序号绑定问题瞬间解决。2.2 “身份感”的具体体现稳定网络标识与 Headless ServiceStatefulSet 最核心的设计是给每个 Pod 一个有序的、永久的“名字”。举个例子StatefulSet 叫 kafka副本数配成 3那么它的 Pod 就固定叫 kafka-0、kafka-1、kafka-2。不管它们重建多少次、漂移到哪个节点名字永远不变。但光有名字还不够K8s 里 Pod 之间通信靠 DNS所以 StatefulSet 还必须配一个 Headless Serviceheadless service 就是 clusterIP 为 None 的 Service。有了它每个 Pod 才能拿到独立的 DNS 记录格式是pod-name.service-name.namespace.svc.cluster.local。这样 kafka-0 无论被调度到哪台节点它的 DNS 地址始终是 kafka-0.kafka.default.svc.cluster.local。依赖这个地址的客户端不会因为 Pod 重启、IP 变化而断连。YAML 里定义 Headless Service 的方式很简单apiVersion: v1 kind: Service metadata: name: kafka labels: app: kafka spec: clusterIP: None selector: app: kafka ports: - port: 9092 name: clientclusterIP: None 是关键。看到这一行K8s 就不会给 Service 分配虚拟 IP而是直接生成 Pod 级别的 DNS 记录。客户端要访问集群里的任意一个 broker直接解析 kafka-0.kafka 这种地址就行。2.3 “稳定存储”和 volumeClaimTemplates数据不丢的秘密有状态应用的另一个刚需是数据不丢。Pod 可以重建但数据卷必须跟 Pod 绑定。StatefulSet 提供的方案是 volumeClaimTemplates——直接在 StatefulSet 里定义 PVC 模板每创建一个 PodK8s 就自动给它生成一份对应的 PVC。PVC 的名字是固定的叫pvc-name-pod-name比如>volumeClaimTemplates: - metadata: name: data spec: accessModes: [ ReadWriteOnce ] resources: requests: storage: 20Gi storageClassName: managed-premiumstorageClassName 我建议不要省略。如果集群里有多个 StorageClass不写的话会用默认值一旦默认值不是你要的那个比如用的是本地磁盘而非云盘数据可能落在节点本地节点坏了数据就没了。生产环境里一定要明确指定 StorageClass别把命运交给“默认”。2.4 有序控制从创建到删除一切都讲秩序StatefulSet 的第三大特性是有序性体现在两个地方部署顺序和删除顺序。创建新 Pod 时默认按序号从 0 到 n-1 一个一个创建。为什么不能并行创建因为很多分布式系统要求先启动的节点成为“种子节点”后面的节点加入时要去问它要数据比如 Kafka 的 controller。如果全并行启动大家互相找不到集群状态就乱了。删除 Pod 时则按从 n-1 到 0 的逆序逐个删除。这与 Kafka 缩容时的数据迁移顺序是一致的先摘除编号最大的 broker让它把数据迁移出去再删 Pod避免把有数据残留的 Pod 突然杀没。StatefulSet 里还有一个参数叫 podManagementPolicy默认是 OrderedReady顺序创建也可以设成 Parallel并行创建。如果是 ZooKeeper、Kafka、Elasticsearch 这类强依赖启动顺序的服务务必用默认的 OrderedReady如果是可以并行启动的有状态服务部分缓存类中间件Parallel 能显著缩短启动时间。我在实际项目里见过有人把 Kafka 的 podManagementPolicy 改成 Parallel结果 ZooKeeper 还没准备好Kafka 的 broker 就全起来了整个集群折腾了一个多小时才恢复。3. StatefulSet 全解析实战从 Redis 集群开始3.1 为什么要用 StatefulSet 部署 Redis ClusterRedis 集群是高可用架构里的常客。用 StatefulSet 搭建 Redis Cluster 是一个很经典场景也能把 StatefulSet 的特性串起来讲明白。Redis Cluster 要求每个节点有一个固定 ID节点之间通过 gossip 协议互相通信而且每个节点承担不同的 slot哈希槽。如果节点的 IP 或 DNS 每次重启都变Redis 的 cluster 状态会迅速崩溃。用 StatefulSet 部署每个节点有固定 DNS 名重启后集群依然能通过 DNS 找到彼此再配合持久化存储做数据保护这就是 Redis 集群高可用的基础。我建议初学者先别急着上 Operator先用原生 StatefulSet 手工部署一个最小 Redis 集群这能帮你把 StatefulSet 的工作原理彻底摸清。Operator 是帮你偷懒的不是帮你补课的。3.2 一个可以直接套用的 StatefulSet 配置Redis 示例这个配置我用过多次虽不是最精简但每一步都有实际用途。apiVersion: v1 kind: Service metadata: name: redis labels: app: redis spec: clusterIP: None selector: app: redis ports: - port: 6379 name: redis-client --- apiVersion: apps/v1 kind: StatefulSet metadata: name: redis spec: serviceName: redis replicas: 6 selector: matchLabels: app: redis template: metadata: labels: app: redis spec: affinity: podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 podAffinityTerm: topologyKey: kubernetes.io/hostname labelSelector: matchLabels: app: redis containers: - name: redis image: redis:7.0-alpine command: - redis-server - /usr/local/etc/redis/redis.conf env: - name: POD_IP valueFrom: fieldRef: fieldPath: status.podIP ports: - containerPort: 6379 name: redis volumeMounts: - name: data mountPath: /data livenessProbe: exec: command: - redis-cli - ping initialDelaySeconds: 20 periodSeconds: 10 readinessProbe: exec: command: - redis-cli - ping initialDelaySeconds: 10 periodSeconds: 5 volumeClaimTemplates: - metadata: name: data spec: accessModes: [ ReadWriteOnce ] storageClassName: managed-premium resources: requests: storage: 10Gi注意几个细节。serviceName 必须指向那个 Headless Service 的名字没有它Pod 的身份 DNS 记录就不会生成。podAntiAffinity 我用的是 preferred软反亲和因为 Redis 集群 6 个实例有时候不一定能完全分散到 6 台机器硬性要求会带来调度失败。生产环境如果节点足够也可以换成 requiredDuringSchedulingIgnoredDuringExecution优先保障。startup 阶段可能遇到 Redis 卡在 loading 数据的情况此时 livenessProbe 如果用 redis-cli ping 可能会误杀。我建议给 Redis 加上 startupProbe或者把 livenessProbe 的 initialDelaySeconds 调大一些保底数据加载时间。3.3 初始化集群先让每个 Pod 稳定再做 cluster meetStatefulSet 创建完6 个 Pod 启动后Redis 还只是 6 个独立实例需要执行 cluster init。这一步典型做法是先确认所有 Pod 变成 Running 并 Readykubectl get pod -l appredis -o wide然后进入第一个 Pod用 redis-cli 执行集群初始化把每个节点加进去。kubectl exec -it redis-0 -- redis-cli --cluster create \ redis-0.redis.default.svc.cluster.local:6379 \ redis-1.redis.default.svc.cluster.local:6379 \ redis-2.redis.default.svc.cluster.local:6379 \ redis-3.redis.default.svc.cluster.local:6379 \ redis-4.redis.default.svc.cluster.local:6379 \ redis-5.redis.default.svc.cluster.local:6379 \ --cluster-replicas 1用 DNS 名而不是 Pod IP 非常重要。如果这里你图省事写了 IP一旦 Pod 重建、IP 变化Redis 集群会重新变成“陌生人”。用 DNS 名就算 Pod 被调度到别的节点下次启动后依然能找到彼此。这里其实有一个生产环境必须做的调整Redis 默认会用自己的主机名拼接集群信息进入容器后 hostname 其实就是固定的 Pod 名比如 redis-0所以它生成的 cluster nodes 信息里会带上 redis-0 这个主机名。只要客户端和节点都通过同一个 DNS 解析到 redis-0就能建立稳定连接。千万别在容器里手动改 hostname也不要让 Pod 和 Service 名对不上否则 gossip 协议就乱了。3.4 弹性伸缩与升级StatefulSet 的两种常见操作StatefulSet 支持直接kubectl scale statefulset redis --replicas6扩缩容。扩容时注意 Redis 集群新节点不会自动加入集群你得手工执行cluster meet缩容前建议先手工执行cluster forget让其他节点忘记这个即将下线的节点再缩容否则集群里会残留一堆“标记下线”的节点信息。升级镜像时StatefulSet 默认的 RollingUpdate 策略是一个一个更新。这和 Deployment 的思路不同对有状态应用来说同时把 6 个 Redis 全换新数据同步负载瞬间拉满反而容易造成集群抖动。你也可以把 strategy 改成 onDelete意思是只有你手动删除某个 Pod它才会按新配置重建。这个策略适合你想自己控制升级节奏的场景比如先升级 redis-0 观察一天再升级剩下节点。我自己的经验是Redis 这种集群升级前先看redis-cli cluster info确保 cluster_stateok然后一次只升级一个节点并且升级完成后等 cluster_state 重新变成 ok再动下一个。动作慢一点事故少一点。3.5 存储扩容不是简单改 PVC 大小StatefulSet 的数据盘扩容也是高频需求。很多人在 volumeClaimTemplates 里把 storage 直接改成 20Gi然后 apply结果发现 PVC 大小根本没变。原因在于 PVC 一旦创建容量是绑定死的不能靠模板修改来“原地长胖”。正确做法是分三步先修改 StatefulSet 里的 volumeClaimTemplates新 Pod 会用新大小再单独kubectl edit pvc>kubectl patch pvc>journalctl -u kubelet -f docker ps | grep kube-apiserver kubectl get pods -n kube-system大概率能看到两种结果一是 etcd 容器反复重启说明磁盘 IO 或 CPU 资源跟不上二是 kube-apiserver 容器起不来日志里报证书过期或端口占用。处理方式也直接检查系统 swap 是否关闭、内存和 CPU 是否达到 kubeadm 最低要求把 kubelet 日志里的错误清掉后kubeadm reset再来一次。这个报错让我印象深刻因为它是新手向生产环境迈进的第一步。反过来说如果你连 master 启动都搞不定后面谈 Deploymnet 高可用也连 p 都谈不了。另外提醒一点初始化失败后千万不要直接在原环境反复 init先 reset 清干净否则残留的 etcd 数据会让下一次初始化更诡异。4.2 StatefulSet 里的 Pod 被删后PVC 绑定为什么会丢删除 StatefulSet Pod 时有个细节如果你执行的是kubectl delete statefulset redisPod 会被删除但 PVC 大多数情况下不会被级联删除这其实是 K8s 保护数据的行为。但如果有人手贱执行了kubectl delete pvc>