kubernetes的五种控制器

k8s的控制器类型

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

  1. Deployment：适合无状态的服务部署
  2. StatefullSet：适合有状态的服务部署
  3. DaemonSet：一次部署，所有的node节点都会部署，例如一些典型的应用场景：
    运行集群存储 daemon，例如在每个Node上运行 glusterd、ceph
    在每个Node上运行日志收集 daemon，例如 fluentd、 logstash
    在每个Node上运行监控 daemon，例如 Prometheus Node Exporter
  4. Job：一次性的执行任务
  5. Cronjob：周期性的执行任务

Deployment控制器

Deployment概述

Deployment对象，顾名思义，是用于部署应用的对象。它使Kubernetes中最常用的一个对象，它为ReplicaSet和Pod的创建提供了一种声明式的定义方法，从而无需像前两篇文章中那样手动创建ReplicaSet和Pod对象（使用Deployment而不直接创建ReplicaSet是因为Deployment对象拥有许多ReplicaSet没有的特性，例如滚动升级和回滚）。

通过Deployment对象，你可以轻松的做到以下事情：

  • 创建ReplicaSet和Pod
  • 滚动升级（不停止旧服务的状态下升级）和回滚应用（将应用回滚到之前的版本）
  • 平滑地扩容和缩容
  • 暂停和继续Deployment

Deployment的创建

以下列的deploy.yml文件为例，使用以下命令创建一个nginx的Deployment：

[root@master ~]# vi deploy.yml
[root@master ~]# cat deploy.yml
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
   matchLabels:
     app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80




[root@master ~]# kubectl create -f deploy.yml  --record
Flag --record has been deprecated, --record will be removed in the future
deployment.apps/nginx-deployment created

--record参数可以记录当前版本的Deployment都执行过哪些命令。

创建完成后立即执行get命令可以查看这个Deployment：

[root@master ~]# kubectl get deployments
NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   3/3     3            3           2m14s
[root@master ~]# kubectl get pods
NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-74d589986c-kxcvx   1/1     Running   0          2m11s
nginx-deployment-74d589986c-s277p   1/1     Running   0          2m11s
nginx-deployment-74d589986c-zlf8v   1/1     Running   0          2m11s

NAME代表Deployment的名字，DESIRED代表这个Deployment期望的副本数量，CURRENT代表当前已经创建了的副本数量，UP-TO-DATE代表已经更新完成的副本数量，AVAILABLE代表对于当前用户可用的副本数量，AGE代表当前Deployment已经运行的时长。

等待几秒钟，再次运行get命令，可以查看到变化：

[root@master ~]# kubectl get deployments
NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   3/3     3            3           3m4s

通过kubectl get rs来查看系统中ReplicaSet对象，由此可以看出Deployment会自动创建一个ReplicaSet对象。

[root@master ~]# kubectl get rs
NAME                          DESIRED   CURRENT   READY   AGE
nginx-deployment-74d589986c   3         3         3       4m29s

通过kubectl get pods --show-labels命令来查看当前系统中的Pod对象，可以成功观察到nginx-deployment创建的3个Pod。

[root@master ~]# kubectl get pods --show-labels
NAME                                READY   STATUS    RESTARTS   AGE     LABELS
nginx-deployment-74d589986c-kxcvx   1/1     Running   0          3m55s   app=nginx,pod-template-hash=74d589986c
nginx-deployment-74d589986c-s277p   1/1     Running   0          3m55s   app=nginx,pod-template-hash=74d589986c
nginx-deployment-74d589986c-zlf8v   1/1     Running   0          3m55s   app=nginx,pod-template-hash=74d589986c

Deployment的更新

假如我们现在想要让 nginx pod 使用 nginx:1.9.1 的镜像来代替原来的 nginx的镜像，运行以下命令：

[root@master ~]# kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1
deployment.apps/nginx-deployment image updated

或者我们可以使用 edit 命令来编辑 Deployment，将image从nginx改写成 nginx:1.9.1。

kubectl edit deployment/nginx-deployment

查看更新进度：

[root@master ~]# kubectl rollout status deployment/nginx-deployment
Waiting for deployment "nginx-deployment" rollout to finish: 1 old replicas are pending termination...
Waiting for deployment "nginx-deployment" rollout to finish: 1 old replicas are pending termination...
deployment "nginx-deployment" successfully rolled out

