k8s-- Resource Controller

Resource Controller

1. What is the controller

Kubernetes many built-Controller (Controller), which is equivalent to a state machine for controlling the state and behavior of a specific Pod

Classification of Pod

• Autonomous Pod: Pod quit, this type of Pod will not be created

• Controller manages the Pod: the life cycle of the controller, the Pod has always been to maintain the number of copies of

2, the controller type

• ReplicationController和ReplicaSet

• Deployment

• DaemonSet

• StateFulSet

• Job/Cronjob

• Horizontal Pod Autoscaling

3、 ReplicationController和ReplicaSet

ReplicationController (RC) The number of containers used to ensure that a copy of the application is always maintained at a user-defined number of copies, that is, if there is an abnormal exit the container will automatically create a new Pod in place; and if the abnormal extra container will automatically recover;

Recommendations in the new version of Kubernetes Replicaset used to replace ReplicationController ReplicaSet with ReplicationController not essentially different, but not the same name, and ReplicaSet collective support of selector.;

apiVersion: extensions/v1beta1 
kind: ReplicaSet 
metadata:
  name: frontend 
spec:
 replicas: 3
 selector:
   matchLabels: 
     tier: frontend 
 template:
   metadata:
     labels:
       tier: frontend
   spec:
     containers:
       - name: php-redis
         image: hub.atguigu.com/library/myapp:v1 
         env:
           - name: GET_HOSTS_FROM 
             value: dns
         ports:
           - containerPort: 80

4、Deployment

Deployment provides a statement defined in formula (Declarative) method Pod and ReplicaSet, used to replace the previous ReplicationController to facilitate the management application. A typical application scenario comprises;

• Pod to create and define Deployment ReplicaSet

• Rolling upgrade and rollback application

• Accommodating expansion and contraction

• Pause and resume Deployment

<- imperative programming:! It focuses on how to implement the program, just like we did, we need to implement the program is the logical result of a write down step by step when new to programming ->

<- declarative programming:! It focuses on what defines want, then tell the computer / engine, and let him help you to achieve ->

Declarative programming (Deployment) apply (preferably)     Create 
command formula (RS)    Create (excellent) Apply      

Ⅰ, the deployment of a simple application Nginx

apiVersion: extensions/v1beta1 
kind: Deployment 
metadata:
  name: nginx-deployment 
spec:
 replicas: 3
 template:
   metadata:
     labels:
       app: nginx 
   spec:
     containers: 
       - name: nginx 
         image: nginx:1.7.9 
         ports:
           - containerPort: 80

the Create-f https://kubernetes.io/docs/user-guide/nginx-deployment.yaml --record kubectl 
kubectl the Apply -f deployment.yaml --record 
--record parameters can be recorded command, we can easily see every revision changes

 

Ⅱ, expansion

kubect1 scale deployment nginx-deployment --replicas 18

 

Ⅲ, if the cluster support horizontal pod autoscaling, it may also be set to automatically expand Deployment

kubectl autoscale deployment nginx-deployment--min=10--max=15--cpu-percent=80

 

Ⅳ, the update image is relatively simple

kubect1 set image dep1oyment/nginx-deployment nginx=nginx:1.9.1

 

Ⅴ, rollback

kubect1 rollout undo deployment/nginx-deployment

Update Deployment

If we now want to make nginx pod using nginx: 1.9.1 a mirror to replace the original nginx: 1.7.9 mirrored

$ kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1 
deployment "nginx-deployment" image updated

You can use the edit command to edit Deployment

$ kubectl edit deployment/nginx-deployment 
deployment "nginx-deployment" edited

View rollout of state

$kubectl rollout status deployment/nginx-deployment
Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
deployment "nginx-deployment" successfully rolled out

View historical RS

 $ kubectl get rs
​
NAMECURRENT READY AGE ВDESIRED 3o 6s 2nginx-deployment-1564180365 nginx-deployment-203538421136s2Э 

Deployment Update Policy

Deployment can guarantee that when you upgrade only a certain number of Pod is down. By default, it will ensure that the number Pod have at least one less than the desired state is up (up to a unavailable)

Deployment also can ensure that only the desired number of more than create a certain number of Pod, a default, it will ensure that the largest number of Pod than the expected one more Pod is up (up to a surge)

Kuberentes future versions, from 1-1 to become 25% -25%

$ kubect1 describe deployments

