持续创作，加速成长！这是我参与「掘金日新计划 · 10 月更文挑战」的第21天，点击查看活动详情
DaemonSet
1) 概念
DaemonSet确保所有的节点(或者一部分节点)上运行一个Pod的副本。当有新的Node加入集群时，也会为他们新增一个Pod。当有Node从集群移除时，这些Pod也会被回收。删除DaemonSet将会删除它创建的所有的 Pod
DaemonSet 的一些典型用法：
- 运行集群存储 daemon，例如在每个 Node 上运行
glusterd、ceph - 在每个 Node 上运行日志收集 daemon，例如
fluentd、logstash - 在每个 Node 上运行监控 daemon，例如 Prometheus Node Exporter、
collectd、Datadog 代理、New Relic 代理，或 Ganglia gmond
2) 演示案例:
第一步: 准备资源清单
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: daemonset-controller
labels:
app: daemonset
spec:
selector:
matchLabels:
name: daemonset-pod
template:
metadata:
labels:
name: daemonset-pod
spec:
containers:
- name: daemonset-example
image: wangyanglinux/myapp:v1
资源清单解析:
-
首先创建了一个资源清单, 类型是DaemonSet, 所在的group是apps/v1. 资源清单的名字是deamonSet-controller
-
spec设置DaemonSet的期望.
- spec.selector.matchLabels: 定义了控制器匹配的pod的标签
- template: 定义pod的信息, 里面的具体含义就不说了, 需要注意的是, 要保证控制器匹配的标签是pod的标签的子集.
第二步: 创建控制器
kubectl create -f daemonSet-controller.yaml
从图中可以看出, 当创建了daemonSet控制器以后, 会自动在所有node节点上创建一个pod. 但有一个问题, 为什么不再master节点上创建pod呢?
找到这个问题的原因，我们要知道master的功能和作用。 master上是不需要安装docker的， master上安装的kubectl， schedule，server-api, etcd等他们都是以后台进程的方式运行的， 他们都不需要docker。
我们可以吧master和node节点合并， 也就是部署在一台机器上，通常我们不会这么做，因为master本身调度压力就很大了。但是在k8s中，master节点上其实我们也安装了kubelet，kube-proxy，但是为什么没有在master节点上部署项目呢？这时因为，master节点天生就带有“污点”，这个“污点”就是master的角色是master，不允许被调度。我们可以通过命令查看
kubectl describe node master
这就是master的污点. NoSchedule表示不允许被调度. 这也是为什么每次rs, rc, deployment在构建pod的时候都不会在master构建的原因. 这里有一个"污点"和"容忍"的概念. 比如master有污点,被标记不允许被调度. 而daemonset的容忍度是0, 就表示master有污点, 不能容忍, 那这样daemonset就不能再master上创建pod. 这个是可以设置的, 如果有需要, 可以设置这个容忍度. 也就是这个是可控制的.
比如我们系统创建的flannel
kubectl get pod -o wide -n kube-system
我们看到flannel在node和master节点上都部署了, 那么可以猜一下flannel是用什么控制器部署的呢? DaemonSet.
kubectl get daemonSet -n kube-system
我们的猜测是对的.
那么问题来了？flannel为什么部署的时候会部署到master上呢？我们上面看到master是不允许调度的呀。那么，这就要看daemonSet的容忍度了。查看一下flannel中daemonSet的容忍度是什么呢？可以通过看pod的yaml
tolerations:
- effect: NoSchedule
operator: Exists
- effect: NoExecute
key: node.kubernetes.io/not-ready
operator: Exists
- effect: NoExecute
key: node.kubernetes.io/unreachable
operator: Exists
- effect: NoSchedule
key: node.kubernetes.io/disk-pressure
operator: Exists
- effect: NoSchedule
key: node.kubernetes.io/memory-pressure
operator: Exists
- effect: NoSchedule
key: node.kubernetes.io/pid-pressure
operator: Exists
- effect: NoSchedule
key: node.kubernetes.io/unschedulable
operator: Exists
- effect: NoSchedule
key: node.kubernetes.io/network-unavailable
operator: Exists
具体含义我们后面还会详细讲到
