Merge pull request #39177 from zhangxyjlu/pod-scheduling-readiness

[zh-cn] add 2022-12-26-pod-scheduling-readiness.md chinese version

Author: k8s-ci-robot

content/zh-cn/blog/_posts/2022-12-26-pod-scheduling-readiness.md

@@ -0,0 +1,201 @@
+---
+layout: blog
+title: "Kubernetes 1.26：Pod 调度就绪态"
+date: 2022-12-26
+slug: pod-scheduling-readiness-alpha
+---
+
+<!--
+layout: blog
+title: "Kubernetes 1.26: Pod Scheduling Readiness"
+date: 2022-12-26
+slug: pod-scheduling-readiness-alpha
+-->
+
+<!--
+**Author:** Wei Huang (Apple), Abdullah Gharaibeh (Google)
+-->
+**作者：** Wei Huang (Apple), Abdullah Gharaibeh (Google)
+
+**译者：** XiaoYang Zhang (HuaWei)
+
+<!--
+Kubernetes 1.26 introduced a new Pod feature: _scheduling gates_. In Kubernetes, scheduling gates
+are keys that tell the scheduler when a Pod is ready to be considered for scheduling.
+-->
+Kubernetes 1.26 引入了一个新的 Pod 特性：**调度门控**。
+在 Kubernetes 中，调度门控是通知调度器何时可以考虑 Pod 调度的关键。
+
+<!--
+## What problem does it solve?
+
+When a Pod is created, the scheduler will continuously attempt to find a node that fits it. This
+infinite loop continues until the scheduler either finds a node for the Pod, or the Pod gets deleted.
+-->
+## 它解决了什么问题？
+
+当 Pod 被创建时，调度器会不断尝试寻找适合它的节点。这个无限循环一直持续到调度程序为 Pod 找到节点，或者 Pod 被删除。
+
+<!--
+Pods that remain unschedulable for long periods of time (e.g., ones that are blocked on some external event) 
+waste scheduling cycles. A scheduling cycle may take ≅20ms or more depending on the complexity of
+the Pod's scheduling constraints. Therefore, at scale, those wasted cycles significantly impact the
+scheduler's performance. See the arrows in the "scheduler" box below.
+-->
+长时间无法被调度的 Pod（例如，被某些外部事件阻塞的 Pod）会浪费调度周期。
+一个调度周期可能需要约 20ms 或更长时间，这取决于 Pod 的调度约束的复杂度。
+因此，大量浪费的被调度周期会严重影响调度器的性能。请参阅下面 “调度器” 框中的箭头。
+
+{{< mermaid >}}
+graph LR;
+  pod((新 Pod))-->queue
+  subgraph 调度器
+    queue(调度器队列)
+    sched_cycle[/调度周期/]
+    schedulable{可调度?}
+    
+    queue==>|弹出|sched_cycle
+    sched_cycle==>schedulable
+    schedulable==>|否|queue
+    subgraph note [循环浪费在不断重新安排 'unready' 状态的 Pod 上]
+    end
+  end
+  
+ classDef plain fill:#ddd,stroke:#fff,stroke-width:1px,color:#000;
+ classDef k8s fill:#326ce5,stroke:#fff,stroke-width:1px,color:#fff;
+ classDef Scheduler fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
+ classDef note fill:#edf2ae,stroke:#fff,stroke-width:1px;
+ class queue,sched_cycle,schedulable k8s;
+ class pod plain;
+ class note note;
+ class Scheduler Scheduler;
+{{< /mermaid >}}
+
+<!--
+Scheduling gates helps address this problem. It allows declaring that newly created Pods are not
+ready for scheduling. When scheduling gates are present on a Pod, the scheduler ignores the Pod
+and therefore saves unnecessary scheduling attempts. Those Pods will also be ignored by Cluster
+Autoscaler if you have it installed in the cluster.
+-->
+调度门控有助于解决这个问题。它允许声明新创建的 Pod 尚未准备好进行调度。
+当 Pod 上设置了调度门控时，调度程序会忽略该 Pod，从而避免不必要的调度尝试。
+如果你在集群中安装了 Cluster Autoscaler，这些 Pod 也将被忽略。
+
+<!--
+Clearing the gates is the responsibility of external controllers with knowledge of when the Pod
+should be considered for scheduling (e.g., a quota manager).
+-->
+清除门控是外部控制器的责任，外部控制器知道何时应考虑对 Pod 进行调度（例如，配额管理器）。
+
+{{< mermaid >}}
+graph LR;
+  pod((新 Pod))-->queue
+  subgraph 调度器
+    queue(调度器队列)
+    sched_cycle[/调度周期/]
+    schedulable{可调度?}
+    popout{弹出?}
+    
+    queue==>|PreEnqueue 检查|popout
+    popout-->|是|sched_cycle
+    popout==>|否|queue
+    sched_cycle-->schedulable
+    schedulable-->|否|queue
+    subgraph note [控制 Pod 调度的开关]
+    end
+  end
+  
+ classDef plain fill:#ddd,stroke:#fff,stroke-width:1px,color:#000;
+ classDef k8s fill:#326ce5,stroke:#fff,stroke-width:1px,color:#fff;
+ classDef Scheduler fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
+ classDef note fill:#edf2ae,stroke:#fff,stroke-width:1px;
+ classDef popout fill:#f96,stroke:#fff,stroke-width:1px;
+ class queue,sched_cycle,schedulable k8s;
+ class pod plain;
+ class note note;
+ class popout popout;
+ class Scheduler Scheduler;
+{{< /mermaid >}}
+
+<!--
+## How does it work?
+
+Scheduling gates in general works very similar to Finalizers. Pods with a non-empty 
+`spec.schedulingGates` field will show as status `SchedulingGated` and be blocked from
+scheduling. Note that more than one gate can be added, but they all should be added upon Pod
+creation (e.g., you can add them as part of the spec or via a mutating webhook).
+-->
+## 它是如何工作的？
+
+总体而言，调度门控的工作方式与 Finalizer 非常相似。具有非空 `spec.schedulingGates` 字段的 Pod
+的状态将显示为 `SchedulingGated`，并阻止被调度。请注意，添加多个门控是可以的，但它们都应该在创建 Pod
+时添加（例如，你可以将它们作为规约的一部分或者通过变更性质的 Webhook）。
+
+```
+NAME       READY   STATUS            RESTARTS   AGE
+test-pod   0/1     SchedulingGated   0          10s
+```
+
+<!--
+To clear the gates, you update the Pod by removing all of the items from the Pod's `schedulingGates`
+field. The gates do not need to be removed all at once, but only when all the gates are removed the
+scheduler will start to consider the Pod for scheduling.
+-->
+要清除这些门控，你可以通过删除 Pod 的 `schedulingGates` 字段中的所有条目来更新 Pod。
+不需要一次性移除所有门控，但是，只有当所有门控都移除后，调度器才会开始考虑对 Pod 进行调度。
+
+<!--
+Under the hood, scheduling gates are implemented as a PreEnqueue scheduler plugin, a new scheduler
+framework extension point that is invoked at the beginning of each scheduling cycle.
+-->
+在后台，调度门控以 PreEnqueue 调度器插件的方式实现，这是调度器框架的新扩展点，在每个调度周期开始时调用。
+
+<!--
+## Use Cases
+
+An important use case this feature enables is dynamic quota management. Kubernetes supports
+[ResourceQuota](/docs/concepts/policy/resource-quotas/), however the API Server enforces quota at
+the time you attempt Pod creation. For example, if a new Pod exceeds the CPU quota, it gets rejected.
+The API Server doesn't queue the Pod; therefore, whoever created the Pod needs to continuously attempt
+to recreate it again. This either means a delay between resources becoming available and the Pod
+actually running, or it means load on the API server and Scheduler due to constant attempts.
+-->
+## 用例
+
+此特性所支持的一个重要使用场景是动态配额管理。Kubernetes 支持[资源配额](/zh-cn/docs/concepts/policy/resource-quotas/)，
+但是 API Server 会在你尝试创建 Pod 时强制执行配额。例如，如果一个新的 Pod 超过了 CPU 配额，它就会被拒绝。
+API Server 不会对 Pod 进行排队；因此，无论是谁创建了 Pod，都需要不断尝试重新创建它。
+这意味着在资源可用和 Pod 实际运行之间会有延迟，或者意味着由于不断尝试，会增加 API Server 和 Scheduler 的负载。
+
+<!--
+Scheduling gates allows an external quota manager to address the above limitation of ResourceQuota.
+Specifically, the manager could add a `example.com/quota-check` scheduling gate to all Pods created in the
+cluster (using a mutating webhook). The manager would then remove the gate when there is quota to
+start the Pod.
+-->
+调度门控允许外部配额管理器解决 ResourceQuota 的上述限制。具体来说，
+管理员可以（使用变更性质的 Webhook）为集群中创建的所有 Pod 添加一个
+`example.com/quota-check` 调度门控。当存在用于启动 Pod 的配额时，管理器将移除此门控
+
+<!--
+## Whats next?
+
+To use this feature, the `PodSchedulingReadiness` feature gate must be enabled in the API Server
+and scheduler. You're more than welcome to test it out and tell us (SIG Scheduling) what you think!
+-->
+## 接下来
+
+要使用此特性，必须在 API Server 和调度器中启用 `PodScheduleingReadiness` 特性门控。
+非常欢迎你对其进行测试并告诉我们（SIG Scheduling）你的想法！
+
+<!--
+## Additional resources
+
+- [Pod Scheduling Readiness](https://kubernetes.io/docs/concepts/scheduling-eviction/pod-scheduling-readiness/)
+ in the Kubernetes documentation
+- [Kubernetes Enhancement Proposal](https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/3521-pod-scheduling-readiness/README.md)
+-->
+## 附加资源
+
+- Kubernetes 文档中的 [Pod 调度就绪态](/zh-cn/docs/concepts/scheduling-eviction/pod-scheduling-readiness/)
+- [Kubernetes 增强提案](https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/3521-pod-scheduling-readiness/README.md)