kubernetes concepts -- Replication Controller

Edit This Page

ReplicationController

NOTE: A Deployment that configures a ReplicaSet is now the recommended way to set up replication.

注意：更加推薦使用ReplicaSet部署集羣。

A ReplicationController ensures that a specified number of pod replicas are running at any one time. In other words, a ReplicationController makes sure that a pod or a homogeneous set of pods is always up and available.

RC保證任意時間有固定的副本Pod在運行。

How a ReplicationController Works

If there are too many pods, the ReplicationController terminates the extra pods. If there are too few, the ReplicationController starts more pods. Unlike manually created pods, the pods maintained by a ReplicationController are automatically replaced if they fail, are deleted, or are terminated. For example, your pods are re-created on a node after disruptive maintenance such as a kernel upgrade. For this reason, you should use a ReplicationController even if your application requires only a single pod. A ReplicationController is similar to a process supervisor, but instead of supervising individual processes on a single node, the ReplicationController supervises multiple pods across multiple nodes.

若是有太多pods，RC會終止多餘的pod。若是Pod太少，RC會啓動更多Pod。與手動建立Pod相比，RC會在pod掛掉時自動建立新的Pod，更加及時、方便。例如在破壞性的維護（如kernel升級）以後，節點上的Pods會被從新建立。在這種狀況下，即便你的應用只須要一個Pod，也應該使用RC。RC就像一個超級監控進程，同時監控多個節點上的多個Pods。

ReplicationController is often abbreviated to 「rc」 or 「rcs」 in discussion, and as a shortcut in kubectl commands.

A simple case is to create one ReplicationController object to reliably run one instance of a Pod indefinitely. A more complex use case is to run several identical replicas of a replicated service, such as web servers.

ReplicationController常常被簡寫爲rc或rcs，在kuberctl命令行中也可使用rc。

rc的簡單用例是建立一個rc而後運行一個單獨的Pod，複雜的用法是運行服務的多個相同副本，好比web 服務器。

Running an example ReplicationController

This example ReplicationController config runs three copies of the nginx web server.

下面是運行三個nginx web server副本的RC配置。

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

Run the example job by downloading the example file and then running this command:

使用kuberctl create -f rc.yaml建立rc

$ kubectl create -f ./replication.yaml replicationcontroller "nginx" created 

Check on the status of the ReplicationController using this command:

使用命令行查詢RC的狀態，kubectl describe rc/{rc.name}

$ 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 

Here, three pods are created, but none is running yet, perhaps because the image is being pulled. A little later, the same command may show:

當前三個pods被建立了，沒有一個是running的，可能由於正在拉取鏡像。一會再運行命令，查詢到的狀態多是3 Running

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

To list all the pods that belong to the ReplicationController in a machine readable form, you can use a command like this:

可使用下面的命令將全部的Pod名稱輸出爲機器可讀的格式。

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

