If we are to solve pod manually restart the problems encountered, it seems to be back before the era of slash and burn is not it, if there is a tool to help us manage just fine Pod, Pod enough to help me add a automatic, Pod hung up automatically give me a new start in a Pod on the appropriate node, this is not a problem we do not need to restart the encounter to manually resolved.
Fortunately, Kubernetes provides such a resource object for us:
- Replication Controller: to deploy, upgrade Pod
- Replica Set: The Next Generation Replication Controller
- Deployment: can more easily manage Pod and Replica Set
This section will speak ReplicaSet and ReplicationController.
一、ReplicationController
Replication Controller referred to as RC, RC is one of the core concepts Kubernetes system, in simple terms, RC can guarantee that the number of copies at any time to run Pod, to ensure Pod always available . If the actual number would be more than a specified Pod end off the excess, if the actual number is less than the specified number of Pod on the new start, when Pod failure, deleted, or hang up, RC will go automatically creates a new copy to ensure Pod number, even if only a Pod, we should also use the RC to manage our Pod. It can be said, by ReplicationController, Kubernetes achieve high availability cluster.
- Start presentation
#启动k8s
minikube start
#删除上次的pod
kubectl delete -f pod_nginx.yml
- View rc_nginx.yml
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
The above YAML file:
- kind：ReplicationController
- spec.replicas: Pod specify the number of copies, the default is 1
- spec.selector: RC filter Pod to be controlled by the property
- spec.template: Here is the definition of Pod of our previous modules, but does not require the kind and apiVersion
- spec.template.metadata.labels: Note that the labels to the Pod and spec.selector the same, so that the current RC since you can control the Pod.
#创建一个ReplicationController的横向扩展
kubectl create -f rc_nginx.yml
kubectl get pods
kubectl get rc
- Delete a look at how effective
To delete a container by way of delete pods, and immediately a new container up
kubectl get rc
kubectl get pod
kubectl delete pods nginx-h2qbt
kubectl get pods
kubectl get rc
- scale horizontal expansion of the number of
kubectl scale rc nginx --replicas=2
kubectl get rc
kubectl scale rc nginx --replicas=5
kubectl get pods -o wide
Two, ReplicaSet
Replication Set referred to as RS, with the rapid development of Kubernetes, officials have recommended that we use the RS and Deployment to replace the RC, RS and RC function is actually basically the same, the only difference is that RC only support a equation-based selector ( env = dev or environment! = qa), but also supports RS-based selector collections (version in (v1.0, v2.0)), this complex operation and maintenance management is very convenient.
kubectl command-line tool on most commands RC also apply to our RS resource object. But we rarely go to the RS alone, it is mainly Deployment of the more high-level resource object used unless the user needs to upgrade custom functions or no upgrade Pod, in general, we recommend using the Deployment rather than direct use the Set Replica .
Here's a summary and some characteristics of the role of the RC / RS is:
- In most cases, we can define a RC realization of creation and number of copies Pod control
- RC Pod contains a full definition module (not included apiversion and kind)
- RC is to achieve control of Pod copies by label selector mechanism
- By changing the number of copies of RC Pod which can be achieved Pod receiving a scaling function
- By changing the Pod template mirrored version of RC which can be achieved Pod rolling upgrade functionality (but does not support a key roll back, you need to modify the mirror address in the same way)
- View rc_nginx.yml
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: nginx
labels:
tier: frontend
spec:
replicas: 3
selector:
matchLabels:
tier: frontend
template:
metadata:
name: nginx
labels:
tier: frontend
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
#删除ReplicationController创建的pod
kubectl delete -f rc_nginx.yml
#创建一个ReplicationController的横向扩展
kubectl create -f rs_nginx.yml
kubectl get pods -o wide
kubectl get pods
kubectl get rc
- Delete a look at how effective
To delete a container by way of delete pods, and immediately a new container up
kubectl get rs
kubectl get pod
kubectl delete pods nginx-h2qbt
kubectl get pods
kubectl get rs
- scale horizontal expansion of the number of
kubectl scale rs nginx --replicas=2
kubectl get rs
kubectl scale rs nginx --replicas=5
kubectl get pods -o wide
Through this expanded understanding of the pod, ReplicaSet and ReplicationController way, basically abandon direct pod last way to create the app. Next talk Deployment.
