Kubernetes集群部署与运维 课件 单元8 控制器概述及ReplicaSet

控制器概述及ReplicaSet软件技术专业群·

专业选修课目录/Contents控制器概述0201ReplicaSet控制器控制器概述01控制器在Kubernetes中，控制器通过监控集群的公共状态，并致力于将当前状态转变为期望的状态，根据不同的应用场景分为以下控制器：ReplicaSet：用于实现Pod副本数的管理；Deployment：常用的控制器对象，通过管理ReplicaSet实现更高级的功能，适合用来管理集群上的无状态应用；StatefulSet：用于保证有状态应用的副本数，能够运行一个或者多个以某种方式跟踪应用状态的Pods；DaemonSet：其将在每个节点上都运行一个Pod，提供节点本地支撑设施的Pods；Job：用于执行一次性任务；CronJob：用于根据其时间规划反复运行任务。ReplicaSet控制器02ReplicaSet控制器ReplicaSet的目标是在任何给定时刻，其均可维护一组处于运行状态的Pod，以使这些Pod的副本数达到预期。应用场景：通常用来保证给定数量的、完全相同的Pod的可用性。原理：ReplicaSet通过选择器Selector和标签Label确定Pod的数量。ReplicaSet的yaml文件里的字段replicas是指控制器应该维护的Pod副本数量。当ReplicSet需要创建新的Pod副本时会使用yaml文件里的Pod模板，也即template字段。ReplicaSet控制器——配置文件在主节点master01上创建controllers文件夹，在其中创建replicaset-demo.yaml文件，内容如下：注意：selector的matchLabels要与template的labels相匹配；在yaml文件中，#字符表示注释。ReplicaSet控制器——创建根据配置文件创建该replicaset，查看pod信息可发现：此时系统中存在三个pod，同属于一个replicaset，labels都为app=nginx-pod，运行于不同的节点上。ReplicaSet控制器——维持副本数若删除掉其中一个pod副本，replicaset控制器将根据template模板重新创建一个新的pod。rs-nginx-7sp7q是被删除的pod；rs-nginx-fm579是重新创建的pod。ReplicaSet控制器——扩缩容使用kubectlscalereplicaset--replicas=<number><replicaSetName>命令进行扩缩容。注意：副本数缩容至0，并不意味着控制器被删除，重新设置大于0的副本数，系统仍会自动创建pod。ReplicaSet控制器——删除直接使用kubectldeletepods<podName>无法删除replicaset控制器，需要使用命令：kubectldeletereplicasets.app<replicaSetName>删除后，即使改变副本数量报错：找不到该控制器，证明已完全删除。THANKS谢谢聆听集群部署与运维Deployment控制器创建与更新管理软件技术专业群·

