Kubernetes ReplicationController

ReplicationController

現(xiàn)在推薦使用配置 ReplicaSet 的 Deployment 來建立副本管理機制。

ReplicationController 確保在任何時候都有特定數(shù)量的 Pod 副本處于運行狀態(tài)。 換句話說，ReplicationController 確保一個 Pod 或一組同類的 Pod 總是可用的。

ReplicationController 如何工作 

當 Pod 數(shù)量過多時，ReplicationController 會終止多余的 Pod。當 Pod 數(shù)量太少時，ReplicationController 將會啟動新的 Pod。 與手動創(chuàng)建的 Pod 不同，由 ReplicationController 創(chuàng)建的 Pod 在失敗、被刪除或被終止時會被自動替換。 例如，在中斷性維護（如內(nèi)核升級）之后，你的 Pod 會在節(jié)點上重新創(chuàng)建。 因此，即使你的應用程序只需要一個 Pod，你也應該使用 ReplicationController 創(chuàng)建 Pod。 ReplicationController 類似于進程管理器，但是 ReplicationController 不是監(jiān)控單個節(jié)點上的單個進程，而是監(jiān)控跨多個節(jié)點的多個 Pod。

在討論中，ReplicationController 通?？s寫為 "rc"，并作為 kubectl 命令的快捷方式。

一個簡單的示例是創(chuàng)建一個 ReplicationController 對象來可靠地無限期地運行 Pod 的一個實例。 更復雜的用例是運行一個多副本服務（如 web 服務器）的若干相同副本。

運行一個示例 ReplicationController 

這個示例 ReplicationController 配置運行 nginx Web 服務器的三個副本。

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 apply -f https://k8s.io/examples/controllers/replication.yaml

輸出類似于：

replicationcontroller/nginx created

使用以下命令檢查 ReplicationController 的狀態(tài):

kubectl describe replicationcontrollers/nginx

輸出類似于：

Name:        nginx
Namespace:   default
Selector:    app=nginx
Labels:      app=nginx
Annotations:    <none>
Replicas:    3 current / 3 desired
Pods Status: 0 Running / 3 Waiting / 0 Succeeded / 0 Failed
Pod Template:
  Labels:       app=nginx
  Containers:
   nginx:
    Image:              nginx
    Port:               80/TCP
    Environment:        <none>
    Mounts:             <none>
  Volumes:              <none>
Events:
  FirstSeen       LastSeen     Count    From                        SubobjectPath    Type      Reason              Message
  ---------       --------     -----    ----                        -------------    ----      ------              -------
  20s             20s          1        {replication-controller }                    Normal    SuccessfulCreate    Created pod: nginx-qrm3m
  20s             20s          1        {replication-controller }                    Normal    SuccessfulCreate    Created pod: nginx-3ntk0
  20s             20s          1        {replication-controller }                    Normal    SuccessfulCreate    Created pod: nginx-4ok8v

在這里，創(chuàng)建了三個 Pod，但沒有一個 Pod 正在運行，這可能是因為正在拉取鏡像。 稍后，相同的命令可能會顯示：

Pods Status:    3 Running / 0 Waiting / 0 Succeeded / 0 Failed

要以機器可讀的形式列出屬于 ReplicationController 的所有 Pod，可以使用如下命令：

pods=$(kubectl get pods --selector=app=nginx --output=jsonpath={.items..metadata.name})
echo $pods

輸出類似于：

nginx-3ntk0 nginx-4ok8v nginx-qrm3m

這里，選擇算符與 ReplicationController 的選擇算符相同，并以不同的形式出現(xiàn)在 ?replication.yaml? 中。 ?--output=jsonpath? 選項指定了一個表達式，僅從返回列表中的每個 Pod 中獲取名稱。

編寫一個 ReplicationController 規(guī)約

與所有其它 Kubernetes 配置一樣，ReplicationController 需要 ?apiVersion?、 ?kind ?和 ?metadata ?字段。

ReplicationController 也需要一個 ?.spec? 部分。

Pod 模板 

