在日常Kubernetes运维实践中,你是否也曾遇到这样的情况:
👉 关键服务设置了多个副本(replicas),本想提高可用性; 👉 结果部署时多个副本却集中到了同一台节点上; 👉 一旦该节点宕机,所有副本“抱团下线”,导致服务整体中断!
这不是设计的问题,而是调度策略的缺失。 今天我们来实战讲解一个Kubernetes调度利器 —— Pod反亲和性(Pod Anti-Affinity),通过它,让服务副本自动分散部署,每台主机仅跑一个副本,从容应对节点故障,极大提升服务可用性。
Kubernetes 提供了亲和性(Affinity)与反亲和性(Anti-Affinity)调度规则,让 Pod 更加智能地选择节点。
希望与指定标签的 Pod 部署在同一节点上背景问题:
某业务部署了一个关键服务 nginx,副本数设置为2,但由于调度器默认无策略控制,两个副本被调度到了同一个节点。当节点故障时,两个副本一起失效,服务整体不可用。
解决目标:
通过配置 podAntiAffinity,强制同一节点上不能运行多个相同标签的Pod副本,实现副本自动分散部署。
requiredDuringSchedulingIgnoredDuringExecution
必须满足条件,调度器会严格执行,确保副本分散。preferredDuringSchedulingIgnoredDuringExecution
尽量满足条件,但如果无法满足也可以调度,会存在副本集中风险。以下是一个使用 硬性反亲和性 的 nginx Deployment 示例:
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx
labels:
app: nginx
spec:
replicas: 2
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- nginx
topologyKey: "kubernetes.io/hostname"
containers:
- name: nginx
image: nginx
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80
name: http
protocol: TCP🔍配置要点解析:
匹配标签为 app=nginx 的Pod⚠️ 注意:使用该策略前确保集群节点数量 ≥ 副本数,否则Pod可能调度失败。
部署完成后,两个 nginx 副本会分别运行在不同的节点上:
$ kubectl get pods -o wide
NAME READY STATUS NODE
nginx-7f46d78f9d-abcde 1/1 Running node1
nginx-7f46d78f9d-xyz12 1/1 Running node2即使某一节点宕机,另一副本依旧存活,保障服务持续可用。
通过 Pod 反亲和性(Pod Anti-Affinity),我们可以优雅地解决服务副本集中部署的问题,实现副本级别的高可用调度策略。 适用于数据库主备服务、Web多副本服务、微服务关键组件等场景,是 DevOps 与平台团队必须掌握的实战技巧!
如果你也在构建高可用Kubernetes服务集群,这一招一定要学会!📚
END
本文分享自 DevOps和k8s全栈技术 微信公众号,前往查看
如有侵权,请联系 cloudcommunity@tencent.com 删除。
本文参与 腾讯云自媒体同步曝光计划 ,欢迎热爱写作的你一起参与!