关于后端:replicaSetDaemonSet-and-Job

ReplicaSet

上一篇讲到的 ReplicationController 是用于复制和在异样的时候从新调度节点的 K8S 组件，前面 K8S 又引入了 ReplicaSet 资源来代替 ReplicationController

ReplicationController 和 ReplicaSet 有什么区别呢？

ReplicationController 和 ReplicaSet 的行为是完全相同的，然而 ReplicaSet 的 pod 选择器表达能力更强

• ReplicationController 只容许蕴含某个标签的匹配 pod
• ReplicaSet 能够蕴含特定标签名的 pod，例如 env=dev 和 env=pro 一起匹配
• ReplicaSet 还能够匹配短少某个标签的 pod

总之，无论 ReplicationController 匹配的标签值是多少，ReplicationController 都无奈基于标签名来进行匹配，例如 匹配 env=* ReplicationController 就不行，然而 ReplicaSet 能够

写一个 ReplicaSet Demo

rs 是 ReplicaSet 的简称，写一个 ReplicaSet 的 demo

• api 版本是 apps/v1

此处的 api 版本和之前咱们写到的有些许不一样，这里解释一下

此处的 apps 代表的是 api 组的意思

这里的 v1 代表的是 apps 组下的 v1 版本，此处就和咱们平时写的 路由一样

• 正本数 3 个
• 选择器指定匹配标签为 app=xmt-kubia，（ReplicationController 是间接写在 selector 前面）
• 模板拉取的镜像是 xiaomotong888/xmtkubia

kubia-rs.yaml

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: kubia-rs
spec:
  replicas: 3
  selector:
    matchLabels:
      app: xmt-kubia
  template:
    metadata:
      labels:
        app: xmt-kubia
    spec:
      containers:
      - name: rs-kubia
        image: xiaomotong888/xmtkubia
        ports:
        - containerPort: 8080

部署 rs

kubectl create -f kubia-rs.yaml

部署 rs 后，咱们能够看到，通过 Kubectl get rs 查看新建的 rs 根本信息

对于本来就有的 3 个标签为 app=xmt-kubia 的 pod 没有影响，rs 也没有多创立 pod，这没故障

rs 也是会去搜寻环境内的匹配的标签对应的 pod 个数，而后和本人配置中的冀望做比拟，若 冀望的大，则减少 pod 数量，若期望的小，则缩小 pod 数量

感兴趣的敌人 也能够应用 kubectl describe 查看一下这个 rs，和 rc 没有什么区别

ReplicaSet 能够这样用

下面的例子我咱们能够看到的 RepilicaSet 应用 matchLabels 的时候 如同和 ReplicationController 没有什么区别，那么当初咱们能够来丰盛一下咱们的抉择，咱们能够应用 matchExpressions

例如咱们在 yaml 退出 matchExpressions 的时候，咱们能够这样来写

省略多行...
selector:
  matchExpressions:
    - key: env
      operator: In
      values:
        - dev
省略多行...

例如下面 yaml 代码段的含意是：

• 匹配的标签 key 是 env
• 运算符是 In
• 匹配的 env 对应的 值是有 dev 即可

key

具体的标签 key

operator

运算符，有这 4 个

• In

Label 的值必须与其中一个制订的 values 匹配

• NotIn

Label 的值必须与任何制订的 values 不匹配

• Exists

pod 必须蕴含一个制订的名称的标签，有没有值不关怀，这个时候不要指定 values 字段

• DoesNotExist

pod 的标签名称不得蕴含有指定的名称，这个时候不要指定 values 字段

留神

如果咱们指定了多个表达式，那么须要这些表达式都是 true 才能够失效，才能够正确匹配

删除 rs

删除 rs 的时候和删除 rc 的做法是一样的，默认的话都是会删除掉 rs 治理的 pod，如果咱们不须要删除对应的 pod，那么咱们也能够退出 --cascade=false 或者 –cascade=orphan

依照上述形式指定之后，删除 rs，就不会对 pod 有任何影响

DaemonSet

