Kubernetes之DaemonSet
1.DaemonSet在每个节点上运行一个pod
K8s中Replicationcontroller和ReplicaSet都用于在Kubernetes集群上运行部署特定数量的pod。但是，当希望pod在集群中的每个节点上运行时（并且每个节点都需要正好一个运行的pod实例），就会出现某些情况。
这些情况包括pod执行系统级别的与基础结构相关的操作。例如，希望在每个节点上运行日志收集器和资源监控器。另一个典型的例子是Kubernetes自己的kube-proxy进程，它需要运行在所有节点上才能使服务工作。
在Kuberneters之外，此类进程通常在节点启动期间通过系统初始化脚本或systemd守护进程启动。在Kuberneters节点上，仍然可以使用systemd运行系统进程，但这样就不能利用所有的Kuberneters特性了。
1.1 使用DaemonSet在每个节点上运行一个pod
要在所有集群节点上运行一个pod需要创建一个DaemonSet对象,这很像一个ReplicationController或ReplicaSet，除了由DaemonSet创建的pod，己经有一个指定的目标节点并跳过Kubemetes调度程序。它们不是随机分布在集群上的。
DaemonSet确保创建足够的pod，并在自己的节点上部署每个pod。
尽管ReplicaSet(或ReplicationController)确保集群中存在期望数量的pod副本，但DaemonSet并没有期望的副本数的概念。它不需要，因为它的工作是确保一个pod匹配它的选择器并在每个节点上运行。
如果节点下线，DaemonSet不会在其他地方重新创建pod。但是，当将一个新节点添加到集群中时，DaemonSet会立刻部署一个新的pod实例。如果有人无意中删除了一个pod，那么它也会重新创建一个新的pod。与ReplicaSet—样，DaemonSet从配置的pod模板创建pod。
1.2 使用DaemonSet只在特定的节点上运行pod
DaemonSet将pod部署到集群中的所有节点上，除非指定这些pod只在部分节点上运行。这是通过pod模板中的nodeSelector属性指定的，这是DaemonSet定义的一部分（类似于ReplicaSet或ReplicationController中的pod模板）。
也可以使用节点选择器将pod部署到特定的节点上。DaemonSet中的节点选择器与之相似——它定义了DaemonSet必须将其pod部署到的节点。
注意：节点可以被设置为不可调度的，防止pod被部署到节点上。DaemonSet甚至会将pod部署到这些节点上，因为无法调度的属性只会被调度器使用，而DaemonSet管理的pod则完全绕过调度器。这是预期的，因为DaemonSet的目的是运行系统服务，即使是在不可调度的节点上，系统服务通常也需要运行。
用一个例子来解释DaemonSet
假设有一个名为ssd-monitor的守护进程，它需要在包含固态驱动器(SSD)的所有节点上运行。你将创建一个DaemonSet,它在标记为具有SSD的所有 节点上运行这个守护进程。集群管理员己经向所有此类节点添加了disk=ssd的标签，因此你将使用节点选择器创建DaemonSet，该选择器只选择具有该标签的节点，如图4.9所示。
创建一个DaemonSet YAML定义文件
假设将创建一个运行模拟的ssd-monitor监控器进程的DaemonSet,该进程每5秒会将“SSD OK”打印到标准输出。为DaemonSet创建一个YAML文件，如下面的代码清单所示。
#代码4.10 一个DaemonSet的YAML: ssd-monitor-daemonset.yaml
apiVersion: apps/v1beta2 #DaemonSet在apps的API组中，版本是v1beta2 kind: DaemonSet metadata: name: ssd-monitor spec: selector: matchLabels: app: ssd-monitor template: metadata: labels: app: ssd-monitor spec: nodeSelector: #pod模版包含一个节点选择器，会选择所有disk=ssd标签的节点 disk: ssd containers: - name: main image: luksa/ssd-monitor
创建DaemonSet
创建一个DaemonSet就像从YAML文件创建资源那样:
$ kubectl create -f ssd-monitor-daemonset.yaml daemonset "ssd-monitor" created
来看一下创建的DaemonSet:
$ kubectl get ds NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE-SELECTOR ssd-monitor 0 0 0 0 0 disk=ssd
这0看起来很奇怪。DaemonSet应该部署pod吗? 现在列出pod:
$ kubectl get po
No resources found
pod在哪里呢？知道发生了什么吗？是的，忘记给节点打上disk=ssd标签了。 打上标签之后，DaemonSet将检测到节点的标签己经更改，并将pod部署到有匹配标签的所有节点。
向节点上添加所需的标签
无论你使用的是Minikube、GKE或其他多节点集群，都需要首先列出节点，因为在标记时需要知道节点的名称:
$ kubectl get node
NAME STATUS AGE VERSION
minikube Ready 4d v1.6.0
现在给节点添加disk=ssd标签(如果没有使用Minikube,用你的节点名替换minikube)
kubectl label node minikube disk=ssd node "minikube" labeled
DaemonSet现在应该己经创建pod了
$ kubectl get po
NAME READY STATUS RESTARTS AGE
ssd-monitor-hgxwq 1/1 Running 0 35s
现在看起来一切正常。如果有多个节点并且其他的节点也加上了同样的标签，将会看到DaemonSet在每个节点上都启动pod。
从节点上删除所需的标签
现在假设给其中一个节点打错了标签。它的硬盘是磁盘而不是SSD。这时修改了标签会发生什么呢？
$ kubectl label node minikube disk=hdd --overwrite node "minikube" labeled
看一下更改是否影响了运行在节点上的pod:
$ kubectl get po
NAME READY STATUS RESTARTS AGE
ssd-monitor-hgxwq 1/1 Terminating 0 4m
pod如预期中正在被终止。这里对DaemonSet的探索就要结束了，因此可能想要删除ssd-monitor DaemonSet。如果还有其他的pod在运行，删除DaemonSet也会一起删除这些pod。