Deployment更新时会创建一个新的ReplicaSet，然后将新的ReplicaSet中的Pod慢慢扩容到指定的副本数，将旧的ReplicaSet慢慢缩容到0。因此，更新时总能够确保旧的服务不会停止，这就是滚动更新。

Deployment的回滚

当我们像上文一样更新了Deployment之后，我们发现nginx:1.9.1的镜像不是很稳定，因此想要修改回nginx:1.7.9的版本，此时我们不需要手动更改Deployment文件，而是利用Deployment的回滚功能。

使用rollout history命令查看Deployment的版本（revision）：

[root@master ~]# kubectl rollout history deployment/nginx-deployment
deployment.apps/nginx-deployment 
REVISION  CHANGE-CAUSE
1         kubectl create --filename=deploy.yml --record=true
2         kubectl create --filename=deploy.yml --record=true

因为我们创建 Deployment 的时候使用了 —recored 参数可以记录命令，我们可以很方便的查看每次 revison 的变化。

查看单个 revision 的详细信息：

[root@master ~]# kubectl rollout history deployment/nginx-deployment --revision=2
deployment.apps/nginx-deployment with revision #2
Pod Template:
  Labels:       app=nginx
        pod-template-hash=658d7f4b4b
  Annotations:  kubernetes.io/change-cause: kubectl create --filename=deploy.yml --record=true
  Containers:
   nginx:
    Image:      nginx:1.9.1
    Port:       80/TCP
    Host Port:  0/TCP
    Environment:        <none>
    Mounts:     <none>
  Volumes:      <none>

现在，可以使用rollout undo命令回滚到前一个revision：

[root@master ~]# kubectl rollout undo deployment/nginx-deployment
deployment.apps/nginx-deployment rolled back

[root@master ~]# kubectl describe deployment/nginx-deployment
Name:                   nginx-deployment
Namespace:              default
CreationTimestamp:      Fri, 24 Dec 2021 22:24:10 +0800
Labels:                 <none>
Annotations:            deployment.kubernetes.io/revision: 3
                        kubernetes.io/change-cause: kubectl create --filename=deploy.yml --record=true
Selector:               app=nginx
Replicas:               3 desired | 3 updated | 3 total | 3 available | 0 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  25% max unavailable, 25% max surge
Pod Template:
  Labels:  app=nginx
  Containers:
   nginx:
    Image:        nginx
    Port:         80/TCP
    Host Port:    0/TCP
    Environment:  <none>
    Mounts:       <none>
  Volumes:        <none>

也可以使用–to-revision参数指定某个历史版本：

[root@master ~]#  kubectl rollout undo deployment/nginx-deployment --to-revision=2
deployment.apps/nginx-deployment rolled back

[root@master ~]# kubectl describe deployment/nginx-deployment
Name:                   nginx-deployment
Namespace:              default
CreationTimestamp:      Fri, 24 Dec 2021 22:24:10 +0800
Labels:                 <none>
Annotations:            deployment.kubernetes.io/revision: 4
                        kubernetes.io/change-cause: kubectl create --filename=deploy.yml --record=true
Selector:               app=nginx
Replicas:               3 desired | 3 updated | 4 total | 3 available | 1 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  25% max unavailable, 25% max surge
Pod Template:
  Labels:  app=nginx
  Containers:
   nginx:
    Image:        nginx:1.9.1
    Port:         80/TCP
    Host Port:    0/TCP
    Environment:  <none>
    Mounts:       <none>
  Volumes:        <none>

你可以通过设置 .spec.revisonHistoryLimit 项来指定 deployment 最多保留多少 revison 历史记录。默认的会保留所有的 revision；如果将该项设置为 0，Deployment 就不允许回退了。

只有 Deployment 的 rollout 被触发才会创建一个 revision！注意！当且仅当 Deployment 的 Pod template被更改，例如更新 template 中的 label 和容器镜像时，才会触发一个rollout，从而为Deployment创建出一个新的 revision。

rollout命令的更多用法：

  • history（查看历史版本）
  • pause（暂停Deployment）
  • resume（恢复暂停的Deployment）
  • status（查看资源状态）
  • undo（回滚版本）

Replicaset控制器

Replicaset概述

ReplicaSet是kubernetes中的一种副本控制器，简称rs，主要作用是控制由其管理的pod，使pod副本的数量始终维持在预设的个数。它的主要作用就是保证一定数量的Pod能够在集群中正常运行，它会持续监听这些Pod的运行状态，在Pod发生故障时重启pod，pod数量减少时重新运行新的 Pod副本。官方推荐不要直接使用ReplicaSet，用Deployments取而代之，Deployments是比ReplicaSet更高级的概念，它会管理ReplicaSet并提供很多其它有用的特性，最重要的是Deployments支持声明式更新，声明式更新的好处是不会丢失历史变更。所以Deployment控制器不直接管理Pod对象，而是由 Deployment 管理ReplicaSet，再由ReplicaSet负责管理Pod对象。

