daemonset-job企业级实战案例演示
DaemonSet控制器：概念、原理解读
DaemonSet概述
DaemonSet是Kubernetes中的一种资源对象，它用于确保集群中的每个节点都运行着一个相同 的Pod副本。与Deployment或ReplicaSet不同，它们会尽量确保在每个节点上运行指定数量的Pod 副本。
每当有新节点加入集群或者已有节点发生变化（如节点故障或节点扩容），DaemonSet会自动在新 节点上创建一个Pod副本，以确保集群的每个节点都具有所需的Pod实例。
DaemonSet通常用于在集群的每个节点上运行一些特殊的系统级别任务，例如日志收集、监控代理 或网络插件。它们还可用于确保集群中的每个节点都具有相同的配置或运行特定的系统服务。
DaemonSet工作原理：如何管理Pod？
- 创建：当你创建一个DaemonSet对象时，Kubernetes控制器会检查集群中的每个节点，并在 每个节点上创建一个Pod副本。
- 调度：Pod的调度是由Kubernetes调度器处理的。调度器会根据节点的资源可用性和调度策 略，将Pod分配给适合的节点。通常情况下，每个节点只能运行一个DaemonSet·Pod副本。
- 监控和自适应：一旦DaemonSet的Pod副本在节点上启动，Kubernetes控制器会监视节点 的状态。如果节点发生变化，比如节点故障、节点添加或移除，控制器将采取相应的措施来维持 DaemonSet的副本数量。例如，如果新节点加入集群，控制器将在新节点上创建一个Pod副本。
- 节点更新：当集群中的节点需要进行系统更新或升级时，DaemonSet可以与节点的更新流程进 行集成。您可以设置DaemonSet的更新策略，以确保在节点更新时，Pod副本能够平滑地迁移到其他 节点上，以保持集群的高可用性。
- 删除：如果您删除了一个DaemonSet对象，，Kubernetes控制器将停止在所有节点上运行的 Pod副本，并将它们从集群中删除。
Daemonset典型的应用场景
- 日志收集：您可以使用DaemonSet在每个节点上运行日志收集代理，例如Fluentd或 Filebeat。这样可以确保每个节点的日志都被收集并发送到集中式日志存储或分析系统中。
- 监控和指标收集：DaemonSet可用于在每个节点上运行监控代理，例如Prometheus·Node Exporter，以收集节点级别的指标数据，如CPU、内存、磁盘和网络使用情况。这有助于进行集群性能 监控和故障排查。
- 网络插件和代理：DaemonSet可用于在每个节点上部署网络插件，例如Calico、Flannel或 Weave，以提供集群内部和集群外部的网络功能，如网络隔离、负载均衡和服务发现。
DaemonSet·与·Deployment·的区别
- Pod副本的数量：在Deployment中，你可以定义所需的Pod副本数量，Kubernetes将确保 在集群中运行指定数量的Pod副本。而在DaemonSet中，每个节点上只能运行一个Pod副本， DaemonSet会自动在每个节点上创建Pod。
- 调度策略：Deployment的Pod可以在集群中的任何节点上进行调度，调度器会根据节点的可 用性和资源情况来选择合适的节点。而DaemonSet的Pod只能在每个节点上运行一个副本，无法在同 一节点上运行多个相同的Pod副本。
- 滚动更新：Deployment支持滚动更新策略，可以控制Pod的版本升级过程，确保无中断地进 行应用程序的更新。而DaemonSet通常用于运行系统级别的任务，不涉及滚动更新
- 故障恢复和节点变化：Deployment在节点故障或节点扩容时，会自动将Pod副本重新调度到 其他可用节点上，以确保高可用性。而DaemonSet会在新节点加入集群或节点发生变化时，在新节点 上创建一个Pod副本，以保持在每个节点上都运行一个Pod副本。
DaemonSet资源清单文件编写技巧
kubectl explain ds
- apiVersion：指定当前资源使用的·Kubernetes·APl·版本。在这个例子中，apiVersion·字段的值应该是一个字符串，表示该资源使用的·APl·版本，通常是”apps/v1"。
- kind：表示资源的类型。在这个例子中，kind·字段的值应该是一个字符串，表示该资源的类型，即."DaemonSet"。
- metadata：包含关于资源的元数据，例如名称、命名空间、标签等。它是一个对象，其中可以包含以下字段：
- name:指定·DaemonSet·的名称，是一个字符串。
- namespace：指定·DaemonSet·所属的命名空间，是一个字符串。
- labels：用于标识和组织资源的标签，是一个键值对的对象。
- spec：包含·DaemonSet·的规范定义，描述了容器的配置和部署。它是一个对象，其中可以包含以下字段：
- template：定义了要在每个节点上运行的·Pod·模板。包含了容器的规格、镜像、环境变量、挂载卷等配置。
- selector：用于选择将·Pod·分配给·DaemonSet·的节点的标签选择器。
- status：包含有关资源的当前状态信息，由·Kubernetes·系统自动生成并更新，不能手动修改。它是一个对象，其中可以包含关于·DaemonSet·的运行状态、副本数、事件等信息。
kubectl explain ds.spec
- minReadySeconds：指定新的·Pod·启动后，在几秒钟之后才会终止l旧的·Pod。这个字段是一个整数值，用于控制滚动更新过程中的最小就绪时间。在启动新的·Pod·之后，如果minReadySeconds·时间内l旧的·Pod·仍然处于运行状态，Kubernetes·将保留l旧的·Pod，确保新的·Pod·正确启动并运行后再终止l旧的·Pod。
- revisionHistoryLimit：指定保留的历史版本数量。这个字段是一个整数值，用于控制保留的DaemonSet·历史版本的数量。Kubernetes·将保留历史版本的副本集，以便可以回滚到之前的版本，避免意外的升级问题。
- selector：用于匹配·Pod·的标签选择器。这个字段是一个对象，其中可以包含以下字段：
- matchLabels：用于选择将·Pod·分配给·DaemonSet·的节点的标签。Pod·必须具有与·matchLabels·字段匹配的标签才能被分配到·DaemonSet。
- matchExpressions：可以使用表达式来定义更复杂的选择规则，例如根据标签的键、值和操作符进行选择。
- template：定义了要在每个节点上运行的·Pod·模板。这个字段是一个对象，其中包含了定义Pod·配置的详细信息，例如容器的规格、镜像、环境变量、挂载卷等。所有基于这个模板定义的·Pod·都具有相同的配置和规格。
- updateStrategy：定义了·DaemonSet·的升级策略。这个字段是一个对象，其中可以包含以下字段：
- type：指定升级策略的类型，可以是“RollingUpdate"·或·“OnDelete"。
- rollingUpdate：如果升级策略类型为：“RollingUpdate”，则可以配置以下字段：
- maxUnavailable：指定在进行滚动更新时，最大允许的不可用·Pod·的副本数量
- maxSurge：指定在进行滚动更新时，最大允许的超出期望·Pod数量的数量。
备注：当同时设置了minReadySeconds和就绪探测时，它们是相互独立的，而不会互相影响。下面是对它们的进一步解释： 1. minReadySeconds字段定义了在新的·Pod·启动后，在指定的秒数内，旧的·Pod·保持运行状 态，即使新的·Pod·已经就绪。这个字段的作用是确保在进行滚动更新时，新的·Pod·有足够的时间来完 成启动和初始化过程，然后才会终止l旧的·Pod。换句话说，即使新的·Pod·标记为就绪，旧的·Pod·也 会在滚动更新过程中保持运行一段时间，以确保没有中断或丢失的请求。minReadySeconds适用于整 体的·DaemonSet·升级过程。 2. 就绪探测（readiness·probe）是一个用于检查容器是否已经准备好接收流量的机制。通过定义 就绪探测，Kubernetes·可以检测到·Pod·是否已经准备好接收流量，并将其标记为就绪状态，如果 pod前面有svc代理，pod就会被svc关联到
实战DaemonSet使用案例-日志收集组件fluentd
image:
quay.io/fluentd_elasticsearch/fluentd:v2.5.2
file:
daemonset.yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: fluentd-elasticsearch
namespace: kube-system
labels:
k8s-app: fluented-app
spec:
selector:
matchLabels:
name: fluentd-elasticsearch
template:
metadata:
labels:
name: fluentd-elasticsearch
spec:
tolerations:
- key: node-role.kubernetes.io/control-plane
effect: NoSchedule
containers:
- name: fluentd-elasticsearch
image: quay.io/fluentd_elasticsearch/fluentd:v2.5.2
imagePullPolicy: IfNotPresent
查看
$ kubectl get ds -n kube-system
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
calico-node 3 3 3 3 3 kubernetes.io/os=linux 70d
fluentd-elasticsearch 3 3 0 3 0 <none> 8m24s
kube-proxy 3 3 3 3 3 kubernetes.io/os=linux 70d
$ kubectl get pods -owide -n kube-system -l name=fluentd-elasticsearch
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
fluentd-elasticsearch-6xs8b 0/1 ContainerCreating 0 9m8s <none> xuegod64 <none> <none>
fluentd-elasticsearch-f9ddg 0/1 ContainerCreating 0 9m8s <none> xuegod63 <none> <none>
fluentd-elasticsearch-h86dw 0/1 ContainerCreating 0 59s <none> xuegod62 <none> <none>
更新策略
kubectl explain ds.spec.updateStrategy.rollingUpdate
由于·DaemonSet·在每个节点上只运行一个副本，因此 maxUnavailable 字段在这种情况下
的作用较小。在滚动更新期间，它指定了可以同时不可用的最大·Pod·副本数。然而，由于每个节点只有
个副本，所以无论设置为什么值，都只会同时不可用一个副本。
maxSurge·字段对于DaemonSet·更有意义，它定义了可以同时创建的超过所需副本数的最 大·Pod·副本数。在滚动更新期间，当新节点加入集群时，通过增加临时的额外副本，可以让集群中同时 存在多个Pod·副本。这些额外副本会在滚动更新完成后被逐步删除，以保持每个节点上只有一个副本。
实战：Daemonset管理pod-滚动更新
镜像 docker.io/ikubernetes/filebeat:5.6.6-alpine
修改 daemonset.yaml 文件，添加 镜像改成上面镜像
-
默认是先删除再创建
-
修改为先创建再删除 rollingUpdate下增加 maxSurge: 1,可以保证更新的时候至少有1个镜像，
Job和CronJob控制器：概念、原理解读
Job概念、原理解读
在Kubernetes中，Job是一种用于执行短暂任务的资源对象。已用于在集群中创建个或多不 Pod来完成任务，确保任务成功完成后自动终止。
kubectl explain job
-
activeDeadlineSeconds→
·#通过指定job存活时间，来结束一个job。当job运 行时间达到activeDeadlineSeconds指定的时间后，job会停止由它启动的所有任务（如：pod），并 设置job的状态为failed -
backoffLimit→
·#job建议指定pod的重启策略为never， 如：.spec.template.spec.restartPolicy·="Never"，然后通过job的backoffLimit来指定失败重试 次数，在达到backoffLimit指定的次数后，job状态设置为failed（默认为6次） -
completions→
·#指定job启动的任务（如：pod）成功运行completions次） job才算成功结束 -
manualSelector>
-
parallelism>
#指定job同时运行的任务（如：pod）个数，Parallelism默认为1， 如果设置为0，则job会暂定 -
selector
-
template
-
ttlSecondsAfterFinished→
·#默认情况下，job异常或者成功结束后，包括job启 动的任务（pod），都不会被清理掉，因为你可以依据保存的job和pod，查看状态、日志，以及调试 等。这些用户可以手动删除，用户手动删除job，job·controller会级联删除对应的pod，除了手动删 除，通过指定参数ttlSecondsAfterFinished也可以实现自动删除job，以及级联的资源，如：pod。 如果设置为0，job会被立即删除。如果不指定，job则不会被删除
实战：Job使用案例-创建一个一次性任务
job.yaml
apiVersion
kind: Job
metadata:
name: my-busybox-job
spec:
# 要保证6 个pod 完成任务
completions: 6
# 每次启动3个
parallelism: 3
# 6个失败才算失败
backoffLimit: 6
template:
metadata:
labels:
app: test
spec:
restartPolicy: Never
containers:
- name: my-container-job
image: busybox
imagePullPolicy: IfNotPresent
command: ["sh", "-c"]
# args: ["echo hello;sleep 60; bye"]
args: ["echo hello;sleep 60; echo bye"]
- 操作
# 删除job，会自动删除pod
kubectl delete job my-busybox-job
实战：CronJob使用案例-创建周期性的定时任务
CronJob是Kubernetes中的一种资源对象，用于调度周期性的任务。它基于类似于Unix系统中 的cron表达式来定义任务的执行时间和频率。CronJob负责创建和管理与定期任务相关的Job。
cronjob.yaml
apiVersion: batch/v1
kind: CronJob
metadata:
name: hello
spec:
schedule: "* * * * *"
jobTemplate:
spec:
template:
spec:
backoffLimit: 3
completions: 6
parallelism: 3
containers:
- name: hello
image: busybox
imagePullPolicy: IfNotPresent
command:
- /bin/sh
- -c
- date; echo Hello from the Kubernetes cluster
restartPolicy: Never
实战： 使用 CronJob 定期备份mysql 数据
CronJob所描述的，正是定时任务。 1、在给定时间点只运行一次 2、在给定时间点周期性地运行
一个CronJob·对象类似于·crontab.（cron·table）文件中的一行。它根据指定的预定计划周期 性地运行一个·Job。在这里简单的说一下cron，是指unix中cron表达式。比如：“/1*"，这个 Cron表达式里/1中表示从0开始，/表示"每"，1表示偏移量，所以它的意思是：从0开始，每1 个时间单位执行一次。Cron表达式中五个部分分别代表：分钟，小时，日，月，星期。所以上述这句 Cron表达式的意思是：从当前开始，每分钟执行一次。那么我们可以利用这个机制来指定创建mysql 备份任务的对象：