whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

[zh] Resync concepts files (2)

Browse Source
This commit is contained in:
Qiming Teng
2021-04-27 13:02:33 +08:00
parent 86fa9cff43
commit b33e1aec19
6 changed files with 97 additions and 65 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/zh/docs/concepts/scheduling-eviction/assign-pod-node.md
+59 -38
View File
@@ -1,7 +1,7 @@
---
title: 将 Pod 分配给节点
content_type: concept
weight: 50
weight: 20
---
<!--
@@ -11,24 +11,24 @@ reviewers:
- bsalamat
title: Assigning Pods to Nodes
content_type: concept
weight: 50
weight: 20
-->
<!-- overview -->
<!--
You can constrain a {{< glossary_tooltip text="Pod" term_id="pod" >}} to only be able to run on particular
{{< glossary_tooltip text="Node(s)" term_id="node" >}}, or to prefer to run on particular nodes.
You can constrain a {{< glossary_tooltip text="Pod" term_id="pod" >}} so that it can only run on particular set of
{{< glossary_tooltip text="Node(s)" term_id="node" >}}.
There are several ways to do this, and the recommended approaches all use
[label selectors](/docs/concepts/overview/working-with-objects/labels/) to make the selection.
[label selectors](/docs/concepts/overview/working-with-objects/labels/) to facilitate the selection.
Generally such constraints are unnecessary, as the scheduler will automatically do a reasonable placement
(e.g. spread your pods across nodes, not place the pod on a node with insufficient free resources, etc.)
(e.g. spread your pods across nodes so as not place the pod on a node with insufficient free resources, etc.)
but there are some circumstances where you may want more control on a node where a pod lands, for example to ensure
that a pod ends up on a machine with an SSD attached to it, or to co-locate pods from two different
services that communicate a lot into the same availability zone.
-->
你可以约束一个 {{< glossary_tooltip text="Pod" term_id="pod" >}} 只能在特定的
{{< glossary_tooltip text="节点" term_id="node" >}} 上运行，或者优先运行在特定的节点上。
{{< glossary_tooltip text="节点" term_id="node" >}} 上运行。
有几种方法可以实现这点，推荐的方法都是用
[标签选择算符](/zh/docs/concepts/overview/working-with-objects/labels/)来进行选择。
通常这样的约束不是必须的，因为调度器将自动进行合理的放置（比如，将 Pod 分散到节点上，
@@ -132,22 +132,12 @@ Pod 将会调度到将标签添加到的节点上。
## Interlude: built-in node labels {#built-in-node-labels}
In addition to labels you [attach](#step-one-attach-label-to-the-node), nodes come pre-populated
with a standard set of labels. These labels are
with a standard set of labels. See [Well-Known Labels, Annotations and Taints](/docs/reference/labels-annotations-taints/) for a list of these.
-->
## 插曲：内置的节点标签 {#built-in-node-labels}
除了你[添加](#attach-labels-to-node)的标签外，节点还预先填充了一组标准标签。
这些标签有：
* [`kubernetes.io/hostname`](/zh/docs/reference/kubernetes-api/labels-annotations-taints/#kubernetes-io-hostname)
* [`failure-domain.beta.kubernetes.io/zone`](/zh/docs/reference/kubernetes-api/labels-annotations-taints/#failure-domainbetakubernetesiozone)
* [`failure-domain.beta.kubernetes.io/region`](/zh/docs/reference/kubernetes-api/labels-annotations-taints/#failure-domainbetakubernetesioregion)
* [`topology.kubernetes.io/zone`](/zh/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesiozone)
* [`topology.kubernetes.io/region`](/zh/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesiozone)
* [`beta.kubernetes.io/instance-type`](/zh/docs/reference/kubernetes-api/labels-annotations-taints/#beta-kubernetes-io-instance-type)
* [`node.kubernetes.io/instance-type`](/zh/docs/reference/kubernetes-api/labels-annotations-taints/#nodekubernetesioinstance-type)
* [`kubernetes.io/os`](/zh/docs/reference/kubernetes-api/labels-annotations-taints/#kubernetes-io-os)
* [`kubernetes.io/arch`](/zh/docs/reference/kubernetes-api/labels-annotations-taints/#kubernetes-io-arch)
参见[常用标签、注解和污点](/zh/docs/reference/labels-annotations-taints/)。
{{< note >}}
<!--
@@ -247,12 +237,12 @@ Pod 可以调度到哪些节点。
<!--
There are currently two types of node affinity, called `requiredDuringSchedulingIgnoredDuringExecution` and
`preferredDuringSchedulingIgnoredDuringExecution`. You can think of them as "hard" and "soft" respectively,
in the sense that the former specifies rules that *must* be met for a pod to be scheduled onto a node (just like
in the sense that the former specifies rules that *must* be met for a pod to be scheduled onto a node (similar to
`nodeSelector` but using a more expressive syntax), while the latter specifies *preferences* that the scheduler
will try to enforce but will not guarantee. The "IgnoredDuringExecution" part of the names means that, similar
to how `nodeSelector` works, if labels on a node change at runtime such that the affinity rules on a pod are no longer
met, the pod will still continue to run on the node. In the future we plan to offer
`requiredDuringSchedulingRequiredDuringExecution` which will be just like `requiredDuringSchedulingIgnoredDuringExecution`
met, the pod continues to run on the node. In the future we plan to offer
`requiredDuringSchedulingRequiredDuringExecution` which will be identical to `requiredDuringSchedulingIgnoredDuringExecution`
except that it will evict pods from nodes that cease to satisfy the pods' node affinity requirements.
-->
目前有两种类型的节点亲和性，分别为 `requiredDuringSchedulingIgnoredDuringExecution` 和
@@ -264,8 +254,8 @@ except that it will evict pods from nodes that cease to satisfy the pods' node a
如果节点的标签在运行时发生变更，从而不再满足 Pod 上的亲和性规则，那么 Pod
将仍然继续在该节点上运行。
将来我们计划提供 `requiredDuringSchedulingRequiredDuringExecution`，
它将类似于 `requiredDuringSchedulingIgnoredDuringExecution`，
除了它会将 pod 从不再满足 pod 的节点亲和性要求的节点上驱逐。
它将与 `requiredDuringSchedulingIgnoredDuringExecution` 完全相同，
只是它会将 Pod 从不再满足 Pod 的节点亲和性要求的节点上驱逐。
<!--
Thus an example of `requiredDuringSchedulingIgnoredDuringExecution` would be "only run the pod on nodes with Intel CPUs"
@@ -538,22 +528,23 @@ Pod 亲和性与反亲和性的合法操作符有 `In`，`NotIn`，`Exists`，`D
然而，出于性能和安全原因，topologyKey 受到一些限制：
<!--
1. For affinity and for `requiredDuringSchedulingIgnoredDuringExecution` pod anti-affinity,
empty `topologyKey` is not allowed.
2. For `requiredDuringSchedulingIgnoredDuringExecution` pod anti-affinity, the admission controller `LimitPodHardAntiAffinityTopology` was introduced to limit `topologyKey` to `kubernetes.io/hostname`. If you want to make it available for custom topologies, you may modify the admission controller, or simply disable it.
3. For `preferredDuringSchedulingIgnoredDuringExecution` pod anti-affinity, empty `topologyKey` is interpreted as "all topologies" ("all topologies" here is now limited to the combination of `kubernetes.io/hostname`, `topology.kubernetes.io/zone` and `topology.kubernetes.io/region`).
1. For pod affinity, empty `topologyKey` is not allowed in both
`requiredDuringSchedulingIgnoredDuringExecution`
and `preferredDuringSchedulingIgnoredDuringExecution`.
2. For pod anti-affinity, empty `topologyKey` is also not allowed in both `requiredDuringSchedulingIgnoredDuringExecution`
and `preferredDuringSchedulingIgnoredDuringExecution`.
3. For `requiredDuringSchedulingIgnoredDuringExecution` pod anti-affinity, the admission controller `LimitPodHardAntiAffinityTopology` was introduced to limit `topologyKey` to `kubernetes.io/hostname`. If you want to make it available for custom topologies, you may modify the admission controller, or disable it.
4. Except for the above cases, the `topologyKey` can be any legal label-key.
-->
1. 对于亲和性与 `requiredDuringSchedulingIgnoredDuringExecution` 要求的
Pod 反亲和性，`topologyKey` 不允许为空。
2. 对于 `requiredDuringSchedulingIgnoredDuringExecution` 要求的 Pod 反亲和性，
准入控制器 `LimitPodHardAntiAffinityTopology` 被引入来限制 `topologyKey`
为 `kubernetes.io/hostname`。
如果你想设置topologyKey为其他值来用于自定义拓扑结构，你必须修改准入控制器或者禁用它。
3. 对于 `preferredDuringSchedulingIgnoredDuringExecution` 要求的 Pod 反亲和性，
空的 `topologyKey` 被解释为“所有拓扑结构”（这里的“所有拓扑结构”限制为
`kubernetes.io/hostname`，`topology.kubernetes.io/zone` 和
`topology.kubernetes.io/region` 的组合）。
1. 对于 Pod 亲和性而言，在 `requiredDuringSchedulingIgnoredDuringExecution`
和 `preferredDuringSchedulingIgnoredDuringExecution` 中，`topologyKey` 不允许为空。
2. 对于 Pod 反亲和性而言，`requiredDuringSchedulingIgnoredDuringExecution`
和 `preferredDuringSchedulingIgnoredDuringExecution` 中，`topologyKey`
都不可以为空。
3. 对于 `requiredDuringSchedulingIgnoredDuringExecution` 要求的 Pod 反亲和性，
准入控制器 `LimitPodHardAntiAffinityTopology` 被引入以确保 `topologyKey`
只能是 `kubernetes.io/hostname`。如果你希望 `topologyKey` 也可用于其他定制
拓扑逻辑，你可以更改准入控制器或者禁用之。
4. 除上述情况外，`topologyKey` 可以是任何合法的标签键。
<!--
@@ -573,6 +564,36 @@ must be satisfied for the pod to be scheduled onto a node.
所有与 `requiredDuringSchedulingIgnoredDuringExecution` 亲和性与反亲和性
关联的 `matchExpressions` 必须满足，才能将 pod 调度到节点上。
<!--
#### Namespace selector
-->
#### 名字空间选择算符
{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
<!--
Users can also select matching namespaces using `namespaceSelector`, which is a label query over the set of namespaces.
The affinity term is applied to the union of the namespaces selected by `namespaceSelector` and the ones listed in the `namespaces` field.
Note that an empty `namespaceSelector` ({}) matches all namespaces, while a null or empty `namespaces` list and
null `namespaceSelector` means "this pod's namespace".
-->
用户也可以使用 `namespaceSelector` 选择匹配的名字空间，`namespaceSelector`
是对名字空间集合进行标签查询的机制。
亲和性条件会应用到 `namespaceSelector` 所选择的名字空间和 `namespaces` 字段中
所列举的名字空间之上。
注意，空的 `namespaceSelector`（{}）会匹配所有名字空间，而 null 或者空的
`namespaces` 列表以及 null 值 `namespaceSelector` 意味着“当前 Pod 的名字空间”。
<!--
This feature is alpha and disabled by default. You can enable it by setting the
[feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
`PodAffinityNamespaceSelector` in both kube-apiserver and kube-scheduler.
-->
此功能特性是 Alpha 版本的，默认是被禁用的。你可以通过针对 kube-apiserver 和
kube-scheduler 设置
[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)
`PodAffinityNamespaceSelector` 来启用此特性。
<!--
#### More Practical Use-cases
content/zh/docs/concepts/scheduling-eviction/kube-scheduler.md
+4 -2
View File
@@ -1,13 +1,13 @@
---
title: Kubernetes 调度器
content_type: concept
weight: 50
weight: 10
---
<!--
title: Kubernetes Scheduler
content_type: concept
weight: 50
weight: 10
-->
<!-- overview -->
@@ -173,6 +173,7 @@ of the scheduler:
* Read about [scheduler performance tuning](/docs/concepts/scheduling-eviction/scheduler-perf-tuning/)
* Read about [Pod topology spread constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/)
* Read the [reference documentation](/docs/reference/command-line-tools-reference/kube-scheduler/) for kube-scheduler
* Read the [kube-scheduler config (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/) reference
* Learn about [configuring multiple schedulers](/docs/tasks/extend-kubernetes/configure-multiple-schedulers/)
* Learn about [topology management policies](/docs/tasks/administer-cluster/topology-manager/)
* Learn about [Pod Overhead](/docs/concepts/scheduling-eviction/pod-overhead/)
@@ -180,6 +181,7 @@ of the scheduler:
* 阅读关于 [调度器性能调优](/zh/docs/concepts/scheduling-eviction/scheduler-perf-tuning/)
* 阅读关于 [Pod 拓扑分布约束](/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints/)
* 阅读关于 kube-scheduler 的 [参考文档](/zh/docs/reference/command-line-tools-reference/kube-scheduler/)
* 阅读 [kube-scheduler 配置参考 (v1beta1)](/zh/docs/reference/config-api/kube-scheduler-config.v1beta1/)
* 了解关于 [配置多个调度器](/zh/docs/tasks/extend-kubernetes/configure-multiple-schedulers/) 的方式
* 了解关于 [拓扑结构管理策略](/zh/docs/tasks/administer-cluster/topology-manager/)
* 了解关于 [Pod 额外开销](/zh/docs/concepts/scheduling-eviction/pod-overhead/)
content/zh/docs/concepts/scheduling-eviction/resource-bin-packing.md
+6 -2
View File
@@ -1,12 +1,16 @@
---
title: 扩展资源的资源装箱
content_type: concept
weight: 50
weight: 30
---
<!--
reviewers:
- bsalamat
- k82cn
- ahg-g
title: Resource Bin Packing for Extended Resources
content_type: concept
weight: 50
weight: 30
-->
<!-- overview -->
content/zh/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md
+15 -9
View File
@@ -78,12 +78,14 @@ had set a value of 100.
kube-scheduler 的表现等价于设置值为 100。
<!--
To change the value, edit the kube-scheduler configuration file (this is likely
to be `/etc/kubernetes/config/kube-scheduler.yaml`), then restart the scheduler.
-->
要修改这个值，编辑 kube-scheduler 的配置文件
（通常是 `/etc/kubernetes/config/kube-scheduler.yaml`），
然后重启调度器。
To change the value, edit the
[kube-scheduler configuration file](/docs/reference/config-api/kube-scheduler-config.v1beta1/)
and then restart the scheduler.
In many cases, the configuration file can be found at `/etc/kubernetes/config/kube-scheduler.yaml`.
-->
要修改这个值，编辑 [kube-scheduler 的配置文件](/zh/docs/reference/config-api/kube-scheduler-config.v1beta1/)，
之后重启调度器。
在很多场合下，配置文件位于 `/etc/kubernetes/config/kube-scheduler.yaml`。
<!--
After you have made this change, you can run
@@ -193,8 +195,8 @@ minimum value of 50 nodes.
另外，还有一个 50 个 Node 的最小值是硬编码在程序中。
<!--
{{< note >}} In clusters with less than 50 feasible nodes, the scheduler still
checks all the nodes, simply because there are not enough feasible nodes to stop
In clusters with less than 50 feasible nodes, the scheduler still
checks all the nodes because there are not enough feasible nodes to stop
the scheduler's search early.
In a small cluster, if you set a low value for `percentageOfNodesToScore`, your
@@ -203,7 +205,6 @@ change will have no or little effect, for a similar reason.
If your cluster has several hundred Nodes or fewer, leave this configuration option
at its default value. Making changes is unlikely to improve the
scheduler's performance significantly.
{{< /note >}}
-->
{{< note >}}
当集群中的可调度节点少于 50 个时，调度器仍然会去检查所有的 Node，
@@ -293,3 +294,8 @@ After going over all the Nodes, it goes back to Node 1.
-->
在评估完所有 Node 后，将会返回到 Node 1，从头开始。
## {{% heading "whatsnext" %}}
* 查阅 [kube-scheduler 配置参考 (v1beta1)](/zh/docs/reference/config-api/kube-scheduler-config.v1beta1/)
content/zh/docs/concepts/scheduling-eviction/scheduling-framework.md
+12 -13
View File
@@ -1,6 +1,4 @@
---
reviewers:
- ahg-g
title: 调度框架
content_type: concept
weight: 70
@@ -11,7 +9,7 @@ reviewers:
- ahg-g
title: Scheduling Framework
content_type: concept
weight: 60
weight: 70
-->
<!-- overview -->
@@ -19,16 +17,17 @@ weight: 60
{{< feature-state for_k8s_version="1.15" state="alpha" >}}
<!--
The scheduling framework is a plugable architecture for Kubernetes Scheduler
that makes scheduler customizations easy. It adds a new set of "plugin" APIs to
the existing scheduler. Plugins are compiled into the scheduler. The APIs
allow most scheduling features to be implemented as plugins, while keeping the
The scheduling framework is a plugable architecture for the Kubernetes Scheduler.
It adds a new set of "plugin" APIs to the existing scheduler. Plugins are compiled
into the scheduler. The APIs allow most scheduling features to be implemented as
plugins, while keeping the
scheduling "core" simple and maintainable. Refer to the [design proposal of the
scheduling framework][kep] for more technical information on the design of the
framework.
-->
调度框架是 Kubernetes Scheduler 的一种可插入架构，可以简化调度器的自定义。
它向现有的调度器增加了一组新的“插件” API。插件被编译到调度器程序中。
调度框架是 Kubernetes 调度器的一种可插入架构。
调度框架向现有的调度器增加了一组新的“插件（Plugin）” API。
插件被编译到调度器程序中。
这些 API 允许大多数调度功能以插件的形式实现，同时使调度“核心”保持简单且可维护。
请参考[调度框架的设计提案](https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/624-scheduling-framework/README.md)
获取框架设计的更多技术信息。
@@ -328,15 +327,15 @@ _Permit_ 插件在每个 Pod 调度周期的最后调用，用于防止或延迟
<!--
While any plugin can access the list of "waiting" Pods and approve them
(see [`FrameworkHandle`](#frameworkhandle)), we expect only the permit
(see [`FrameworkHandle`](https://git.k8s.io/enhancements/keps/sig-scheduling/624-scheduling-framework#frameworkhandle)), we expect only the permit
plugins to approve binding of reserved Pods that are in "waiting" state. Once a Pod
is approved, it is sent to the [PreBind](#pre-bind) phase.
-->
{{< note >}}
尽管任何插件可以访问 “等待中” 状态的 Pod 列表并批准它们
(查看 [`FrameworkHandle`](#frameworkhandle))。
我们希望只有允许插件可以批准处于 “等待中” 状态的预留 Pod 的绑定。
一旦 Pod 被批准了，它将发送到[预绑定](#pre-bind) 阶段。
（参阅 [`FrameworkHandle`](https://git.k8s.io/enhancements/keps/sig-scheduling/624-scheduling-framework#frameworkhandle)）。
我们希望只有被允许的插件可以批准处于“等待中”状态的预留 Pod 的绑定。
一旦 Pod 被批准了，它将进入到[预绑定](#pre-bind) 阶段。
{{< /note >}}
<!--
content/zh/docs/tasks/manage-gpus/scheduling-gpus.md
+1 -1
View File
@@ -54,7 +54,7 @@ When the above conditions are true, Kubernetes will expose `amd.com/gpu` or
`nvidia.com/gpu` as a schedulable resource.
You can consume these GPUs from your containers by requesting
`<vendor>.com/gpu` just like you request `cpu` or `memory`.
`<vendor>.com/gpu` the same way you request `cpu` or `memory`.
However, there are some limitations in how you specify the resource requirements
when using GPUs:
-->