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，如果未指定，则为默认值

• 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导致)