K8S实战(九)| 控制器 DaemonSet - 将守护进程容器化
前言Deployment 管理的 Pod 允许在一个节点上运行多个副本。当需要在节点上运行收集日志或者执行监控任务的容器时,显然不适合启动多个 Pod 副本。这种场景下,我们可以启用 DaemonSet 控制器来管理 Pod。更新历史20200620 - 初稿 - 左程立原文地址 - https://blog.zuolinux.com/2020/06/20/about-controller-dae
前言
Deployment 管理的 Pod 允许在一个节点上运行多个副本。
当需要在节点上运行收集日志或者执行监控任务的容器时,显然不适合启动多个 Pod 副本。
这种场景下,我们可以启用 DaemonSet 控制器来管理 Pod。
更新历史
- 20200620 - 初稿 - 左程立
- 原文地址 - https://blog.zuolinux.com/2020/06/20/about-controller-daemonset.html
Daemon Pod 的特点
- Pod 运行在集群中的全部或者部分节点上
- 每个节点上只能有一个这样的 Pod
- 当集群中加入了新节点,Pod 会自动在新节点上创建
- 当节点被从集群中移除后,节点上 Pod 会自动被回收掉
Daemon Pod 适用的场景
- 网络插件的 Agent
- 存储插件的 Agent
- 监控任务的 Agent
- 收集日志的 Agent
DaemonSet
创建一个 DS
cat 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
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
# kubectl apply -f daemonset.yaml
daemonset.apps/fluentd-elasticsearch created
查看
[root@master01 ~]# kubectl get ds --namespace kube-system
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
fluentd-elasticsearch 6 6 6 6 6 <none> 11m
目前集群中有 3 个 master,3 个 worker,一共 6 个节点,可以看到 6 个节点上都运行了该 node
工作流程
DaemonSet Controller,从 Etcd 里获取所有的 Node 列表,然后遍历所有的 Node。
然后检查当前这个 Node 上是不是有一个携带了 name=fluentd-elasticsearch 标签的 Pod 在运行。
而检查的结果,大概有这么三种情况:
- Node 上没有这种 Pod,那么就意味着要在这个 Node 上创建这个 Pod;
- Node 上有这种 Pod,但是数量大于 1,那就说明要把多余的 Pod 从这个 Node 上删除掉;
- 只有一个这种 Pod,说明这个节点是正常的。
重要参数
spec.affinity.nodeAffinity
通过命令
# kubectl edit pod fluentd-elasticsearch-22g5r --namespace=kube-system
可以看到 DaemonSet 自动给 Pod 增加了参数
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchFields:
- key: metadata.name
operator: In
values:
- master03
限制了该 Pod 只能运行在 master03 这个 Node 上
tolerations
同样通过上面的命令,可以看到有参数
tolerations:
- effect: NoSchedule
key: node-role.kubernetes.io/master
- effect: NoExecute
key: node.kubernetes.io/not-ready
operator: Exists
- effect: NoExecute
key: node.kubernetes.io/unreachable
operator: Exists
- effect: NoSchedule
key: node.kubernetes.io/disk-pressure
意味着可以容忍所有标记有如下“污点”的 Node,可以在这些 Node 上运行
master/not-ready/unreachable/disk-pressure
正常情况下,如果 Node 上被标记了这些“污点”,Pod 被禁止调度到这样的 Node 上运行
但 DaemonSet 给 Pod 加上了 tolerations,使 Pod 可以忽略这些污点,从而成功将 Pod 调度到“污点”节点上
如果节点有故障导致 Pod 启动失败,DaemonSet 会一直尝试,直到 Pod 成功启动
仅在部分节点运行 Pod
可以在 YAML 中手工指定 .spec.template.spec.affinity,这样 Pod 会运行在指定的 Node 上
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchFields:
- key: metadata.name
operator: In
values:
- target-host-name
如果没有指定该参数,那么 Pod 会运行在所有 Node 上
DaemonSet 优点
我们也可以自己写一个守护进程来执行类似的工作,使用 DaemonSet Pod 有哪些优点呢。
- DaemonSet Pod 自带自身监控功能,省去了我们自己再写一个针对守护进程的监控程序的工作
- DaemonSet Pod 不管运行什么任务,都是统一的语言和管理方式
- DaemonSet Pod 自带了资源限制功能,避免了守护进程长时间运行占用过多资源对宿主机造成影响
结束语
DaemonSet 倾向于精确控制 Pod 运行在哪些机器上,确保这些机器上都有这个 Pod 在运行。
而 Deployment 更适合于管理离用户更近的无状态类 Pod,比如 Web 服务。
它们的共同点是,都不希望自己管理的 Pod 终止,Pod 出现问题后可以自愈。
联系我
微信公众号:zuolinux_com
更多推荐
所有评论(0)