关于kubernetes:Kubernetes-认识下Pod的管理者

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

本文次要介绍 k8s 中 pod 控制器的应用

如有须要，能够参考

如有帮忙，不忘 点赞 ❥

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

前文回顾：

• 《k8s 集群搭建》不要让贫困扼杀了你学 k8s 的趣味！
• 万字正告 – k8s 入门，理当 Pod 后行！

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

Pod 控制器

一、前头预热

咱们曾经分明了 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： 治理有状态的利用

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

二、实际操作

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 还没介绍！路漫漫，小菜与你一起求索~

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

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

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