?.spec.template? 是 ?.spec? 的唯一必需字段。

?.spec.template? 是一個 Pod 模板。 它的模式與 Pod 完全相同，只是它是嵌套的，沒有 ?apiVersion ?或 ?kind ?屬性。

除了 Pod 所需的字段外，ReplicationController 中的 Pod 模板必須指定適當?shù)臉撕灪瓦m當?shù)闹匦聠硬呗浴?nbsp;對于標簽，請確保不與其他控制器重疊。

只允許 ?.spec.template.spec.restartPolicy? 等于 ?Always?，如果沒有指定，這是默認值。

對于本地容器重啟，ReplicationController 委托給節(jié)點上的代理， 例如 Kubelet 或 Docker。

ReplicationController 上的標簽 

ReplicationController 本身可以有標簽 （?.metadata.labels?）。 通常，你可以將這些設置為 ?.spec.template.metadata.labels?； 如果沒有指定 ?.metadata.labels? 那么它默認為 ?.spec.template.metadata.labels?。

但是，Kubernetes 允許它們是不同的，?.metadata.labels? 不會影響 ReplicationController 的行為。

Pod 選擇算符

?.spec.selector? 字段是一個標簽選擇算符。 ReplicationController 管理標簽與選擇算符匹配的所有 Pod。 它不區(qū)分它創(chuàng)建或刪除的 Pod 和其他人或進程創(chuàng)建或刪除的 Pod。 這允許在不影響正在運行的 Pod 的情況下替換 ReplicationController。

如果指定了 ?.spec.template.metadata.labels?，它必須和 ?.spec.selector? 相同，否則它將被 API 拒絕。 如果沒有指定 ?.spec.selector?，它將默認為 ?.spec.template.metadata.labels?。

另外，通常不應直接使用另一個 ReplicationController 或另一個控制器（例如 Job） 來創(chuàng)建其標簽與該選擇算符匹配的任何 Pod。如果這樣做，ReplicationController 會認為它創(chuàng)建了這些 Pod。 Kubernetes 并沒有阻止你這樣做。

如果你的確創(chuàng)建了多個控制器并且其選擇算符之間存在重疊，那么你將不得不自己管理刪除操作。

多個副本

你可以通過設置 ?.spec.replicas? 來指定應該同時運行多少個 Pod。 在任何時候，處于運行狀態(tài)的 Pod 個數(shù)都可能高于或者低于設定值。例如，副本個數(shù)剛剛被增加或減少時，或者一個 Pod 處于優(yōu)雅終止過程中而其替代副本已經(jīng)提前開始創(chuàng)建時。

如果你沒有指定 ?.spec.replicas? ，那么它默認是 1。

使用 ReplicationController

刪除一個 ReplicationController 以及它的 Pod

要刪除一個 ReplicationController 以及它的 Pod，使用 ?kubectl delete?。 kubectl 將 ReplicationController 縮放為 0 并等待以便在刪除 ReplicationController 本身之前刪除每個 Pod。 如果這個 kubectl 命令被中斷，可以重新啟動它。

當使用 REST API 或客戶端庫時，你需要明確地執(zhí)行這些步驟（縮放副本為 0、 等待 Pod 刪除，之后刪除 ReplicationController 資源）。

只刪除 ReplicationController

你可以刪除一個 ReplicationController 而不影響它的任何 Pod。

使用 kubectl，為 ?kubectl delete? 指定 ?--cascade=orphan? 選項。

當使用 REST API 或客戶端庫(/zh/docs/reference/using-api/client-libraries)時，只需刪除 ReplicationController 對象。

一旦原始對象被刪除，你可以創(chuàng)建一個新的 ReplicationController 來替換它。 只要新的和舊的 ?.spec.selector? 相同，那么新的控制器將領養(yǎng)舊的 Pod。 但是，它不會做出任何努力使現(xiàn)有的 Pod 匹配新的、不同的 Pod 模板。 如果希望以受控方式更新 Pod 以使用新的 spec，請執(zhí)行滾動更新操作。

