Kubernetes的DaemonSet(上篇)

背景

静儿作为美团容器化团队HULK的一员,经常需要和Kubernetes(k8s)打交道。第一次登陆node(宿主机)的时候,发现连续登陆几台都看到了Prometheus-Node-Exporter字样的docker进程。他们和普通的Pod(容器)一样,占用IP等资源,占用宿主机允许的pod数上限。后来通过看书了解到这是DaemonSet控制管理的Pod.

DaemonSet官方文档译文

一个DaemonSet确保了所有的node上仅有一个的Pod的一个实例。当node被添加到集群中,Pod也被添加上去。当node被从集群移除,这些Pod会被垃圾回收。删除一个DaemonSet将会清理它创建的Pod。

举一些DaemonSet典型用法的例子:

  • 在每个node上运行一个集群存储守护进程,例如glusterd、ceph
  • 在每个node上运行一个日志集合,例如fuentd或者logstash
  • 在每个node上运行一个node监控后台线程,例如Prometheus Node Exporter,collectd,Dynatrace OneAgent,AppDynamics Agent,Datadog agent,New Relic agent,Ganglia gmod 或者Instana agent.

在一种简单的场合下,一个DeamonSet会被使用在任意种后台线程、覆盖所有的node。在更复杂的安装方式中,多个DaemonSet会被用于一种后台线程。但是在不同的硬件类型会对应不同的标识或者不同的内存和CPU请求。

写一个DaemonSet Spec

创建一个DaemonSet

在YAML文件中生命一个DaemonSet。daemonset.yaml文件描述了一个运行着fluentd-elasticsearch的docker镜像的DaemonSet。

controllers/daemonset.yaml

apiVersion: apps/v1kind: DaemonSetmetadata:  name: fluentd-elasticsearch  namespace: kube-system  labels:    k8s-app: fluentd-loggingspec:  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
  • 创建一个基于YAML文件的DaemonSet kubectl create -f https://k8s.io/examples/controllers/daemonset.yaml

所需的字段

和其他的Kubernetes配置文件一样,一个DaemonSet需要apiVersion,kind和metadata字段。配置文件的通用信息,可以看deploying application,configuring containers和object management using kubectl文档。

一个DaemonSet也需要一个spec区

Pod模板

.spec.template是.spec的必需字段。

.spec.template是一个pod模板。除了是嵌套的并且没有apiVersion或者kind之外,它的schema和pod是一样的。

除了pod必需的字段,在DaemonSet中的pod模板必需指定合适的label(详见pod selector)。

在DaemonSet中的pod模板必需要有一个Always的RestartPolicy。如果没有明确指定,默认也是Aways。

Pod选择器

.spec.selector字段是pod的选择器。它的功能和job的.spec.selector一样。

在Kubernetes1.8中,必需指定一个带有.spec.template的pod选择器。当pod选择器为空时将不会再是默认的选择器。选择器默认和kubectl apply是不兼容的。一旦DaemonSet被创建,.spec.selector就不能变了。一旦改变了pod选择器,可能会导致意外将这个pod变成「孤岛」。用户会很迷惑。

.spec.selector是有两个字段组成的对象:

  • matchLabels - 和ReplicationController的.spec.selector是一样的
  • matchExpressions - 通过制定key、values列表、operatorl来定制更加精细的选择器。

指定了两个,它们的作用关系是and。

一旦.spec.selector被指定,就必须和.spec.template.metadata.labels匹配。不匹配的配置会被API拒掉。

同时,用户平时也不应该创建匹配这些选择器的标签。包括直接创建、通过其他的DaemonSet创建,或者通过其他的像ReplicaSet这样的控制器来创建。否则,DaemonSet控制器会认为这些pod是自己创建的。但是如果说想手动创建一个值不同的pod放在node上做测试就另当别论了。

在指定node上运行pod

指定.spec.template.spec.nodeSelector,DaemonSet控制器会在node上创建一个匹配node选择器的pod。同时,如果指定.spec.template.spec.affinity,这时候DaemonSet控制器会创建匹配node的affinity的pod。如果什么两者都不指定,DaemonSet控制器将会在所有node上创建pod。

