kubernetes - 选择部署而不是 daemon-set 的用例

Question

通常，当我们扩展应用程序时，我们不会在同一个节点上部署超过 1 个相同服务的 pod，使用 daemon-set 我们可以确保我们在每个节点上都有我们的服务，并且可以很容易地在扩展和缩减节点时管理 pod。如果我改用deployment，扩容时会出现问题，同一个节点可能有多个pod，新节点可能没有pod。

我想知道部署比 daemon-set 更适合的用例。

Answer 1

您的集群运行数十个服务，因此运行数百个节点，但为了规模和可靠性，您只需要每个服务的几个副本。部署在这里更有意义；如果您将所有内容都作为 DaemonSet 运行，则您必须能够将整个堆栈放入单个节点中，并且您将无法独立扩展组件。

我几乎总是会选择一个部署而不是 DaemonSet，除非我正在运行某种管理工具，必须在每个节点上运行（度量收集器、日志收集器，等）。您可以将其与 Horizo​​ntalPodAutoscaler 结合使用，以使 Deployment 的大小对系统负载做出反应，然后将其与集群自动扩缩器（如果您在云环境中）结合使用，以使集群的大小对正在运行的 pod 的资源需求。

集群放大和缩小并不是什么特别的问题。如果集群自动扩缩器删除了一个节点，它会首先将所有现有的 pod 移出它，因此您将保留服务的集群范围内的总副本数。同样，如果不是每个节点都运行每个服务，这通常不是问题，只要集群中某处运行的每个服务有足够的副本。

Answer 2

使用部署时有两个级别（或者说层）的扩展：

1. 假设在 kubernetes 上运行的网站仅在周五有高流量。
2. 随着流量的增加，部署规模扩大以启动更多的 Pod，并在流量下降时缩小规模。这是服务/pod 自动缩放。
3. 为了适应 Pod 的增加，更多的节点被添加到集群中，稍后当 Pod 减少时，一些节点将被关闭并释放。这是集群自动扩展。

与上述情况不同，daemonset 与节点具有 1 对 1 的映射关系。只有当 1 个 pod 恰好适合 1 个节点资源时，N 个节点 = N 个 pod 类型的缩放才会有用。然而，这在现实世界中不太可能发生。

Answer 3

拥有Daemonset 的缺点是您可能需要扩展应用程序，因此需要扩展节点数量以添加更多 pod。此外，如果您只需要应用程序的几个 pod，但拥有一个大型集群，您最终可能会运行大量未使用的 pod，从而阻塞其他应用程序的资源。

Deployment 解决了这个问题，因为同一应用程序的两个或多个 Pod 可以在一个节点上运行，并且 Pod 的数量与默认的节点数量是解耦的。但这带来了另一个问题：如果您的集群相当小，并且您的 pod 数量很少，它们可能最终都在几个节点上运行。在所有可用节点上没有良好的分布。如果其中一些节点由于某种原因出现故障，您会丢失大部分应用程序 pod。

您可以使用PodAntiAffinity 解决此问题，因此 pod 无法在运行已定义的其他 pod 的节点上运行。通过这种方式，您可以拥有与 Daemonset 类似的行为，但在扩展和资源使用方面具有更少的 pod 和更大的灵活性。

所以一个用例是，当您不需要每个节点一个 pod 但仍希望它们分布在您的节点上时。假设您有 50 个节点和一个需要 15 个 pod 的应用程序。使用 Deployment 和 PodAntiAffinity 您可以在不同的 15 个节点上以分布式方式运行这 15 个 pod。当您突然需要 20 个时，您可以扩展应用程序（而不是节点），以便 20 个 pod 在 20 个不同的节点上运行。但是你永远不会有 50 个 pod，而你只需要 15 个（或 20 个）。

您可以使用nodeSelector 或taints/tolerations 来实现与Daemonset 相同的效果，但这会更加复杂且不太灵活。