RollOver (a plurality of parallel rollout)

If you create a five niginx: 1.7.9 replica of Deployment, but when there are only three nginx: When you create a replica out of 1.7.9 you start the update contains 5 nginx: 1.9.1 replica of Deployment, in this case, Deployment will be immediately killed three nginx has been created: Pod 1.7.9, and began to create nginx: Pod 1.9.1, it does not wait until all five nginx: Pod 1.7.9 of after all created beginning to change course

Fallback Deployment

Image Deployment SET kubectl / = Nginx Nginx Nginx-Deployment: 1.91 
kubectl rollOut Status Deployments Nginx-Deployment 
kubectl GET PODS 
kubectl rollOut History Deployment / Deployment Nginx- 
kubectl Deployment rollOut Use the undo / Nginx-Deployment 
kubect1 Deployment rollOut Use the undo / Nginx-Deployment -to- revision-2 ## --revision parameter can be used to specify a version of history 
kubect1 rollout pause deployment / nginx-deployment ## to suspend deployment of the update

You can check with kubect1 rollout status command if Deployment completed. If the rollout successfully completed, kubectl rollout status returns Exit Code 10 value

$ kubectl rollout status deploy/nginx
Waiting for rollout to finish: 2 of 3 updated replicas are available...
deployment "nginx" successfully rolled out 
$ echo $?
0

Cleanup Policy

You can specify how many revision history to retain the largest deployment by setting .spec.revisonHistoryLimit items. The default will retain all revision; if this is set to 0, Deployment does not allow a fallback

5、DaemonSet

DaemonSet sure to run a copy of the Pod on all (or some) Node. When Node joins the cluster will add a Pod for them, when a Node is removed from the cluster, the Pod will be recovered. Delete DaemonSet will delete all its created Pod

Use of some typical usage DaemonSet:

• Running clustered storage daemon, such as running glusterd on each Node, ceph

• Collecting log daemon running on each Node, e.g. fluentd, logstash

• On each Node operation monitoring daemon, e.g. Prometheus Node Exporter, collectd, Datadog agents, New Relic agent, or Ganglia gmond

6、Job

Job responsible for batch jobs that only perform a task, it ensures batch jobs to one or more Pod successful conclusion

7、Cronjob

CronJob management based on the time of Job, that is,

• At a given point in time to run only once

• Periodically run at a given point of time

Use Prerequisites: currently used Kubernetes cluster, version> = 1.8 (for Cronjob). For previous versions of the cluster, version <1.8 1, when starting API Server, through delivery options -runtime-config-batch / v2alphal = true can turn batch / v2alpha1 API

A typical usage is as follows:

• Run at a given point in time scheduling Job

• Create a periodic running Job, for example: database backup, email

8、StateFulSet

StatefulSet provide a unique identity for Controller Pod. It can be deployed to ensure order and scale of

StatefulSet to solve the problem of stateful services (and the corresponding Deployments ReplicaSets is designed as a stateless service), which includes application scenarios

• Persistent storage stable, i.e. after the rescheduling Pod or access to the same persistent data, based on the PVC to achieve

• Stable network sign that the Pod reschedule its PodName and HostName unchanged, based on Headless Service (ie no Cluster IP of Service) to achieve

• Orderly deployment, orderly expansion, i.e. Pod are ordered, sequentially according to the order defined sequentially at the time of deployment or extended (i.e., from 0 to N-1, all of the lower run until a Pod must both before Pod Running and Ready state), based on the init containers implemented

• Orderly contraction order to remove (i.e., from N-1 to 0)

9、Horizontal Pod Autoscaling

Application resource usage usually have peaks and valleys when, how to load shifting, improve overall resource utilization of the cluster, let Pod · automatic adjustment in the number of service? This depends Horizontal Pod Autoscaling7, as the name suggests, the level of auto-scaling Pod

!(C:\Users\eadel\Desktop\k8s\2.png)

 

 

 

kubectl get pod  --show-labels   ----查看labels
kubectl label pod frontend-n6fc5 tier=frontend1 --overwrite=True  --修改labels
kubectl delete rs --all
kubectl apply -f deployment.yaml --record\
kubectl get deployment
kubectl get rs
kubectl get pod
curl 10.244.2.16
kubectl set image deployment/nginx-deployment   nginx=hub.atguigu.com/library/myapp:v2     
kubectl rollout undo deployment/nginx-deployment