2023年7月6日发(作者：)

K8S中五种控制器的介绍以及使⽤⽬录k8s的控制器类型pod与控制器之间的关系Deployment（⽆状态化应⽤）状态与⽆状态化对特点Deployment的更新Deployment的回滚CronJob控制器总结k8s的控制器类型Kubernetes中内建了很多controller（控制器），这些相当于⼀个状态机，⽤来控制Pod的具体状态和⾏为Deployment：适合⽆状态的服务部署StatefullSet：适合有状态的服务部署DaemonSet：⼀次部署，所有的node节点都会部署，例如⼀些典型的应⽤场景：运⾏集群存储 daemon，例如在每个Node上运⾏ glusterd、ceph在每个Node上运⾏⽇志收集 daemon，例如 fluentd、 logstash在每个Node上运⾏监控 daemon，例如 Prometheus Node ExporterJob：⼀次性的执⾏任务Cronjob：周期性的执⾏任务总体来说，K8S有五种控制器，分别对应处理⽆状态应⽤、有状态应⽤、守护型应⽤和批处理应⽤pod与控制器之间的关系controllers：在集群上管理和运⾏容器的对象通过label-selector相关联Pod通过控制器实现应⽤的运维，如伸缩，升级等Deployment（⽆状态化应⽤）应⽤场景：web服务Deployment中⽂意思为部署、调度，通过Deployment我们能操作RS（ReplicaSet），你可以简单的理解为它是⼀种通过yml⽂件的声明，在Deployment ⽂件⾥可以定义Pod数量、更新⽅式、使⽤的镜像，资源限制等。⽆状态应⽤都⽤Deployment来创建通过Deployment对象，你可以轻松的做到以下事情：创建ReplicaSet和Pod滚动升级（不停⽌旧服务的状态下升级）和回滚应⽤（将应⽤回滚到之前的版本）平滑地扩容和缩容暂停和继续DeploymentDeployment创建[root@master shuai]# vim iVersion: apps/v1kind: Deployment '定义是Deployment'metadata: name: nginx-deployment labels: app: nginxspec: replicas: 3 '副本数量为3' selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.15.4 ports: - containerPort: 80'创建资源'[root@master shuai]# kubectl apply -f

/nginx-deployment created//Replicaset 是控制版本，副本数，回滚就是通过此来实现'//查看所有资源'[root@master shuai]# kubectl get allNAME READY STATUS RESTARTS AGEpod/nginx-deployment-d55b94fd-cndf2 1/1 Running 0 3m31spod/nginx-deployment-d55b94fd-ghlwk 1/1 Running 0 3m31spod/nginx-deployment-d55b94fd-tm4sw 1/1 Running 0 3m31spod/pod-example 1/1 Running 0 10hNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEservice/kubernetes ClusterIP 10.0.0.1 443/TCP 3d6hNAME DESIRED CURRENT UP-TO-DATE AVAILABLE /nginx-deployment 3 3 3 3 3m31sNAME DESIRED CURRENT READY /nginx-deployment-d55b94fd 3 3 3 3m31s查看控制器信息kubectl deit 省略信息.....strategy: rollingUpdate: '版本更新为滚动更新机制' maxSurge: 25% '最⼤更新副本数是25%，最多扩容125%' '为了保持副本数量，增加的百分⽐同时要销毁多少' maxUnavailable: 25% '最⼤删除副本是25%，最多缩容到75%' type: 省略信息....'执⾏kubectl describe deploy nginx-deployment 也可以查看'....省略信息....RollingUpdateStrategy: 25% max unavailable, 25% max surge查看历史版本[root@master shuai]# kubectl rollout history deploy/ions/nginx-deployment

