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

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

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

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

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

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

网络插件的 Agent
存储插件的 Agent
监控工作的 Agent
收集日志的 Agent

创立一个 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 胜利启动

能够在 YAML 中手工指定 .spec.template.spec.affinity，这样 Pod 会运行在指定的 Node 上

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

如果没有指定该参数，那么 Pod 会运行在所有 Node 上

咱们也能够本人写一个守护过程来执行相似的工作，应用 DaemonSet Pod 有哪些长处呢。

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

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

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

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

微信公众号：zuolinux_com

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

前言

更新历史

Daemon Pod 的特点

Daemon Pod 实用的场景

DaemonSet

工作流程

重要参数

仅在局部节点运行 Pod

DaemonSet 长处

结束语

分割我