K8s-控制器

K8s-控制器

引入：Kubernetes 中内建了很多 controller（控制器），这些相当于 一个状态机，用来控制 Pod 的具体状态和行为

控制器类型：

  • ReplicationController 和 ReplicaSet
  • Deployment
  • DaemonSet
  • StateFulSet
  • Job/CronJob
  • Horizontal Pod Autoscaling

控制器详细说明

  • ReplicationController 和 ReplicaSet

​ ReplicationController（RC）用来确保容器应用的副本数始终保 持在用户定义的副本数，即如果有容器异常退出，会自动创建新的 Pod 来替代；而如果异常多出来的容器也会自动回收 ReplicaSet 支持集合式的 selector In：label 的值在某个列表中 NotIn：label 的值不在某个列表中 Exists：某个 label 存在 DoesNotExist：某个 label 不存在 在新版本的 Kubernetes 中建议使用 ReplicaSet 来取代 ReplicationController 。ReplicaSet 跟ReplicationController 没 有本质的不同，只是名字不一样，但 ，即标签运算

​ RS 在标签选择器上，除了可以定义键值对的选择形式，还支持 matchExpressions 字段，可以提供多种选择。 目前支持的操作包 括：

​ In：label 的值在某个列表中

​ NotIn：label 的值不在某个列表中

​ Exists：某个 label 存在

​ DoesNotExist：某个 label 不存在

  • 命令的开发模式

​ 声明式表达：kubectl apply (deployment支持)--热更新

​ 命令式表达：kubectl create (RS，RC)

  • Deployment

​ Deployment 为 Pod 和 ReplicaSet 提供了一个声明式定义 (declarative) 方法，用来替代以前的ReplicationController 来方便 的管理应用。典型的应用场景包括；

​ 定义 Deployment 来创建 Pod 和 ReplicaSet

​ 滚动升级和回滚应用

​ 扩容和缩容

​ 暂停和继续 Deployment

  • Deployment与RS的关联

​ kubectl apply -f nginx-deployment.yaml --record

​ # --record参数可以记录命令，我们可以很方便的查看每次 revision 的变化 在回滚时具有记录命令的优点；

  • 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

  • Job

​ Job 负责批处理任务，即仅执行一次的任务，它保证批处理任务 的一个或多个 Pod 成功结束

  • job特殊说明

    • spec.template格式同Pod
    • RestartPolicy仅支持Never或OnFailure
    • 单个Pod时，默认Pod成功运行后Job即结束
    • .spec.completions标志Job结束需要成功运行的Pod个数，默认 为1 .
    • spec.parallelism标志并行运行的Pod的个数，默认为1，设置时 考虑资源占用问题
    • spec.activeDeadlineSeconds标志失败Pod的重试最大时间，超过这个时间不会继续重试

  • CronJob

​ Cron Job 管理基于时间的 Job，即在给定时间点只运行一次 周期性地在给定时间点运行

​ 注： 使用前提条件：当前使用的 Kubernetes 集群，版本 >= 1.8（对 CronJob）。对于先前版本的集群，版本 < 1.8，启动 API Server时，通过传递选项 --runtime-config=batch/v2alpha1=true 可以开启 batch/v2alpha1 API

​ 典型的用法如下

​ 在给定的时间点调度 Job 运行

​ 创建周期性运行的 Job，例如：数据库备份、发送邮件

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

​ 注意：CronJob本身的一些限制 创建 Job 操作应该是幂等的

​ 幂等性定义：是用户对于同一操作发起的一次请求或者多次请求的结果是一致 的,不会因为多次点击而产生了副作用， 即多次操作,结果是一致的

  • 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）

  • HPA

​ 应用的资源使用率通常都有高峰和低谷的时候，如何削峰填谷， 提高集群的整体资源利用率，让 service 中的Pod个数自动调整呢？ 这就有赖于 HPA （Horizontal Pod Autoscaling）了，顾名思义， 使 Pod 水平自动缩放

​ 注意： 在创建pod时，以往使用create关键字，但现在使用apply关键字 会更好，它具有声明式表达的作用还有兼容上下版本的优点，功能全面，支持热更新

  • 控制器中常见使用命令

    • 创建资源类型时加--record参数可以记录命令，我们可以很方便的 查看每次 revision 的变化

      kubectl create -f xxx.yaml --record

  • deployment扩容

    • 命令模式下执行
      • kubectl scale deployment nginx-deployment --replicas 10
    • 交互模式下执行
      • kubectl edit deployment nginx-deployment

