5.2.3 ReplicaSet 管控下的 Pod 对象
5.2.2 节中创建的 rc-example 通过标签选择器将拥有 “app=rs-demo” 标签的 Pod 资源收归与麾下，并确保其数量精确符合所期望的数目，使用标签选择器显示出的 Pod 资源列表也能验证这一点。然而，实际中存在着不少可能导致 Pod 对象数目与期望值不符合的可能性，如 Pod 对象的意外删除、Pod 对象标签的变动（已有的 Pod 资源变得不匹配控制器的标签选择器，或者外部的 Pod 资源标签变得匹配到了控制器的标签选择器）、控制器的标签选择器变动，甚至是工作节点故障等。ReplicaSet 控制器的和解循环过程能够实时监控到这类异常，并及时启动和解操作。
1. 缺少 Pod 副本
任何原因导致的相关 Pod 对象丢失，都会由 ReplicaSet 控制器自动补足。例如，手动删除上面列出的一个 Pod 对象，命令如下：
**[terminal]
**[delimiter $ ]**[command kubectl delete pods rs-example-cwvpn]
pod "rs-example-cwvpn" deleted
再次列出相关的 Pod 资源，可以看到 rs-example 控制器启动了删除多余 Pod 的操作，pod-example 正处于终止过程中：
**[terminal]
**[delimiter $ ]**[command kubectl get pods -l app=rs-demo]
NAME READY STATUS RESTARTS AGE
rs-example-cwvpn 1/1 Terminating 0 13m
rs-example-s47z9 1/1 Running 0 99s
rs-example-tc7d8 0/1 ContainerCreating 0 2s
另外，强制修改隶属于控制器 rs-example 的某 Pod 资源（匹配于标签控制器）的标签，会导致它不再被控制器作为副本计数，这也将触发控制器的 Pod 对象副本缺失补足机制。例如，将 rs-example-tc7d8 的标签 app 的值重置为空：
**[terminal]
**[delimiter $ ]**[command kubectl label pods rs-example-tc7d8 app= --overwrite]
pod/rs-example-tc7d8 labeled
列出 rs-example 相关的 Pod 对象的信息，发现 rs-example-tc7d8 已经消失不见了，并且正在创建新的对象副本。
**[terminal]
**[delimiter $ ]**[command kubectl get pods -l app=rs-demo]
NAME READY STATUS RESTARTS AGE
rs-example-42cw7 0/1 ContainerCreating 0 1s
rs-example-s47z9 1/1 Running 0 12m
由此可见，修改 Pod 资源的标签即可将其从控制器的管控之下移除，当然，修改后的标签他如果又能被其他控制器资源的标签选择器命中，则此时它又成了隶属于另一控制器的副本。如果修改其标签后的 Pod 对象不再隶属于任何控制器，那么它就将成为自主式 Pod，与此前手动直接创建的 Pod 对象的特征相同，即误删除或所在工作节点故障都会造成其永久性的消失。
2. 多处 Pod 副本
一旦被标签选择器匹配到的 Pod 资源数量因任何原因超出期望值，多余的部分都将被控制器自动删除。例如，为 pod-example 手动为其添加 “app: rs-demo” 标签：
**[terminal]
**[delimiter $ ]**[command kubectl label pods pod-example app=rs-demo]
pod/pod-example labeled
再次列出相关的 Pod 资源，可以看到 rs-example 控制器启动了删除多余 Pod 的操作，rs-example-42cw7 正处于终止过程中：
**[terminal]
**[delimiter $ ]**[command kubectl get pod -l app=rs-demo]
NAME READY STATUS RESTARTS AGE
pod-example 1/1 Running 1 6d23h
rs-example-42cw7 0/1 Terminating 0 10m
rs-example-s47z9 1/1 Running 0 23m
这就意味着，任何自主式的或本隶属于其他控制器的 Pod 资源其标签变动的结果一旦匹配到了其他的副本数足额的控制器，就会导致这类资源被删除。
查看 Pod 资源变动的相关事件
“kubectl describe replicasets” 命令可打印出 ReplicaSet 控制器的详细状态。从下面命令结果中 Events 一段也可以看出，rs-example 执行了 Pod 资源的创建和删除操作，为的就是确保其数量的精确性。
**[terminal]
**[delimiter $ ]**[command kubectl describe replicasets/rs-example]
Name: rs-example
Namespace: default
Selector: app=rs-demo
Labels: <none>
Annotations: kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"apps/v1","kind":"ReplicaSet","metadata":{"annotations":{},"name":"rs-example","namespace":"default"},"spec":{"replicas":2,"...
Replicas: 2 current / 2 desired
Pods Status: 2 Running / 0 Waiting / 0 Succeeded / 0 Failed
Pod Template:
Labels: app=rs-demo
Containers:
myapp:
Image: ikubernetes/myapp:v1
Port: 80/TCP
Host Port: 0/TCP
Environment: <none>
Mounts: <none>
Volumes: <none>
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulCreate 42m replicaset-controller Created pod: rs-example-q99nt
Normal SuccessfulCreate 42m replicaset-controller Created pod: rs-example-cwvpn
Normal SuccessfulCreate 30m replicaset-controller Created pod: rs-example-s47z9
Normal SuccessfulCreate 28m replicaset-controller Created pod: rs-example-tc7d8
事实上，ReplicaSet 控制器能对 Pod 对象数目的异常及时作出响应，是因为它向 API Server 注册监听（watch）了相关资源及其列表的变动信息，于是 API Server 会在变动发生时立即通知给相关的监听客户端。
而因节点自身故障而导致的 Pod 对象丢失，ReplicaSet 控制器一样会使用补足资源的方式进行处理，这里不再详细说明其过程。有兴趣的读者可通过直接关掉类似上面 Pod 对象运行所在的某一节点来检验其处理过程。