從 ReplicationController 中隔離 Pod

通過更改 Pod 的標簽，可以從 ReplicationController 的目標中刪除 Pod。 此技術可用于從服務中刪除 Pod 以進行調(diào)試、數(shù)據(jù)恢復等。以這種方式刪除的 Pod 將被自動替換（假設復制副本的數(shù)量也沒有更改）。

常見的使用模式

重新調(diào)度

如上所述，無論你想要繼續(xù)運行 1 個 Pod 還是 1000 個 Pod，一個 ReplicationController 都將確保存在指定數(shù)量的 Pod，即使在節(jié)點故障或 Pod 終止(例如，由于另一個控制代理的操作)的情況下也是如此。

擴縮容 

通過設置 ?replicas ?字段，ReplicationController 可以允許擴容或縮容副本的數(shù)量。 你可以手動或通過自動縮放控制代理來控制 ReplicationController 執(zhí)行此操作。

滾動更新

ReplicationController 的設計目的是通過逐個替換 Pod 以方便滾動更新服務。

如 #1353 PR 中所述，建議的方法是使用 1 個副本創(chuàng)建一個新的 ReplicationController， 逐個擴容新的（+1）和縮容舊的（-1）控制器，然后在舊的控制器達到 0 個副本后將其刪除。 這一方法能夠?qū)崿F(xiàn)可控的 Pod 集合更新，即使存在意外失效的狀況。

理想情況下，滾動更新控制器將考慮應用程序的就緒情況，并確保在任何給定時間都有足夠數(shù)量的 Pod 有效地提供服務。

這兩個 ReplicationController 將需要創(chuàng)建至少具有一個不同標簽的 Pod，比如 Pod 主要容器的鏡像標簽，因為通常是鏡像更新觸發(fā)滾動更新。

滾動更新是在客戶端工具 ?kubectl rolling-update? 中實現(xiàn)的。訪問 kubectl rolling-update 任務以獲得更多的具體示例。

多個版本跟蹤

除了在滾動更新過程中運行應用程序的多個版本之外，通常還會使用多個版本跟蹤來長時間， 甚至持續(xù)運行多個版本。這些跟蹤將根據(jù)標簽加以區(qū)分。

例如，一個服務可能把具有 ?tier in (frontend), environment in (prod)? 的所有 Pod 作為目標。 現(xiàn)在假設你有 10 個副本的 Pod 組成了這個層。但是你希望能夠 ?canary ?（金絲雀）發(fā)布這個組件的新版本。 你可以為大部分副本設置一個 ReplicationController，其中 ?replicas ?設置為 9， 標簽為 ?tier=frontend, environment=prod, track=stable? 而為 ?canary ?設置另一個 ReplicationController，其中 ?replicas ?設置為 1， 標簽為 ?tier=frontend, environment=prod, track=canary?。 現(xiàn)在這個服務覆蓋了 ?canary ?和非 ?canary ?Pod。但你可以單獨處理 ReplicationController，以測試、監(jiān)控結(jié)果等。

和服務一起使用 ReplicationController

多個 ReplicationController 可以位于一個服務的后面，例如，一部分流量流向舊版本， 一部分流量流向新版本。

一個 ReplicationController 永遠不會自行終止，但它不會像服務那樣長時間存活。 服務可以由多個 ReplicationController 控制的 Pod 組成，并且在服務的生命周期內(nèi) （例如，為了執(zhí)行 Pod 更新而運行服務），可以創(chuàng)建和銷毀許多 ReplicationController。 服務本身和它們的客戶端都應該忽略負責維護服務 Pod 的 ReplicationController 的存在。

編寫多副本的應用

由 ReplicationController 創(chuàng)建的 Pod 是可替換的，語義上是相同的， 盡管隨著時間的推移，它們的配置可能會變得異構。 這顯然適合于多副本的無狀態(tài)服務器，但是 ReplicationController 也可以用于維護主選、 分片和工作池應用程序的可用性。 這樣的應用程序應該使用動態(tài)的工作分配機制，例如 RabbitMQ 工作隊列， 而不是靜態(tài)的或者一次性定制每個 Pod 的配置，這被認為是一種反模式。 執(zhí)行的任何 Pod 定制，例如資源的垂直自動調(diào)整大?。ɡ纾珻PU 或內(nèi)存）， 都應該由另一個在線控制器進程執(zhí)行，這與 ReplicationController 本身沒什么不同。