REVISION CHANGE-CAUSE1 '//这边只有⼀个，证明还没有滚动更新'状态与⽆状态化对特点⽆状态服务的特点：1）deployment 认为所有的pod都是⼀样的2）不⽤考虑顺序的要求3）不⽤考虑在哪个node节点上运⾏4）可以随意扩容和缩容1）实例之间有差别，每个实例都有⾃⼰的独特性，元数据不同，例如etcd，zookeeper2）实例之间不对等的关系，以及依靠外部存储的应⽤。Deployment的更新如果想要让 nginx pod 使⽤ nginx:1.9.1 的镜像来代替原来的 nginx的镜像，运⾏以下命令[root@master ~]# kubectl set image deployment/nginx-deployment nginx=nginx:/nginx-deployment image updated或者我们可以使⽤ edit 命令来编辑 Deployment，将image从nginx改写成 nginx:1.9.1kubectl edit deployment/nginx-deployment查看更新进度[root@master ~]# kubectl rollout status deployment/nginx-deploymentWaiting for deployment "nginx-deployment" rollout to finish: 1 old replicas are Waiting for deployment "nginx-deployment" rollout to finish: 1 old replicas are deployment "nginx-deployment" successfully rolled outDeployment更新时会创建⼀个新的ReplicaSet，然后将新的ReplicaSet中的Pod慢慢扩容到指定的副本数，将旧的ReplicaSet慢慢缩容到0。因此，更新时总能够确保旧的服务不会停⽌，这就是滚动更新。Deployment的回滚当我们像上⽂⼀样更新了Deployment之后，我们发现nginx:1.9.1的镜像不是很稳定，因此想要修改回nginx:1.7.9的版本，此时我们不需要⼿动更改Deployment⽂件，⽽是利⽤Deployment的回滚功能。使⽤rollout history命令查看Deployment的版本（revision）：[root@master ~]# kubectl rollout history deployment//nginx-deployment

REVISION CHANGE-CAUSE1 kubectl create --filename= --record=true2 kubectl create --filename= --record=true因为我们创建 Deployment 的时候使⽤了 —recored 参数可以记录命令，我们可以很⽅便的查看每次 revison 的变化。查看单个 revision 的详细信息：[root@master ~]# kubectl rollout history deployment/nginx-deployment --revision=/nginx-deployment with revision #2Pod Template: Labels: app=nginx pod-template-hash=658d7f4b4b Annotations: /change-cause: kubectl create --filename= --record=true Containers: nginx: Image: nginx:1.9.1 Port: 80/TCP Host Port: 0/TCP Environment: Mounts: Volumes: 可以使⽤rollout undo命令回滚到前⼀个revision[root@master ~]# kubectl rollout undo deployment//nginx-deployment rolled back[root@master ~]# kubectl describe deployment/nginx-deploymentName: nginx-deploymentNamespace: defaultCreationTimestamp: Fri, 24 Dec 2021 22:24:10 +0800Labels: Annotations: /revision: 3 /change-cause: kubectl create --filename= --record=trueSelector: app=nginxReplicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailableStrategyType: RollingUpdateMinReadySeconds: 0RollingUpdateStrategy: 25% max unavailable, 25% max surgePod Template: Labels: app=nginx Containers: nginx: Image: nginx Port: 80/TCP Host Port: 0/TCP Environment: Mounts: Volumes: 也可以使⽤–to-revision参数指定某个历史版本：[root@master ~]# kubectl rollout undo deployment/nginx-deployment --to-revision=/nginx-deployment rolled back[root@master ~]# kubectl describe deployment/nginx-deploymentName: nginx-deploymentNamespace: defaultCreationTimestamp: Fri, 24 Dec 2021 22:24:10 +0800Labels: Annotations: /revision: 4 /change-cause: kubectl create --filename= --record=trueSelector: app=nginxReplicas: 3 desired | 3 updated | 4 total | 3 available | 1 unavailableStrategyType: RollingUpdateMinReadySeconds: 0RollingUpdateStrategy: 25% max unavailable, 25% max surgePod Template: Labels: app=nginx Containers: nginx: Image: nginx:1.9.1 Port: 80/TCP Host Port: 0/TCP Environment: Mounts: Volumes: 你可以通过设置 .nHistoryLimit 项来指定 deployment 最多保留多少 revison 历史记录。默认的会保留所有的revision；如果将该项设置为 0，Deployment 就不允许回退了。只有 Deployment 的 rollout 被触发才会创建⼀个 revision！注意！当且仅当 Deployment 的 Pod template被更改，例如更新template 中的 label 和容器镜像时，才会触发⼀个rollout，从⽽为Deployment创建出⼀个新的 revision。rollout命令的更多⽤法：history（查看历史版本）pause（暂停Deployment）resume（恢复暂停的Deployment）status（查看资源状态）undo（回滚版本）Job Controller负责根据Job Spec创建Pod，并持续监控Pod的状态，直⾄其成功结束。如果失败，则根据restartPolicy（只⽀持OnFailure和Never，不⽀持Always）决定是否创建新的Pod再次重试任务。Job负责批量处理短暂的⼀次性任务 (short lived one-off tasks)，即仅执⾏⼀次的任务，它保证批处理任务的⼀个或多个Pod成功结束。Kubernetes⽀持以下⼏种Job：⾮并⾏Job：通常创建⼀个Pod直⾄其成功结束固定结束次数的Job：设置.tions，创建多个Pod，直到.tions个Pod成功结束带有⼯作队列的并⾏Job：设置.elism但不设置.tions，当所有Pod结束并且⾄少⼀个成功时，Job就认为是成功根据.tions和.elism的设置，可以将Job划分为以下⼏种patternJOB类型⼀次性Job固定结束次数的Job固定结束次数的并⾏Job并⾏Job使⽤实例数据库迁移处理⼯作队列的Pod⾏为创建⼀个Pod直⾄其成功结束completionsparallelism1112+2+依次创建⼀个Pod运⾏直⾄completions个成功结2+束多个Pod同时处理⼯作队依次创建多个Pod运⾏直⾄completions个成功结2+列束多个Pod同时处理⼯作队创建⼀个或多个Pod直⾄有⼀个成功结束列的使⽤[root@master ~]# vi

