如何理解ReplicationController及其配置，相信很多沒有經(jīng)驗(yàn)的人對此束手無策，為此本文總結(jié)了問題出現(xiàn)的原因和解決方法，通過這篇文章希望你能解決這個(gè)問題。

在互助等地區(qū)，都構(gòu)建了全面的區(qū)域性戰(zhàn)略布局，加強(qiáng)發(fā)展的系統(tǒng)性、市場前瞻性、產(chǎn)品創(chuàng)新能力，以專注、極致的服務(wù)理念，為客戶提供成都做網(wǎng)站、網(wǎng)站設(shè)計(jì) 網(wǎng)站設(shè)計(jì)制作按需定制網(wǎng)站,公司網(wǎng)站建設(shè),企業(yè)網(wǎng)站建設(shè),成都品牌網(wǎng)站建設(shè),成都全網(wǎng)營銷推廣,成都外貿(mào)網(wǎng)站制作,互助網(wǎng)站建設(shè)費(fèi)用合理。

在介紹ReplicationController之前，我們先思考一下下圖所示的場景，Kubernetes集群包含2個(gè)Node，每個(gè)Node上均運(yùn)行一個(gè)同類型的Pod來做負(fù)載均衡，如果其中某個(gè)Node被管理員強(qiáng)制關(guān)機(jī)或者Node意外宕機(jī)時(shí)，會(huì)發(fā)生什么呢？

由于Pod被調(diào)度到某個(gè)Node后就與Node綁定，當(dāng)Node宕機(jī)后，Node中的所有Pod也都停止運(yùn)行。 上圖所示場景中，Node2被關(guān)閉后，相應(yīng)的Pod-2也會(huì)停止，Pod-2并不會(huì)重新被調(diào)度到Node1。

實(shí)際應(yīng)用場景中，維持穩(wěn)定的Pod副本數(shù)是非常必要的，因此Kubernetes引入了ReplicationController。

工作機(jī)制

ReplicationController用于定義指定Pod的副本數(shù)，與創(chuàng)建多個(gè)Pod相比，它可以保證Pod意外終止后，集群中仍會(huì)有指定個(gè)數(shù)的Pod副本在運(yùn)行。運(yùn)行于kube-controller-manager組件中的ReplicationController控制器（控制器和資源名相同）會(huì)監(jiān)控集群中Pod的副本數(shù)：

• 如果Pod數(shù)量已經(jīng)超出預(yù)期，那么ReplicationController將會(huì)刪除部分Pod，使Pod數(shù)量符合預(yù)期。

• 如果Pod數(shù)量低于預(yù)期，那么ReplicationController將會(huì)創(chuàng)建新的Pod，使用Pod數(shù)量符合預(yù)期。

ReplicationController控制器會(huì)時(shí)刻監(jiān)控Pod的副本數(shù)量，一旦發(fā)現(xiàn)Pod數(shù)量不符合預(yù)期（Pod數(shù)量過多或過少），均會(huì)通過增加或刪除Pod的手段來讓Pod維持在預(yù)期數(shù)量。

ReplicationController控制器更像是一個(gè)Pod監(jiān)管者，它監(jiān)管的是整個(gè)集群范圍的Pod。在本節(jié)開頭中所引用的場景中，如果使用ReplicationController創(chuàng)建兩個(gè)Pod的副本，當(dāng)其中一個(gè)Pod意外終止后，新的Pod會(huì)被創(chuàng)建出來，從而保證集群中仍有兩個(gè)副本在運(yùn)行，整體工作機(jī)制如下圖所示：

通過示意圖可以看到，通過ReplicationController創(chuàng)建兩個(gè)Pod情況下，當(dāng)Node2被關(guān)閉后，運(yùn)行于其上的Pod被重新調(diào)度到Node1中運(yùn)行，集群中總的Pod數(shù)始終保持在2個(gè)。

ReplicationController配置

一個(gè)簡單的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

其中有三個(gè)關(guān)鍵的項(xiàng)：

• spec.replicas指定了期望的Pod副本數(shù)；

• spec.selector指定了Selector，ReplicationController正是通過該Selector來查找Pod對象；

• spec.template指定了Pod的模版，當(dāng)ReplicationController發(fā)現(xiàn)Pod數(shù)量低于預(yù)期時(shí)將使用該模版創(chuàng)建新的Pod。

Pod 模板

Pod模版用于Kubernetes內(nèi)部動(dòng)態(tài)地創(chuàng)建Pod，它廣泛應(yīng)用于各種控制器中，包括本節(jié)中介紹的ReplicationController，以及后續(xù)將要介紹的Deployments、Jobs和DaemonSets等等。

從數(shù)據(jù)結(jié)構(gòu)上看，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設(shè)計(jì)初衷是維持集群中指定類型Pod的副本數(shù)，但它只支持等值Selector，不支持基于集合的Selector。為了不違背API兼容性原則，Kubernetes不得已提供了另一種制器ReplicaSet來替換它。

所以，實(shí)際場景中幾乎不會(huì)用到ReplicationController，雖然它是一個(gè)穩(wěn)定的API。

看完上述內(nèi)容，你們掌握如何理解ReplicationController及其配置的方法了嗎？如果還想學(xué)到更多技能或想了解更多相關(guān)內(nèi)容，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝各位的閱讀！