Replicaset工作原理

Replicaset核心作用在于用户创建指定数量的pod副本，并确保pod副本一直处于满足用户期望的数量， 起到多退少补的作用，并且还具有自动扩容缩容等制。
Replicaset控制器主要由三个部分组成：

  1. 用户期望的pod副本数：用来定义由这个控制器管控的pod副本有几个
  2. 标签选择器：选定哪些pod是自己管理的，如果通过标签选择器选到的pod副本数量少于我们指定的数量，需要用到下面的组件
  3. pod资源模板：如果集群中现存的pod数量不够我们定义的副本中期望的数量怎么办，需要新建pod，这就需要pod模板，新建的pod是基于模板来创建的。

Replicaset使用案例

#编写一个ReplicaSet资源清单
[root@k8s-master1 ~]# cat replicaset.yml 
---
apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: frontend
  labels:
    app: nginx
    tier: frontend
spec:
  replicas: 3
  selector:
    matchLabels:
      tier: frontend
  template:
    metadata:
      labels:
        tier: frontend
    spec:
      containers:
      - name: nginx
        image: nginx
        imagePullPolicy:  IfNotPresent


[root@master ~]# kubectl apply -f replicaset.yaml 
replicaset.apps/frontend created
[root@master ~]# kubectl  get pods
NAME             READY   STATUS    RESTARTS   AGE
frontend-7rrp6   1/1     Running   0          9s
frontend-drmcf   1/1     Running   0          9s
frontend-qnlz6   1/1     Running   0          9s
[root@master ~]# kubectl get rs
NAME       DESIRED   CURRENT   READY   AGE
frontend   3         3         3       41s

DaemonSet控制器

DaemonSet 简介

DaemonSet：服务守护进程，它的主要作用是在Kubernetes集群的所有节点中运行我们部署的守护进程，相当于在集群节点上分别部署Pod副本，如果有新节点加入集群，Daemonset会自动的在该节点上运行我们需要部署的Pod副本，相反如果有节点退出集群，Daemonset也会移除掉部署在旧节点的Pod副本。

DaemonSet的主要特征

  • 这个 Pod 运行在 Kubernetes 集群里的每一个节点（Node）上；
  • 每个节点上只会运行一个这样的 Pod 实例；
  • 如果新的节点加入 Kubernetes 集群后，该 Pod 会自动地在新节点上被创建出来；
  • 而当旧节点被删除后，它上面的 Pod 也相应地会被回收掉。

Daemon Pods的调度特性

默认情况下，Pod被分配到具体哪一台Node上运行是由Scheduler（负责分配调度Pod到集群内的Node上，它通过监听ApiServer，查询还未分配Node的Pod，然后根据调度策略为这些Pod分配Node）决定的。但是，DaemonSet对象创建的Pod却拥有一些特殊的特性：

  • Node的unschedulable属性会被DaemonSet Controller忽略。
  • 即使Scheduler还未启动，DaemonSet Controller也能够创建并运行Pod。

Daemon Pods支持taints and tolerations, 但是这些Pods在创建时就默认容忍下列effect为NoExecute的taints（未设置tolerationSeconds）：

Toleration KeyEffectVersionDescription
node.kubernetes.io/not-readyNoExecute1.13+DaemonSet pods will not be evicted when there are node problems such as a network partition.
node.kubernetes.io/unreachableNoExecute1.13+DaemonSet pods will not be evicted when there are node problems such as a network partition.
node.kubernetes.io/disk-pressureNoSchedule1.8+…
node.kubernetes.io/memory-pressureNoSchedule1.8+…
node.kubernetes.io/unschedulableNoSchedule1.12+DaemonSet pods tolerate unschedulable attributes by default scheduler.
node.kubernetes.io/network-unavailableNoSchedule1.12+DaemonSet pods, who uses host network, tolerate network-unavailable attributes by default scheduler.

