DeamonSet详解

目录

1.1 何为DaemonSet

1.2 DaemonSet 的 API 对象的定义

1.3 DaemonSet实践

1.3.1 创建 DaemonSet 对象

1.3.2 查看 DaemonSet 对象

1.3.3 DaemonSet 版本管理

1.3.4 DaemonSet 的容器镜像版本到 v2.2.0

1.1 何为DaemonSet

介绍DaemonSet我们先来思考一个问题：相信大家都接触过监控系统比如zabbix，监控系统需要在被监控机安装一个agent，安装agent通常会涉及到以下几个场景：

- 所有节点都必须安装agent以便采集监控数据
- 新加入的节点需要配置agent，手动或者运行脚本

k8s中经常涉及到在node上安装部署应用，它是如何解决上述的问题的呢？答案是DaemonSet。DaemonSet守护进程简称DS，适用于在所有节点或部分节点运行一个daemon守护进程。

DaemonSet 的主要作用，是让你在 k8s 集群里，运行一个 Daemon Pod。

这个 Pod 有如下三个特征：

1. 这个 Pod 运行在 k8s 集群里的每一个节点（Node）上；

2. 每个节点上只有一个这样的 Pod 实例；

3. 当有新的节点加入 Kubernetes 集群后，该 Pod 会自动地在新节点上被创建出来；而当旧节点被删除后，它上面的 Pod 也相应地会被回收掉。

举例：

各种网络插件的 Agent 组件，都必须运行在每一个节点上，用来处理这个节点上的容器网络；

各种存储插件的 Agent 组件，也必须运行在每一个节点上，用来在这个节点上挂载远程存储目录，操作容器的 Volume 目录；

各种监控组件和日志组件，也必须运行在每一个节点上，负责这个节点上的监控信息和日志搜集。

1.2 DaemonSet 的 API 对象的定义

所有node节点分别下载镜像

# docker pull daocloud.io/daocloud/fluentd-elasticsearch:1.20
# docker pull daocloud.io/daocloud/fluentd-elasticsearch:v2.2.0

fluentd-elasticsearch 镜像功能：

通过 fluentd 将每个node节点上面的Docker 容器里的日志转发到 ElasticSearch 中。

编写daemonset配置文件

Yaml文件内容如下

[root@k8s-master ~]# mkdir set
[root@k8s-master ~]# cd set/
[root@k8s-master set]# vim fluentd-elasticsearch.yaml # DaemonSet 没有 replicas 字段
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: daocloud.io/daocloud/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
   volumes:
   - name: varlog
     hostPath:  #定义卷使用宿主机目录
      path: /var/log
   - name: varlibdockercontainers
     hostPath:
      path: /var/lib/docker/containers

DaemonSet 没有 replicas 字段

selector :

选择管理所有携带了 name=fluentd-elasticsearch 标签的 Pod。

Pod 的模板用 template 字段定义:

定义了一个使用 fluentd-elasticsearch:1.20 镜像的容器，而且这个容器挂载了两个 hostPath 类型的 Volume，分别对应宿主机的 /var/log 目录和 /var/lib/docker/containers 目录。

fluentd 启动之后，它会从这两个目录里搜集日志信息，并转发给 ElasticSearch 保存。这样，通过 ElasticSearch 就可以很方便地检索这些日志了。Docker 容器里应用的日志，默认会保存在宿主机的 /var/lib/docker/containers/{ {. 容器 ID}}/{ {. 容器 ID}}-json.log 文件里，这个目录正是 fluentd 的搜集目标。

DaemonSet 如何保证每个 Node 上有且只有一个被管理的 Pod ？

DaemonSet Controller，首先从 Etcd 里获取所有的 Node 列表，然后遍历所有的 Node。这时，它就可以很容易地去检查，当前这个 Node 上是不是有一个携带了 name=fluentd-elasticsearch 标签的 Pod 在运行。

检查结果有三种情况：

1. 没有这种 Pod，那么就意味着要在这个 Node 上创建这样一个 Pod；指定的 Node 上创建新 Pod 用 nodeSelector，选择 Node 的名字即可。
2. 有这种 Pod，但是数量大于 1，那就说明要把多余的 Pod 从这个 Node 上删除掉；删除节点（Node）上多余的 Pod 非常简单，直接调用 Kubernetes API 就可以了。
3. 正好只有一个这种 Pod，那说明这个节点是正常的。

tolerations:

