k8s--资源控制器
资源控制器
1、什么是控制器
Kubernetes中内建了很多controller (控制器) ,这些相当于一个状态机,用来控制Pod的具体状态和行为
Pod 的分类
- 自主式 Pod：Pod 退出了，此类型的 Pod 不会被创建
- 控制器管理的 Pod：在控制器的生命周期里，始终要维持 Pod 的副本数目
2、控制器类型
- ReplicationController和ReplicaSet
- Deployment
- DaemonSet
- StateFulSet
- Job/Cronjob
- Horizontal Pod Autoscaling
3、 ReplicationController和ReplicaSet
ReplicationController (RC)用来确保容器应用的副本数始终保持在用户定义的副本数,即如果有容器异常退出,会自动创建新的Pod来替代;而如果异常多出来的容器也会自动回收;
在新版本的Kubernetes中建议使用Replicaset来取代ReplicationController. ReplicaSet跟 ReplicationController没有本质的不同,只是名字不一样,并且ReplicaSet支持集合式的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: 804、Deployment
Deployment为Pod和ReplicaSet提供了一个声明式定义(declarative)方法,用来替代以前的 ReplicationController来方便的管理应用。典型的应用场景包括;
- 定义Deployment来创建Pod和ReplicaSet
- 滚动升级和回滚应用
- 扩容和缩容
- 暂停和继续Deployment
<!-- 命令式编程:它侧重于如何实现程序,就像我们刚接触编程的时候那样,我们需要把程序的实现过程按照逻辑结果一步步写下来-->
<!-- 声明式编程:它侧重于定义想什么,然后告诉计算机/引擎,让他帮你去实现-->
申明式编程 （Deployment） apply（优） create
命令式 （rs） create（优） apply Ⅰ、部署一简单的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: 80kubectl create-f https://kubernetes.io/docs/user-guide/nginx-deployment.yaml --record
kubectl apply -f deployment.yaml --record
--record参数可以记录命令,我们可以很方便的查看每次revision的变化Ⅱ、 扩容
kubect1 scale deployment nginx-deployment --replicas 18Ⅲ、 如果集群支持horizontal pod autoscaling的话,还可以为Deployment设置自动扩展
kubectl autoscale deployment nginx-deployment--min=10--max=15--cpu-percent=80Ⅳ、 更新镜像也比较简单
kubect1 set image dep1oyment/nginx-deployment nginx=nginx:1.9.1Ⅴ、回滚
kubect1 rollout undo deployment/nginx-deployment更新Deployment
假如我们现在想要让nginx pod使用nginx:1.9.1的镜像来代替原来的nginx:1.7.9的镜像
$ kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1
deployment "nginx-deployment" image updated可以使用edit命令来编辑Deployment
$ kubectl edit deployment/nginx-deployment
deployment "nginx-deployment" edited查看rollout的状态
$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查看历史RS
$ kubectl get rs
NAMECURRENT READY AGE ВDESIRED 3o 6s 2nginx-deployment-1564180365 nginx-deployment-203538421136s2Э Deployment更新策略
Deployment可以保证在升级时只有一定数量的Pod是down的。默认的,它会确保至少有比期望的Pod数量少一个是up状态(最多一个不可用)
Deployment同时也可以确保只创建出超过期望数量的一定数量的Pod,默认的,它会确保最多比期望的Pod数量多一个的Pod是up的(最多1个surge )
未来的Kuberentes版本中,将从1-1变成25%-25%
$ kubect1 describe deploymentsRollover (多个rollout并行)
假如您创建了一个有5个niginx:1.7.9 replica的Deployment,但是当还只有3个nginx:1.7.9的replica创建出来的时候您就开始更新含有5个nginx:1.9.1 replica的Deployment,在这种情况下, Deployment会立即杀掉已创建的3个nginx:1.7.9的Pod,并开始创建nginx:1.9.1的Pod,它不会等到所有的5个nginx:1.7.9的 Pod都创建完成后才开始改变航道
回退 Deployment
kubectl set image deployment/nginx-deployment nginx=nginx: 1.91
kubectl rollout status deployments nginx-deployment
kubectl get pods
kubectl rollout history deployment/nginx-deployment
kubectl rollout undo deployment/nginx-deployment
kubect1 rollout undo deployment/nginx-deployment -to-revision-2 ##可以使用--revision参数指定某个历史版本
kubect1 rollout pause deployment/nginx-deployment ##暂停deployment的更新您可以用kubect1 rollout status命令查看Deployment是否完成。如果rollout成功完成, kubectl rollout status将返回一0值的Exit Code
$ kubectl rollout status deploy/nginx
Waiting for rollout to finish: 2 of 3 updated replicas are available...
deployment "nginx" successfully rolled out
$ echo $?
0清理Policy
您可以通过设置.spec.revisonHistoryLimit项来指定deployment最多保留多少revision历史记录。默认的会保留所有的revision;如果将该项设置为0, Deployment就不允许回退了
5、DaemonSet
DaemonSet确保全部(或者一些) Node上运行一个Pod的副本。当有Node加入集群时,也会为他们新增一个 Pod,当有Node从集群移除时,这些Pod也会被回收。删除DaemonSet将会删除它创建的所有Pod
使用DaemonSet的一些典型用法:
- 运行集群存储daemon,例如在每个Node上运行glusterd , ceph
- 在每个Node上运行日志收集daemon,例如fluentd、logstash
- 在每个Node上运行监控daemon,例如Prometheus Node Exporter, collectd, Datadog代理、 New Relic代理,或Ganglia gmond
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: deamonset-example
labels:
app: daemonset
spec:
selector:
matchLabels:
name: deamonset-example
template:
metadata:
labels:
name: deamonset-example
spec:
containers:
- name: daemonset-example
image: wangyanglinux/myapp:v16、Job
Job负责批处理任务,即仅执行一次的任务,它保证批处理任务的一个或多个Pod成功结束
特殊说明
- spec.template格式同Pod
- RestartPolicy仅支持Never或OnFailure
- 单个Pod时,默认Pod成功运行后ob即结束
- .spec.completions标志ob结束需要成功运行的Pod个数,默认为1
- .spec.parallelism标志并行运行的Pod的个数,默认为1
- spec.activeDeadiineseconds标志失败Pod的重试最大时间,超过这个时间不会继续重试
example
apiVersion: batch/v1
kind: Job
metadata:
name: pi
spec:
template:
metadata:
name: pi
spec:
containers:
- name: pi
image: perl
command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
restartPolicy: Never7、Cronjob
CronJob管理基于时间的Job,即
- 在给定时间点只运行一次
- 周期性地在给定时间点运行
使用前提条件: 当前使用的Kubernetes集群,版本>= 1.8 (对Cronjob) 。对于先前版本的集群,版本< 1 1.8,启动API Server时,通过传递选项-runtime-config-batch/v2alphal=true可以开启batch/v2alpha1 API
典型的用法如下所示:
- 在给定的时间点调度Job运行
- 创建周期性运行的Job,例如:数据库备份、发送邮件
Cronjob Spec
- spec.template格式同Pod
- RestartPolicyR支持Never或OnFailure
- 单个Pod时,默认Pod成功运行后Job即结束
- .spec.completions标志Job结束需要成功运行的Pod个数,默认为1
- .spec.parallelism标志并行运行的Pod的个数,默认为1
- spec.activeDeadlineseconds标志失败Pod的重试最大时间,超过这个时间不会继续重试
- .spec.schedule :调度,必需字段,指定任务运行周期,格式同Cron
- .Spec.jobTemplate : Job模板,必需字段,指定需要运行的任务,格式同Job
- .spec.startingDeadlineSeconds :启动lob的期限(秒级别),该字段是可选的。如果因为任何原因而错过了被调度的时间,那么错过执行时间的Job将被认为是失败的。如果没有指定,则没有期阳
- . spec.concurrencyPolicy :并发策略,该字段也是可选的。它指定了如何处理被CronJob创建的Job的并发执行。只允许指定下面策略中的一种:
- Allow (默认) :允许并发运行Job
- Forbid :禁止并发运行,如果前一个还没有完成,则直接跳过下一个 o
- Replace :取消当前正在运行的Job,用一个新的来替换
注意,当前策略只能应用于同一个Cron Job创建的Job,如果存在多个Cron Job,它们创建的Job之间总是允许并发运行。
- .spec.suspend :挂起,该字段也是可选的。如果设置为true ,后续所有执行都会被挂起。它对已经开始执行的Job不起作用。默认值为false
- .spec.successfulJobsHistoryLimit和.spec. failedJobsHistoryLimit :历史限制,是可选的字段。它们指定了可以保留多少完成和失败的Job,默认情况下,它们分别设置为3和1,设置限制的值为。,相关类型的Job完成后将不会被保留。
example
apiVersion: batch/v1beta1
kind: CronJob
metadata:
name: hello
spec:
schedule: "*/1 * * * *"
jobTemplate:
spec:
template:
spec:
containers:
- name: hello
image: busybox
args:
- /bin/sh
- -c
- date; echo Hello from the Kubernetes cluster
restartPolicy: OnFailure5 kubectl get cronjob
NAMESCHEDULESUSPEND ACTIVELAST-SCHEDULEhello */1***False e
$kubectl get jobs
NAMEDESIRED SUCCESSFUL AGE1hello-1202039934 1499pods=
$(kubectl get pods --selector=job-name=hello-1202039034 --output=isonpath= .f.items. .metadata.name}).
$ kubectl logs $podsMon Aug 29 21:34:09 UTC 2016 Hello from the Kubernetes cluster
#注意,删除cronjob的时候不会自动删除job,这些job可以用kubectl delete job来删除
$ kubectl delete cronjob hello
croniob "hello" deletedCrondJob本身的一些限制
创建Job操作应该是幂等的
8、StateFulSet
StatefulSet作为Controller为Pod提供唯一的标识。它可以保证部署和scale的顺序
StatefulSet是为了解决有状态服务的问题(对应Deployments和ReplicaSets是为无状态服务而设计) ,其应用场景包括
- 稳定的持久化存储,即Pod重新调度后还是能访问到相同的持久化数据,基于PVC来实现
- 稳定的网络标志,即Pod重新调度后其PodName和HostName不变,基于Headless Service (即没有 Cluster IP的Service)来实现
- 有序部署,有序扩展,即Pod是有顺序的,在部署或者扩展的时候要依据定义的顺序依次依次进行(即从0到N-1,在下一个Pod运行之前所有之前的Pod必须都是Running和Ready状态) ,基于init containers来实现
- 有序收缩,有序删除(即从N-1到0)
9、Horizontal Pod Autoscaling
应用的资源使用率通常都有高峰和低谷的时候,如何削峰填谷,提高集群的整体资源利用率,让service中的Pod·个数自动调整呢?这就有赖于Horizontal Pod Autoscaling7,顾名思义,使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-deploymentdocker load -i perl.tar