关于K8s文档中Pod UID与重调度规则的技术咨询

解答 #

问题1：关于Pod重调度的说明

这句话不是指kubelet在节点上重启Pod容器的场景。这里的“重调度”特指：一个已经绑定到某节点的Pod（通过唯一UID标识），永远不会被Kubernetes调度器重新分配到其他节点运行。

kubelet在节点上重启Pod的容器，本质是在同一个Pod实例（UID不变）下重启容器进程，Pod的绑定节点、身份标识都没有变化，这不属于“重调度”的范畴。

问题2：Pod被替换的场景与验证方法

这种“同名不同UID”的Pod替换，对应Kubernetes中Pod实例被彻底替换的场景，常见情况包括：

• 手动删除原Pod后，重新创建同名的新Pod
• 原Pod所在节点故障/不可用，由控制器（如StatefulSet）在其他节点重建同名Pod
• 因Pod调度约束变更（如节点亲和性修改），原Pod被删除并重新调度到新节点（若手动指定同名）

模拟验证方法：

1. 手动替换同名Pod

   • 先创建测试Pod并记录UID：

     kubectl apply -f test-crash.yaml
     kubectl get pod test-crash -o=jsonpath='{.metadata.uid}'
     

   • 删除原Pod：

     kubectl delete pod test-crash
     

   • 重新创建同名Pod，再次查看UID：

     kubectl apply -f test-crash.yaml
     kubectl get pod test-crash -o=jsonpath='{.metadata.uid}'
     

     此时会发现UID已完全不同，但Pod名称保持一致。

2. 节点故障触发StatefulSet重建同名Pod

   • 创建StatefulSet资源：

     apiVersion: apps/v1
     kind: StatefulSet
     metadata:
       name: test-sts
     spec:
       serviceName: "test-sts"
       replicas: 1
       selector:
         matchLabels:
           app: test-sts
       template:
         metadata:
           labels:
             app: test-sts
         spec:
           containers:
           - name: busybox
             image: busybox
             command: ['sh', '-c', 'sleep infinity']
     

   • 查看Pod的UID与所在节点：

     kubectl get pod test-sts-0 -o=jsonpath='{.metadata.uid} {.spec.nodeName}'
     

   • 将Pod所在节点标记为不可调度并驱逐所有Pod：

     kubectl cordon <节点名称>
     kubectl drain <节点名称> --ignore-daemonsets
     

   • 等待StatefulSet完成重建，再次查看Pod信息：

     kubectl get pod test-sts-0 -o=jsonpath='{.metadata.uid} {.spec.nodeName}'
     

     会看到Pod名称仍为test-sts-0，但UID已变更，且运行在新的节点上。

关于你的测试无UID变化的原因

你创建的test-crashPod，容器退出后kubelet会根据默认restartPolicy: Always重启容器，但这只是Pod内部容器进程的重启，Pod实例本身（由UID标识）并未被删除或重建，因此UID不会发生变化。这种情况不属于“Pod被替换”的场景。

内容的提问来源于stack exchange，提问作者Trịnh Đức Bình