专业选修课目录/ContentsDeployment概述0201创建与副本数管理03更新与回滚更新暂停与恢复0504更新状态查询Deployment概述01Deployment控制器Deployment控制器通过管理ReplicaSet控制器来实现更多的功能，可以看作是ReplicaSet的升级版本。其典型应用场景有：创建Deployment以将ReplicaSet上线。通过更新Deployment的PodTemplateSpec，声明Pod的新状态。如果Deployment的当前状态不稳定，回滚到较早的Deployment版本。每次回滚都会更新Deployment的修订版本；扩大Deployment规模以承担更多负载；暂停Deployment以应用对PodTemplateSpec所作的多项修改，然后恢复其执行以启动新的上线版本；使用Deployment状态来判定上线过程是否出现停滞；清理较旧的不再需要的ReplicaSet。创建与副本数管理02controllers文件夹内创建deployment-demo1.yaml文件，内容如下：Deployment控制器的创建Deployment的配置文件与replicaset基本一致，仅kind由replicaset改为deployment；该示例中，nginx的镜像使用1.14.2版本。创建deployment控制器，同时观察启动过程中replicaset控制器和labels的情况Deployment控制器的创建注意：Deployment控制器创建的同时，系统中有一个名为deployment-ngxin-<随机数字>的replicaset控制器被创建；Deployment控制器会自动给pod添加一个标签，该标签的值为replicaset名称后的<随机数字>。Deployment副本控制注意：创建dp-nginxPod，仅赋予其标签app=nginx，可照常运行；当赋予dp-nginxPod第二个标签 pod-template-hash=66b6c48dd5，deployment直接将AGE最短的Pod进行了回收，保持副本数与期望值一致。Deployment扩缩容执行缩容命令后，待回收Pod的状态变为Terminating；若执行扩容，即副本数大于当前已有副本数，则待创建Pod的状态为ContainerCreating。使用kubectlscaledeployment--replicas=<Number><deploymentName>命令进行扩缩容更新与回滚03Deployment更新Deployment控制器的更新是指Deployment的Pod模板（即.spec.template）发生改变时，例如模板的标签或容器镜像被更新，才会触发Deployment上线。注意：该配置文件中指定创建的deployment控制器与系统中已存在的deployment-nginx有以下关联：Pod名一致；标签一致；副本数量一致；仅容器镜像版本从1.14.2变为1.16.1。Deployment更新使用kubectlapply-f命令进行镜像版本升级，观察过程可发现：更新过程是先创建三个新版（nginx:1.16.1）Pod，然后再把旧版删除；升级后，可看到有两个replicaset，其中旧版已不包含Pod副本。Deployment更新除了使用yaml配置文件通过kubectlapply-f命令进行Deployment的更新之外，还可以使用kubectlsetimagedeployment<deploymentName><containerName>=<imageName:tag>--recored命令进行更新：Deployment更新使用kubectlrollouthistory命令查看上线内容（更新历史记录）一共有三次更新（三个版本，1.14.2、1.16.1，以及最后使用命令行更新的1.7.6）。注意：但只有1.7.6版对应的命令使用了--record参数，因此这个历史记录是从annotations中解析出来的。！kubectlsetimagedeploymentdeployment-nginxnginx=nginx:1.7.6--recordDeployment回滚回滚：将程序或数据恢复到上一次正确状态的行为，命令：kubectlrolloutundodeployment<deploymentName>--to-revision=<revisionNo>不同版本中与ReplicaSet相应的随机字符串是不同的；每进行版本变更，就存在着一个与之相对应的ReplicaSet；更新暂停与恢复04Deployment暂停暂停命令：kubectlrolloutpausedeployment<deploymentName>在Deployment更新过程中，可能需要暂停，进行相关状态、日志等信息的查看以便进一步排错等注意：需要强调的是，更新副本数不属于Deployment更新，暂停与恢复对此类操作不生效Deployment暂停根据Pod简略信息，申请副本数为3，但是由于是更新过程中出现了暂停要求，而更新的过程是先创建新版Pod，再终止旧版Pod，因此暂停时（更新命令执行2秒之后），新版Pod只启动了一个，而旧版均运行。因此，最后共有四个Pod处于运行状态，一个新版，三个旧版；deployment-nginxDeployment控制器的READY列为4/3，申请的是3个，就绪的为4个Pod副本。查看deployment控制器的状态：Deployment恢复恢复命令：kubectlrolloutresumedeployment<deploymentName>恢复版本变更之后，控制器将继续创建新版Pod，在变更过程中，始终保持处于Running状态的Pod副本数为3更新状态查询05Deployment恢复kubectlrolloutstatusdeployment<deploymentName>命令可查看Deployment的更新状态。THANKS谢谢聆听集群部署与运维DaemonSet与StatefulSet软件技术专业群·

专业选修课目录/ContentsDaemonSet控制器0201StatefulSet控制器DaemonSet控制器01DaemonSet控制器概述DaemonSet作用：DaemonSet确保全部（或者某些）节点上均运行一个Pod的副本。当有节点加入集群时，也会为他们新增一个Pod。当有节点从集群移除时，这些Pod也会被回收。删除DaemonSet将会删除它创建的所有Pod。DaemonSet控制器的典型应用包括：日志收集，比如Fluentd、Logstash等；系统监控，比如PrometheusNodeExporter、collectd、NewRelicagent、Gangliagmond等；系统程序，比如kube-proxy、glusterd、ceph等。副本数量：

