0x00Controller介绍

0x01Controller详述

1.ReplicationController

2.ReplicaSet

3.Deployment

4.DaemonSet

5.Job

6.CronJob

7.StatefulSet

8.HorizontalPodAutoscaling-水平扩展

Q:什么是资源控制器(资源控制器介绍)?答：Kubernetes中内建了很多controller（控制器），这些相当于一个状态机，用来控制Pod的具体状态和行为。

Q:为什么要使用控制器？答:前面说过Pod是k8s最小的部署单元，而如果需要创建批量的Pod副本并进行扩容缩以及POD回退就必须使用Controller进行实现；

Q:有哪些类型的控制器?

(1)ReplicationController和ReplicaSet

(2)Deployment

(3)DaemonSet

(4)Job/CronJob

(5)StatefulSet

(6)HorizontalPodAutoscaling

Q:什么是ReplicationController(RC)?

答:ReplicationController是一个基本的控制器类型,它即我们所说的RC(副本控制器),用于确保任意时间都有指定数量的Pod"副本"在运行;

Q:RC它有何作用?

答:确保容器应用的副本数始终保持在用户定义的副本数，即如果有容器异常退出，会自动创建新的Pod来替代而如果异常多出来的容器也会自动回收；

Q:RC工作原理

答:创建RC之后K8SMaster节点上的ControllerManager(控制器管理器)组件接到创建RC的通知进行创建满足副本数相应的Pod,然后它会定期巡视系统当中的存活的目标Pod,然后进行标签匹配来监视对应的Pod，并确保目标Pod实例刚好等于RC中定义的副本数期望值，而目标Pod超过副本期望值将会被销毁;

Q:RC组成部分

Pod期待的副本数Replicas

用于筛选目标Pod的LableSelector，对应Pod模板(Template)

Pod数量小于副本期望值时根据Pod模板创建相应的Pod

Q:RC使用实例

#rc-demo.yamlapiVersion:v1kind:ReplicationCaontrollermetadata:name:rc-demo#Rc名称spec:replicas:3#Pod副本期望值selector:app:nginxtemplate:metadata:name:nginx#pod名称lables:#Pod模板标签app:nginx#KV值spec:containers:-name:nginx#容器名称image:nginx:latestports:-contianerPort:80

操作实践:

#创建kubectlcreate-frc-demo.yaml#获取RC详细信息kubectlgetrc/rc-demokubectldescriberc/rc-demo#获取Pod的信息kubectlgetpod-lapp=nginx#删除RC创建的Pod(他会重新创建满足其副本数)kubectldeletepodnginx-*#删除RC(慎用-f它是强制的)kubectldelete-frc-demo.yaml

Tips:我们可以在删除RC时不删除其构建的Pod进行更新修改RC,可以采用delete命令子参数cascade=false(级联),原RC被删除后可以创建一个新的RC来替换它，前提是旧的和新.spec.selector相匹配,那么新的将会采用旧的Pod;Tips:官方在新版本的Kubernetes中建议舍弃ReplicationController，切换使用功能能更强的ReplicaSet(RS)这也是下一节的主要内容;

Q:什么是ReplicaSet?

答:ReplicaSet即是我们说的(RS)副本集,它是在k8sv1.2引入可以将它看做是RC的升级版本;而ReplicaSet跟ReplicationController没有本质的不同只是名字不一样，然后支持集合式(Set-Basedselecor)的selector，这使得RS在资源选择上更为灵活；

Q:ReplicaSet有何作用?

答:RS和RC一样都能确保运行满足副本数期望值的Pod;虽然RS可以独立使用而它主要用于协调Deployment对Pod创建、删除、更新等，当使用Deployment时候不用担心RS因为可以直接通过Deployment对其进行管理；

Tips:快速查看控制器的apiVsersion

$kubectlapi-versions

grep$(kubectlapi-resources

grep"ReplicaSet"

awk-F""{print$3})apps/v1

Pod资源文件示例：

catpod-demo.yamlEOFapiVersion:v1kind:Podmetadata:name:pod-demolabels:app:pod-demospec:containers:-name:nginx-pod-demoimage:harbor.weiyigeek.top/test/nginx:v1.0ports:-containerPort:80EOF

ReplicaSet资源文件示例:

