在Kelsey Hightower的Kubernetes Up and Running中，他给出了两个命令：
kubectl get daemonSets --namespace=kube-system kube-proxy
和
kubectl get deployments --namespace=kube-system kube-dns
为什么一个使用daemonSets，而另一个使用？ 和有什么区别？
答案 0 :(得分：5)
Kubernetes部署管理在群集上运行的无状态服务（例如，管理状态服务的StatefulSet相对）。他们的目的是保持一组相同的Pod运行并以受控方式对其进行升级。例如，在部署定义中定义要运行的应用程序有多少个副本（pods），而kubernetes将使应用程序的许多副本分布在节点上。如果您说5个副本超过3个节点，则某些节点正在运行您的应用程序的多个副本。
DaemonSets 管理复制的Pod组。但是，DaemonSets尝试在整个集群或节点子集上遵循每个节点一个Pod的模型。守护程序在每个节点上最多可以运行一个副本。使用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设为{{ 1}}，因为我们不需要每个节点上的deployment。