K8S Replication Controller
Replication Controller可确保在任何时间运行指定数量的pod副本。换句话说，ReplicationController确保一个pod或一组同类pod始终处于可用状态。
可以理解为Replication Controller （RC）是基于 K8S Pod对象之上的，控制Pod副本数量的更高层次的抽象。
工作原理
如果集群环境中Pod数量大于期望值，则RC自动终止额外的Pod。如果Pod数量少于期望值，RC将启动更多的Pod，保证Pod数量始终满足期望值。与手动创建Pod不同，使用RC维护的Pod在出现故障、删除、终止时会自动替换。因此，即使应用程序只需要一个Pod，也应该使用Replication Controller。RC类似于进程管理器，但是RC不是在单节点上管理多个进程，而是在K8S集群多节点上管理多个Pod。
为了方便书写和沟通，Replication Controller 在日常使用中通常缩写为 rc, 并且作为kubectl命令的快捷使用方式。
一个简单的例子是创建一个ReplicationController对象，以可靠地无限期运行Pod的一个实例。更复杂的用例是运行相同Pod服务的多个副本，例如web服务器(相当于为了满足高可用，将web服务进行集群部署)。
运行案例
启动案例
此案例使用Replication Controller配置三个nginx web服务器集群。
# 创建 replication.yaml 文件，文件内容如下
apiVersion: v1
kind: ReplicationController
metadata:
name: nginx
spec:
# 定义副本数量
replicas: 3
selector:
app: nginx
template:
metadata:
name: nginx
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
通过kubectl 命令运行以上配置案例
kubectl apply -f replication.yaml
启动状态
使用以下命令检查RC状态
kubectl describe replicationcontrollers/nginx
如上图所示，创建了三个pod，都处于正在运行状态(相比使用keepalive + nginx 手动创建集群而言，这种方式创建的nginx集群太香了 )。
Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed
如果需要使用更为简单方式罗列出ReplicationController 下的所有Pod，可以使用以下命令
# app=nginx 跟对象定义yaml文件中的信息一致
pods=$(kubectl get pods --selector=app=nginx --output=jsonpath={.items..metadata.name})
echo $pods
shell 中断输出结果类似
nginx-9zczq nginx-gmpq6 nginx-wp4g8
查看集群中所有pod
kubectl get rc
参数说明
在之前的案例中，我们使用yaml配置文件创建了K8S RC对象，现在来学习一下各参数的意义：
-
跟与所有其他Kubernetes 对象配置一样，ReplicationController需要apiVersion、kind和 metadata 字段。
- apiVersion 表示对象版本信息
- kind 表示对象类型 可以是Pod 、ReplicationSet、Deployment等等，这里设置 ReplicationController，即RC
- metadata 表示对象元数据，如名称 这里设置RC对象名称为 nginx
当K8S创建新的Pod时，RC配置文件中的 .metadata.name 配置作为Pod名称的基础。如上面提到的三个nginx节点不同的Pod名称
nginx-9zczq nginx-gmpq6 nginx-wp4g8 -
Pod Template 模板 - .spec.template 是**.spec** 部分唯一需要设置的字段
- .spec.template 定义 Pod 相关信息（可以理解为Pod 模板）但是该部分不需要 apiVersion
、kind - 除了Pod模板的必填字段外，ReplicationController中的 .spec.template 还必须指定适当的标签；适当的重新启动策略。对于标签名称，请确保不要与其他控制器重叠。
- 仅允许.spec.template.spec.restartPolicy等于Always，如果未指定，则为默认值
- .spec.template 定义 Pod 相关信息（可以理解为Pod 模板）但是该部分不需要 apiVersion
-
RC label
ReplicationController 本身可以单独设置label标签（.metadata.labels）。通常，您可以将这些标签设置为与.spec.template.metadata.labels；如果未指定.metadata.labels，则默认为.spec.template.metadata.labels。但是，允许它们不同，并且.metadata.labels不会影响ReplicationController的行为。
-
Pod Selector
-
.spec.selector字段是标签选择器。ReplicationController使用与选择器匹配的标签管理所有pod。
-
如果指定，.spec.template.metadata.labels必须等于.spec.selector，否则API将拒绝它。如果未指定.spec.selector，则默认为.spec.template.metadata.labels。
-
-
RC 副本
用户可以通过设置.spec.replicas参数，来控制pod的运行数量。可以简单理解为该参数控制pod运行实例的节点数，该参数非常重要，如果未指定.spec.creplica，则默认值为1。
RC 验证
上面也提到过，从Replication Controller 的定义中可知，RC控制Pod运行的数量，现在来测试下，手动的删除Pod节点，测试一下RC是否会自动进行恢复Pod数量。
原始节点
请注意，记住上面三个Pod名称，看后续RC自动遇到故障自动恢复的节点名称是否一致
删除节点
目前RC里面运行三个Pod信息，现在手动删除Pod节点，模拟某一个节点遇到故障，看RC是否会自动恢复。
kubectl delete pod nginx-gmpq6
验证结果
在使用命令删除Pod的之后，以极快的速度在其他shell终端查看RC的运行状态
kubectl describe replicationcontrollers/nginx
如上图可知，RC中运行的Pod数量减少为2，等待一会儿再次输入命令查看 RC运行状态，Pod运行的数量变成了3个
Annotations: Replicas: 3 current / 3 desired
Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed
# 另外，使用以下命令查看 pod启动时间
kubectl get pods
启动一个nginx 节点的启动时间明显少于另外两个节点，证明Pod已经发生了重启，且Pod名称也已经发生了变化。(截图中的三个nginx名称跟最初记录的原始节点的名称并不完全一致，是因为测试过程中多次删除Pod导致)