后面说到的 ReplicationController 和 ReplicaSet 都是在 k8s 集群中部署特定的数量的 pod，然而 pod 具体是运行在哪个节点上的，不太关怀。

当初咱们能够来分享一个 DaemonSet，它也是 k8s 中的一种资源

当咱们心愿咱们的 pod 正好在每一个节点运行一个的时候，能够应用 DaemonSet 资源来进行治理

DaemonSet 没有正本数的概念，他是查看每个节点外面是否有本人治理的标签对应的 pod，若有就维持，若没有就创立

如下是一个 ReplicaSet 和 DaemonSet 治理内容和形式的简图：

图中，咱们能够看出 DaemonSet 是每个节点别离部署一个 pod，然而 ReplicaSet 只是保障整个集群中本人治理对应标签的 pod 数量是 4 个即可

DaemonSet 的 小案例

DaemonSet 资源也是应用的 apps/v1 api 版本

• 匹配标签 app=ssd

• pod 模板中咱们设置该 pod 指定运行在 标签为 disk=ssdnode 的节点上运行，能够通过 nodeSelector 关键字来指定

• 镜像拉取的是 xiaomotong888/xmtkubia

daemonset.yaml

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: kubia-ds
spec:
  selector:
    matchLabels:
      app: ssd
  template:
    metadata:
      labels:
        app: ssd
    spec:
      nodeSelector:
        disk: ssdnode
      containers:
      - name: rs-kubia
        image: xiaomotong888/xmtkubia
        ports:
        - containerPort: 8080

部署 DaemonSet

咱们应用命令部署 DaemonSet

kubectl create -f daemonset.yaml

查看 ds 的信息，ds 是 DaemonSet 的简称

kubectl get ds

应用命令查看 node 节点状况

kubectl get nodes

通过上图咱们能够看出，部署完 DaemonSet 资源之后，每一项参数都是 0

起因是，DaemonSet 查找环境中没有标签是 disk=ssdnode 的节点

给指定的 node 加上标签 disk=ssdnode

kubectl label node minikube disk=ssdnode

加上标签之后，咱们能够看到上述图片，DaemonSet 资源的各项参数变成了 1，查看 pod 的时候，也看到了对应的 pod 资源

此处演示应用的是 minikube，因而只有一个 节点

再次批改 node 的标签

咱们再次批改 node 标签，那么之前的 pod 是不是会被终止掉呢？咱们来试试吧

kubectl label node minikube disk=hddnode –overwrite

果然没故障老铁，当咱们批改环境中指定节点的标签后，因为 DaemonSet 资源搜寻环境中没有本人配置中指定的标签对应的节点，因而，方才的 pod 就会被销毁掉

Job

再来介绍一下 k8s 中的 Job 资源

Job 资源是运行咱们运行一种 pod，一旦程序运行 ok，pod 就会推出，job 就完结了，他不会重启 pod

当然，job 治理的 pod，如果在运行过程中，产生了异样，咱们是能够配置 Job 重启 pod 的

如下画了一个 ReplicaSet 和 Job 治理 pod 的简图：

上图中咱们能够看到，被 ReplicaSet 和 Job 资源管理的 pod，当节点产生异样或者 pod 本身产生异样的时候，这些 pod 是会被重启的，不须要人为的去操作

然而没有被上述资源管理的 pod，一旦产生异样，就没有人负责重启了

Job 案例

创立一个 Job 的资源，也是通过 yaml 的形式

• 类型为 Job
• 模板中的重启策略设置为 失败的时候重启 restartPolicy: OnFailure，此处的策略不能设置为 Always，设置成 Always 是会总是重启 pod 的
• 拉取的镜像是 luksa/batch-job

这个镜像是 docker hub 上的镜像，拉进去程序启动之后，运行 2 分钟会完结程序

myjob.yaml

apiVersion: batch/v1
kind: Job
metadata:
  name: batchjob
spec:
  template:
    metadata:
      labels:
        app: batchjob-xmt
    spec:
      restartPolicy: OnFailure
      containers:
      - name: xmt-kubia-batch
        image: luksa/batch-job

部署 Job

kubectl create -f myjob.yaml