DaemonSet常用场景

  • 网络插件的 Agent 组件，如（Flannel，Calico）需要运行在每一个节点上，用来处理这个节点上的容器网络；
  • 存储插件的 Agent 组件，如（Ceph，Glusterfs）需要运行在每一个节点上，用来在这个节点上挂载F远程存储目录；
  • 监控系统的数据收集组件，如（Prometheus Node Exporter，Cadvisor）需要运行在每一个节点上，负责这个节点上的监控信息搜集。
  • 日志系统的数据收集组件，如（Fluent，Logstash）需要运行在每一个节点上，负责这个节点上的日志信息搜集。

创建一个DaemonSet对象

下面的描述文件创建了一个运行着nginx镜像的DaemonSet对象：

[root@master kubenetres]# vi daemonset.yml
---
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd-elasticsearch
  namespace: kube-system
  labels:
    app: fluentd-logging
spec:
  selector:
    matchLabels:
      name: fluentd-elasticsearch
  template:
    metadata:
      labels:
        name: fluentd-elasticsearch
    spec:
      tolerations:
      - key: node-role.kubernetes.io/master
        effect: NoSchedule
      containers:
      - name: fluentd-elasticsearch
        image: quay.io/fluentd_elasticsearch/fluentd:v2.5.2
        resources:
          limits:
            memory: 200Mi
          requests:
            cpu: 100m
            memory: 200Mi
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        - name: varlibdockercontainers
          mountPath: /var/lib/docker/containers
          readOnly: true
      terminationGracePeriodSeconds: 30
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
      - name: varlibdockercontainers
        hostPath:
          path: /var/lib/docker/containers



[root@master ~]# kubectl get pod -n kube-system
NAME                                         READY   STATUS    RESTARTS      AGE
coredns-6d8c4cb4d-6n2xc                      1/1     Running   2 (53m ago)   3d1h
coredns-6d8c4cb4d-hjznw                      1/1     Running   2 (53m ago)   3d1h
etcd-master.example.com                      1/1     Running   8 (53m ago)   3d1h
fluentd-elasticsearch-6sgnt                  1/1     Running   0             44s
fluentd-elasticsearch-chfhc                  1/1     Running   0             42s
kube-apiserver-master.example.com            1/1     Running   9 (53m ago)   3d1h
kube-controller-manager-master.example.com   1/1     Running   8 (53m ago)   3d1h
kube-flannel-ds-67kht                        1/1     Running   3 (53m ago)   3d1h
kube-flannel-ds-hr47p                        1/1     Running   2 (53m ago)   3d1h
kube-flannel-ds-k678m                        1/1     Running   2 (53m ago)   3d1h
kube-proxy-44zx6                             1/1     Running   2 (53m ago)   3d1h
kube-proxy-knkbm                             1/1     Running   2 (53m ago)   3d1h
kube-proxy-n875j                             1/1     Running   3 (53m ago)   3d1h
kube-scheduler-master.example.com            1/1     Running   8 (53m ago)   3d1h

Job控制器

Job Controller

Job Controller负责根据Job Spec创建Pod，并持续监控Pod的状态，直至其成功结束。如果失败，则根据restartPolicy（只支持OnFailure和Never，不支持Always）决定是否创建新的Pod再次重试任务。
在这里插入图片描述
Job负责批量处理短暂的一次性任务 (short lived one-off tasks)，即仅执行一次的任务，它保证批处理任务的一个或多个Pod成功结束。

Kubernetes支持以下几种Job：

  • 非并行Job：通常创建一个Pod直至其成功结束
  • 固定结束次数的Job：设置.spec.completions，创建多个Pod，直到.spec.completions个Pod成功结束
  • 带有工作队列的并行Job：设置.spec.Parallelism但不设置.spec.completions，当所有Pod结束并且至少一个成功时，Job就认为是成功

根据.spec.completions和.spec.Parallelism的设置，可以将Job划分为以下几种pattern：

Job类型使用示例行为completionsParallelism
一次性Job数据库迁移创建一个Pod直至其成功结束11
固定结束次数的Job处理工作队列的Pod依次创建一个Pod运行直至completions个成功结束2+1
固定结束次数的并行Job多个Pod同时处理工作队列依次创建多个Pod运行直至completions个成功结束2+2+
并行Job多个Pod同时处理工作队列创建一个或多个Pod直至有一个成功结束12+

job的使用

[root@master ~]# vi job.yml 
---
apiVersion: batch/v1
kind: Job
metadata:
  name: myjob
spec:
  template:
    spec:
      containers:
      - name: myjob
        image: busybox
        command: ["echo",  "hello k8s job"]
      restartPolicy: Never


