Change:
This is a Feature Request page /docs/tasks/administer-cluster/safely-drain-node/ is not available in Chinese version. What would you like to be file: content/zh/docs/tasks/administer-cluster/safely-drain- the file from its english version Why is this needed synchronize Chinese with English version Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --
/language zh /assign

Discussion:
<ins> --- title: 确保 PodDisruptionBudget 的前提下安全地清空一个节点 content_type: task --- <!-- reviewers: - davidopp - mml - foxish - kow3ns title: Safely Drain a Node while Respecting the PodDisruptionBudget content_type: task --> <!-- overview --> <!-- This page shows how to safely drain a node, respecting the PodDisruptionBudget you have defined. --> 本页展示了如何在确保 PodDisruptionBudget 的前提下，安全地清空一个节点。 ## {{% heading "prerequisites" %}} <!-- This task assumes that you have met the following prerequisites: * You are using Kubernetes release >= 1.5. * Either: 1. You do not require your applications to be highly available during the node drain, or 1. You have read about the [PodDisruptionBudget concept](/docs/concepts/workloads/pods/disruptions/) and [Configured PodDisruptionBudgets](/docs/tasks/run-application/configure-pdb/) for applications that need them. --> 此任务假设您已经满足以下先决条件： * 使用的 Kubernetes 版本 >= 1.5。 * 以下两项，具备其一： 1. 在节点清空期间，不要求应用程序具有高可用性 1. 你已经了解了 [PodDisruptionBudget 的概念](/zh/docs/concepts/workloads/pods/disruptions/)，并为需要它的应用程序[配置了 PodDisruptionBudget](/zh/docs/tasks/run-application/configure-pdb/)。 <!-- steps --> <!-- ## Use `kubectl drain` to remove a node from service You can use `kubectl drain` to safely evict all of your pods from a node before you perform maintenance on the node (e.g. kernel upgrade, hardware maintenance, etc.). Safe evictions allow the pod's containers to [gracefully terminate](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination) and will respect the `PodDisruptionBudgets` you have specified. --> ## 使用 `kubectl drain` 从服务中删除一个节点 {#use-kubectl-drain-to-remove-a-node-from-service} 在对节点执行维护（例如内核升级、硬件维护等）之前， 可以使用 `kubectl drain` 从节点安全地逐出所有 Pods。 安全的驱逐过程允许 Pod 的容器 [体面地终止](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)， 并确保满足指定的 `PodDisruptionBudgets` 。 <!-- By default `kubectl drain` will ignore certain system pods on the node that cannot be killed; see the [kubectl drain](/docs/reference/generated/kubectl/kubectl-commands/#drain) documentation for more details. --> {{< note >}} 默认情况下， `kubectl drain` 将忽略节点上不能杀死的特定系统 Pod； 有关更多细节，请参阅 [kubectl drain](/docs/reference/generated/kubectl/kubectl-commands/#drain) 文档。 {{< /note >}} <!-- When `kubectl drain` returns successfully, that indicates that all of the pods (except the ones excluded as described in the previous paragraph) have been safely evicted (respecting the desired graceful termination period, and respecting the PodDisruptionBudget you have defined). It is then safe to bring down the node by powering down its physical machine or, if running on a cloud platform, deleting its virtual machine. First, identify the name of the node you wish to drain. You can list all of the nodes in your cluster with --> `kubectl drain` 的成功返回，表明所有的 Pods（除了上一段中描述的被排除的那些）， 已经被安全地逐出（考虑到期望的终止宽限期和你定义的 PodDisruptionBudget）。 然后就可以安全地关闭节点， 比如关闭物理机器的电源，如果它运行在云平台上，则删除它的虚拟机。 ```shell kubectl get nodes ``` <!-- Next, tell Kubernetes to drain the node: --> 接下来，告诉 Kubernetes 清空节点： ```shell kubectl drain <node name> ``` <!-- Once it returns (without giving an error), you can power down the node (or equivalently, if on a cloud platform, delete the virtual machine backing the node). If you leave the node in the cluster during the maintenance operation, you need to run --> 一旦它返回（没有报错）， 你就可以下电此节点（或者等价地，如果在云平台上，删除支持该节点的虚拟机）。 如果要在维护操作期间将节点留在集群中，则需要运行： ```shell kubectl uncordon <node name> ``` <!-- afterwards to tell Kubernetes that it can resume scheduling new pods onto the node. --> 然后告诉 Kubernetes，它可以继续在此节点上调度新的 Pods。 <!-- ## Draining multiple nodes in parallel The `kubectl drain` command should only be issued to a single node at a time. However, you can run multiple `kubectl drain` commands for different nodes in parallel, in different terminals or in the background. Multiple drain commands running concurrently will still respect the `PodDisruptionBudget` you specify. --> ## 并行清空多个节点  {#draining-multiple-nodes-in-parallel} `kubectl drain` 命令一次只能发送给一个节点。 但是，你可以在不同的终端或后台为不同的节点并行地运行多个 `kubectl drain` 命令。 同时运行的多个 drain 命令仍然遵循你指定的 `PodDisruptionBudget` 。 <!-- For example, if you have a StatefulSet with three replicas and have set a `PodDisruptionBudget` for that set specifying `minAvailable: 2`. `kubectl drain` will only evict a pod from the StatefulSet if all three pods are ready, and if you issue multiple drain commands in parallel, Kubernetes will respect the PodDisruptionBudget and ensure that only one pod is unavailable at any given time. Any drains that would cause the number of ready replicas to fall below the specified budget are blocked. --> 例如，如果你有一个三副本的 StatefulSet， 并设置了一个 `PodDisruptionBudget`，指定 `minAvailable: 2`。 如果所有的三个 Pod 均就绪，并且你并行地发出多个 drain 命令， 那么 `kubectl drain` 只会从 StatefulSet 中逐出一个 Pod， 因为 Kubernetes 会遵守 PodDisruptionBudget 并确保在任何时候只有一个 Pod 不可用。 任何会导致就绪副本数量低于指定预算的清空操作都将被阻止。 <!-- ## The Eviction API If you prefer not to use [kubectl drain](/docs/reference/generated/kubectl/kubectl-commands/#drain) (such as to avoid calling to an external command, or to get finer control over the pod eviction process), you can also programmatically cause evictions using the eviction API. --> ## 驱逐 API {#the-eviction-api} 如果你不喜欢使用 [kubectl drain](/zh/docs/reference/generated/kubectl/kubectl-commands/#drain) （比如避免调用外部命令，或者更细化地控制 pod 驱逐过程）， 你也可以用驱逐 API 通过编程的方式达到驱逐的效果。 <!-- You should first be familiar with using [Kubernetes language clients](/docs/tasks/administer-cluster/access-cluster-api/#programmatic-access-to-the-api). The eviction subresource of a pod can be thought of as a kind of policy-controlled DELETE operation on the pod itself. To attempt an eviction (perhaps more REST-precisely, to attempt to *create* an eviction), you POST an attempted operation. Here's an example: --> 首先应该熟悉使用 [Kubernetes 语言客户端](/zh/docs/tasks/administer-cluster/access-cluster-api/#programmatic-access-to-the-api)。 Pod 的 Eviction 子资源可以看作是一种策略控制的 DELETE 操作，作用于 Pod 本身。 要尝试驱逐（更准确地说，尝试 *创建* 一个 Eviction），需要用 POST 发出所尝试的操作。这里有一个例子： ```json { "apiVersion": "policy/v1beta1", "kind": "Eviction", "metadata": { "name": "quux", "namespace": "default" } } ``` <!-- You can attempt an eviction using `curl`: --> 你可以使用 `curl` 尝试驱逐： ```bash curl -v -H 'Content-type: application/json' http://127.0.0.1:8080/api/v1/namespaces/default/pods/quux/eviction -d @eviction.json ``` <!-- The API can respond in one of three ways: - If the eviction is granted, then the pod is deleted just as if you had sent a `DELETE` request to the pod's URL and you get back `200 OK`. - If the current state of affairs wouldn't allow an eviction by the rules set forth in the budget, you get back `429 Too Many Requests`. This is typically used for generic rate limiting of *any* requests, but here we mean that this request isn't allowed *right now* but it may be allowed later. Currently, callers do not get any `Retry-After` advice, but they may in future versions. - If there is some kind of misconfiguration, like multiple budgets pointing at the same pod, you will get `500 Internal Server Error`. --> API可以通过以下三种方式之一进行响应： - 如果驱逐被授权，那么 Pod 将被删掉，并且你会收到 `200 OK`， 就像你向 Pod 的 URL 发送了 `DELETE` 请求一样。 - 如果按照预算中规定，目前的情况不允许的驱逐，你会收到 `429 Too Many Requests`。 这通常用于对 *一些* 请求进行通用速率限制， 但这里我们的意思是：此请求 *现在* 不允许，但以后可能会允许。 目前，调用者不会得到任何 `Retry-After` 的提示，但在将来的版本中可能会得到。 - 如果有一些错误的配置，比如多个预算指向同一个 Pod，你将得到 `500 Internal Server Error`。 <!-- For a given eviction request, there are two cases: - There is no budget that matches this pod. In this case, the server always returns `200 OK`. - There is at least one budget. In this case, any of the three above responses may apply. --> 对于一个给定的驱逐请求，有两种情况： - 没有匹配这个 Pod 的预算。这种情况，服务器总是返回 `200 OK`。 - 至少匹配一个预算。在这种情况下，上述三种回答中的任何一种都可能适用。 <!-- In some cases, an application may reach a broken state where it will never return anything other than 429 or 500. This can happen, for example, if the replacement pod created by the application's controller does not become ready, or if the last pod evicted has a very long termination grace period. In this case, there are two potential solutions: - Abort or pause the automated operation. Investigate the reason for the stuck application, and restart the automation. - After a suitably long wait, `DELETE` the pod instead of using the eviction API. Kubernetes does not specify what the behavior should be in this case; it is up to the application owners and cluster owners to establish an agreement on behavior in these cases. --> 在某些情况下，应用程序可能会到达一个中断状态，除了 429 或 500 之外，它将永远不会返回任何内容。 例如应用程序控制器创建的替换 Pod 没有准备好，或者被驱逐的最后一个 Pod 有很长的终止宽限期，就会发生这种情况。 在这种情况下，有两种可能的解决方案： - 中止或暂停自动操作。调查应用程序卡住的原因，并重新启动自动化。 - 经过适当的长时间等待后， `DELETE` Pod，而不是使用驱逐 API。 Kubernetes 并没有具体说明在这种情况下应该采取什么行为； 这应该由应用程序所有者和集群所有者紧密沟通，并达成对行动一致意见。 ## {{% heading "whatsnext" %}} <!-- * Follow steps to protect your application by [configuring a Pod Disruption Budget](/docs/tasks/run-application/configure-pdb/). * Learn more about [maintenance on a node](/docs/tasks/administer-cluster/cluster-management/#maintenance-on-a-node). --> * 跟随以下步骤保护应用程序：[配置 Pod 中断预算](/zh/docs/tasks/run-application/configure-pdb/)。 * 进一步了解[节点维护](/zh/docs/tasks/administer-cluster/cluster-management/#maintenance-on-a-node)。 </ins>