Daemon Sets
1. What is a DaemonSet? : 什么是DaemonSet？
–
2. Writing a DaemonSet Spec : 编写DaemonSet具体配置
Required Fields ： 必选项
Pod Template： Pod 模板写法
Pod Selector ： Pod选择器
–
3. Running Pods on Only Some Nodes : 在节点上运行多个Pod
–
4. How Daemon Pods are Scheduled : 精灵Pod是如何被调度的
–
5. Communicating with DaemonSet Pods : 精灵Pod之间的通信
–
6. Updating a DaemonSet: 更新一个DaemonSet
–
7. Alternatives to DaemonSet : DaemonSet的可选项
Init Scripts: 初始化脚步
Bare Pods:
Static Pods:
Replication Controller: 副本控制器
What is a DaemonSet?
A DaemonSet ensures that all (or some) nodes run a copy of a pod. (DaemonSet保证了所有或者某些节点运行的是同一个Pod的副本。)
As nodes are added to the cluster, pods are added to them. As nodes are removed from the cluster,
those pods are garbage collected. Deleting a DaemonSet will clean up the pods it created.
(当节点加入到集群中时， pod也将在节点中运行。当节点从集群中被删除，这些节点的pod将被垃圾处理器收集，删除一个DaemonSet意味着删除由它创建的所有Pod)
Some typical uses of a DaemonSet are:
(一些DaemonSet的经典使用：)
running a cluster storage daemon, such as glusterd, ceph, on each node.
(在每一节点上运行一个集群存储精灵进程)
running a logs collection daemon on every node, such as fluentd or logstash.
(在每一个节点上运行日志收集精灵进程)
running a node monitoring daemon on every node, such as Prometheus Node Exporter, collectd, New Relic agent, or Ganglia gmond.
(在每一个节点上运行一个监控进程)
In a simple case, one DaemonSet, covering all nodes, would be used for each type of daemon.
A more complex setup might use multiple DaemonSets for a single type of daemon,
but with different flags and/or different memory and cpu requests for different hardware types.
(简单的用法是，一个DaemonSet覆盖了所有节点， 它就是一个精灵进程。
更为复杂的情况是使用多个DaemonSet被用作一个精灵进程， 但是每个DaemonSet有不同的标识，
有不同的内存和CPU等硬件需求。
)
Writing a DaemonSet Spec： 编写一个DaemonSet
Required Fields
As with all other Kubernetes config, a DaemonSet needs apiVersion, kind, and metadata fields.
(与所有k8s的配置一样，DaemonSet的必须字段包括：apiVersion，kind以及metadata域配置。)
For general information about working with config files, see deploying applications, configuring containers, and working with resources documents.
A DaemonSet also needs a .spec section.
(关于更多配置信息请参考:部署应用，配置容器，配置资源等文档， DaemonSet同样也需要配置.spec字段。)
Pod Template
The .spec.template is the only required field of the .spec.
The .spec.template is a pod template. It has exactly the same schema as a pod, except it is nested and does not have an apiVersion or kind.
()
In addition to required fields for a pod, a pod template in a DaemonSet has to specify appropriate labels (see pod selector).
()
A pod template in a DaemonSet must have a RestartPolicy equal to Always, or be unspecified, which defaults to Always.
(DaemonSet模板必须包含重启策略(RestartPolicy)： Always或者不指定，默认就是Always)
Pod Selector
The .spec.selector field is a pod selector. It works the same as the .spec.selector of a Job or other new resources.
(.spec下的.selector字段就是配置pod选择器，工作机制和Job等资源一样)
The spec.selector is an object consisting of two fields:
matchLabels - works the same as the .spec.selector of a ReplicationController
matchExpressions - allows to build more sophisticated selectors by specifying key, list of values and an operator that relates the key and values.
When the two are specified the result is ANDed.
If the .spec.selector is specified, it must match the .spec.template.metadata.labels. If not specified, they are defaulted to be equal. Config with these not matching will be rejected by the API.
Also you should not normally create any pods whose labels match this selector, either directly, via another DaemonSet, or via other controller such as ReplicationController. Otherwise, the DaemonSet controller will think that those pods were created by it. Kubernetes will not stop you from doing this. One case where you might want to do this is manually create a pod with a different value on a node for testing.
Running Pods on Only Some Nodes (在部分节点上运行Pod)
If you specify a .spec.template.spec.nodeSelector, then the DaemonSet controller will create pods on nodes which match that node selector. If you specify a scheduler.alpha.kubernetes.io/affinity annotation in .spec.template.metadata.annotations, then DaemonSet controller will create pods on nodes which match that node affinity.
If you do not specify a .spec.template.spec.nodeSelector nor node affinity, then the DaemonSet controller will create pods on all nodes.
How Daemon Pods are Scheduled （精灵Pod的调度）
Normally, the machine that a pod runs on is selected by the Kubernetes scheduler.
（通常情况下，Pod运行到哪个节点由K8s的调度器调度。）
However, pods created by the Daemon controller have the machine already selected (.spec.nodeName is specified when the pod is created, so it is ignored by the scheduler).
（然而，通过Daemon控制器创建的pod标识了节点选择， 通过.spec.nodeName指定，这意味着它不会被调度器调度。）
Therefore:
the unschedulable field of a node is not respected by the DaemonSet controller.
DaemonSet controller can make pods even when the scheduler has not been started, which can help cluster bootstrap.
（因此，处于不可调度域中的节点，DaemonSet控制器是不重视的。当调度器还未被启动时，DaemonSet控制器可以控制Pod数量为奇数，这有助于集群的启动。）
Communicating with DaemonSet Pods（DaemonSet中Pod的通信）
Some possible patterns for communicating with pods in a DaemonSet are:
（DaemonSet中Pod的几种可能的通信方式）
Push: Pods in the DaemonSet are configured to send updates to another service, such as a stats database. They do not have clients.
（Push方式：DaemonSet中的Pod被配置成向其他服务发送更新，比如数据库的状态。它们没有客户端。）NodeIP and Known Port: Pods in the DaemonSet use a hostPort, so that the pods are reachable via the node IPs. Clients know the list of nodes ips somehow, and know the port by convention.
（通过NodeIP和端口的范式：DaemonSet中的Pod使用了一个主机端口，因此通过NodeIP，Pod是可访问的。
客户端通过某种方式获取到各个节点的IP，并根据约定得到端口）DNS: Create a headless service with the same pod selector, and then discover DaemonSets using the endpoints resource or retrieve multiple A records from DNS.
(DNS方式： 为同一个pod选择器创建一个无主服务，然后发现DaemonSet使用终端资源或者从DNS获取多条记录)Service: Create a service with the same pod selector, and use the service to reach a daemon on a random node. (No way to reach specific node.)
（Service方式：）
–
Updating a DaemonSet （更新DaemonSet）
If node labels are changed, the DaemonSet will promptly add pods to newly matching nodes and delete pods from newly not-matching nodes.
(如果是label改变的话，DaemonSet可以迅速响应改变，在新的匹配节点上创建pod而在不匹配的节点上删除旧pod)
You can modify the pods that a DaemonSet creates. However, pods do not allow all fields to be updated. Also, the DaemonSet controller will use the original template the next time a node (even with the same name) is created.
(允许修改DaemonSet创建的Pod，然而并不是允许更新所有的域属性。并且，DaemonSet会使用原始的yaml配置模板来创建新节点上的pod)
You can delete a DaemonSet. If you specify –cascade=false with kubectl, then the pods will be left on the nodes.
（DaemonSet可以被删除。如果指定了使用kubectl删除指定–cascade=false的话，那么节点上的pod还将遗留。）
You can then create a new DaemonSet with a different template. the new DaemonSet with the different template will recognize all the existing pods as having matching labels.
(DaemonSet可以通过不同的yaml模板创建。使用不同模板创建的DaemonSet也会识别出所有匹配到相同label的pod)
It will not modify or delete them despite a mismatch in the pod template. You will need to force new pod creation by deleting the pod or deleting the node.
(尽管pod模板有改变了，pod不会被更改，也不会被删除。必须通过强制删除pod或者节点，然后启动新pod。)
You cannot update a DaemonSet. （无法更新DaemonSet）
Support for updating DaemonSets and controlled updating of nodes is planned.
（支持DaemonSet的更新和控制已经在计划之中）
Alternatives to DaemonSet：DaemonSet的替代者
Init Scripts （初始化脚本）
It is certainly possible to run daemon processes by directly starting them on a node (e.g. using init, upstartd, or systemd). This is perfectly fine. However, there are several advantages to running such processes via a DaemonSet:
（在一个节点上运行精灵进程可以直接在节点上启动，比如通过init/upstartd/systemd方式。这种直接启动方式很好。然后，通过DaemonSet启动一个守护进程有如下优势：）
Ability to monitor and manage logs for daemons in the same way as applications.
Same config language and tools (e.g. pod templates, kubectl) for daemons and applications.
（可以以应用同样的方式监控以及管理守护进程的日志，同样的配置语言和工具，如pod.temlates何kubectl可供守护进程和应用使用。）
Future versions of Kubernetes will likely support integration between DaemonSet-created pods and node upgrade workflows.
(将来版本的k8s可能集成在DaemonSet创建Pod和节点更新之间的工作流)
Running daemons in containers with resource limits increases isolation between daemons from app containers. However, this can also be accomplished by running the daemons in a container but not in a pod (e.g. start directly via Docker).
(在容器中运行有资源限制的守护进程增加了守护进程与应用容器间的隔离性。
然而，这同样可以通过直接在容器中启动守护进程完成而不是在pod中，例如直接通过Docker。
)
Bare Pods （空Pod）
It is possible to create pods directly which specify a particular node to run on. However, a DaemonSet replaces pods that are deleted or terminated for any reason, such as in the case of node failure or disruptive node maintenance, such as a kernel upgrade. For this reason, you should use a DaemonSet rather than creating individual pods.
Static Pods （静态pod）
It is possible to create pods by writing a file to a certain directory watched by Kubelet. These are called static pods. Unlike DaemonSet, static pods cannot be managed with kubectl or other Kubernetes API clients. Static pods do not depend on the apiserver, making them useful in cluster bootstrapping cases. Also, static pods may be deprecated in the future.
（在某个目录下写一个文件，该目录被kubelet监控，该方式不依赖apiserver以及其他K8s API客户端。后续可能会过时。）
Replication Controller （副本控制器）
DaemonSet are similar to Replication Controllers in that they both create pods, and those pods have processes which are not expected to terminate (e.g. web servers, storage servers).
（DaemonSet和RC非常类似，在于它们创建pod，并且这些pod运行的进程不期望被终止。）
Use a replication controller for stateless services, like frontends, where scaling up and down the number of replicas and rolling out updates are more important than controlling exactly which host the pod runs on.
(当一些无状态服务，如果这些服务的副本数量的控制和滚动更新比精确控制这些pod在哪些节点上运行更为重要的话，使用RC是合适的。)
Use a Daemon Controller when it is important that a copy of a pod always run on all or certain hosts, and when it needs to start before other pods.
(当在所有节点或者某些特定节点需要运行一个pod的副本，或者这个Pod需要在其他pod之前启动时，适合使用DaemonSet。)