在 Kelsey Hightower 的 Kubernetes Up and Running 中，他给出了两个命令：
kubectl get daemonSets --namespace=kube-system kube-proxy
和
kubectl get deployments --namespace=kube-system kube-dns
为什么一个使用 daemonSets 而另一个部署？ 又有什么区别呢？
【问题讨论】：
标签： kubernetes
Kubernetes 部署管理集群上运行的无状态服务（与管理有状态服务的 StatefulSets 不同）。它们的目的是保持一组相同的 pod 运行并以可控的方式升级它们。例如，您在部署定义中定义要运行的应用程序的多少副本（pods），kubernetes 将使您的应用程序的这么多副本分布在节点上。如果您说 5 个副本超过 3 个节点，那么某些节点将运行您的应用程序的多个副本。
DaemonSets 管理复制的 Pod 组。然而，DaemonSets 试图坚持一个 Pod-per-node 模型，无论是跨整个集群还是节点子集。 Daemonset 不会在每个节点上运行多个副本。使用 Daemonset 的另一个优点是，如果您将一个节点添加到集群中，那么 Daemonset 将自动在该节点上生成一个 pod，而部署不会这样做。
DaemonSets 可用于部署需要在所有或某些节点上运行且不需要用户干预的持续后台任务。此类任务的示例包括像ceph 这样的存储守护进程，像fluentd 这样的日志收集守护进程，以及像collectd 这样的节点监控守护进程
让我们以您在问题中提到的示例为例：为什么kube-dns 是部署而kube-proxy 是守护进程？
背后的原因是集群中的每个节点都需要kube-proxy来运行IP表，这样每个节点都可以访问每个pod，无论它位于哪个节点上。因此，当我们将 kube-proxy 设为 daemonset 并且稍后将另一个节点添加到集群中时，kube-proxy 会自动在该节点上生成。
Kube-dns 的职责是使用其名称发现服务 IP，并且仅kube-dns 的一个副本就足以将服务名称解析为其 IP。因此我们将kube-dns 设为deployment，因为我们不需要在每个节点上都使用kube-dns。
【讨论】：