标签：node name kubernetes Kuebernetes DaemonSet io pod
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提供统一入口与负载均衡。
标签：node,name,kubernetes,Kuebernetes,DaemonSet,io,pod 来源： https://www.cnblogs.com/ExMan/p/13721042.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。