---apiVersion: batch/v1kind: Jobmetadata: name: myjobspec: template: spec: containers: - name: myjob image: busybox command: ["echo", "hello k8s job"] restartPolicy: Never[root@master ~]# kubectl apply -f

/myjob created[root@master ~]# kubectl get podsNAME READY STATUS RESTARTS AGEmyjob-gq27p 0/1 Completed 0 37s#查看这个 pod的任务[root@master ~]# kubectl get jobNAME COMPLETIONS DURATION AGEmyjob 1/1 19s 5m11s#查看这个 pod的⽇志[root@master ~]# kubectl logs myjob-gq27phello k8s jobCronJob控制器CronJob 可以⽤来执⾏基于时间计划的定时任务，类似于Linux/Unix系统中的 crontable (opens new window)。CronJob 执⾏周期性的重复任务时⾮常有⽤，例如备份数据、发送邮件等。CronJob 也可以⽤来指定将来某个时间点执⾏单个任务，例如将某项任务定时到系统负载⽐较低的时候执⾏。⼀个 CronJob 对象就像 crontab (cron table) ⽂件中的⼀⾏。 它⽤Cron格式进⾏编写， 并周期性地在给定的调度时间执⾏Job。注意：所有 CronJob 的 schedule: 时间都是基于kube-controller-manager. 的时区。如果你的控制平⾯在 Pod 或是裸容器中运⾏了 kube-controller-manager， 那么为该容器所设置的时区将会决定 CronJob 的控制器所使⽤的时区。为 CronJob 资源创建清单时，请确保所提供的名称是⼀个合法的DNS ⼦域名. 名称不能超过 52 个字符。 这是因为CronJob 控制器将⾃动在提供的 Job 名称后附加 11 个字符，并且存在⼀个限制， 即 Job 名称的最⼤长度不能超过 63个字符。CronJob ⽤于执⾏周期性的动作，例如备份、报告⽣成等。 这些任务中的每⼀个都应该配置为周期性重复的（例如：每天/每周/每⽉⼀次）； 你可以定义任务开始执⾏的时间间隔。下⾯的 CronJob ⽰例清单会在每分钟打印出当前时间和问候消息：[root@master kubenetres]# vi ---apiVersion: batch/v1beta1kind: CronJobmetadata: name: hellospec: schedule: "*/1 * * * *" jobTemplate: spec: template: spec: containers: - name: hello image: busybox imagePullPolicy: IfNotPresent command: - /bin/sh - -c - date; echo Hello nihao restartPolicy: OnFailure创建pod查看[root@master ~]# kubectl apply -f

Warning: batch/v1beta1 CronJob is deprecated in v1.21+, unavailable in v1.25+; use batch/v1 /hello created#等⼀分钟查看[root@master ~]# kubectl get podsNAME READY STATUS RESTARTS AGEhello-27339330-kkfxv 0/1 Completed 0 2s#查看⽇志[root@master ~]# kubectl logs hello-27339330-kkfxvFri Dec 24 15:30:00 UTC 2021Hello nihao总结到此这篇关于K8S中五种控制器及使⽤的⽂章就介绍到这了,更多相关K8S控制器使⽤内容请搜索以前的⽂章或继续浏览下⾯的相关⽂章希望⼤家以后多多⽀持！