[root@master ~]# kubectl apply -f job.yml 
job.batch/myjob created
[root@master ~]# kubectl get pods
NAME          READY   STATUS      RESTARTS   AGE
myjob-gq27p   0/1     Completed   0          37s

#查看这个 pod的任务
[root@master ~]# kubectl get job
NAME    COMPLETIONS   DURATION   AGE
myjob   1/1           19s        5m11s

#查看这个 pod的日志
[root@master ~]# kubectl logs myjob-gq27p
hello k8s job

CronJob控制器

CronJob可以用来执行基于时间计划的定时任务，类似于Linux/Unix系统中的 crontable (opens new window)。

CronJob 执行周期性的重复任务时非常有用，例如备份数据、发送邮件等。CronJob 也可以用来指定将来某个时间点执行单个任务，例如将某项任务定时到系统负载比较低的时候执行。

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

注意：

所有 CronJob 的 schedule: 时间都是基于kube-controller-manager. 的时区。

如果你的控制平面在 Pod 或是裸容器中运行了 kube-controller-manager， 那么为该容器所设置的时区将会决定 Cron Job 的控制器所使用的时区。

为 CronJob 资源创建清单时，请确保所提供的名称是一个合法的DNS 子域名. 名称不能超过 52 个字符。 这是因为 CronJob 控制器将自动在提供的 Job 名称后附加 11 个字符，并且存在一个限制， 即 Job 名称的最大长度不能超过 63 个字符。

CronJob 用于执行周期性的动作，例如备份、报告生成等。 这些任务中的每一个都应该配置为周期性重复的（例如：每天/每周/每月一次）； 你可以定义任务开始执行的时间间隔。

下面的 CronJob 示例清单会在每分钟打印出当前时间和问候消息：

[root@master kubenetres]# vi cronjob.yml
---
apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "*/1 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox
            imagePullPolicy: IfNotPresent
            command:
            - /bin/sh
            - -c
            - date; echo Hello world
          restartPolicy: OnFailure

创建pod查看

[root@master ~]# kubectl apply -f cronjob.yml 
Warning: batch/v1beta1 CronJob is deprecated in v1.21+, unavailable in v1.25+; use batch/v1 CronJob
cronjob.batch/hello created

#等一分钟查看
[root@master ~]# kubectl get pods
NAME                   READY   STATUS      RESTARTS   AGE
hello-27339330-kkfxv   0/1     Completed   0          2s

#查看日志
[root@master ~]# kubectl logs hello-27339330-kkfxv
Fri Dec 24 19:00 UTC 2021
Hello world
# kubernetes # docker # java
Logo
Cloudpods

开源、云原生的融合云平台

更多推荐

面向未来的 IT 基础设施管理架构——融合云（Unified IaaS）

随着数字化时代的到来，IT系统已成为人类社会正常运转不可或缺的组成部分。不远的未来，智能制造，5G和人工智能等技术将成为推动生产力发展的重要引擎，人类社会将面临前所未有的全面彻底的数字化浪潮。IT基础设施作为IT系统运行的平台和载体，是实现数字化的基石。在这场数字化浪潮中，企业必须积极拥抱云计算技术，采用符合技术发展趋势、面向未来的IT基础构架，才能在未来的竞争中赢得先机。 一、云计算历经十余年

avatar Cloudpods

Cloudpods负载均衡的功能介绍

作者:周有松 今天的内容会从以下几个方面展开： 负载均衡产品简介。主要介绍负载均衡作为一个云上产品，它的功能模型是怎样的，日常使用中会遇到的业务词汇负载均衡的功能与典型应用场景。这部分主要结合业务词汇，对负载均衡服务中常见的一些功能选项进行介绍，并举例介绍一些典型的应用场景最后，我们做一下总结，讨论一下负载均衡产品相比传统方式的优点 一、产品简介​ 1. 以NGINX为例​ 提到负载均衡，我们以

avatar Cloudpods

使用Linux vfio将Nvidia GPU透传给QEMU虚拟机

Linux 上虚拟机 GPU 透传需要使用 vfio 的方式。主要是因为在 vfio 方式下对虚拟设备的权限和 DMA 隔离上做的更好。但是这么做也有个缺点，这个物理设备在主机和其他虚拟机都不能使用了。 qemu 直接使用物理设备本身命令行是很简单的，关键在于事先在主机上对系统、内核和物理设备的一些配置。 单纯从 qemu 的命令行来看，其实和普通虚拟机启动就差了最后那个-device的选项。这

avatar Cloudpods