k8s工作负载控制器
在Kubernetes你可以在一组Pods中运行它。在Kuberneres中,pod它代表一组集群上运行的容器。
Kubernetes Pods有一定的生命周期。例如,当某个Pod集群运行时,Pod当运行节点出现致命错误时,所有节点Pods都会失败。Kubernetes即使节点后来恢复正常运行,你也需要创造新的失败Pod恢复应用。
但是,为了让用户的生活稍微好一点,你不需要直接管理每一个Pod。相反,您可以使用负载资源为您管理一组Pods。这些资源配置控制器可以确保正确的类型和运行状态Pod数量是正确的,符合你指定的状态。
常用的工作负载控制器:
- Deployment
- StatefulSet
- DaemonSet
- Job
- CronJob
Deployment
一个Deployment为Pods和ReplicaSets提供声明更新能力。
你负责描述Deployment目标状态,而Deployment控制器以控制速率改变实际状态,使其成为预期状态。您可以定义它Deployment以创建新的ReplicaSet,或删除现有Deployment,并通过新的Deployment收养其资源。
Deployment非常适合管理您的集群中的无状态应用,Deployment中的所有pod它们相等,必要时被更换。
[root@master kubenetres]# cat deploy.yml 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 kubenetres]# kubectl apply -f deploy.yml deployment.apps/deploy created [root@master kubenetres]# kubectl get pod NAME READY STATUS RESTARTS AGE deploy-8d545c96d-6vmnd 1/1 Running 0 32s deploy-8d545c96d-l4kx4 1/1 Running 0 32s deploy-8d545c96d-nk25r 1/1 Running 0 32s
在该例中:
- 创建了名为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
。
- Pod 被使用
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 获得。
何时使用ReplicaSet
ReplicaSet 确保任何时候都有指定的数量 Pod 副本正在运行。 然而,Deployment 它管理是一个更先进的概念 ReplicaSet,并向 Pod 提供声明更新和许多其他有用的功能。 因此,建议使用 Deployment 而不是直接使用 ReplicaSet,除非 您需要定制更新业务流程或根本不需要更新。
这实际上意味着你可能永远不需要操作 ReplicaSet 对象:但使用 Deployment,并在 spec 定义你的应用程序。
[root@master kubenetres]# cat replicaset.yml 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
查看目前已部署的ReplicaSet
[root@master mainfest]# kubectl apply -f replicaset.yaml replicaset.apps/replicaset created [root@master kubenetres]# kubectl apply -f replicaset.yml replicaset.apps/replicaset created [root@master kubenetres]# kubectl get rs NAME DESIRED CURRENT READY AGE deploy-8d545c96d 3 3 3 2m16s replicaset 3 3 0 10s [[root@master kubenetres]# kubectl get pod NAME READY STATUS RESTARTS AGE deploy-8d545c96d-6vmnd 1/1 Running 0 2m39s deploy-8d545c96d-l4kx4 1/1 Running 0 2m39s deploy-8d545c96d-nk25r 1/1 Running 0 2m39s httpd1-57c7b6f7cb-sk86h 1/1 Running 5 (21h ago) 2d22h nginx1-7cf8bc594f-8j8tv 1/1 Rnning 2 (21h ago) 25h
replicaset-2v8rh 1/1 Running 0 33s
replicaset-5r5mb 0/1 ContainerCreating 0 33s
replicaset-rc4zq 0/1 ContainerCreating 0 33s
test 1/1 Running 1 (21h ago) 21h
DaemonSet
DaemonSet 确保全部(或者某些)节点上运行一个 Pod 的副本。 当有节点加入集群时, 也会为他们新增一个 Pod 。 当有节点从集群移除时,这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod。
DaemonSet 的一些典型用法:
- 在每个节点上运行集群守护进程
- 在每个节点上运行日志收集守护进程
- 在每个节点上运行监控守护进程
一种简单的用法是为每种类型的守护进程在所有的节点上都启动一个 DaemonSet。 一个稍微复杂的用法是为同一种守护进程部署多个 DaemonSet;每个具有不同的标志, 并且对不同硬件类型具有不同的内存、CPU 要求。
创建DaemonSet
你可以在YAML文件中描述DaemonSet。例如下面这个daemonset.yaml文件描述了一个运行
[root@master kubenetres]# cat daemonset.yml
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: 210Mi
requests:
cpu: 100m
memory: 210Mi
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 kubenetres]# kubectl apply -f daemonset.yml
daemonset.apps/fluentd-elasticsearch created
[root@master kubenetres]# kubectl get pod -n kube-system
NAME READY STATUS RESTARTS AGE
coredns-6d8c4cb4d-pqvll 1/1 Running 11 (21h ago) 3d2h
coredns-6d8c4cb4d-txmm6 1/1 Running 11 (21h ago) 3d2h
etcd-master.example.com 1/1 Running 11 (21h ago) 4d2h
fluentd-elasticsearch-9hcxh 0/1 ContainerCreating 0 12s
fluentd-elasticsearch-wqtv5 0/1 ContainerCreating 0 12s
fluentd-elasticsearch-xk92n 0/1 ContainerCreating 0 12s
Daemon Pods是如何被调度的
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
节点。
Jobs
Job 会创建一个或者多个 Pods,并将继续重试 Pods 的执行,直到指定数量的 Pods 成功终止。 随着 Pods 成功结束,Job 跟踪记录成功完成的 Pods 个数。 当数量达到指定的成功个数阈值时,任务(即 Job)结束。 删除 Job 的操作会清除所创建的全部 Pods。 挂起 Job 的操作会删除 Job 的所有活跃 Pod,直到 Job 被再次恢复执行。
一种简单的使用场景下,你会创建一个 Job 对象以便以一种可靠的方式运行某 Pod 直到完成。 当第一个 Pod 失败或者被删除(比如因为节点硬件失效或者重启)时,Job 对象会启动一个新的 Pod。
你也可以使用 Job 以并行的方式运行多个 Pod。
[root@master kubenetres]# cat 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 kubenetres]# kubectl apply -f jobs.yaml
job.batch/pi created
[root@master kubenetres]# kubectl describe jobs/pi
Name: pi
Namespace: default
Selector: controller-uid=8d4b7a4d-0e9f-476d-ac0c-b05389e85e57
Labels: controller-uid=8d4b7a4d-0e9f-476d-ac0c-b05389e85e57
job-name=pi
Annotations: batch.kubernetes.io/job-tracking:
Parallelism: 1
Completions: 1
Completion Mode: NonIndexed
Start Time: Fri, 24 Dec 2021 08:03:23 -0500
Pods Statuses: 1 Active / 0 Succeeded / 0 Failed
Pod Template:
Labels: controller-uid=8d4b7a4d-0e9f-476d-ac0c-b05389e85e57
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 23s job-controller Created pod: pi-dblxb
CronJob
Kubernetes v1.21 [stable]
CronJob 创建基于时隔重复调度的Jobs。
一个 CronJob 对象就像 crontab (cron table) 文件中的一行。 它用Cron格式进行编写, 并周期性地在给定的调度时间执行 Job。
所有 的 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
[root@master kubenetres]# cat 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 from the Kubernetes cluster
restartPolicy: OnFailure
运行查看
[root@master kubenetres]# 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 mainfest]# kubectl apply -f cronjob.yaml
cronjob.batch/hello created
[root@master kubenetres]# kubectl get pods
NAME READY STATUS RESTARTS AGE
hello-27339185-2z8qj 0/1 Completed 0 16s
[root@master kubenetres]# kubectl logs hello-27339185-2z8qj
Fri Dec 24 13:05:01 UTC 2021
Hello from the Kubernetes cluster
Cron时间表语法
# ┌───────────── 分钟 (0 - 59)
# │ ┌───────────── 小时 (0 - 23)
# │ │ ┌───────────── 月的某天 (1 - 31)
# │ │ │ ┌───────────── 月份 (1 - 12)
# │ │ │ │ ┌───────────── 周的某天 (0 - 6)(周日到周一;在某些系统上,7 也是星期日)
# │ │ │ │ │
# │ │ │ │ │
# │ │ │ │ │
# * * * * *
# ┌───────────── 分钟 (0 - 59)
# │ ┌───────────── 小时 (0 - 23)
# │ │ ┌───────────── 月的某天 (1 - 31)
# │ │ │ ┌───────────── 月份 (1 - 12)
# │ │ │ │ ┌───────────── 周的某天 (0 - 6) (周日到周一;在某些系统上,7 也是星期日)
# │ │ │ │ │
# │ │ │ │ │
# │ │ │ │ │
# * * * * *
输入 | 描述 | 相当于 |
---|---|---|
@yearly (or @annually) | 每年 1 月 1 日的午夜运行一次 | 0 0 1 1 * |
@monthly | 每月第一天的午夜运行一次 | 0 0 1 * * |
@weekly | 每周的周日午夜运行一次 | 0 0 * * 0 |
@daily (or @midnight) | 每天午夜运行一次 | 0 0 * * * |
@hourly | 每小时的开始一次 | 0 * * * * |
例如,下面这行指出必须在每个星期五的午夜以及每个月 13 号的午夜开始任务:
0 0 13 * 5