由于DaemonSet保证在每个正常节点上都运行一个Pod副本，因此其副本数是与节点数量一致的。所以，与ReplicaSet和Deployment不同，DaemonSet无需指定副本数DaemonSet控制器概述使用kubectl-nkube-systemgetpods-owide命令，查看集群核心组件部署情况calico-node和kube-proxy均为DaemonSet类型的控制器，其在示例中的三个节点（master01、worker01和worker02）中均部署了一个Pod副本DaemonSet控制器创建尝试创建DaemonSet控制器，配置文件如下：类型指定为DaemonSet；DaemonSet的配置文件中没有replicas字段，无需指定副本数；问：左侧配置文件是否会在所有节点都上部署DaemonSet控制器的Pod副本？注意：主节点master01默认被标记为污点，不参与任何调度。DaemonSet控制器创建使用命令kubectlapply-fdaemonset-demo1.yaml创建该资源，可以看到只在worker节点上存在Pod，而master节点则没有。若要master节点也运行该Pod，需要在配置文件中设置对污点进行容忍，例如右图所示配置。StatefulSet控制器02StatefulSet控制器概述DaemonSet作用：StatefulSet控制器能够保证Pod的每个副本在整个生命周期中名称是不变的；同时StatefuleSet会保证副本按照固定的顺序启动、更新或者删除。StatefulSet控制器主要解决的问题有：稳定的持久化存储，即Pod重新调度后还是能访问到相同的持久化数据；稳定的网络标志，即Pod重新调度后其PodName和HostName不变；有序部署，有序扩展，即Pod是有顺序的，在部署或者扩展的时候要依据定义的顺序依次依序进行（即从0到N-1，在下一个Pod运行之前所有之前的Pod必须都是Running和Ready状态）；有序收缩（即从N-1到0）。StatefulSet控制器创建相较于Deployment控制器配置文件而言：多出一个serviceName字段；多出一个超止期terminationGracePeriodSeconds字段，10秒；Kubernetes等待指定的时间称为优雅终止宽限期（默认30s），是创建稳定系统和提供出色用户体验的核心；尝试创建StatefulSet控制器，配置文件如下：StatefulSet控制器创建StatefulSet控制器启动之后：各Pod的名称为<statefulSetName>-<数字>；创建的顺序由0开始；每一个Pod的创建启动均是依次创建启动，前一个Pod未进入到Running状态之前，后一个Pod不会创建StatefulSet控制器删除注意：StatefulSet控制器的删除，建议先进行缩容为0，然后再删除StatefulSet控制器。缩容的过程中，也是按照N-1到0的次序进行Pod的删除。THANKS谢谢聆听集群部署与运维Job控制器与CronJob控制器软件技术专业群·

专业选修课目录/ContentsJob控制器0201CronJob控制器Job控制器01Job控制器概述Job控制器用于运行结束就删除的应用。而其他控制器中的Pod通常是长期持续运行。Job控制器运行原理：Job控制器会创建一个或者多个Pod，并将继续重试Pod的执行，直到指定数量的Pod成功终止。随着Pod成功结束，Job控制器跟踪记录成功完成的Pod个数。当数量达到指定的成功个数阈值时，任务（即Job）结束。删除Job控制器的操作会清除所创建的全部Pods。Job运行方式：串行、并行创建名为pi的Job控制器，计算π小数点后2000位，并将结果打印出来，参考配置文件如下：restartPolicy重启策略：此处指定的是Pod的重启策略，而非Job控制器，只有Never和OnFailure两种取值；backoffLimit：指Job控制器失败次数达到指定值时，Job终止Job控制器案例一使用kubectlapply命令创建该Job：COMPLETIONS列表示Job中的command执行次数；DURATION表示Job的执行时间Job控制器案例一Job的最终状态为Completed，即任务完成。在pi-parallJob执行期间，每次均启动2个Pod，并行执行作业Job控制器案例二在pi-parallJob执行期间，每次均启动2个Pod，并行执行作业CronJob控制器02CronJob控制器概述类似于Deployment与ReplicaSet的关系，CronJob控制器管理基于时间的Job.Job控制器运行原理：在给定时间点只运行一次，周期性地在给定时间点运行；CronJob对象类似于Linux命令crontab（cronta