catreplicaset-demo.yamlEOFapiVersion:apps/v1kind:ReplicaSetmetadata:name:replicaset-demo#ReplicaSet名称labels:#ReplicaSet标签app:replicaset-demospec:replicas:3#有3个副本selector:#标签选择器matchLabels:#matchLabels是{key,value}对的映射app:replicaset-demo#注意:匹配的标签需要原数据中的replicaset-demo一致matchExpressions:-{key:tier,operator:In,values:{frontend}}template:#模板metadata:labels:app:replicaset-demospec:#模板细则containers:-name:nginx-replicaset-demoimage:harbor.weiyigeek.top/test/nginx:v1.0 　　·spec.template格式同Pod 　　·RestartPolicy仅支持Never或OnFailure·单个Pod时，默认Pod成功运行后Job即结束· 　　.spec. 　　.spec.parallelism标志并行运行的Pod的个数，默认为1 　　·spec.activeDeadlineSeconds标志失败Pod的重试最大时间，超过这个时间不会继续重试

.spec.schedule：调度，必需字段，指定任务运行周期，格式同Cron· 　　.spec.jobTemplate:Job模板，必需字段，指定需要运行的任务，格式同Job 　　.spec.startingDeadlineSeconds:启动Job的期限（秒级别），该字段是可选的。如果因为任何原因而错过了被调度的时间，那么错过执行时间的Job将被认为是失败的。如果没有指定，则没有期限.spec.concurrencyPolicy:并发策略，该字段也是可选的。它指定了如何处理被CronJob创建的Job的并发执行。只允许指定下面策略中的一种： 　　 　　Allow（默认）：允许并发运行Job 　　 　　Forbid：禁止并发运行，如果前一个还没有完成，则直接跳过下一个 　　 　　Replace：取消当前正在运行的Job，用一个新的来替换 　　注意，当前策略只能应用于同一个CronJob创建的Job。如果存在多个CronJob，它们创建的Job之间总是允许并发运行。 　　.spec.suspend：挂起，该字段也是可选的。如果设置为true，后续所有执行都会被挂起。它对已经开始执行的Job不起作用。默认值为false。 　　.spec.successfulJobsHistoryLimit和.spec.failed]obsHistoryLimit:历史限制，是可选的字段。它们指定了可以保留多少完成和失败的Job。默认情况下，它们分别设置为3和1。设置限制的值为0，相关类型的Job完成后将不会被保留。

CronJob资源文件示例

catcronjob-demo.yamlEOFapiVersion:batch/v1beta1kind:CronJobmetadata:name:cronjob-demospec:schedule:"*/1****"#表示每一分钟运行一次jobTemplate:spec:template:spec:#模板配置说明书containers:-name:cronjob-demoimage:busyboxargs:-/bin/sh--c-date;echoHellofromtheKubernetescluster,Thisiscronjob-demo;imagePullPolicy:IfNotPresent#如果本地存在则不拉取restartPolicy:OnFailureEOF

操作流程:

#(1)忘记如果编写CronJob的资源清单的时候可以按照下面格式查找帮助;~$kubectlexplainCronJob.spec.jobTemplate.spec.template.spec.containers#(2)创建~/K8s/Day5/demo3$kubectlcreate-fcronjob-demo.yamlcronjob.batch/cronjob-democreated#(3)查看$kubectlgetcj-owide--show-labels#cronjob控制创建#NAMESCHEDULESUSPEND(是否延迟)ACTIVELASTSCHEDULE(下一次执行)AGECONTAINERSIMAGESSELECTORLABELS#cronjob-demo*/1****Falses3m3scronjob-demobusyboxnonenone$kubectlgetjobs-owide#实际上cronjob调用Job创建pod,可以看见已经完成有三个job(缺省保留3次成功或者失败的Job)#NAMECOMPLETIONSDURATIONAGECONTAINERSIMAGESSELECTOR#cronjob-demo-/12s2m46scronjob-demobusyboxcontroller-uid=0ec-d-4a5a-8f83-fdf18#cronjob-demo-/12sscronjob-demobusyboxcontroller-uid=e9ccc-ed2b-4b49--e4dd2fd#cronjob-demo-/12s46scronjob-demobusyboxcontroller-uid=f-14f2-4fc9-b-fbbe~/K8s/Day5/demo3$kubectlgetpod-owide--show-labels#NAMEREADY(这里由于完成后便立即退出了)STATUSRESTARTSAGEIPNODELABELS#cronjob-demo--pfw/1Completed02m32s10..1.62k8s-node-4controller-uid=f-14f2-4fc9-b-fbbe,job-name=cronjob-demo-#cronjob-demo--6jslj0/1Completeds10..1.63k8s-node-4controller-uid=ca2-c28e-4c3d-b7ea-a0acf59f3,job-name=cronjob-demo-#cronjob-demo--h0/1Completeds10..1.65k8s-node-4controller-uid=d4b1e-b---7a3ef78ddc69,job-name=cronjob-demo-#(4)执行反馈结果~$kubectlgetpod

grep"cronjob"

