Updating a DaemonSet 更新守护进程集

DaemonSets are great for deploying services across an entire cluster, but what about upgrades? Prior to Kubernetes 1.6, the only way to update Pods managed by a DaemonSet was to update the DaemonSet and then manually delete each Pod that was managed by the DaemonSet so that it would be re-created with the new configuration. With the release of Kubernetes 1.6, DaemonSets gained an equivalent to the Deployment object that manages a DaemonSet rollout inside the cluster.

DaemonSet非常适合在整个集群中部署服务，但升级怎么办？在 Kubernetes 1.6 之前，更新由 DaemonSet 管理的 Pod 的唯一方法是更新 DaemonSet，然后手动删除由 DaemonSet 管理的每个 Pod，以便用新配置重新创建 Pod。随着 Kubernetes 1.6 的发布，DaemonSets 获得了一个与部署对象等价的对象，可以在集群内管理 DaemonSet 的推出。

Rolling Update of a DaemonSet 滚动更新守护进程集

DaemonSets can be rolled out using the same RollingUpdate strategy that deployments use. You can configure the update strategy using the spec.updateStrategy.type field, which should have the value RollingUpdate. When a DaemonSet has an update strategy of RollingUpdate, any change to the spec.template field (or subfields) in the DaemonSet will initiate a rolling update.

可以使用与部署相同的 RollingUpdate 策略推出守护进程集。您可以使用 spec.updateStrategy.type 字段配置更新策略，该字段的值应为 RollingUpdate。当 DaemonSet 的更新策略为 RollingUpdate 时，DaemonSet 中 spec.template 字段（或子字段）的任何更改都将启动滚动更新。

As with rolling updates of deployments (see Chapter 10), the RollingUpdate strategy gradually updates members of a DaemonSet until all of the Pods are running the new configuration.

与部署的滚动更新一样（见第 10 章），RollingUpdate 策略会逐步更新 DaemonSet 的成员，直到所有 Pod 都运行新配置。

There are two parameters that control the rolling update of a DaemonSet:

• spec.minReadySeconds, which determines how long a Pod must be “ready” before the rolling update proceeds to upgrade subsequent Pods
• spec.updateStrategy.rollingUpdate.maxUna vailable, which indicates how many Pods may be simultaneously updated by the rolling update

有两个参数可以控制 DaemonSet 的滚动更新：

• spec.minReadySeconds（最小就绪秒数），用于确定在滚动更新继续升级后续 Pod 之前，Pod 必须 "就绪 "多长时间

• spec.updateStrategy.rollingUpdate.maxUna vailable，表示滚动更新可同时更新多少个 Pod

You will likely want to set spec.minReadySeconds to a reasonably long value, for example 30–60 seconds, to ensure that your Pod is truly healthy before the rollout proceeds.

您可能希望将 spec.minReadySeconds 设置为一个相当长的值，例如 30-60 秒，以确保 Pod 在启动前真正处于健康状态。

The setting for spec.updateStrategy.rollingUpdate.maxUnavailab le is more likely to be application-dependent. Setting it to 1 is a safe, general-purpose strategy, but it also takes a while to complete the rollout (number of nodes × minReadySeconds). Increasing the maximum unavailability will make your rollout move faster, but increases the “blast radius” of a failed rollout. The characteristics of your application and cluster environment dictate the relative values of speed versus safety. A good approach might be to set maxUnavailable to 1 and only increase it if users or administrators complain about DaemonSet rollout speed.

spec.updateStrategy.rollingUpdate.maxUnavailab le 的设置更可能取决于应用。将其设置为 1 是一种安全的通用策略，但也需要一段时间才能完成滚动（节点数 × minReadySeconds）。增加最大不可用时间会使推出速度更快，但会增加推出失败的 “爆炸半径”。应用程序和群集环境的特性决定了速度与安全的相对值。一个好的方法可能是将 maxUnavailable 设置为 1，只有在用户或管理员抱怨 DaemonSet 推出速度时才增加它。

Once a rolling update has started, you can use the kubectl rollout commands to see the current status of a DaemonSet rollout.

启动滚动更新后，可以使用 kubectl rollout 命令查看 DaemonSet 滚动的当前状态。

For example, kubectl rollout status daemonSets mydaemon-set will show the current rollout status of a DaemonSet named my-daemon-set.

例如，kubectl rollout status daemonSets mydaemon-set 将显示名为 my-daemon-set 的 DaemonSet 的当前启动状态。