《Kubernetes》- 认识下Pod的管理者？

你们好，我是小菜，前面几篇文章咱们已经从 k8s 集群的搭建而后到 k8s 中NameSpace 再说到了 k8s 中 Pod 的使用，若是还干到意犹未尽，那么接下来的 Pod 控制器 一样是一道硬菜！
死鬼~看完记得给我来个三连哦！

本文主要介绍 k8s中pod控制器的使用

若有须要，能够参考

若有帮助，不忘 点赞 ❥

微信公众号已开启，小菜良记，没关注的同窗们记得关注哦！

前文回顾：

• 《k8s 集群搭建》不要让贫穷扼杀了你学 k8s 的兴趣！
• 万字警告 - k8s入门，理应Pod先行！

既然有 pod 的存在，那便须要对pod 进行管理，控制器又怎么了少的了，那么接下来的时间交给小菜，带你一探到底！

Pod控制器

1、前头预热

咱们已经清楚了Pod是 k8s 中最小的管理单元。想一想咱们以前是怎么建立 pod，动动小脑壳，隐约想起好像有3种方式！1. 命令式对象管理 2. 命令式对象配置 3. 声明式对象配置 。 若是能想到这三种，说明上篇没白学！可是这三种的建立方式，咱们都是围绕 pod 展开的，无论是经过命令直接建立，仍是经过 yaml文件配置完再生成，咱们生成的 Kind 都是直接指明 Pod，仿佛咱们对 pod 的认知也局限于此了。可是今天，小菜就带你认识点不同的东西，咱们能够经过 Pod管理器 来建立 pod！

1）概念

什么是 pod 控制器呢？上面只是简单说了能够用来建立 pod，难道做用也仅此而已，那我何须又画蛇添足呢~

Pod 控制器，意如其名。就是用来控制 pod的，它是做为管理 pod 的中间层，使用 pod 控制器以后，只须要告诉 pod 控制器，我想要几个pod，想要什么样的pod，它便会为咱们建立出知足条件的 pod，并确保每个 pod 资源都是处于用户指望的目标状态，若是 pod 资源在运行中出现故障，它便会基于指定的策略从新编排 pod

至关于控制器也就是一个管家，能够更好的为咱们管理 pod。

经过 pod 控制器建立的 pod还有个最大的不一样点，那即是：若是经过直接建立出来的 pod，这种 pod 删除后也就真的删除了，不会重建。而经过 pod 控制器建立的pod，删除后还会基于指定的策略从新建立！

pod控制器 也分为不少种类型，k8s 中支持的控制器类型以下：

• ReplicaSet：保证副本数量一致维持在指望值，支持 pod 数量扩缩容 和 镜像版本升级
• Deployment： 经过控制 ReplicaSet 来控制 Pod，支持滚动升级和回退版本
• Horizontal Pod Autoscaler：能够根据集群负载自动水平调整 pod 的数量
• DaemonSet： 在集群中的指定 Node 上运行且仅运行一个副本，通常用于守护进程类的任务
• Job：它建立出来的pod只要完成任务就会当即退出，不须要重启或重建，用于执行一次性任务
• Cronjob： 它建立的pod负责周期性任务控制，不须要持续后台运行
• StatefulSet： 管理有状态的应用

这么多控制器，看了也别慌，接下来咱们一个个认识过去~

2、实际操做

1）ReplicaSet

ReplicaSet 简称 rs，它的主要做用即是保证必定数量的 pod 正常运行，它会持续监听这些pod的运行状态，一旦 pod 发生故障，就会重启或重建，同时它还支持对 pod 数量的扩缩容和镜像版本的升降级。

咱们来看下 RS 的资源清单：

apiVersion: apps/v1   # 版本号
kind: ReplicaSet       # 类型
metadata:             # 元数据信息
  name:               # 名称
  namespace:          # 命名空间
  labels:             # 标签
    key: value
spec:                  # 详细描述
  replicas:           # 副本数
  selector:           # 选择器，经过它指定该控制器管理那些Pod
    matchLabels:      # labels 匹配规则
      app: 
    matchExpressions:
    - key: xxx
      operator: xxx
      values: ['xxx', 'xxx']
  template:       # 模板，当副本数量不足时，会根据如下模板建立Pod副本
    metadata:
      labels:
        key: value
    spec:
      containers:
      - name: 
        image:
        ports:
        - containerPort:

