Linux企业运维——Kubernetes控制器

Posted 2021-09-01 是大姚呀

Linux企业运维——Kubernetes（五）控制器

文章目录

• • Linux企业运维——Kubernetes（五）控制器
  • 1、控制器简介
  • 2、各控制器示例
  • • 2.1、ReplicaSet控制器
    • 2.2、Deployment控制器
    • 2.3、DaemonSet控制器
    • 2.4、StatefulSet控制器
    • 2.5、Job控制器
    • 2.6、CronJob控制器
    • 2.7、HPA控制器

1、控制器简介

自主POD调度绑定至节点若主程序崩溃则节点kubelet能够自动重启容器，但若是非主进程崩溃类的容器kubelet无从感知。这便需要依赖于POD对象定义的存活探测，以便kubelet能够探知到此类故障，但若pod被删除或者工作节点自身发生故障（工作节点上都有kubelet，kubelet不可用，因此其健康状态便无法保证），则便需要控制器来处理相应的容器重启和配置。
Kubernetes 中内建了很多 controller（控制器），这些相当于一个状态机，用来控制 Pod 的具体状态和行为。

Pod 的分类：

• 自主式 Pod：Pod 退出后不会被创建
• 控制器管理的 Pod：在控制器的生命周期里，始终要维持 Pod 的副本数目

控制器类型：

• ReplicationController和ReplicaSet
• Deployment
• DaemonSet
• StatefulSet
• Job
• CronJob
• HPA全称Horizontal Pod Autoscaler

2、各控制器示例

本篇给出了ReplicaSet和Deployment控制器的实例用法

2.1、ReplicaSet控制器

• ReplicaSet 是下一代的 Replication Controller，官方推荐使用ReplicaSet。
• ReplicaSet 和 Replication Controller 的唯一区别是选择器的支持，ReplicaSet 支持新的基于集合的选择器需求。
• ReplicaSet 确保任何时间都有指定数量的 Pod 副本在运行
• 虽然 ReplicaSets 可以独立使用，但今天它主要被Deployments 用作协调 Pod 创建、删除和更新的机制。

1、删除已有的pod，编辑ReplicaSet控制器清单文件rs.yaml，读取该文件新建pod


2、查看pod信息可以看到由RS控制器管理的三个pod副本成功创建，查看RS控制器信息可以看到由rs.yaml文件创建的控制器

3、编辑ReplicaSet控制器清单文件rs.yaml，指定运行的Pod 副本数量为6

4、读取应用该文件，查看pod信息可以看到由RS控制器管理的pod副本数量变为6个，更改其中任意副本的标签，再次查看pod信息可以看到由RS控制器新建了一个pod副本，其管理的pod副本数量仍为6个

5、此时删除更改过标签的副本，RS控制器管理的副本无变化，删除未修改过标签的副本，查看pod信息可以看到RS控制器新拉起一个pod副本，其管理的pod副本数量始终为6个
这是因为ReplicaSet 控制器是通过标签控制在任何时间都有指定数量的 Pod 副本在运行

2.2、Deployment控制器

Deployment 为 Pod 和 ReplicaSet 提供了一个申明式的定义方法。

典型的应用场景：

• 用来创建Pod和ReplicaSet
• 滚动更新和回滚
• 扩容和缩容
• 暂停与恢复

1、编辑ReplicaSet控制器清单文件rs.yaml，缩小运行的Pod 副本数量为3（3个副本够实验使用），设定RS控制器生成的副本使用v1版本的myapp镜像

2、读取应用该文件，查看pod信息可以看到由RS控制器管理的pod副本数量变为3个，curl访问任一pod副本分配到的ip，是nginx容器的默认发布页面，这说明RS副本控制器只通过标签控制副本数量，不能实现pod副本镜像版本的迭代更新

3、pod副本镜像版本的迭代更新需要与deployment控制器结合，读取rs.yaml文件删除生成的pod副本及控制器，编辑deployment控制器清单文件deployment.yaml，设定deployment控制器生成的三个副本使用nginx镜像（不进行设定时deployment控制器默认副本数为1)

4、读取应用该文件，查看pod资源额外信息可以得到生成的pod副本的ip，curl访问任一pod副本分配到的ip，是nginx容器的默认发布页面

5、编辑deployment.yaml，设定deployment控制器生成的副本使用v1版本的myapp镜像，读取应用该文件

6、再次查看pod资源额外信息可以得到生成的pod副本的ip，curl访问任一pod副本分配到的ip，是myapp:v1容器的默认发布页面，pod副本镜像版本迭代更新成功

7、查看RS控制器信息可以看到，deployment控制器生成时会同时生成RS控制器来协调 Pod 创建、删除和更新，由于我们进行了镜像版本更新，所以会有两个RS控制器，即原有的RS控制器不会删除，便于镜像版本的回滚

2.3、DaemonSet控制器

DaemonSet 确保全部（或者某些）节点上运行一个 Pod 的副本。当有节点加入集群时， 也会为他们新增一个 Pod 。当有节点从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod。

DaemonSet 的典型用法：

1. 在每个节点上运行集群存储 DaemonSet，例如 glusterd、ceph。
2. 在每个节点上运行日志收集 DaemonSet，例如 fluentd、logstash。
3. 在每个节点上运行监控 DaemonSet，例如 Prometheus Node Exporter、zabbix agent等

