关于devops:K8S实战九-控制器-DaemonSet-将守护进程容器化

前言

Deployment 治理的 Pod 容许在一个节点上运行多个正本。

当须要在节点上运行收集日志或者执行监控工作的容器时，显然不适宜启动多个 Pod 正本。

这种场景下，咱们能够启用 DaemonSet 控制器来治理 Pod。

更新历史

• 20200620 – 初稿 – 左程立
• 原文地址 – https://blog.zuolinux.com/2020/06/20/about-controller-daemonset.html

Daemon Pod 的特点

1. Pod 运行在集群中的全副或者局部节点上
2. 每个节点上只能有一个这样的 Pod
3. 当集群中退出了新节点，Pod 会主动在新节点上创立
4. 当节点被从集群中移除后，节点上 Pod 会主动被回收掉

Daemon Pod 实用的场景

1. 网络插件的 Agent
2. 存储插件的 Agent
3. 监控工作的 Agent
4. 收集日志的 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 在运行。

而查看的后果，大略有这么三种状况：

1. Node 上没有这种 Pod，那么就意味着要在这个 Node 上创立这个 Pod；
2. Node 上有这种 Pod，然而数量大于 1，那就阐明要把多余的 Pod 从这个 Node 上删除掉；
3. 只有一个这种 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 有哪些长处呢。

1. DaemonSet Pod 自带本身监控性能，省去了咱们本人再写一个针对守护过程的监控程序的工作
2. DaemonSet Pod 不论运行什么工作，都是对立的语言和治理形式
3. DaemonSet Pod 自带了资源限度性能，防止了守护过程长时间运行占用过多资源对宿主机造成影响

结束语

DaemonSet 偏向于准确管制 Pod 运行在哪些机器上，确保这些机器上都有这个 Pod 在运行。

而 Deployment 更适宜于治理离用户更近的无状态类 Pod，比方 Web 服务。

它们的共同点是，都不心愿本人治理的 Pod 终止，Pod 呈现问题后能够自愈。

分割我

微信公众号：zuolinux_com