咱们这里须要新了解的属性以下：

• spec.replicas： 副本数量。当前 rs 会建立出来的 pod 数量，默认为 1
• spec.selector： 选择器。创建 pod 控制器和 pod 之间的关联关系，在 pod 模板上定义 label，在控制器上定义选择器，就可让pod归属于哪一个控制器底下
• spec.template： 模板。当前控制器建立 pod 所使用的的模板，里面定义内容与上节说到的 pod 定义是同样的

建立RS

咱们编写一个 yaml 试着建立一个 RS 控制器：

经过 kubectl create -f rs.yaml 后能够发现已经存在了两个pod，说明副本数量生效，当咱们删除一个 pod，过一会便会自动启动一个 pod！

扩缩容

既然 RS 建立的时候能控制 pod 的副本数量，固然在运行的时候也可以动态扩缩容。

直接修改

咱们经过如下命令，可以直接编辑 rs 的yaml文件

kubectl edit rs rs-ctrl -n cbuc-test

将 replicas 数量改成 3，保存退出后，能够发现正在运行的pod 数量已经变成了 3 个。

命令修改

除了以上经过修改yaml的方式，咱们也能够直接经过命令的方式修改

kubectl scale rs rs-ctrl --replicas=2 -n cbcu-test

以上命令咱们是借助 scale 指令的帮助修改 pod 的副本数量。

镜像更新

除了能够控制副本数量，还能够进行镜像的升级。咱们上面运行Pod使用的镜像是 nginx:1.14.1 若是咱们想要升级镜像版本号一样有两种方法：

直接修改

咱们经过如下命令，可以直接编辑 rs 的yaml文件

kubectl edit rs rs-ctrl -n cbuc-test

编辑镜像版本号后保存退出，能够发现正在运行的pod使用的镜像已经变了

命令修改

处理以上经过修改yaml的方式，咱们也能够直接经过命令的方式修改

kubectl set image rs rs-ctrl nginx=nginx:1.17.1 -n cbuc-test

格式以下：

kubectl set image rs 控制器名称 容器名称=镜像名称:镜像版本 -n 命名空间

删除镜像

若是咱们不想要使用该控制器了，最好的方式即是将其删除。咱们能够根据资源清单删除

kubectl delete -f rs.yaml

也能够直接删除

kubectl delete deploy rs-ctrl -ncbuc-test

可是咱们须要清楚的是，默认状况下，控制器删除后，底下所控制的pod也会对应删除，可是有时候咱们只是想单纯的删除控制器，而不想删除pod，就得借助命令选项--cascade=false

kubectl delete rs rs-ctrl -n cbuc-test --cascade=false

2）Deployment

Deployment 控制器简称 Deploy，这个控制器是在kubernetes v1.2版本以后开始引入的。这种控制器并非直接管理 pod，而是经过管理 ReplicaSet 控制器 来间接管理 pod

由图可知，Deployment的功能只会更增强大：

• 支持 ReplicaSet 全部功能
• 支持发布的中止、继续
• 支持滚动升级和回滚版本

三大利器，将开发拿捏死死地~咱们来看下资源清单是如何配置的：

从资源清单中咱们能够看出，ReplicaSet 中有的，Deployment 都有，并且还增长了许多属性

建立Deploy

准备一份 deploy 资源清单：

而后经过 kubectl create -f deploy-ctrl.yaml 建立pod控制器，查看结果：

扩缩容

扩缩容的方式和 ReplicaSet 同样，有两种方式，这里简单带过

直接修改

kubectl edit deploy deploy-ctrl -n cbuc-test

将 replicas 数量改成 3，保存退出后，能够发现正在运行的pod 数量已经变成了 3 个。

命令修改

kubectl scale deploy deploy-ctrll --replicas=2 -n cbcu-test

镜像更新

Deployment支持两种更新策略: 重建更新和滚动更新 ，能够经过 strategy 指定策略类型,支持两个属性:

