Kubernetes DaemonSet控制器

涉及文档

• Kubernetes DaemonSet官方文档

简介说明
DaemonSet 确保全部（或者某些）节点上运行一个 Pod 的副本。 当有节点加入集群时， 也会为他们新增一个 Pod 。 当有节点从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod

DaemonSet 涉及应用场景

• 在每个节点上运行集群守护进程
• 在每个节点上运行日志收集守护进程 (fluentd、logstash)
• 在每个节点上运行监控守护进程

一、创建 DaemonSet

vim fluentd-elasticsearch.yaml

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd-elasticsearch
  labels:
    k8s-app: fluentd-logging
spec:
  selector:
    matchLabels:
      name: fluentd-elasticsearch
  template:
    metadata:
      labels:
        name: fluentd-elasticsearch
    spec:
      tolerations:
      - key: node-role.kubernetes.io/k8s-master
        effect: NoSchedule
      containers:
      - name: fluentd-elasticsearch
        image: fluent/fluentd:latest
        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 fluentd-elasticsearch.yaml

三、 DaemonSet调度机制

通过默认调度器调度
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。

1、查看是否使用NodeAffinity 进行Pod的调度

kubectl  get  po -o yaml  fluentd-elasticsearch-cj8ss |grep -E "nodeAffinity" -A7

四、污点和容忍度

尽管DaemonSet Pods 遵循污点和容忍度 规则，根据相关特性，控制器会自动将以下容忍度添加到 DaemonSet Pod

容忍度键名	效果	描述
node.kubernetes.io/not-ready	NoExecute	当出现类似网络断开的情况导致节点问题时，DaemonSet Pod 不会被逐出
node.kubernetes.io/unreachable	NoExecute	当出现类似于网络断开的情况导致节点问题时，DaemonSet Pod 不会被逐出
node.kubernetes.io/disk-pressure	NoSchedule	DaemonSet Pod 被默认调度器调度时能够容忍磁盘压力属性。
node.kubernetes.io/memory-pressure	NoSchedule	DaemonSet Pod 被默认调度器调度时能够容忍内存压力属性。
node.kubernetes.io/unschedulable	NoSchedule	DaemonSet Pod 能够容忍默认调度器所设置的 unschedulable 属性
node.kubernetes.io/network-unavailable	NoSchedule	DaemonSet 在使用宿主网络时，能够容忍默认调度器所设置的 network-unavailable 属性

五、Deployments 与 DaemonSet 控制器区别(红色重点)

DaemonSet 与 Deployments 非常类似， 它们都能创建 Pod，并且 Pod 中的进程都不希望被终止（例如，Web 服务器、存储服务器）。 建议为无状态的服务使用 Deployments，比如前端服务。 对这些服务而言，对副本的数量进行扩缩容、平滑升级，比精确控制 Pod 运行在某个主机上要重要得多。 当需要 Pod 副本总是运行在全部或特定主机上，并需要它们先于其他 Pod 启动时， 应该使用 DaemonSet。