Shulou(Shulou.com)05/31 Report--

How to understand ReplicationController and its configuration, I believe that many inexperienced people do not know what to do. Therefore, this paper summarizes the causes and solutions of the problem. Through this article, I hope you can solve this problem.

Before introducing ReplicationController, let's consider the scenario shown in the following figure. The Kubernetes cluster consists of two Node, and each Node runs a Pod of the same type to do load balancing. what happens if one of the Node is forcibly shut down by the administrator or Node goes down unexpectedly?

Because Pod is bound to Node after being dispatched to a Node, when Node goes down, all Pod in Node also stops running. In the scenario shown above, after the Node2 is closed, the corresponding Pod-2 will stop, and the Pod-2 will not be rescheduled to Node1.

In practical application scenarios, it is necessary to maintain a stable number of Pod copies, so Kubernetes introduces ReplicationController.

Working mechanism

ReplicationController is used to define the number of copies of a specified Pod. Compared with creating multiple Pod, it ensures that there will still be a specified number of Pod copies running in the cluster after the Pod terminates unexpectedly. The ReplicationController controller running in the kube-controller-manager component (with the same controller and resource name) monitors the number of replicas of the Pod in the cluster:

If the number of Pod has exceeded expectations, then ReplicationController will remove some of the Pod so that the number of Pod meets expectations.

If the number of Pod is lower than expected, then ReplicationController will create a new Pod, using the number of Pod as expected.

The ReplicationController controller will always monitor the number of copies of the Pod, and if it is found that the number of Pod is not in line with expectations (too much or too little Pod), it will keep the Pod at the expected number by adding or deleting Pod.

The ReplicationController controller is more like a Pod supervisor, supervising the cluster-wide Pod. In the scenario referenced at the beginning of this section, if you use ReplicationController to create two replicas of Pod, when one of the Pod terminates unexpectedly, a new Pod will be created to ensure that there are still two replicas running in the cluster. The overall working mechanism is shown below:

As you can see from the diagram, when two Pod are created through ReplicationController, when the Node2 is turned off, the Pod running on it is rescheduled to run in Node1, and the total number of Pod in the cluster is always maintained at 2.

ReplicationController configuration

A simple ReplicationController resource configuration is as follows:

ApiVersion: v1kind: ReplicationControllermetadata: name: replication-controller-runs-podspec: replicas: 3 selector: app: nginx template: metadata: labels: app: nginx spec: containers:-name: nginx image: nginx:1.19.0

There are three key items:

Spec.replicas specifies the expected number of Pod copies

Spec.selector specifies that Selector,ReplicationController uses this Selector to find Pod objects.

Spec.template specifies the template for Pod, which will be used to create a new Pod when ReplicationController finds that the number of Pod is lower than expected.

Pod template

The Pod template is used to create Pod dynamically within Kubernetes, and it is widely used in a variety of controllers, including ReplicationController introduced in this section, as well as Deployments, Jobs, DaemonSets, and so on.

In terms of data structure, Pod template (PodTemplateSpec) can be understood as a simplified version of Pod, which retains only the Metadata and Spec of Pod, as shown below:

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 is designed to maintain the number of replicas of the specified type Pod in the cluster, but it only supports equivalent Selector and does not support set-based Selector. In order not to violate the principle of API compatibility, Kubernetes has no choice but to provide another maker ReplicaSet to replace it.

As a result, ReplicationController is rarely used in real scenarios, although it is a stable API.

After reading the above, have you mastered how to understand ReplicationController and its configuration? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel, thank you for reading!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.