strategy：            # 指定新的Pod替换旧的Pod的策略， 支持两个属性：
  type：                # 指定策略类型，支持两种策略
    Recreate：         # 在建立出新的Pod以前会先杀掉全部已存在的Pod
    RollingUpdate：  # 滚动更新，就是杀死一部分，就启动一部分，在更新过程当中，存在两个版本Pod
  rollingUpdate：    # 当type为RollingUpdate时生效，用于为RollingUpdate设置参数，支持两个属性
    maxUnavailable： # 用来指定在升级过程当中不可用Pod的最大数量，默认为25%。
    maxSurge：         # 用来指定在升级过程当中能够超过时望的Pod的最大数量，默认为25%。

正常来讲 滚动更新 会比较友好，在更新过程当中更加趋向于“无感”更新

版本回退

Deployment 还支持版本升级过程当中的暂停、继续以及版本回退等诸多功能，这些都与rollout有关：

使用方式：

• history

显示升级历史记录

kubectl rollout history deploy deploy-ctrl -ncbuc-test

• pause

暂停版本升级过程

kubectl rollout pause deploy deploy-ctrl -ncbuc-test

• restart

重启版本升级过程

kubectl rollout restart deploy deploy-ctrl -ncbuc-test

• resume

继续已经暂停的版本升级过程

kubectl rollout resume deploy deploy-ctrl -ncbuc-test

• status

显示当前升级状态

kubectl rollout status deploy deploy-ctrl -ncbuc-test

• undo

回滚到上一级版本

kubectl rollout undo deploy deploy-ctrl -ncbuc-test

3）Horizontal Pod Autoscaler

看名字就感受这个不简单，该控制器简称 HPA ，咱们以前是手动控制 pod 的扩容或缩容，可是这中方式并不智能，咱们须要随时随地观察资源状态，而后控制副本数量，这是一个至关费时费力的工做~ 所以咱们想要可以存在一种可以自动控制 Pod 数量的控制器来帮助咱们监测 pod 的使用状况，实现 pod 数量的自动调整。而 K8s 也为咱们提供了 Horizontal Pod Autoscaler - HPA

HPA 能够获取每一个 pod 的利用率， 而后和 HPS 中定义的指标进行对比，同时计算出须要伸缩的具体数量，而后对 pod 进行调整。

若是须要监测 pod 的负载状况，咱们须要 metrics-server 的帮助，所以咱们首先须要先安装 metrics-server

# 安装git
yum install -y git
# 获取mertrics-server
git clone -b v0.3.6 https://github.com/kubernetes-incubator/metrics-server
# 修改metrics-server deploy
vim /root/metrics-server/deploy/1.8+/metrics-server-deployment.yaml
# 添加下面选项
hostNetwork: true
image: registry.cn-hangzhou.aliyuncs.com/google_containers/metrics-server-amd64:v0.3.6
args:
- --kubelet-insecure-tls
- --kubelet-preferred-address-types=InternalIP,Hostname,InternalDNS,ExternalDNS,ExternalIP

而后直接建立便可：

kubectl apply -f /root/metrics-server/deploy/1.8+/

安装结束后咱们即可以使用如下命令查看每一个node的资源使用状况了

kubectl top node

查看pod资源使用状况

kubectl top pod -n cbuc-test

而后咱们即可以建立 HPA，准备好资源清单：

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: hpa-ctrl
  namespace: cbuc-test
spec:
  minReplicas: 1        # 最小Pod数量
  maxReplicas: 5           # 最大Pod数量
  targetCPUUtilzationPercentage: 3   # CPU使用率指标
  scaleTargetRef:         # 指定要控制 deploy 的信息
    apiVersion: apps/v1
    kind: Deployment
    name: deploy-ctrl

# 建立hpa
[root@master /]# kubectl create -f hpa-deploy.yaml
# 查看hpa
[root@master /]# kubectl get hpa -n dev

到这里咱们就建立好了一个 HPA，它能够动态对 pod 进行扩缩容，这里就不作测试了，有兴趣的同窗能够进行压测，看看结果是否如本身所指望的~

4）DaemonSet

