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-rnonitor-hgxwq 1/1    Terminating       0        4m

　　pod如预期中正在被终止。这里对DaemonSet的探索就要结束了，因此可能想要删除ssd-monitor DaemonSet。如果还有其他的pod在运行，删除DaemonSet也会一起删除这些pod。