Kuebernetes之DaemonSet

系列目录

DaemonSet确保集群中每个(部分)node运行一份pod副本,当node加入集群时创建pod,当node离开集群时回收pod。如果删除DaemonSet,其创建的所有pod也被删除,DaemonSet中的pod覆盖整个集群。

当需要在集群内每个node运行同一个pod,使用DaemonSet是有价值的,以下是典型使用场景:

  • 运行集群存储守护进程,如glusterd、ceph。

  • 运行集群日志收集守护进程,如fluentd、logstash。

  • 运行节点监控守护进程,如Prometheus Node Exporter, collectd, Datadog agent, New Relic agent, or Ganglia gmond。

创建DaemonSet

以下是DaemonSet的示例spec文件,运行fluentd-elasticsearch image:

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:
      - key: node-role.kubernetes.io/master
        effect: NoSchedule
      containers:
      - name: fluentd-elasticsearch
        image: k8s.gcr.io/fluentd-elasticsearch:1.20
        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

以上DaemonSet中没有restart policy字段,默认为Always。如果有的话,必需将值设置成Always,否则在创建时出出现不可用错误。

DaemonSet同样会受到Taint的抵制,如果不在配置中加入匹配的Toleration,那么DaemonSet不会在拥有Taint属性的node上部署pod。上例中有如下内容:

tolerations:
      - key: node-role.kubernetes.io/master
        effect: NoSchedule

原因就是系统默认为master节点增加了 “node-role.kubernetes.io/master”的Taint,以抵制普通pod部署,使master成为专用节点。因为我们预期上例DaemonSet在集群内全局部署,因此需要加入相匹配的Toleration。

如果预期DaemonSet只在特定节点上运行,可以在上述配置文件中加入.spec.template.spec.nodeSelector字段。.
spec.template.spec.nodeSelector字段内加入节点选择器(node selector)或者亲和选择器(node affinity),则DaemonSet只会在满足条件的node上部署pod。总之,可以通过Taint、Toleration、Affinity、node label控制DaemonSet部署pod的节点范围。

将以上内容保存在daemonset.yaml文件中,执行如下命令创建DaemonSet:

kubectl create -f https://k8s.io/examples/controllers/daemonset.yaml

系统如何调度DaemonSet pod?

默认情况下DaemonSet在创建pod时,为其增加spec.nodeName字段,也就是说所创建的pod运行在那个节上在创建阶段就已经确定,所以DaemonSet中的pod实际上没有接受kubernetes scheduler的调度,它不需要调度,因此产生以下两个特性:

  • DaemonSet中的pod不遵从节点的unreachable条件,也就是即使节点被系统判定为不可达,DaemonSet仍然试图在其上部署pod。

  • 在集群引导阶段,即使kubernetes scheduler还没有部署生效,DaemonSet仍然可以将pod部署到集群中的任何节点,此特性主要是在集群引导阶段使用。

因为DaemonSet不同于常规pod的调度特性,它带来两个问题:

  • pod行为不一致。普通pod被创建以后等待调度的阶段称为pending,因为DaemonSet中的pod无需调度,因而无此状态,用户会因此产生迷惑。

  • pod优先级特性由kubernetes scheduler实现,DaemonSet无此特性。当系统打开pod优先级功能时,pod优先级特性会被DaemonSet中的pod忽略。

为了解决以上两个问题,kubernetes增加了通过设置允许DaemonSet使用kurbernetes scheduler的功能,并在1.11的 alpha版本中成为稳定特性。其实现机制是DaemonSet在创建pod时,不再自动添加.spec.nodeName,而是以nodeAffinity取而代之,示例如下:

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

其中"target-host-name"就是原来.spec.nodeName的值,这样pod就会被kubernetes scheduler调度。通过以上操作解决了上述两个问题。但DaemonSet的调度有自己因有的特性,在上文中提到的“不受节点unreachable条件限制”,为了使DaemonSet在使用kubernetes scheduler时仍然保持此特性需要打开集群的"TaintNodesByCondition"特性,如果DaemonSet使用主机网络那么必需在DaemonSet中添加如下的Toleration:

node.kubernetes.io/network-unavailable:NoSchedule

DaemonSet自动添加的Toleration

系统在某此条件下会自动为节点添加Taint,比如硬盘不足、网络不可达等,以阻止新pod往不满足条件的节点上调度。但DaemonSet的目的是在全部有资格的node上部署,不希望被这种Taint打断,因经系统也默认为DaemonSet上的pod添加Toleration。如下表:

Toleration Key Effect Alpha Features Version Description
node.kubernetes.io/not-ready NoExecute TaintBasedEvictions 1.8+ when TaintBasedEvictions is enabled,they will not be evicted when there are node problems such as a network partition.
node.kubernetes.io/unreachable NoExecute TaintBasedEvictions 1.8+ when TaintBasedEvictions is enabled,they will not be evicted when there are node problems such as a network partition.
node.kubernetes.io/disk-pressure NoSchedule TaintNodesByCondition 1.8+
node.kubernetes.io/memory-pressure NoSchedule TaintNodesByCondition 1.8+
node.kubernetes.io/unschedulable NoSchedule ScheduleDaemonSetPods, TaintNodesByCondition 1.11+ When ScheduleDaemonSetPodsis enabled, TaintNodesByConditionis necessary to make sure DaemonSet pods tolerate unschedulable attributes by default scheduler.
node.kubernetes.io/network-unavailable NoSchedule ScheduleDaemonSetPods, TaintNodesByCondition, hostnework 1.11+ When ScheduleDaemonSetPodsis enabled, TaintNodesByConditionis necessary to make sure DaemonSet pods, who uses host network, tolerate network-unavailable attributes by default scheduler.
node.kubernetes.io/out-of-disk NoSchedule ExperimentalCriticalPodAnnotation(critical pod only), TaintNodesByCondition 1.8+

与DaemonSet中pod通信的几种模式

  • Push:收集数据并向其它服务发送,如将收集到的统计信息发送给统计类型数据库。

  • NodeIP and Known Port:DaemonSet中的pod可以被设置使用主机网络的一个port,而客户端可以很方便的知道节点IP列表,因此可以通过节点IP地址与port访问DaemonSet pod。

  • DNS:创建无头服务并且让它的选择器匹配所有DaemonSet的pod,这样DaemonSet中的pod就会成为无头服务的endpoints。类似于StatefulSet。

  • Service:让Service选中DaemonSet,为访问DaemonSet中的pod提供统一入口与负载均衡。

posted @ 2019-06-12 08:03  周国通  阅读(1464)  评论(0编辑  收藏  举报