DaemonSet 控制器简称 DS ，它的做用即是能够保证在集群中的每一台（或指定）节点上都运行一个副本。这个做用场景通常是用来作日志采集或节点监控。

若是一个Pod提供的功能是节点级别的（每一个节点都须要且只须要一个），那么这类Pod就适合使用 DaemonSet 类型的控制器建立

特色：

• 每向集群添加一个节点时，指定的 Pod 副本也将会被添加到该节点上
• 当节点从集群中移除时，Pod 也将被回收

资源清单模板：

其实不难发现，该清单跟 Deployment 几乎一致，所以咱们不妨大胆猜想，这个控制器就是针对 Deployment 改良的懒人工具，能够自动帮咱们建立Pod~

实战清单：

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: pc-daemonset
  namespace: dev
spec:
  selector:
    matchLabels:
      app: nginx-pod
  template:
    metadata:
      labels:
        app: nginx-pod
      spec:
      containers:
      - name: nginx
        image: nginx:1.14-alpine

经过该清单建立后，咱们能够发如今每一个 Node 节点上都建立了 nginx pod~

5）Job

Job，意如其名，该控制器的任务即是 负责批量处理（一次要处理指定数量任务）短暂的一次性（每一个任务仅运行一次就结束）的任务。

特色：

• 当Job建立的Pod执行成功结束时，Job会记录成功结束的pod数量
• 当成功结束的pod达到指定的数量时，Job将完成执行

资源清单模板：

这里重启策略是必须指明的，且只能为 Never 或 OnFailure，缘由以下：

• 若是指定为OnFailure，则job会在pod出现故障时重启容器，而不是建立pod，failed次数不变
• 若是指定为Never，则job会在pod出现故障时建立新的pod，而且故障pod不会消失，也不会重启，failed次数加1
• 若是指定为Always的话，就意味着一直重启，意味着job任务会重复去执行了，固然不对，因此不能设置为
  Always

实战清单：

apiVersion: batch/v1
kind: Job
metadata:
  name: job-ctrl
  namespace: cbuc-test
  labels:
    app: job-ctrl
spec:
  manualSelector: true
  selector:
    matchLabels:
      app: job-pod
  template:
    metadata:
      labels:
        app: job-pod
    spec:
      restartPolicy: Never
      containers:
      - name: test-pod
        image: cbuc/test/java:v1.0
        command: ["bin/sh","-c","for i in 9 8 7 6 5 4 3 2 1; do echo $i;sleep 2;done"]

经过观察pod状态能够看到，pod在运行完毕任务后，就会变成Completed状态

6）CronJob

CronJob控制器简称 CJ，它的做用是以 Job 控制器为管理单位，借助它管理 pod 资源对象。Job 控制器定义的任务在建立时便会马上执行，但 cronJob 控制器能够控制其运行的 时间点及 重复运行 的方式。

资源清单模板：

其中 并发执行策略 有如下几种：

• Allow： 容许 Jobs 并发运行
• Forbid： 禁止并发运行，若是上一次运行还没有完成，则跳过下一次运行
• Replace： 替换，取消当前正在运行的做业并用新做业替换它

实战清单：

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: cj-ctrl
  namespace: cbuc-test
  labels:
    controller: cronjob
spec:
  schedule: "*/1 * * * *"
  jobTemplate:
    metadata:
    spec:
      template:
        spec:
          restartPolicy: Never
          containers:
           - name: test
            image: cbuc/test/java:v1.0
            command: ["bin/sh","-c","for i in 9 8 7 6 5 4 3 2 1; do echo $i;sleep3;done"]

从结果上看咱们也已经成功实现了定时任务，每秒执行了一次~

END

这篇咱们介绍了 Pod 控制器的使用，一共有 6种控制器，不知道看完后，你还记住几种呢~老样子，实践出真知，凡事仍是要上手练习才能记得更牢哦~ K8s 仍未结束，咱们还有 Service、Ingress和 Volumn 还没介绍！路漫漫，小菜与你一同求索~

今天的你多努力一点，明天的你就能少说一句求人的话！

我是小菜，一个和你一块儿学习的男人。 💋

微信公众号已开启，小菜良记，没关注的同窗们记得关注哦！