K8s跨机房Pod打散需统一节点dc标签并配置topologySpreadConstraints：先用kubectl label统一打标，再在Deployment中设置maxSkew、topologyKey=dc及whenUnsatisfiable策略，最后通过kubectl get node查标签+统计验证分布。
在K8s中实现跨机房（即跨物理位置、跨IDC）的Pod打散，必须让调度器能识别“机房”这个拓扑域——这依赖于节点标签是否真实反映物理归属，且topologyKey必须指向该标签键。若标签错误或未打标，配置再正确也完全失效。
确认并统一机房标签
先检查集群中所有节点是否已打上明确标识机房的标签，例如dc=shanghai-idc1或rack=beijing-dc3。运行：kubectl get nodes -o wide --show-labels | grep -E "(dc=|rack=)"。
若输出为空或值混乱（如有的节点标dc=sh，有的标datacenter=shanghai），必须统一修正。不统一就无法定义拓扑域，后续所有配置都无效。
用kubectl label node <node-name> dc=shanghai-idc1 --overwrite逐个补全，【所有参与调度的节点都必须有且仅有一个dc标签值，不可为空、不可重复使用不同键名】。
编写Deployment并嵌入TopologySpreadConstraints
在Deployment的spec.template.spec层级下添加topologySpreadConstraints字段：
方法一：强约束，拒绝不合规调度
设置whenUnsatisfiable: DoNotSchedule，确保绝不把多个副本塞进同一机房。适用于核心服务，如订单中心、支付网关。
topologySpreadConstraints:- maxSkew: 1 topologyKey: dc whenUnsatisfiable: DoNotSchedule labelSelector: matchLabels: app: order-service
方法二：柔性约束，优先均衡但不阻断
设whenUnsatisfiable: ScheduleAnyway，当机房数量少于副本数时仍可调度，只是会按偏差最小化排序节点。适合日志采集、监控探针等非关键组件。
- maxSkew: 2 topologyKey: dc whenUnsatisfiable: ScheduleAnyway labelSelector: { matchLabels: { app: fluent-bit } }
验证Pod是否真正在跨机房分布
第一步：部署后立即执行kubectl get pods -o wide，观察每个Pod的NODE列对应的是哪个节点。
第二步：对每个节点反查其机房标签：kubectl get node <node-name> -o jsonpath='{.metadata.labels.dc}'。
第三步：统计各dc值下的Pod数量，例如：kubectl get pods -l app=order-service -o jsonpath='{range .items[*]}{.spec.nodeName}{"\t"}{.metadata.labels.app}{"\n"}{end}' | xargs -n2 sh -c 'kubectl get node $0 -o jsonpath="{.metadata.labels.dc}" 2>/dev/null' | sort | uniq -c。
若某机房出现3个Pod而另一机房为0，说明maxSkew设得过大或标签未生效；若全部Pod卡在Pending状态，大概率是DoNotSchedule触发且可用机房数