一个简单的用法是在所有的节点上都启动一个 DaemonSet，将被作为每种类型的 daemon 使用。
一个稍微复杂的用法是单独对每种 daemon 类型使用多个 DaemonSet，但具有不同的标志， 并且对不同硬件类型具有不同的内存、CPU 要求。

DaemonSet控制器示例：

$ vim daemonset-example.yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
 name: daemonset-example
 labels:
   k8s-app: zabbix-agent
spec:
 selector:
   matchLabels:
     name: zabbix-agent
 template:
   metadata:
     labels:
       name: zabbix-agent
   spec:
     containers:
     - name: zabbix-agent
       image: zabbix/zabbix-agent

2.4、StatefulSet控制器

StatefulSet 是用来管理有状态应用的工作负载 API 对象。实例之间有不对等关系，以及实例对外部数据有依赖关系的应用，称为“有状态应用”
StatefulSet 用来管理 Deployment 和扩展一组 Pod，并且能为这些 Pod 提供序号和唯一性保证。
StatefulSets 对于需要满足以下一个或多个需求的应用程序很有价值：

• 稳定的、唯一的网络标识符。
• 稳定的、持久的存储。
• 有序的、优雅的部署和缩放。
• 有序的、自动的滚动更新。

2.5、Job控制器

执行批处理任务，仅执行一次任务，保证任务的一个或多个Pod成功结束。

Job控制器示例：

$ vim job-example.yaml
apiVersion: batch/v1
kind: Job
metadata:
 name: pi
spec:
 template:
   spec:
     containers:
     - name: pi
       image: perl
       command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
     restartPolicy: Never
  backoffLimit: 4
$kubectlapply -f job-example.yaml
$kubectl get pod
NAME      READY   STATUS      RESTARTS  AGE
pi-6phk8  0/1     Completed   0         2m22s
$kubectl logspi-6phk8
$kubectldelete job pi

2.6、CronJob控制器

Cron Job 创建基于时间调度的 Jobs。
一个 CronJob 对象就像 crontab (cron table) 文件中的一行，它用 Cron 格式进行编写，并周期性地在给定的调度时间执行 Job。

Cronjob控制器示例：

$ vim cronjob-example.yaml
apiVersion: batch/v1beta1
kind: CronJob
metadata:
 name: cronjob-example
spec:
 schedule: "* * * * *"
 jobTemplate:
   spec:
     template:
       spec:
         containers:
         - name: cronjob
            image: busybox
            args:
            - /bin/sh
            - -c
            - date; echo Hello from k8s cluster
         restartPolicy: OnFailure
         
$ kubectlapply -f cronjob-example.yaml
$ kubectl get cronjob
NAME              SCHEDULE    SUSPEND  ACTIVE   LAST SCHEDULE   AGE
cronjob-example  * * * * *   False     0       38s             8m22s 
$kubectl get job -w
NAME                         COMPLETIONS   DURATION  AGE
cronjob-example-1581873180   1/1          1s         3m
cronjob-example-1581873240   1/1          1s         2m
$kubectl get pod
NAME                               READY   STATUS     RESTARTS   AGE
cronjob-example-1581873240-r644w   0/1    Completed   0          2m51s
cronjob-example-1581873300-p89rc   0/1    Completed   0          111s
$kubectl logs cronjob-example-1581873240-r644w
Sun Feb 16 17:14:06 UTC 2020
Hello from k8s cluster
$kubectldelete  cronjob  cronjob-example
cronjob.batch"cronjob-example" deleted

2.7、HPA控制器

Horizontal Pod Autoscaler（HPA）
HPA可作为KubernetesAPI资源的控制实现，它基于采集到得资源指标数据来调整控制器的行为，HPA获取资源指标数据是通过Heapster和REST客户端接口获取。目前HPA有两个版本分别是HPA和HPA v1。

工作流程:

1.创建HPA资源，设定目标CPU使用率限额，以及最大、最小实例数, 一定要设置Pod的资源限制参数: request, 否则HPA不会工作。
2.控制管理器每隔30s(可以通过–horizontal-pod-autoscaler-sync-period修改)查询metrics的资源使用情况
3.然后与创建时设定的值和指标做对比(平均值之和/限额)，求出目标调整的实例个数
4.目标调整的实例数不能超过1中设定的最大、最小实例数，如果没有超过，则扩容；超过，则扩容至最大的实例个数
然后就是重复2-4步

自动伸缩算法:
HPA Controller会通过调整副本数量使得CPU使用率尽量向期望值靠近，而且不是完全相等．另外，官方考虑到自动扩展的决策可能需要一段时间才会生效：例如当pod所需要的CPU负荷过大，从而在创建一个新pod的过程中，系统的CPU使用量可能会同样在有一个攀升的过程。所以，在每一次作出决策后的一段时间内，将不再进行扩展决策。对于扩容而言，这个时间段为3分钟，缩容为5分钟(可以通过–horizontal-pod-autoscaler-downscale-delay, --horizontal-pod-autoscaler-upscale-delay进行调整)。

HPA Controller中有一个tolerance（容忍力）的概念，它允许一定范围内的使用量的不稳定，现在默认为0.1，这也是出于维护系统稳定性的考虑。例如，设定HPA调度策略为cpu使用率高于50%触发扩容，那么只有当使用率大于55%或者小于45%才会触发伸缩活动，HPA会尽力把Pod的使用率控制在这个范围之间。

具体的每次扩容或者缩容的多少Pod的算法为:
Ceil(前采集到的使用率 / 用户自定义的使用率) * Pod数量)
每次最大扩容pod数量不会超过当前副本数量的2倍