Daemon的pod是怎么被调度的

通过DaemonSet控制器来调度(1.12版本被禁用)

pod实际运行的设备通常是Kubernetes调度器来选择的。但是DaemonSet控住器创建的pod是已经指定好了设备的(Pod在创建时.spec.nodeName已经被指定了,所以会被调度器忽略)。基于这个原因:

  • node节点上的字段unschedulable会被DaemonSet控制器忽略。
  • DaemonSet控制器在调度还没开始时就会创建Pod来帮助启动集群。

被默认调度器调度(1.12版本开始默认启动)

DaemonSet确保所有有资格的node运行一个pod的一个实例。一般来说,Kubernetes控制器决定了一个Pod选择哪个node。但是DaemonSet控制器却负责创建和调度DaemonSet的pod。这引入了下面的问题:

  • 不一致的Pod行为:普通Pod会以Pending状态创建出来等待调度。但是DaemonSet的Pod的初始状态却不是Pending。这让用户很疑惑。
  • 默认调度器处理Pod优先权(Pod preemption)。当preemption被启用,DaemonSet控制器在做调度决策时就不考虑pod优先权。

ScheduleDaemonSetPods允许你使用默认调度器而不是DaemonSet控制器来调度。这是通过添加NodeAffinity项而不是.spec.nodeName到DaemonSet的Pod来实现的。默认调度被应用于绑定pod到目标宿主机。DaemonSet Pod的node affinity已经存在时会被替换。DaemonSet控制器只在创建或者修改DaemonSet Pod时才会这样。不会修改DaemonSet的spec.template。

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

污点和容忍

Daemon Pod支持污点和容忍。下面的容忍会根据相应的特性被自动添加到DaemonSet。

总结

初学一个技术如果感觉无法下手,学了也记不住的赶脚。不如先从一个问题出发:为什么会有这个Pod存在?这样先进行感知再系统学习。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏盟主来了

19.2.16日报:script的文本解码流程

起源是https://zhitongche.taobao.com/ 有个url(g.alicdn.com/kissy/k/1.4.4/seed.js)老是解码错...

12530
来自专栏ccylovehs

前端异步技术之Promise

由于是参(抄)考(袭)前辈的polyfill,自己编码测试时出现了两处错误,ES6 Promise 规范的2.3.1和2.3.4

16140
来自专栏芝麻实验室

Elasticsearch基础

# curl -XGET 'http://192.168.10.221:9200/_cat/health?pretty' 1516176817 16:13:37...

12710
来自专栏芝麻实验室

基于Keepalived的Nginx高可用实践

17720
来自专栏运维记录点滴

Lync Server 2013 部署前端池支持NLB吗?

    部署Lync server 2013前端池时遇到负载均衡的问题,没有HLB的硬件负载均衡设备,使用DNS负载轮询pool A记录建立多条指向不同的前端服...

11040
来自专栏芝麻实验室

Redis集群的故障转移实现

[root@node2 ~]# systemctl restart redis-sentinel [root@node3 ~]# systemctl resta...

13620
来自专栏芝麻实验室

Redis主从复制

20230
来自专栏Angular&服务

angular打包报错内存溢出 nodejs 执行失败报错 “JavaScript heap out of memory” 的解决办法

报错信息很直观地指出是内存溢出了。是什么导致了内存溢出呢?其根本原因在于 nodejs 默认限制了最大可使用的内存大小。

1.9K20
来自专栏编程微刊

'wepy' 不是内部或外部命令,也不是可运行的程序 或批处理文件。

在学习安装wepy创建项目的时候,开启实时编译,出现了这样的一个报错: 'wepy' 不是内部或外部命令,也不是可运行的程序 或批处理文件。

53940
来自专栏黑光技术

使用gitbook来写文档和文章啦

项目中文档管理是一个比较麻烦的事情,一般的做法都是写word文档,或者pdf;针对代码或者接口文档高级一点的可以使用Doxygen或者swagger这样的工具自...

37240

扫码关注云+社区

领取腾讯云代金券

年度创作总结 领取年终奖励