​ 注意： edit选项进入交互模式可以更改许多选项，具体参看修改要求

  • 镜像更新

    • kubectl set image deployment/nginx-deployment nginx=wangyanglinux/myapp:v2

  • 回滚

    • kubectl rollout undo deployment/nginx-deployment

​ 注意： Deployment 的 rollout 当且仅当 Deployment 的 pod template（例如.spec.template）中的label更新或者镜像更改时被 触发。其他更新，例如扩容Deployment不会触发 rollout

  • 回退到指定版本：

    • 可以使用 --revision参数指定某个历史版本
    • kubectl rollout undo deployment/nginx-deployment --torevision=2

  • 查看历史版本

    • kubectl rollout history deployment/nginx-deployment

  • 暂停 deployment 的更新，用于测试更新版本的稳定性

    • kubectl rollout pause deployment/nginx-deployment

​ 注意： 可以用kubectl rollout status命令查看 Deployment 是否完 成。如果 rollout 成功完成，kubectl rollout status`将返回一个0 值的 Exit Code** 即 echo $?

  • 回滚优化方案，以文件的方式保存在本地，每次只需更改文件名的 形式去更改版本即可(当然，yaml文件内的版本号需改为要升级后的版本号)

  • 示例：

    • 依次实现即可
      • kubectl apply -f deployment.yaml
      • mv deployment.yaml deployment.v2.yaml
      • vim deployment.v2.yaml #更改到要升级的版本
      • kubectl apply -f deployment.v2.yam

  • 会自动实现更新版本功能 回滚的话直接找到原来的yaml文件再次只需创建即可，此种方法只会占用磁盘空间资源，不会占用etcd存储服务器的资源，是为优选方案

  • Deployment更新策略

    • Deployment 可以保证在升级时只有一定数量的 Pod 是 down 的。默认的，它会确保至少有比期望的Pod数量少一个是up状态 （最多一个不可用）
    • Deployment 同时也可以确保只创建出超过期望数量的一定数量 的 Pod。默认的，它会确保最多比期望的Pod数量多一个的 Pod 是 up 的（最多1个 surge)
    • 未来的 Kuberentes 版本中，将从1-1变成25%-25%

  • 更新策略声明

​ kubectl explain deploy.spec.strategy.type

​ Recreate #全部退到重建

​ rollingUpdate

​ maxSurge：指定超出副本数有几个，两种方式：1、指定数 量 2、百分比

​ maxUnavailable ： 最多有几个不可用

​ 举例

​ 命令模式更改

​ kubectl patch deployment nginx-deployment -p '{"spec": {"strategy":{"rollingUpdate": {"maxSurge":1,"maxUnavailable":0}}}}'

​ 交互模式更改

​ kubectl edit deployment nginx-deployment

​ 查看更新策略的说明

​ kubectl explain deployment.spec.strategy.rollingUpdate

​ 查看 rollout 的状态

​ kubectl rollout status deployment/nginx-deployment

  • 金丝雀部署

    • pause：暂停更新，相当于更新一个之后就不更新了，为了方便测 试新系统的稳定性

      • kubectl set image deployment nginx-deployment nginx=wangyanglinux/myapp:v3 && kubectl rollout pause deployment nginx-deployment

      • 当觉得此版本稳定之后恢复更新，resume：恢复更新到最新版本

        kubectl rollout resume deployment nginx-deployment

  • Rollover（多个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 的 rollout 被触发就会创建一个 revision。也就是说当且仅当 Deployment 的 Pod template（如 .spec.template）被更改，例如更新template 中的 label 和容器 镜像时，就会创建出一个新的 revision。其他的更新，比如扩容 Deployment 不会创建 revision——因此我们可以很方便的手动或 者自动扩容。这意味着当您回退到历史 revision 时，只有 Deployment 中的 Pod template 部分才会回退

​ 清理Policy，基于以文件的形式保存过yaml文件了，您可以通过设置.spec.revisionHistoryLimit项来指定 deployment 最多保留多少 revision 历史记录。默认的会保留所有 的 revision；如果将该项设置为0，Deployment 就不允许回退了

  • 总结

    在实际生产中，当只有RC和RS时，建议使用RS，当需要支持回 滚更新时，建议使用Deployment，当不需要回滚更新时和声明式 表达方式，还是建议使用RS，因为消耗的资源比Deployment消耗 的资源小

posted @ 2022-07-22 10:40  Sunset_cloud  阅读(195)  评论(0)  编辑  收藏  举报