write in front
The cloud-native wave is overwhelming and unstoppable, and it is also the only way for enterprises to migrate their business to the cloud. But going to the cloud has never been smooth, and we will always encounter some difficulties and challenges along the way. Thanks to the growing maturity of cloud-native technologies, these problems are bound to have corresponding solutions.
Article directory
Concept introduction
Earlier, we learned some basic usage methods of Pod, and we were all directly operating Pods. If we have a Pod that is providing online services, let's think about what we might be able to do. Some scenarios that will be encountered:
- A very successful operation and a sudden surge in website traffic
- The node running the current Pod has failed, and the Pod cannot provide services normally
In the first case, it may be better to deal with it. Before the general event, we will roughly calculate how much traffic there will be, start a few more Pods in advance, and kill the redundant Pods after the event, although it is a bit troublesome , but should still be able to handle this situation.
In the second case, you may receive a large number of alarms one night saying that the service is down, and then get up and turn on the computer to restart a new Pod on another node, and the problem is solved very well.
If we all solve these problems manually, it seems that we are back to the era of farming fire, right? If there is a tool that can help us manage Pods, Pods are not enough to be automatic. Help me add a new one, and the Pod will automatically restart a Pod on a suitable node when it hangs, so that we don't need to solve the above problems manually.
Fortunately, Kubernetes provides us with such resource objects:
- Replication Controller : used to deploy and upgrade Pods
- ** Replica Set**: The next generation of Replication Controller
- Deployment : It is easier to manage Pods and Replica Sets
Replication Controller（RC）
Replication ControllerReferred to as RC, RC is one of the core concepts in the Kubernetes system. In simple terms, RC can guarantee the number of copies of Pods running at any time, and can ensure that Pods are always available.
If the actual number of Pods is more than the specified number, then end the redundant ones. If the actual number of Pods is less than the specified number, start some new Pods. When the Pods fail, are deleted, or hang up, RC will automatically create new Pods. The number of replicas is guaranteed, so even if there is only one Pod, we should use RC to manage our Pod.
Let's think about if we encounter the above problems now, maybe we don't have to worry about the rest except the first one that cannot be fully automated. The node running the Pod hangs up, and the RC detects it. When the Pod fails, it will go to the appropriate node to restart a Pod, and we do not need to manually create a new Pod. If it is the first case, we assign 10 replicas to the Pod before the activity starts, and change the number of replicas to 2 after the event. Is this far better than manually starting and closing it manually?
Now let's use RC to manage the Nginx Pod we used earlier. The YAML file is as follows:
apiVersion: v1
kind: ReplicationController
metadata:
name: rc-demo
labels:
name: rc
spec:
replicas: 3
selector:
name: rc
template:
metadata:
labels:
name: rc
spec:
containers:
- name: nginx-demo
image: nginx
ports:
- containerPort: 80
The format of the above YAML file relative to our previous Pod:
- kind： ReplicationController
- spec.replicas : Specify the number of Pod replicas, the default is 1
- spec.selector : RC uses this property to filter the Pods to be controlled
- spec.template : This is the module defined by our previous Pod, but we don't need apiVersion and kind anymore
- spec.template.metadata.labels : Note that the labels of the Pod here should be the same as spec.selector, so that the RC can control the current Pod.
The meaning in this YAML file is to define an RC resource object, its name is called rc-demo , to ensure that there will always be 3 Pods running, and the Pod's image is nginx 镜像.
Note that the two fields spec.selector and spec.template.metadata.labels must be the same, otherwise the creation will fail. Of course, we can also not write spec.selector, which will be the same as the metadata.labels in the Pod template by default. So in order to avoid unnecessary mistakes, it is better not to write.
Then let's create the RC object above (saved as rc-demo.yaml):
$ kubectl create -f rc-demo.yaml
Check out RC:
$ kubectl get rc
View specific information:
$ kubectl describe rc rc-demo
Then we modify the number of copies of the Pod to 2 through RC:
$ kubectl apply -f rc-demo.yaml
or
$ kubectl edit rc rc-demo
And we can also use RC for rolling upgrades, for example, we change the mirror address to nginx:1.7.9 :
$ kubectl rolling-update rc-demo --image=nginx:1.7.9
But if there are multiple containers in our Pod, we need to modify it by modifying the YAML file:
$ kubectl rolling-update rc-demo -f rc-demo.yaml
If a new problem occurs after the upgrade is completed, and you want to roll back to the previous version with one click, you can only use RC to replace the mirror address with the previous one in the same way, and then re-roll the upgrade.
Replication Set（RS）
Replication SetRS for short. With the rapid development of Kubernetes, the official has recommended that we use RS and Deployment instead of RC. In fact, the functions of RS and RC are basically the same. The only difference at present is that RC only supports Equation-based selector (env=dev or environment!=qa) , but RS also supports set-based selector (version in (v1.0, v2.0)) , which is very convenient for complex operation and maintenance management .
kubectlMost of the commands in the command line tool about RC also apply to our RS resource objects. However, we rarely use RS alone. It is mainly used by Deploymentthis higher-level resource object, unless the user needs to customize the upgrade function or does not need to upgrade the Pod at all. In general, we recommend using Use Deployment instead of directly Replica Set.
Finally, let's summarize some features and functions of RC/RS:
- In most cases, we can control the creation of Pods and the number of replicas by defining an RC
- RC contains a complete Pod definition module (excluding apiversion and kind)
- RC controls Pod replicas through the label selector mechanism
- By changing the number of Pod replicas in the RC, the expansion and contraction of the Pod can be realized.
- By changing the image version in the Pod template on the RC side, the Pod rolling upgrade function can be implemented (but one-key rollback is not supported, and the same method needs to be used to modify the image address)