ReplicationController 的職責

ReplicationController 僅確保所需的 Pod 數(shù)量與其標簽選擇算符匹配，并且是可操作的。 目前，它的計數(shù)中只排除終止的 Pod。 未來，可能會考慮系統(tǒng)提供的就緒狀態(tài)和其他信息， 我們可能會對替換策略添加更多控制， 我們計劃發(fā)出事件，這些事件可以被外部客戶端用來實現(xiàn)任意復雜的替換和/或縮減策略。

ReplicationController 永遠被限制在這個狹隘的職責范圍內(nèi)。 它本身既不執(zhí)行就緒態(tài)探測，也不執(zhí)行活躍性探測。 它不負責執(zhí)行自動縮放，而是由外部自動縮放器控制（如 #492 中所述），后者負責更改其 replicas 字段值。 我們不會向 ReplicationController 添加調(diào)度策略(例如， spreading)。 它也不應該驗證所控制的 Pod 是否與當前指定的模板匹配，因為這會阻礙自動調(diào)整大小和其他自動化過程。 類似地，完成期限、整理依賴關系、配置擴展和其他特性也屬于其他地方。 我們甚至計劃考慮批量創(chuàng)建 Pod 的機制（查閱 #170）。

ReplicationController 旨在成為可組合的構建基元。 我們希望在它和其他補充原語的基礎上構建更高級別的 API 或者工具，以便于將來的用戶使用。 kubectl 目前支持的 "macro" 操作（運行、縮放、滾動更新）就是這方面的概念示例。 例如，我們可以想象類似于 Asgard 的東西管理 ReplicationController、自動定標器、服務、調(diào)度策略、金絲雀發(fā)布等。

API 對象

在 Kubernetes REST API 中 Replication controller 是頂級資源。 更多關于 API 對象的詳細信息可以在 ReplicationController API 對象找到

ReplicationController 的替代方案

ReplicaSet

?ReplicaSet ?是下一代 ReplicationController， 支持新的基于集合的標簽選擇算符。 它主要被 ?Deployment ?用來作為一種編排 Pod 創(chuàng)建、刪除及更新的機制。 請注意，我們推薦使用 Deployment 而不是直接使用 ReplicaSet，除非 你需要自定義更新編排或根本不需要更新。

Deployment （推薦） 

?Deployment ?是一種更高級別的 API 對象，用于更新其底層 ReplicaSet 及其 Pod。 如果你想要這種滾動更新功能，那么推薦使用 Deployment，因為它們是聲明式的、服務端的，并且具有其它特性。

裸 Pod

與用戶直接創(chuàng)建 Pod 的情況不同，ReplicationController 能夠替換因某些原因 被刪除或被終止的 Pod ，例如在節(jié)點故障或中斷節(jié)點維護的情況下，例如內(nèi)核升級。 因此，我們建議你使用 ReplicationController，即使你的應用程序只需要一個 Pod。 可以將其看作類似于進程管理器，它只管理跨多個節(jié)點的多個 Pod ，而不是單個節(jié)點上的單個進程。 ReplicationController 將本地容器重啟委托給節(jié)點上的某個代理(例如，Kubelet 或 Docker)。

Job

對于預期會自行終止的 Pod (即批處理任務)，使用 ?Job ?而不是 ReplicationController。

DaemonSet 

對于提供機器級功能（例如機器監(jiān)控或機器日志記錄）的 Pod， 使用 ?DaemonSet ?而不是 ReplicationController。 這些 Pod 的生命期與機器的生命期綁定：它們需要在其他 Pod 啟動之前在機器上運行， 并且在機器準備重新啟動或者關閉時安全地終止。