DaemonSet 还会给这个 Pod 自动加上另外一个与调度相关的字段，叫作 tolerations。这个字段意思是这个 Pod，会"容忍"（Toleration）某些 Node 的"污点"（Taint）。

tolerations 字段，格式如下：

apiVersion: v1
kind: Pod
metadata:
 name: with-toleration
spec:
 tolerations:
 - key: node.kubernetes.io/unschedulable  #污点的key
   operator: Exists #将会忽略value；只要有key和effect就行
   effect: NoSchedule  #污点的作用

含义是："容忍"所有被标记为 unschedulable"污点"的 Node；"容忍"的效果是允许调度。可以简单地把"污点"理解为一种特殊的 Label。

正常情况下，被标记了 unschedulable"污点"的 Node，是不会有任何 Pod 被调度上去的（effect: NoSchedule）。可是，DaemonSet 自动地给被管理的 Pod 加上了这个特殊的 Toleration，就使得这些 Pod 可以忽略这个限制，保证每个节点上都会被调度一个 Pod。如果这个节点有故障的话，这个 Pod 可能会启动失败，DaemonSet 会始终尝试下去，直到 Pod 启动成功。

DaemonSet 的"过人之处"，其实就是依靠 Toleration 实现的

DaemonSet 是一个控制器。在它的控制循环中，只需要遍历所有节点，然后根据节点上是否有被管理 Pod 的情况，来决定是否要创建或者删除一个 Pod。

更多种类的Toleration

可以在 Pod 模板里加上更多种类的 Toleration，从而利用 DaemonSet 实现自己的目的。

比如，在这个 fluentd-elasticsearch DaemonSet 里，给它加上了这样的 Toleration：

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

这是因为在默认情况下，Kubernetes 集群不允许用户在 Master 节点部署 Pod。因为，Master 节点默认携带了一个叫作node-role.kubernetes.io/master的"污点"。所以，为了能在 Master 节点上部署 DaemonSet 的 Pod，就必须让这个 Pod"容忍"这个"污点"。

1.3 DaemonSet实践

1.3.1 创建 DaemonSet 对象

[root@k8s-master set] # kubectl create -f fluentd-elasticsearch.yaml

DaemonSet 上一般都加上 resources 字段，来限制它的 CPU 和内存使用，防止它占用过多的宿主机资源。

创建成功后，如果有 3 个节点，就会有 3 个 fluentd-elasticsearch Pod 在运行

[root@k8s-master set]# kubectl get pod -n kube-system -l name=fluentd-elasticsearch
NAME                          READY   STATUS    RESTARTS   AGE
fluentd-elasticsearch-6lmnb   1/1     Running   0          21m
fluentd-elasticsearch-9fd7k   1/1     Running   0          21m
fluentd-elasticsearch-vz4n4   1/1     Running   0          21m

1.3.2 查看 DaemonSet 对象

[root@k8s-master set]# kubectl get ds -n kube-system fluentd-elasticsearch
NAME                    DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
fluentd-elasticsearch   3         3         3       3            3           <none>          22m

注：k8s 里比较长的 API 对象都有短名字，比如 DaemonSet 对应的是 ds，Deployment 对应的是 deploy。

1.3.3 DaemonSet 版本管理

[root@k8s-master set]# kubectl rollout history daemonset fluentd-elasticsearch -n kube-system
daemonset.apps/fluentd-elasticsearch 
REVISION  CHANGE-CAUSE
1         <none>

1.3.4 DaemonSet 的容器镜像版本到 v2.2.0

[root@k8s-master set]# kubectl set image ds/fluentd-elasticsearch fluentd-elasticsearch=daocloud.io/daocloud/fluentd-elasticsearch:v2.2.0 --record -n=kube-system
daemonset.apps/fluentd-elasticsearch image updated

这个 kubectl set image 命令里，第一个 fluentd-elasticsearch 是 DaemonSet 的名字，第二个 fluentd-elasticsearch 是容器的名字。

--record 参数:

升级使用到的指令会自动出现在 DaemonSet 的 rollout history 里面，如下所示：

[root@k8s-master set]# kubectl rollout history daemonset fluentd-elasticsearch -n kube-system
daemonset.apps/fluentd-elasticsearch 
REVISION  CHANGE-CAUSE
1         <none>
2         kubectl set image ds/fluentd-elasticsearch fluentd-elasticsearch=daocloud.io/daocloud/fluentd-elasticsearch:v2.2.0 --record=true --namespace=kube-system

有了版本号，也就可以像 Deployment 一样，将 DaemonSet 回滚到某个指定的历史版本了。