cut-d""-f1#cronjob-demo--twsb8#cronjob-demo--dtscf#cronjob-demo--64g88~$kubectllogscronjob-demo--twsb8#WedNov:33:03UTC#HellofromtheKubernetescluster,Thisiscronjob-demo~$kubectllogscronjob-demo--dtscf#WedNov:34:03UTC#HellofromtheKubernetescluster,Thisiscronjob-demo~$kubectllogscronjob-demo--64g88#WedNov:35:03UTC#HellofromtheKubernetescluster,Thisiscronjob-demo#(5)两种方式删除CronJob控制器创建的Job以及附属的Pod资源~/K8s/Day5/demo3$kubectldeletecronjob--all~/K8s/Day5/demo3$kubectldelete-fcronjob-demo.yamlcronjob.batch"cronjob-demo"deleted

PS:Cronjob本身的一些限制创建Job操作应该是幂等的,CronJob并不太好去判断任务是否成功，CronJob通过创建Job去完成任务，Job成功与否可以判断，但CronJob无法链接到Job去获取成功与否，Cron只会定期的去创建Job仅此而已。

描述:前面我们学习了RC、RS、Deployment、DaemonSet与Job等它们都是面向无状态服务的，而本节学习的StatefulSet的控制器是有状态服务的即主要用于部署（有状态服务的应用程序）。

在K8s中使用StatefulSet控制器来部署有状态服务,StatefulSet是一个给Pod提供唯一标准的控制器，它可以保证部署和扩展收缩的顺序;

Q:什么是有状态服务?什么又是无状态服务?

A:服务所维护的与客户交互活动的信息称为状态信息StatelessService（无状态服务）：在应用程序运行过程之中不保存任何数据和状态信息的服务；例如Mysql它需要存储产生的新数据;StatafulService(有状态服务):在应用程序运行过程之中保存的数据或状态的服务；例如Nginx;

StatefulSet特征

(1)稳定(固定)的网络标识符，即Pod重新调度后其PodName和HostName不变基于HeadlessService（即没有ClusterIP的Service)来实现，例如一个Pod叫做mysql-0，第二个叫做mysql-1，然后依次顺序满足其期望值即n的一个叫做mysql-(n-1)。

(2)有序部署和有序扩展：基于initcontainers来实现，在第n个Pod启动之间，前一个Pod必须是处于Ready且Running状态;

(3)稳定的持久化存储：即Pod重新调度后还是能访问到相同的持久化数据，基于PV/PVC、以及StorageClass来实现。

(4)有序删除和停止:即从N-1到0Terminal依次销毁;

Statefulset启停顺序详述:

1.有序部署:部罢Statefulset时，如果有多个Pod副本，它们会被顺序地创建（从0到N-1)并且，在下一个Pod运行之前所有之前的Pod必须都是Running和Ready状态。

2.有序删除:当Pod被删除时，它们被终止的顺序是从N-1到0。

3.有序扩展:当对Pod执行扩展操作时，与部署一样，它前面的Pod必须都处于Running和Ready状态

Tips:StatefulSet除了需要采用PV/PVC持久化Pod状态数据之外还需使用到HeadlessService,该Service为StatefulSet控制的每个Pod创建一个DNS域名,其格式PodName.HeadlessServiceName

#例如HeadlessServiceName=database,而StatefulSet名称为mysql-app则其DNS名称为mysql-app-1.databasemysql-app-2.database

此次是针对于StatefulSet控制器做一个简单的了解后续在进行PVC持久化卷数据时演示;

#statefulset资源控制器~$kubectlapi-resources

grep"stateful"#资源#statefulsetsstsappstrueStatefulSet~$kubectlapi-versions

grep"apps"#api-groups及其版本#apps/v1~$kubectlgetstorageclass#NAMEPROVISIONERRECLAIMPOLICYVOLUMEBINDINGMODEALLOWVOLUMEEXPANSIONAGE#managed-nfs-storage(default)fuseim.pri/ifsDeleteImmediatefalse57d

资源清单示例:

catstatefulset-demo.yamlENDapiVersion:v1kind:Servicemetadata:name:nginx-statefulset-servicelabels:app:nginxspec:clusterIP:Noneselector:app:nginx-sfsports:-name:webport:80---apiVersion:apps/v1kind:StatefulSet#资源控制器metadata:name:webspec:selector:matchLabels:app:nginx-sfs#匹配.spec.template.metadata.labels中的标签serviceName:"nginx-statefulset-service"#绑定的SVC与上面的Service名称对应replicas:3template:metadata:labels:app:nginx-sfs#Pod模板的标签(有了它StatefulSet知道创建的Pod是否在自己期望数量中以及便于SVC)spec:containers:-name:nginximage:nginx:1.19.6ports:-containerPort:80name:webvolumeMounts:-name: