Kubernetes工作负载型控制器

最新推荐文章于 2024-05-03 22:07:06 发布

寂寞的槟榔丶

最新推荐文章于 2024-05-03 22:07:06 发布

阅读量166

点赞数

分类专栏： kubernetes 运维文章标签： kubernetes docker 运维

本文链接：https://blog.csdn.net/m0_56305656/article/details/122137408

版权

运维同时被 2 个专栏收录

43 篇文章 0 订阅

订阅专栏

kubernetes

6 篇文章 0 订阅

订阅专栏

1 k8s工作负载型控制器

工作负载控制器是什么?

工作负载控制器（Workload Controllers）是K8s的一个抽象概念，用于更高级层次对象，部署和管理Pod。
工作负载是在kubernetes上运行的应用程序。
无论你的负载是单一组件还是由多个一同工作的组件构成，在Kubernetes中你可以在一组Pods中运行它。在Kuberneres中，pod代表的是集群上处于运行状态的一组容器。
Kubernetes Pods有确定的生命周期。例如，当某Pod在你的集群中运行时，Pod运行所在的节点出现致命错误时，所有该节点上的Pods都会失败。Kubernetes将这类失败视为最终状态：即使该节点后来恢复正常运行，你也需要创建新的Pod来恢复应用。
不过，为了让用户的日子略微好过一点，你并不需要直接管理每个Pod。相反，你可以使用负载资源来替你管理一组Pods。这些资源配置控制器来确保合适类型的、处于运行状态的Pod个数是正确的，与你所指定的状态相一致。

常用的工作负载控制器：

Deployment
StatefulSet
DaemonSet
Job
CronJob

控制器的作用：

管理Pod对象
使用标签与Pod关联
控制器实现了Pod的运维，例如滚动更新、伸缩、副本管理、维护Pod状态等

在这里插入图片描述

2 Deployment

一个Deployment为Pods和ReplicaSets提供声明式的更新能力。
你负责描述Deployment中的目标状态，而Deployment控制器以受控速率更改实际状态，使其变为期望状态。你可以定义Deployment以创建新的ReplicaSet，或删除现有Deployment，并通过新的Deployment收养其资源。
Deployment很适合用来管理你的集群上的无状态应用，Deployment中的所有pod都是相互等价的，并且在需要的时候被换掉。

Deployment的功能：
基于ReplicaSet之上，可为Pod和ReplicaSet资源提供声明式更新，它具有以下特性：

事件和状态查看：可以查看Deployment对象升级的详细进度和状态
回滚：当升级操作完成后发现问题时，支持将应用返回到指定的历史版本中
版本记录：对Deployment 对象的每一次操作都予以保存
暂停和启动：每一次升级，都可以随时暂停和启动
多种自动更新方案：Recreate-重建更新、RollingUpdate-滚动更新

应用场景：

网站
微服务
APi

Deployment的更新策略描述如下：

RollingUpdate 策略：旧控制器的Pod数量不断减少，同时新控制器的Pod不断增加，以下两个属性：

maxSurge：升级期间存在的总Pod数量最多可超过期望值的个数，可以是数值或百分比。
maxUnavailabe：升级期间正常可用的Pod数(新旧版本)最多不能低于期望的个数，可以是数值或百分比。

创建Deployment

[root@master mainfest]# vim deploy.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: deploy
  labels:
    app: nginx
spec: 
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template: 
    metadata: 
      labels:
        app: nginx
    spec: 
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80
        
[root@master mainfest]# kubectl apply -f deploy.yaml 
deployment.apps/deploy created
[root@master mainfest]# kubectl get pod
NAME                     READY   STATUS    RESTARTS   AGE
deploy-6799fc88d8-qmw4h   1/1     Running   0          46s
deploy-6799fc88d8-xn6mk   1/1     Running   0          46s
deploy-6799fc88d8-2dmrq   1/1     Running   0          46s

在该例中：

创建了名为deploy(由.metadata.name字段标明)的deployment
该deployment创建三个(由replicas字段标明)pod副本
selector字段定义 Deployment 如何查找要管理的 Pods。在这里，你选择在 Pod 模板中定义的标签（app: nginx）。不过，更复杂的选择规则是也可能的，只要 Pod 模板本身满足所给规则即可。
template字段包含以下子字段：
Pod 被使用 labels 字段打上 app: nginx 标签。
Pod 模板规约（即 .template.spec 字段）指示 Pods 运行一个 nginx 容器，该容器运行版本为 1.14.2 的 nginx Docker Hub镜像。
创建一个容器并使用 name 字段将其命名为 nginx。

3 ReplicaSet

ReplicaSet的目的是维护一组在任何时候都处于运行状态的Pod副本的稳定集合。因此，它通常用来保证给定数量的、完全相同的Pod的可用性。

ReplicaSet的工作原理

RepicaSet是通过一组字段来定义的，包括一个识别可获得的Pod的集合的选择算符、一个用来标明应该维护的副本个数的数值、一个用来指定应该创建新Pod以满足副本个数条件时要使用的Pod模板等等。每个ReplicaSet都通过根据需要创建新的Pod时，会使用所提供的Pod模板。
ReplicaSet通过Pod上的metadata.ownerReferences字段连接到附属Pod，该字段给出当前对象的属主资源。ReplicaSet所获得的Pod都在其ownerReferences字段中包含了属主ReplicaSet的标识信息。正是通过这一连接，ReplicaSet 知道它所维护的 Pod 集合的状态，并据此计划其操作行为。
ReplicaSet 使用其选择算符来辨识要获得的 Pod 集合。如果某个 Pod 没有 OwnerReference 或者其 OwnerReference 不是一个控制器，且其匹配到某 ReplicaSet 的选择算符，则该 Pod 立即被此 ReplicaSet 获得。

在这里插入图片描述
ReplicationController、ReplicaSet、Deployment的区别

ReplicaSet是新一代的ReplicationController, 并推荐使用它替代- ReplicationController来复制和管理 Pod。
同时，在使用 Deployment 时，实际的 Pod是由Deployment的Replicaset创建和管理的，而不是由Deployment直接创建和管理的。
Deployment每次发布都会创建一个RS作为记录，用于实现回滚

何时使用ReplicaSet

ReplicaSet 确保任何时间都有指定数量的 Pod 副本在运行。然而，Deployment 是一个更高级的概念，它管理 ReplicaSet，并向 Pod 提供声明式的更新以及许多其他有用的功能。因此，我们建议使用 Deployment 而不是直接使用 ReplicaSet，除非你需要自定义更新业务流程或根本不需要更新。
这实际上意味着，你可能永远不需要操作 ReplicaSet 对象：而是使用 Deployment，并在 spec 部分定义你的应用。
示例：

[root@master mainfest]# vim replicaset.yaml
apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: replicaset
  labels:
    app: httpd
    tier: frontend
spec:
  replicas: 3
  selector:
    matchLabels:
      tier: frontend
  template:
    metadata:
      labels:
        tier: frontend
    spec:
      containers:
      - name: httpd
        image: httpd:latest

[root@master mainfest]# kubectl apply -f replicaset.yaml 
replicaset.apps/replicaset created
[root@master mainfest]# kubectl get rs
NAME               DESIRED   CURRENT   READY   AGE
deploy-585449566   3         3         3       94m
replicaset         3         3         2       49s
[root@master mainfest]# kubectl get pod
NAME                     READY   STATUS    RESTARTS   AGE
deploy-6799fc88d8-qmw4h   1/1    Running   0          46s
deploy-6799fc88d8-xn6mk   1/1    Running   0          46s
deploy-6799fc88d8-2dmrq   1/1    Running   0          46s       
replicaset-de35r         1/1     Running   0          54s
replicaset-l4kx4         1/1     Running   0          54s
replicaset-f295r         1/1     Running   0          54s

4 DaemonSet

DaemonSet控制器确保集群中的每一个Node只运行一个特定的Pod副本，实现系统级的后台任务，也具有标签选择器。也可以指定部分满足条件的Node运行一个Pod副本，比如监控具有ssd存储的Node节点。

常用来部署一些集群的日志、监控或者其他系统管理应用。典型的应用包括：

日志收集，比如fluentd、logstash等。
系统监控，比如Prometheus Node Exporter、collectd、New Relic agent、Ganglia gmond等。
系统程序，比如kube-proxy、kube-dns、Glusterd、Ceph等。

一种简单的用法是为每种类型的守护进程在所有的节点上都启动一个 DaemonSet。一个稍微复杂的用法是为同一种守护进程部署多个 DaemonSet；每个具有不同的标志，并且对不同硬件类型具有不同的内存、CPU 要求。

创建DaemonSet
你可以在YAML文件中描述DaemonSet。例如下面这个daemonset.yaml文件描述了一个运行

[root@master mainfest]# vim daemonset.yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd-elasticsearch
  namespace: kube-system
  labels:
    k8s-app: fluentd-logging
spec:
  selector:
    matchLabels:
      name: fluentd-elasticsearch
  template:
    metadata:
      labels:
        name: fluentd-elasticsearch
    spec:
      tolerations:
      # this toleration is to have the daemonset runnable on master nodes
      # remove it if your masters can't run pods
      - key: node-role.kubernetes.io/master
        operator: Exists
        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 mainfest]# kubectl create -f daemonset.yaml 
daemonset.apps/fluentd-elasticsearch created
[root@master mainfest]# kubectl get pod -n kube-system
fluentd-elasticsearch-36bv8      1/1     Running   0          23s
fluentd-elasticsearch-b8d73      1/1     Running   0          23s

5 Daemon Pods是如何被调度的

通过默认调度器调度

FEATURE STATE: Kubernetes v1.23 [stable]

DaemonSet 确保所有符合条件的节点都运行该 Pod 的一个副本。通常，运行 Pod 的节点由 Kubernetes 调度器选择。不过，DaemonSet Pods 由 DaemonSet 控制器创建和调度。这就带来了以下问题：

Pod 行为的不一致性：正常 Pod 在被创建后等待调度时处于Pending状态， DaemonSet Pods 创建后不会处于 Pending状态下。这使用户感到困惑。
Pod 抢占由默认调度器处理。启用抢占后，DaemonSet 控制器将在不考虑 Pod 优先级和抢占的情况下制定调度决策。

ScheduleDaemonSetPods允许您使用默认调度器而不是 DaemonSet 控制器来调度 DaemonSets，方法是将NodeAffinity条件而不是 .spec.nodeName条件添加到 DaemonSet Pods。默认调度器接下来将 Pod 绑定到目标主机。如果 DaemonSet Pod 的节点亲和性配置已存在，则被替换（原始的节点亲和性配置在选择目标主机之前被考虑）。 DaemonSet 控制器仅在创建或修改 DaemonSet Pod 时执行这些操作，并且不会更改 DaemonSet 的 spec.template。

nodeAffinity:
  requiredDuringSchedulingIgnoredDuringExecution:
    nodeSelectorTerms:
    - matchFields:
      - key: metadata.name
        operator: In
        values:
        - target-host-name

此外，系统会自动添加 node.kubernetes.io/unschedulable：NoSchedule 容忍度到 DaemonSet Pods。在调度 DaemonSet Pod 时，默认调度器会忽略 unschedulable 节点。

6 Jobs

Job控制器用于Pod对象运行一次性任务，容器中的进程在正常运行结束后不会对其进行重启，而是将Pod对象置于"Completed"(完成)状态，若容器中的进程因错误而终止，则需要按照重启策略配置确定是否重启，未运行完成的Pod对象因其所在的节点故障而意外终止后会被调度。 Job控制器的Pod对象的状态转换如下图所示：
在这里插入图片描述

Job 会创建一个或者多个 Pods，并将继续重试 Pods 的执行，直到指定数量的 Pods 成功终止。随着 Pods 成功结束，Job 跟踪记录成功完成的 Pods 个数。当数量达到指定的成功个数阈值时，任务（即 Job）结束。删除 Job 的操作会清除所创建的全部 Pods。挂起 Job 的操作会删除 Job 的所有活跃 Pod，直到 Job 被再次恢复执行。
一种简单的使用场景下，你会创建一个 Job 对象以便以一种可靠的方式运行某 Pod 直到完成。当第一个 Pod 失败或者被删除（比如因为节点硬件失效或者重启）时，Job 对象会启动一个新的 Pod。
你也可以使用 Job 以并行的方式运行多个 Pod。

[root@master mainfest]# vim jobs.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

[root@master mainfest]# kubectl apply -f jobs.yaml 
job.batch/pi created

[root@master mainfest]# kubectl describe jobs/pi
Name:           pi
Namespace:      default
Selector:       controller-uid=73b759ad-23db-879b-927c-d73146fd359
Labels:         controller-uid=73b759ad-23db-879b-927c-d73146fd359
                job-name=pi
Annotations:    <none>
Parallelism:    1
Completions:    1
Start Time:     Fri, 24 Dec 2021 23:57:23 -0500
Pods Statuses:  1 Running / 0 Succeeded / 0 Failed
Pod Template:
  Labels:  controller-uid=73b759ad-23db-879b-927c-d73146fd359
           job-name=pi
  Containers:
   pi:
    Image:      perl
    Port:       <none>
    Host Port:  <none>
    Command:
      perl
      -Mbignum=bpi
      -wle
      print bpi(2000)
    Environment:  <none>
    Mounts:       <none>
  Volumes:        <none>
Events:
  Type    Reason            Age   From            Message
  ----    ------            ----  ----            -------
  Normal  SuccessfulCreate  48s   job-controller  Created pod: pi-rm6dx

7 CronJob

FEATURE STATE: Kubernetes v1.21 [stable]

CronJob 创建基于时隔重复调度的Jobs。

一个 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 mainfest]# vim cronjob.yaml
apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: haha
spec:
  schedule: "*/1 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox
            imagePullPolicy: IfNotPresent
            command:
            - /bin/sh
            - -c
            - date; echo Hello from the Kubernetes cluster
          restartPolicy: OnFailure


//运行查看
[root@master mainfest]# kubectl apply -f cronjob.yaml 
cronjob.batch/hello created

[root@master mainfest]# kubectl get pods
NAME                     READY   STATUS      RESTARTS   AGE
haha-2736939037-qnvvx   0/1     Completed           0          3m
haha-3674348466-mcmxs   0/1     Completed           0          2m
haha-1890349842-6gqv4   0/1     Completed           0          60s
[root@master mainfest]# kubectl logs hello-1640349360-6gqv4
Fri Dec 24 23:59:27 UTC 2021
Hello from the Kubernetes cluster

在这里插入图片描述

寂寞的槟榔丶

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
Kubernetes工作负载型控制器

1 k8s工作负载型控制器工作负载控制器是什么?工作负载控制器（Workload Controllers）是K8s的一个抽象概念，用于更高级层次对象，部署和管理Pod。工作负载是在kubernetes上运行的应用程序。无论你的负载是单一组件还是由多个一同工作的组件构成，在Kubernetes中你可以在一组Pods中运行它。在Kuberneres中，pod代表的是集群上处于运行状态的一组容器。Kubernetes Pods有确定的生命周期。例如，当某Pod在你的集群中运行时，Pod运
复制链接

扫一扫

专栏目录