Reprint Kubernetes How to use Replicationcontroller, Replica Set, deployment Manage pod----article is good but not yet practical practice has not yet been remembered.

Kubernetes How to manage pods using Replicationcontroller, Replica Set, deployment53746273

The pod is literally a pod, and we can think of the container as a bean in a pod, and one or more closely related beans wrapped together as pods (a pod). In the k8s we do not directly manipulate the container, but instead wrap the container into pods, and for the pod, how do we manage it? Let's look at the following scenario:

1. Application Scenarios

Assuming a pod is providing online services, let's think about how to deal with the following scenarios:

1. Festival activities, website visits increased suddenly

2. Attacks and a sudden increase in website traffic

3. The node that runs the pod has failed

In the 1th case, a few pods are pre-activated before the activity ends and the excess is ended, although there are a bit more pods to start and end, but they can be organized as planned.

2nd situation, is sleeping suddenly mobile phone rang said the site response special slow card to die, hurriedly climbed up edge expansion side to find attack mode, IP and so on ...

3rd situation, is on vacation suddenly mobile phone rang again said the website does not go, hurriedly open the computer to see the reason, start a new pod.

Pod needs to be managed manually, so tired ...

Therefore, we need a way to automatically manage the scaling of pods. This article describes how to manage pods using Replicationcontroller, Replica Set, and deploymen, divided into the following three parts:

• Use Replicationcontroller to deploy, upgrade pods

• Replica set-The next generation of Replicationcontroller

• deployment-more convenient management of pod and replica Set
  
  

2. Using Replicationcontroller (RC) deployment, upgrade pod

RC guarantees that a specified number of pod copies can be run at the same time, ensuring that the pod is always available. If the actual number of pods is more than specified, the excess is terminated, and if the actual quantity is less than the specified, the boot is missing. When the pod fails, is deleted, or is terminated, RC automatically creates a new pod to guarantee the number of copies, so even if there is only one pod, it should be managed using RC. Let's take a look at the following Rc.yaml file

apiVersion:v1kind:ReplicationControllermetadata:  name:frontend  Labels:    name:frontendspec:   3  selector:    name:frontend  Template:    metadata:     Labels:       name: Frontend    Spec:     containers:     - name:frontend       image:kubeguide/guestbook-php- frontend:latest       env:       - name:get_hosts_from         value:env       ports:         the

1. Meaning of the Yaml field:
   Spec.replicas: Number of Replicas 3
   Spec.selector:RC to filter the pods to be controlled by Spec.selector
   Spec.template: Write the definition of pod here (but not apiversion and kind)
   Spec.template.metadata.labels:Pod label, you can see this label is the same as Spec.selector

2. The meaning of this file:
   Define an RC object whose name is Frontend (metadata.name:frontend), guaranteed to have 3 pods running (spec.replicas:3), and the pod image is kubeguide/ Guestbook-php-frontend:latest (Spec.template.spec.containers.image:kubeguide/guestbook-php-frontend:latest)

3. The key is Spec.selector and Spec.template.metadata.labels, and the two fields must be the same, or the next creation of RC will fail. (You can also not write spec.selector, so the default is the same as Spec.template.metadata.labels)

Then let's look at the common operation commands of RC:

• Create RC from Kubectl

# Kubectl Create-f Rc.yaml

• View RC Specific Information

Kubectl describe RC Frontend

• Modify the number of pod copies via RC (you need to modify the Spec.replicas field of the Yaml file to the target value and replace the old Yaml file)

# Kubectl Replace-f rc.yaml# kubect edit Replicationcontroller frontend

• Use a rolling upgrade to RC to publish new features or fix bugs

# kubectl Rolling-update frontend--image=kubeguide/guestbook-php-frontend:latest

• When there is only one container in the pod, specify a new tag through the –image parameter to complete the rolling upgrade, but if you have multiple containers or other fields modified, you need to specify the Yaml file

# kubectl Rolling-update frontend-f File.yaml

If there is a problem during the upgrade (such as a configuration error, long time no response), you can use CTRL + C to exit, and then roll back

# kubectl Rolling-update frontend--image=kubeguide/guestbook-php-frontend:latest--rollback

However, if the problem occurs after the upgrade is complete (such as a new version of the program out of Core), this command is powerless. We need to use the same method, using the original image, "Upgrade" to the old version.

3. deployment-more convenient management of pod and replica Set

K8s is a fast-growing project, and in the new version, the official recommendation is to use replica set and deployment instead of RC. So where are their advantages, let's take a look:

1. RC supports only equation-based selector (Env=dev or ENVIRONMENT!=QA), but replica set also supports new, set-based selector (version in (v1.0, v2.0) or Env notin (Dev, QA), which is convenient for complex operation and maintenance management.

2. Using deployment to upgrade the pod, you only need to define the final state of the pod, k8s will perform the necessary actions for you, although it is possible to complete the upgrade with a command, # kubectl rolling-update but it is done on the client and the server multiple interactive control RC, so rest There is no Rolling-update interface in the API, which poses some problems for customizing your own management system.

3. The deployment has a more flexible and powerful upgrade and rollback capability.

Currently, the difference between Replica set and RC is only supported by the selector, and the following will definitely add more functionality. Deployment uses the replica Set, which is the concept of a higher layer. Unless the user needs a custom upgrade feature or does not need to upgrade the pod at all, in general we recommend using deployment instead of using replica Set directly.

• Create deployment by using the subcommands command

# kubectl Create-f Deployment.yaml--record

Note the –record parameter, which uses this parameter to record subsequent operations of the created object, facilitating management and problem traceability

• Edit the spec.replicas/using the Sub-command editor Spec.template.spec.container.image field, complete Deployment and rolling upgrade (this is much faster than rolling-update subcommand)

# Kubectl Edit Deployment Hello-deployment

• Use the Rollout history command to view deployment's historical information

# KUBECTL Rollout History Deployment Hello-deployment

• It is mentioned above that RC cannot roll back directly after Rolling-update upgrade, while using deployment can roll back to previous version, but add –revision parameter, specify version number

# KUBECTL Rollout History deployment Hello-deployment--revision=2

Rollback to previous version using rollout undo

Use –to-revision to roll back to the specified version

# KUBECTL Rollout undo Deployment Hello-deployment--to-revision=2

4. Summary

By contrast, we found that the new replica Set, Deployment, is much more powerful and easy to use than RC.

[Reprint] Kubernetes How to use Replicationcontroller, Replica Set, deployment manage pod----article very good but not yet practical practice has not yet been remembered.