什么是 DaemonSet？
编写 DaemonSet 规约
必需字段
Pod 模板
Pod Selector
仅在某些节点上运行 Pod
如何调度 Daemon Pod
与 Daemon Pod 通信
更新 DaemonSet
DaemonSet 的可替代选择
init 脚本
裸 Pod
静态 Pod
Replication ControllerWhat is DaemonSet?
DaemonSet sure to run a copy of the Pod on all (or some) node. When a node joins the cluster will add a Pod for them. When a node is removed from the cluster, which will be recovered Pod. Delete DaemonSet Pod will delete all its created.
Use of some typical usage DaemonSet:
运行集群存储 daemon，例如在每个节点上运行 glusterd、ceph。
在每个节点上运行日志收集 daemon，例如fluentd、logstash。
在每个节点上运行监控 daemon，例如 Prometheus Node Exporter、collectd、Datadog 代理、New Relic 代理，或 Ganglia gmond。A simple usage is to have a DaemonSet start on all nodes, each type will be used as a daemon. It is to use a slightly more complex to use for each individual type daemon plurality DaemonSet, but with different flags, and / or with a different memory, CPU requirements for different types of hardware.
Write DaemonSet statute
required field
And all other Kubernetes same configuration, DaemonSet need apiVersion, kind and metadata fields. Basic information about profiles, see the documentation deploying applications, configuration container and resource management.
DaemonSet also need a .spec configuration section.
Pod template
.spec only required fields are .spec.template.
.spec.template Pod is a template. It Pod Schema has the same, except that it is nested, and without having apiVersion or kind field.
In addition to the required fields Pod, Pod template DaemonSet must specify a reasonable label (see Pod Selector).
Pod DaemonSet template must have a value of Always RestartPolicy, or if its value is not specified, the default is Always.
Pod Selector
.spec.selector field indicates Pod Selector, which acts with Job .spec.selector or other resources are the same.
spec.selector represents an object, which consists of the following fields:
matchLabels - 与 ReplicationController 的 .spec.selector 的作用相同。
matchExpressions - 允许构建更加复杂的 Selector，可以通过指定 key、value 列表，以及与 key 和 value 列表相关的操作符。When the above two fields are specified, the result is represented by an AND relationship.
If you specify .spec.selector, you must match .spec.template.metadata.labels. If not specified, the default they are equivalent. If they do not match the configuration it is rejected API.
If the label and the selector Pod match, directly or based on other DaemonSet, or a Controller (e.g. ReplicationController), nor can create any Pod. Otherwise DaemonSet Controller will assume those Pod is that it creates. Kubernetes will not stop doing so. A scene, it may be desirable to create a Pod manually, for test node has a different value.
Pod runs only on some nodes
If .spec.template.spec.nodeSelector specified, DaemonSet Controller Pod will be created on the node to match the Node Selector. Similarly such a case, you can specify .spec.template.spec.affinity, then DaemonSet Controller Pod created on the node can be matched with the Node Affinity. If you did not specified, DaemonSet Controller will create Pod on all nodes.
How to schedule Daemon Pod
Normally, Pod run on which the machine is selected Kubernetes scheduler. However, created by Daemon Controller Pod it has been identified on which machine (created when Pod specified .spec.nodeName), thus:
DaemonSet Controller 并不关心一个节点的 unschedulable 字段。
DaemonSet Controller 可以创建 Pod，即使调度器还没有启动，这对集群启动是非常有帮助的。Daemon Pod care Taint and Toleration, as they do not specify tolerationSeconds of node.kubernetes.io/not-ready and node.alpha.kubernetes.io/unreachable of Taint, creation of Toleration has NoExecute. This ensures that when TaintBasedEvictions alpha characteristics is enabled, node failure, such as network partition, then they will not be removed (when TaintBasedEvictions feature is not enabled, it will not be cleared in these scenes, but because NodeController the hard-coded behavior is cleared, and not because of Toleration cause is cleared).
Daemon Pod in communication with
DaemonSet communicate with the Pod, several possible modes are as follows:
Push：配置 DaemonSet 中的 Pod 向其它 Service 发送更新，例如统计数据库。它们没有客户端。
NodeIP 和已知端口：DaemonSet 中的 Pod 可以使用 hostPort，从而可以通过节点 IP 访问到 Pod。客户端能通过某种方法知道节点 IP 列表，并且基于此也可以知道端口。
DNS：创建具有相同 Pod Selector 的 Headless Service，然后通过使用 endpoints 资源或从 DNS 检索到多个 A 记录来发现 DaemonSet。
Service：创建具有相同 Pod Selector 的 Service，并使用该 Service 随机访问到某个节点上的 daemon（没有办法访问到特定节点）。Update DaemonSet
If you modify the node label (Label), DaemonSet Pod will immediately add to a node on a new match, and delete the Pod on the node can not match recently.
We can modify the Pod DaemonSet created. However, it does not allow for all fields Pod updated. When the next node (even with the same name) is created, DaemonSet Controller will use the original template.
You can delete a DaemonSet. If kubectl and specify --cascade = false option, Pod will be retained on the node. You can then create a new DaemonSet have different templates. New DaemonSet having different templates will match and be able to identify all existing Pod through the label. It does not modify or delete them, even the false matches the Pod template. Pod by deleting or delete nodes, you can force the creation of a new Pod.
In Kubernetes 1.6 or later, you can perform a rolling upgrade on DaemonSet.
Future versions will support Kubernetes controllable update nodes.
DaemonSet alternative choice
init script
We probably want to start the daemon process directly on a node (for example, using init, upstartd, or systemd). This is very good, but based on DaemonSet to run these processes has the following benefits:
像对待应用程序一样，具备为 daemon 提供监控和管理日志的能力。
为 daemon 和应用程序使用相同的配置语言和工具（如 Pod 模板、kubectl）。
Kubernetes 未来版本可能会支持对 DaemonSet 创建 Pod 与节点升级工作流进行集成。
在资源受限的容器中运行 daemon，能够增加 daemon 和应用容器的隔离性。然而，这也实现了在容器中运行 daemon，但却不能在 Pod 中运行（例如，直接基于 Docker 启动）。Bare Pod
Pod may want to create a direct, specifying that run on a particular node. However, DaemonSet replaced for any reason be deleted or terminated Pod, such as node failure, node routine maintenance, upgrade the kernel. For this reason, we should use DaemonSet rather than creating a separate Pod.
Static Pod
You may need to write in a specified directory file to create Pod, the directory being monitored by Kubelet. These are called static Pod Pod. Unlike DaemonSet, static Pod from kubectl and other Kubernetes API Client Management. Static Pod does not depend on apiserver, which makes them useful in the case of the cluster started. Moreover, the future still Pod may be discarded.
Replication Controller
DaemonSet and Replication Controller are very similar, they can create Pod, Pod correspond to these processes do not wish to be terminated out (for example, Web servers, storage servers). Stateless Service uses Replication Controller, such as front-end (Frontend) services, and the number of copies will be scalable capacity, smooth upgrade, than to precisely control the Pod run much more important on a host. Pod need a copy of all or always run on a particular host, and you need to start at the other Pod, when it was considered very important, you should use Daemon Controller