Here, the selector is the same as the selector for the ReplicationController (seen in the kubectl describe output, and in a different form in replication.yaml. The --output=jsonpath option specifies an expression that just gets the name from each pod in the returned list.其中selector和rc的selector相同， --output=jsonpath選項定義每一個pod返回的數據的格式。

Writing a ReplicationController Spec

As with all other Kubernetes config, a ReplicationController needs apiVersion, kind, and metadata fields. For general information about working with config files, see object management .

A ReplicationController also needs a .spec section.

rc配置文件須要apiVersion、kind、metadata三個普通域，還須要.spec。

Pod Template

The .spec.template is the only required field of the .spec.

The .spec.template is a pod template. It has exactly the same schema as a pod, except it is nested and does not have an apiVersion or kind.

In addition to required fields for a Pod, a pod template in a ReplicationController must specify appropriate labels and an appropriate restart policy. For labels, make sure not to overlap with other controllers. See pod selector.

Only a .spec.template.spec.restartPolicy equal to Always is allowed, which is the default if not specified.

For local container restarts, ReplicationControllers delegate to an agent on the node, for example the Kubelet or Docker.

.spec.template只是.spec的一個域，.spec.template是一個Pod模板，和普通的Pod模板格式相同，只是嵌入到rc配置文件中，沒有apiVersion和kind。在.spec.template中，除了Pod須要的參數，pod模板還必須明確適當的標籤和重啓策略。對於標籤，必定不能和其餘controller重複，具體能夠參考pod selector。重啓策略爲.spec.template.spec.restartPolicy，默認爲Always。

對於本地容器的重啓，rc把任務派送給節點的代理，如kuberlet或docker。

Labels on the ReplicationController

The ReplicationController can itself have labels (.metadata.labels). Typically, you would set these the same as the .spec.template.metadata.labels; if .metadata.labels is not specified then it defaults to .spec.template.metadata.labels. However, they are allowed to be different, and the .metadata.labels do not affect the behavior of the ReplicationController.

rc能夠在.metadata.labels中設置標籤。通常，rc的標籤和.spec.template.metadata.labels相同。若是不設置.metadata.labels，那麼默認.metadata.labels等於.spec.template.metadata.labels。兩個標籤能夠不相同，.metadata.labels不影響rc的行爲。

Pod Selector

The .spec.selector field is a label selector. A ReplicationController manages all the pods with labels that match the selector. It does not distinguish between pods that it created or deleted and pods that another person or process created or deleted. This allows the ReplicationController to be replaced without affecting the running pods.

If specified, the .spec.template.metadata.labels must be equal to the .spec.selector, or it will be rejected by the API. If .spec.selector is unspecified, it will be defaulted to .spec.template.metadata.labels.

Also you should not normally create any pods whose labels match this selector, either directly, with another ReplicationController, or with another controller such as Job. If you do so, the ReplicationController thinks that it created the other pods. Kubernetes does not stop you from doing this.

If you do end up with multiple controllers that have overlapping selectors, you will have to manage the deletion yourself (see below).

.spec.selector是一個label selector。rc管理全部標籤符合selector的Pods。rc不會區分本身或其餘進程建立或刪除的pods。這樣就能夠替換rc，而且不會影響運行中的Pods。

.spec.template.metadata.labels必須等於.spec.selector，不然API 會拒絕建立rc。.spec.selector默認等於.spec.template.metadata.labels。

通常狀況下，不一樣的controller不要建立標籤相同、知足其餘selector的pods，不然rc會認爲pods增多了。kubernetes不會阻止多個controller的標籤相同。

若是多個controller有重疊的selector，用戶須要本身刪除某些controller。

Multiple Replicas

You can specify how many pods should run concurrently by setting .spec.replicas to the number of pods you would like to have running concurrently. The number running at any time may be higher or lower, such as if the replicas were just increased or decreased, or if a pod is gracefully shutdown, and a replacement starts early.

If you do not specify .spec.replicas, then it defaults to 1.

.spec.replicas表示rc中的目標副本數。某個時刻running的pods總數可能會多一些或少一些，好比用戶剛剛增長或減小了副本數、某個pod被關閉了rc正在替換新的pod。.spec.replicas默認爲1。

Working with ReplicationControllers

Deleting a ReplicationController and its Pods

To delete a ReplicationController and all its pods, use kubectl delete. Kubectl will scale the ReplicationController to zero and wait for it to delete each pod before deleting the ReplicationController itself. If this kubectl command is interrupted, it can be restarted.

When using the REST API or go client library, you need to do the steps explicitly (scale replicas to 0, wait for pod deletions, then delete the ReplicationController).

使用kuberctl delete來刪除rc和pods。kubectl會首先將rc的副本數設置爲0，而後等待pods被所有刪除，最後再刪除rc。If this kubectl command is interrupted, it can be restarted.

當使用REST API或go 客戶端，你須要本身執行這三個步驟。

Deleting just a ReplicationController

You can delete a ReplicationController without affecting any of its pods.

Using kubectl, specify the --cascade=false option to kubectl delete.

When using the REST API or go client library, simply delete the ReplicationController object.

Once the original is deleted, you can create a new ReplicationController to replace it. As long as the old and new .spec.selector are the same, then the new one will adopt the old pods. However, it will not make any effort to make existing pods match a new, different pod template. To update pods to a new spec in a controlled way, use a rolling update.

使用kubectl delete --cascade=false ...刪除rc時，不會影響pods。

使用REST API 或go client，能夠直接刪除rc 對象。

當舊的rc被刪除後，用戶能夠建立新的rc。只要.spec.selector是同樣的，新的rc就會管理舊的Pods。可是，若是新的rc的.spec.template與舊的不一樣，rc不會更改已有的pod。若是須要將pod更新爲新的配置，可使用rolling update。

Isolating pods from a ReplicationController

Pods may be removed from a ReplicationController’s target set by changing their labels. This technique may be used to remove pods from service for debugging, data recovery, etc. Pods that are removed in this way will be replaced automatically (assuming that the number of replicas is not also changed).

能夠經過更改標籤將pod從rc中移除。能夠用於測試、數據恢復等。若是副本個數不變，pods被移除後，rc會自動建立新的Pod。

Common usage patterns

Rescheduling

As mentioned above, whether you have 1 pod you want to keep running, or 1000, a ReplicationController will ensure that the specified number of pods exists, even in the event of node failure or pod termination (for example, due to an action by another control agent).

無論rc須要多少副本數，它會一直監控當前狀態，確保當前狀態等於目標狀態，即便出現節點掛掉或pod終止。

Scaling

The ReplicationController makes it easy to scale the number of replicas up or down, either manually or by an auto-scaling control agent, by simply updating the replicas field.

經過手動更改replicas或自動擴縮容代理，能夠方便地對集羣進行擴縮容。

Rolling updates

The ReplicationController is designed to facilitate rolling updates to a service by replacing pods one-by-one.

As explained in #1353, the recommended approach is to create a new ReplicationController with 1 replica, scale the new (+1) and old (-1) controllers one by one, and then delete the old controller after it reaches 0 replicas. This predictably updates the set of pods regardless of unexpected failures.

Ideally, the rolling update controller would take application readiness into account, and would ensure that a sufficient number of pods were productively serving at any given time.

The two ReplicationControllers would need to create pods with at least one differentiating label, such as the image tag of the primary container of the pod, since it is typically image updates that motivate rolling updates.

Rolling update is implemented in the client tool kubectl rolling-update. Visit kubectl rolling-update task for more concrete examples.

經過將Pod一一替換，能夠實現滾動升級。

推薦方法：建立一個新的rc，副本數爲1。逐步增長新rc的副本數、減少舊rc的副本數。當舊rc的副本數爲0時，刪除舊rc。

理想狀況下，滾動升級能夠確保應用一直能夠提供服務，確保任意時間有足夠的pods。

兩個rc建立的Pods須要至少一個標籤是不一樣的，例如鏡像標籤（通常鏡像升級以後再滾動升級rc）.

客戶端工具kubectl rolling-update支持滾動升級。

Multiple release tracks

In addition to running multiple releases of an application while a rolling update is in progress, it’s common to run multiple releases for an extended period of time, or even continuously, using multiple release tracks. The tracks would be differentiated by labels.

For instance, a service might target all pods with tier in (frontend), environment in (prod). Now say you have 10 replicated pods that make up this tier. But you want to be able to ‘canary’ a new version of this component. You could set up a ReplicationController with replicas set to 9 for the bulk of the replicas, with labels tier=frontend, environment=prod, track=stable, and another ReplicationController with replicas set to 1 for the canary, with labels tier=frontend, environment=prod, track=canary. Now the service is covering both the canary and non-canary pods. But you can mess with the ReplicationControllers separately to test things out, monitor the results, etc.

除了滾動升級時會同時運行多個版本的應用，使用multiple release tracks，能夠長時間或一直運行多個版本。根據標籤區分tracks。

例如，serviceA對應的的Pods知足：tier in (frontend), environment in (prod)。假設當前有10個副本。可是你想使用一個新版本測試。這時能夠設置一個rc A，9個副本，標籤爲tier=frontend, environment=prod,track=stable，設置rc B，副本數爲1，標籤爲tier=frontend, environment=prod, track=canary。這時就有兩個版本的pods。

Using ReplicationControllers with Services

Multiple ReplicationControllers can sit behind a single service, so that, for example, some traffic goes to the old version, and some goes to the new version.

A ReplicationController will never terminate on its own, but it isn’t expected to be as long-lived as services. Services may be composed of pods controlled by multiple ReplicationControllers, and it is expected that many ReplicationControllers may be created and destroyed over the lifetime of a service (for instance, to perform an update of pods that run the service). Both services themselves and their clients should remain oblivious to the ReplicationControllers that maintain the pods of the services.

多個rc能夠提供一個服務，這樣，某些請求被轉發到舊版本的pod，有些被轉發到新版本的pod。

RC永遠不會自動終止，只有被用戶刪除，可是RC的存活時間也不能與Services相比。Services可能有不少RC構成，每一個RC下又包含一個或多個Pods。在Service的生命週期中，不少RC被建立、銷燬，例如更新Pod。Services和服務的客戶端不感知RC的變化。

 

Writing programs for Replication

Pods created by a ReplicationController are intended to be fungible and semantically identical, though their configurations may become heterogeneous over time. This is an obvious fit for replicated stateless servers, but ReplicationControllers can also be used to maintain availability of master-elected, sharded, and worker-pool applications. Such applications should use dynamic work assignment mechanisms, such as the RabbitMQ work queues, as opposed to static/one-time customization of the configuration of each pod, which is considered an anti-pattern. Any pod customization performed, such as vertical auto-sizing of resources (for example, cpu or memory), should be performed by another online controller process, not unlike the ReplicationController itself.

RC建立的Pods能夠相互替代、語義相同（猜想是暴露的端口相同），可能隨着時間變化、版本更新，Pods內部的配置有變化。這種Pod十分適合無狀態的多副本服務器，但RC也能夠被用來維護主備、分片、工做池（worker-pool）的應用。這種應用應該使用動態工做分配機制（dynamic work assignment mechanisms），例如RabbitMQ Work queues，而不是對每一個Pod進行靜態或一次性的配置定製，這種一次性修改是反設計的。任何對Pod的定製，如對資源的垂直擴縮容（如cpu、內存），都應該由另一個controller執行，而不是RC自己。

 

Responsibilities of the ReplicationController

The ReplicationController simply ensures that the desired number of pods matches its label selector and are operational. Currently, only terminated pods are excluded from its count. In the future, readiness and other information available from the system may be taken into account, we may add more controls over the replacement policy, and we plan to emit events that could be used by external clients to implement arbitrarily sophisticated replacement and/or scale-down policies.

The ReplicationController is forever constrained to this narrow responsibility. It itself will not perform readiness nor liveness probes. Rather than performing auto-scaling, it is intended to be controlled by an external auto-scaler (as discussed in #492), which would change its replicas field. We will not add scheduling policies (for example, spreading) to the ReplicationController. Nor should it verify that the pods controlled match the currently specified template, as that would obstruct auto-sizing and other automated processes. Similarly, completion deadlines, ordering dependencies, configuration expansion, and other features belong elsewhere. We even plan to factor out the mechanism for bulk pod creation (#170).

The ReplicationController is intended to be a composable building-block primitive. We expect higher-level APIs and/or tools to be built on top of it and other complementary primitives for user convenience in the future. The 「macro」 operations currently supported by kubectl (run, scale, rolling-update) are proof-of-concept examples of this. For instance, we could imagine something like Asgard managing ReplicationControllers, auto-scalers, services, scheduling policies, canaries, etc.

目前RC只是簡單的保證符合label selector的Pods個數等於所需副本數，而且這些Pods都是正常的，只有被終止的Pods被排除。之後，系統的準備狀態（readiness）和其餘已有信息也會被考慮在內，Pods的替換策略更可控，咱們計劃之後向外部客戶端發送事件，用戶能夠根據這些事件實現更加複雜的替換和擴縮容。

RC的功能不多，他不會進行準備狀態或存活狀態的架空。也只能被其餘的auto-scaler來控制，經過修改replicas的數值進行擴縮容。之後不會增長調度策略，也不會將現有的Pod匹配當前的Pod模板，由於這會妨礙擴縮容和其餘自動進程。相似的，完成截止期限、排序依賴、配置擴展或其餘特性也不會被增長。咱們甚至計劃把建立Pod的大部分功能分解出來。

RC應該是原始的可組合的基本單元。咱們但願高級API和工具在它和其餘補充的原始單元之上。目前kubectl支持的微操做（run, scale, rolling-update）就是這個概念的證據和示例。例如咱們假想有個Asgard管理RC、auto-scalers、services、調度策略、canaries（測試版本）等。

API Object

Replication controller is a top-level resource in the Kubernetes REST API. More details about the API object can be found at: ReplicationController API object.

RC是kubernetes REST API的高級資源。

Alternatives to ReplicationController

ReplicaSet

ReplicaSet is the next-generation ReplicationController that supports the new set-based label selector. It’s mainly used by Deployment as a mechanism to orchestrate pod creation, deletion and updates. Note that we recommend using Deployments instead of directly using Replica Sets, unless you require custom update orchestration or don’t require updates at all.

ReplicaSet是RC的高級版本，支持新的set-based label selector。ReplicaSet主要由Deployment用於對Pod進行建立、刪除和更新。注意咱們推薦直接使用Deployment而不是ReplicaSet，除非你須要定製更新編排機制或根本不須要更新。

Deployment (Recommended)

Deployment is a higher-level API object that updates its underlying Replica Sets and their Pods in a similar fashion as kubectl rolling-update. Deployments are recommended if you want this rolling update functionality, because unlike kubectl rolling-update, they are declarative, server-side, and have additional features.

Deployment是基於ReplicaSet的高級API對象，可使用相似於kubectl rolling-update的機制更新底層的Replica Sets和Pods。若是想要可行的滾動升級，推薦使用Deployments，與kubectl rolling-update相比，Deployment是declarative, server-side, and have additional features.

Bare Pods

Unlike in the case where a user directly created pods, a ReplicationController replaces pods that are deleted or terminated for any reason, such as in the case of node failure or disruptive node maintenance, such as a kernel upgrade. For this reason, we recommend that you use a ReplicationController even if your application requires only a single pod. Think of it similarly to a process supervisor, only it supervises multiple pods across multiple nodes instead of individual processes on a single node. A ReplicationController delegates local container restarts to some agent on the node (for example, Kubelet or Docker).

相對於直接建立Pods，RC能夠對狀態進行維護，當節點掛掉或毀壞性的節點維護時，能夠從新建立Pods。因此咱們推薦使用RC，即便某個應用只須要一個Pod。RC至關於一個進程監控，監控多個節點行的多個pods。RC將本地容器的重啓任務安排給節點上的客戶端，如kubelet或docker。

Job

Use a Job instead of a ReplicationController for pods that are expected to terminate on their own (that is, batch jobs).

若是須要Pods本身終止，須要使用Job，如batch jobs。

DaemonSet

Use a DaemonSet instead of a ReplicationController for pods that provide a machine-level function, such as machine monitoring or machine logging. These pods have a lifetime that is tied to a machine lifetime: the pod needs to be running on the machine before other pods start, and are safe to terminate when the machine is otherwise ready to be rebooted/shutdown.

DaemonSet提供machine-level function，如機器架空或機器日誌打印。這些Pods和machine的聲明週期綁定，須要先啓動這些pods，當他們在運行時在啓動其餘pods，當機器須要被重啓或關機時，能夠關閉這些pods.

For more information

Read Run Stateless AP Replication Controller.