如何理解ReplicationController及其配置

如何理解ReplicationController及其配置，相信很多没有经验的人对此束手无策，为此本文总结了问题出现的原因和解决方法，通过这篇文章希望你能解决这个问题。

在互助等地区，都构建了全面的区域性战略布局，加强发展的系统性、市场前瞻性、产品创新能力，以专注、极致的服务理念，为客户提供成都做网站、网站设计 网站设计制作按需定制网站,公司网站建设,企业网站建设,成都品牌网站建设,成都全网营销推广,成都外贸网站制作,互助网站建设费用合理。

在介绍ReplicationController之前，我们先思考一下下图所示的场景，Kubernetes集群包含2个Node，每个Node上均运行一个同类型的Pod来做负载均衡，如果其中某个Node被管理员强制关机或者Node意外宕机时，会发生什么呢？

由于Pod被调度到某个Node后就与Node绑定，当Node宕机后，Node中的所有Pod也都停止运行。 上图所示场景中，Node2被关闭后，相应的Pod-2也会停止，Pod-2并不会重新被调度到Node1。

实际应用场景中，维持稳定的Pod副本数是非常必要的，因此Kubernetes引入了ReplicationController。

工作机制

ReplicationController用于定义指定Pod的副本数，与创建多个Pod相比，它可以保证Pod意外终止后，集群中仍会有指定个数的Pod副本在运行。运行于kube-controller-manager组件中的ReplicationController控制器（控制器和资源名相同）会监控集群中Pod的副本数：

• 如果Pod数量已经超出预期，那么ReplicationController将会删除部分Pod，使Pod数量符合预期。

• 如果Pod数量低于预期，那么ReplicationController将会创建新的Pod，使用Pod数量符合预期。

ReplicationController控制器会时刻监控Pod的副本数量，一旦发现Pod数量不符合预期（Pod数量过多或过少），均会通过增加或删除Pod的手段来让Pod维持在预期数量。

ReplicationController控制器更像是一个Pod监管者，它监管的是整个集群范围的Pod。在本节开头中所引用的场景中，如果使用ReplicationController创建两个Pod的副本，当其中一个Pod意外终止后，新的Pod会被创建出来，从而保证集群中仍有两个副本在运行，整体工作机制如下图所示：

通过示意图可以看到，通过ReplicationController创建两个Pod情况下，当Node2被关闭后，运行于其上的Pod被重新调度到Node1中运行，集群中总的Pod数始终保持在2个。

ReplicationController配置

一个简单的ReplicationController资源配置如下所示：

apiVersion: v1
kind: ReplicationController
metadata:
  name: replication-controller-runs-pod
spec:
  replicas: 3
  selector:
    app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.19.0

其中有三个关键的项：

• spec.replicas指定了期望的Pod副本数；

• spec.selector指定了Selector，ReplicationController正是通过该Selector来查找Pod对象；

• spec.template指定了Pod的模版，当ReplicationController发现Pod数量低于预期时将使用该模版创建新的Pod。

Pod 模板

Pod模版用于Kubernetes内部动态地创建Pod，它广泛应用于各种控制器中，包括本节中介绍的ReplicationController，以及后续将要介绍的Deployments、Jobs和DaemonSets等等。

从数据结构上看，Pod模版（PodTemplateSpec）可以理解为简化版的Pod，它只保留了Pod的Metadata和Spec，如下所示：

type PodTemplateSpec struct {
	// Metadata of the pods created from this template.
	// +optional
	metav1.ObjectMeta

	// Spec defines the behavior of a pod.
	// +optional
	Spec PodSpec
}

ReplicationController设计初衷是维持集群中指定类型Pod的副本数，但它只支持等值Selector，不支持基于集合的Selector。为了不违背API兼容性原则，Kubernetes不得已提供了另一种制器ReplicaSet来替换它。

所以，实际场景中几乎不会用到ReplicationController，虽然它是一个稳定的API。

看完上述内容，你们掌握如何理解ReplicationController及其配置的方法了吗？如果还想学到更多技能或想了解更多相关内容，欢迎关注创新互联行业资讯频道，感谢各位的阅读！