能够看到 Job 资源曾经部署胜利了，且 pod 曾经是在创立中了

pod 运行过程中，咱们查看一下这个 pod 的日志

kubectl logs -f batchjob-gpckc

能够看到程序有开始日志的输入

等到 pod 运行 2 分钟左右的时候，咱们能够持续查看日，程序曾经胜利完结了，且咱们的 pod 也进行了 Completed 状态，该 Job 也完结了

上述说到的 Job 资源，也能够设置多个 pod 实例，能够设置多个 pod 实例并行运行，也能够设置串行运行，就看咱们的业务需要是什么样的了

串行的话，咱们能够这样来写 yaml：

在定义 Job 资源的时候，配置上 completions 即可，Job 资源就会一个挨着一个的创立 pod 运行，pod 运行完结后，再创立下一个 pod

apiVersion: batch/v1
kind: Job
metadata:
  name: batchjob
spec:
  completions: 10
  template:
  省略多行...

并行的话咱们能够这样来写 yaml：

设置并行的话，咱们只须要在下面的 yaml 上退出 parallelism 配置即可，示意并行运行多少个 pod

apiVersion: batch/v1
kind: Job
metadata:
  name: batchjob
spec:
  completions: 10
  parallelism: 4
  template:
  省略多行...

CronJob

下面的 Job 治理的 pod，都是启动一次，运行一次，或者是管制运行的次数，那么，咱们能不能管制周期性的运行 一个 pod 呢？

k8s 中当然是能够的了，咱们就能够应用 k8s 中的 CronJob 资源 来实现咱们的想法

咱们只须要在 yaml 文件中写好 CronJob 的配置即可，指定好 pod 运行的周期时间即可

CronJob 的 demo

• 资源类型是 CronJob
• 运行的周期是 "* * * * *"，示意 每隔 1 分钟运行一次 pod

cronjob.yaml

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: mycronjob
spec:
  schedule: "* * * * *"
  jobTemplate:
    spec:
      template:
        metadata:
          labels:
            app: cronjob-xmt
        spec:
          restartPolicy: OnFailure
          containers:
          - name: cronjobxmt
            image: luksa/batch-job

此处咱们设置的是每一分钟运行一次 pod，咱们要是有别的需要也能够自行设定，上述 5 个 * 含意如下：

• 分钟
• 小时
• 天
• 月
• 星期

例如，我须要设置每个星期一的，8 点起床，就能够这样写

“0 8 1”

部署 CronJob

kubectl create -f cronjob.yaml

查看 CronJob

kubectl get cj

部署 cj 后，咱们能够看到 cj 曾经起来了，然而如同还没有对应的 pod 被创立，cj 是 CronJob 简称

当然是不会有 pod 被创立的了，须要等 1 分钟才会创立

再次查看咱们的 cj，咱们能够看到 ACTIVE 曾经是 1 了，阐明曾经通过 cj 创立了 1 个 pod

咱们来查看 pod，果然是创立胜利了一个 pod，且曾经在运行中了，没故障老铁

咱们在应用 CronJob 资源的时候，会遇到这么一种状况：

启动的 Job 或者 pod 启动的时候绝对比拟晚的时候，咱们能够这样来设定一个边界值

当咱们的 pod 开始启动的工夫不能晚于咱们预约工夫的过多，咱们能够设置成 20s，如果晚于这个值，那么该 job 就算是失败

咱们能够这样来写 yaml：

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: mycronjob
spec:
  schedule: "* * * * *"
  startingDeadlineSeconds: 20
  jobTemplate:
  省略多行...

以上就是本次的全部内容了，别离分享了 ReplicaSet，DaemonSet，Job，CronJob，感兴趣的敌人口头起来吧

明天就到这里，学习所得，若有偏差，还请斧正

欢送点赞，关注，珍藏

敌人们，你的反对和激励，是我保持分享，提高质量的能源

好了，本次就到这里

技术是凋谢的，咱们的心态，更应是凋谢的。拥抱变动，背阴而生，致力向前行。

我是 阿兵云原生，欢送点赞关注珍藏，下次见~