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

[zh]Concept files to sync for 1.22 #29325 task 12

Browse Source
This commit is contained in:
superleo
2021-10-24 18:26:00 +08:00
parent b67a853e93
commit c5abf03306
6 changed files with 264 additions and 607 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/zh/docs/concepts/architecture/nodes.md
+247 -94
View File
@@ -204,6 +204,11 @@ To mark a Node unschedulable, run:
```shell
kubectl cordon $NODENAME
```
<!--
See [Safely Drain a Node](/docs/tasks/administer-cluster/safely-drain-node/)
for more details.
-->
更多细节参考[安全腾空节点](/zh/docs/tasks/administer-cluster/safely-drain-node/)。
<!--
Pods that are part of a {{< glossary_tooltip term_id="daemonset" >}} tolerate
@@ -279,9 +284,9 @@ The `conditions` field describes the status of all `Running` nodes. Examples of
{{< table caption = "Node conditions, and a description of when each condition applies." >}}
| Node Condition | Description |
|----------------|-------------|
| `Ready` | `True` if the node is healthy and ready to accept pods, `False` if the node is not healthy and is not accepting pods, and `Unknown` if the node controller has not heard from the node in the last `node-monitor-grace-period` (default is 40 seconds) |
| `DiskPressure` | `True` if there is insufficient free space on the node for adding new pods, otherwise `False` |
| `MemoryPressure` | `True` if pressure exists on the node memory - that is, if the node memory is low; otherwise `False` |
| `Ready` | `True` if the node is healthy and ready to accept pods, `False` if the node is not healthy and is not accepting pods, and `Unknown` if the node controller has not heard from the node in the last `node-monitor-grace-period` (default is 40 seconds) |
| `DiskPressure` | `True` if pressure exists on the disk size—that is, if the disk capacity is low; otherwise `False` |
| `MemoryPressure` | `True` if pressure exists on the node memory—that is, if the node memory is low; otherwise `False` |
| `PIDPressure` | `True` if pressure exists on the processes - that is, if there are too many processes on the node; otherwise `False` |
| `NetworkUnavailable` | `True` if the network for the node is not correctly configured, otherwise `False` |
{{< /table >}}
@@ -290,7 +295,7 @@ The `conditions` field describes the status of all `Running` nodes. Examples of
| 节点状况 | 描述 |
|----------------|-------------|
| `Ready` | 如节点是健康的并已经准备好接收 Pod 则为 `True`；`False` 表示节点不健康而且不能接收 Pod；`Unknown` 表示节点控制器在最近 `node-monitor-grace-period` 期间（默认 40 秒）没有收到节点的消息 |
| `DiskPressure` | `True` 表示节点的空闲空间不足以用于添加新 Pod, 否则为 `False` |
| `DiskPressure` | `True` 表示节点存在磁盘空间压力，即磁盘可用量低, 否则为 `False` |
| `MemoryPressure` | `True` 表示节点存在内存压力，即节点内存可用量低，否则为 `False` |
| `PIDPressure` | `True` 表示节点存在进程压力，即节点上进程过多；否则为 `False` |
| `NetworkUnavailable` | `True` 表示节点网络配置不正确；否则为 `False` |
@@ -308,9 +313,11 @@ Condition，被保护起来的节点在其规约中被标记为不可调度（Un
{{< /note >}}
<!--
The node condition is represented as a JSON object. For example, the following response describes a healthy node.
In the Kubernetes API, a node's condition is represented as part of the `.status`
of the Node resource. For example, the following JSON structure describes a healthy node:
-->
节点条件使用 JSON 对象表示。例如，下面的响应描述了一个健康的节点。
在 Kubernetes API 中，节点的状况表示节点资源中`.status` 的一部分。
例如，以下 JSON 结构描述了一个健康节点：
```json
"conditions": [
@@ -326,11 +333,23 @@ The node condition is represented as a JSON object. For example, the following r
```
<!--
If the Status of the Ready condition remains `Unknown` or `False` for longer than the `pod-eviction-timeout`, an argument is passed to the {{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}}), all the Pods on the node are scheduled for deletion by the Node Controller. The default eviction timeout duration is **five minutes**. In some cases when the node is unreachable, the apiserver is unable to communicate with the kubelet on the node. The decision to delete the pods cannot be communicated to the kubelet until communication with the API server is re-established. In the meantime, the pods that are scheduled for deletion may continue to run on the partitioned node.
If the `status` of the Ready condition remains `Unknown` or `False` for longer
than the `pod-eviction-timeout` (an argument passed to the
{{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager"
>}}), then the [node controller](#node-controller) triggers
{{< glossary_tooltip text="API-initiated eviction" term_id="api-eviction" >}}
for all Pods assigned to that node. The default eviction timeout duration is
**five minutes**.
In some cases when the node is unreachable, the API server is unable to communicate
with the kubelet on the node. The decision to delete the pods cannot be communicated to
the kubelet until communication with the API server is re-established. In the meantime,
the pods that are scheduled for deletion may continue to run on the partitioned node.
-->
如果 Ready 条件处于 `Unknown` 或者 `False` 状态的时间超过了 `pod-eviction-timeout` 值，
如果 Ready 条件的 `status` 处于 `Unknown` 或者 `False` 状态的时间超过了 `pod-eviction-timeout` 值，
（一个传递给 {{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}} 的参数），
节点上的所有 Pod 都会被节点控制器计划删除。默认的逐出超时时长为 **5 分钟**。
[节点控制器](#node-controller) 会对节点上的所有 Pod 触发
{{< glossary_tooltip text="API-发起的驱逐" term_id="api-eviction" >}}。
默认的逐出超时时长为 **5 分钟**。
某些情况下，当节点不可达时，API 服务器不能和其上的 kubelet 通信。
删除 Pod 的决定不能传达给 kubelet，直到它重新建立和 API 服务器的连接为止。
与此同时，被计划删除的 Pod 可能会继续在游离的节点上运行。
@@ -389,17 +408,74 @@ to [reserve compute resources](/docs/tasks/administer-cluster/reserve-compute-re
<!--
### Info
Describes general information about the node, such as kernel version, Kubernetes version (kubelet and kube-proxy version), Docker version (if used), and OS name.
This information is gathered by Kubelet from the node.
Describes general information about the node, such as kernel version, Kubernetes
version (kubelet and kube-proxy version), container runtime details, and which
operating system the node uses.
The kubelet gathers this information from the node and publishes it into
the Kubernetes API.
-->
### 信息 {#info}
关于节点的一般性信息，例如内核版本、Kubernetes 版本（`kubelet` 和 `kube-proxy` 版本）、
Docker 版本（如果使用了）和操作系统名称。这些信息由 `kubelet` 从节点上搜集而来。
描述节点的一般信息，如内核版本、Kubernetes 版本（`kubelet` 和 `kube-proxy` 版本）、
容器运行时详细信息，以及 节点使用的操作系统。
`kubelet` 从节点收集这些信息并将其发布到 Kubernetes API。
<!--
### Node Controller
## Heartbeats
Heartbeats, sent by Kubernetes nodes, help your cluster determine the
availability of each node, and to take action when failures are detected.
For nodes there are two forms of heartbeats:
* updates to the `.status` of a Node
* [Lease](/docs/reference/kubernetes-api/cluster-resources/lease-v1/) objects
within the `kube-node-lease`
{{< glossary_tooltip term_id="namespace" text="namespace">}}.
Each Node has an associated Lease object.
Compared to updates to `.status` of a Node, a Lease is a lightweight resource.
Using Leases for heartbeats reduces the performance impact of these updates
for large clusters.
The kubelet is responsible for creating and updating the `.status` of Nodes,
and for updating their related Leases.
- The kubelet updates the node's `.status` either when there is change in status
or if there has been no update for a configured interval. The default interval
for `.status` updates to Nodes is 5 minutes, which is much longer than the 40
second default timeout for unreachable nodes.
- The kubelet creates and then updates its Lease object every 10 seconds
(the default update interval). Lease updates occur independently from
updates to the Node's `.status`. If the Lease update fails, the kubelet retries,
using exponential backoff that starts at 200 milliseconds and capped at 7 seconds.
-->
## 心跳 {#heartbeats}
Kubernetes 节点发送的心跳帮助你的集群确定每个节点的可用性，并在检测到故障时采取行动。
对于节点，有两种形式的心跳:
* 更新节点的 `.status`
* [Lease](/docs/reference/kubernetes-api/cluster-resources/lease-v1/) 对象
在 `kube-node-lease` {{<glossary_tooltip term_id="namespace" text="命名空间">}}中。
每个节点都有一个关联的 Lease 对象。
与 Node 的 `.status` 更新相比，`Lease` 是一种轻量级资源。
使用 `Leases` 心跳在大型集群中可以减少这些更新对性能的影响。
kubelet 负责创建和更新节点的 `.status`，以及更新它们对应的 `Lease`。
- 当状态发生变化时，或者在配置的时间间隔内没有更新事件时，kubelet 会更新 `.status`。
`.status` 更新的默认间隔为 5 分钟（比不可达节点的 40 秒默认超时时间长很多）。
- `kubelet` 会每 10 秒（默认更新间隔时间）创建并更新其 `Lease` 对象。
`Lease` 更新独立于 `NodeStatus` 更新而发生。
如果 `Lease` 的更新操作失败，`kubelet` 会采用指数回退机制，从 200 毫秒开始
重试，最长重试间隔为 7 秒钟。
<!--
## Node Controller
The node {{< glossary_tooltip text="controller" term_id="controller" >}} is a
Kubernetes control plane component that manages various aspects of nodes.
@@ -407,7 +483,7 @@ Kubernetes control plane component that manages various aspects of nodes.
The node controller has multiple roles in a node's life. The first is assigning a
CIDR block to the node when it is registered (if CIDR assignment is turned on).
-->
### 节点控制器 {#node-controller}
## 节点控制器 {#node-controller}
节点{{< glossary_tooltip text="控制器" term_id="controller" >}}是
Kubernetes 控制面组件，管理节点的方方面面。
@@ -428,74 +504,35 @@ controller deletes the node from its list of nodes.
<!--
The third is monitoring the nodes' health. The node controller is
responsible for updating the NodeReady condition of NodeStatus to
ConditionUnknown when a node becomes unreachable (i.e. the node controller stops
receiving heartbeats for some reason, e.g. due to the node being down), and then later evicting
all the pods from the node (using graceful termination) if the node continues
to be unreachable. (The default timeouts are 40s to start reporting
ConditionUnknown and 5m after that to start evicting pods.)
responsible for:
- In the case that a node becomes unreachable, updating the NodeReady condition
of within the Node's `.status`. In this case the node controller sets the
NodeReady condition to `ConditionUnknown`.
- If a node remains unreachable: triggering
[API-initiated eviction](/docs/concepts/scheduling-eviction/api-eviction/)
for all of the Pods on the unreachable node. By default, the node controller
waits 5 minutes between marking the node as `ConditionUnknown` and submitting
the first eviction request.
The node controller checks the state of each node every `-node-monitor-period` seconds.
-->
第三个是监控节点的健康情况。节点控制器负责在节点不可达
（即，节点控制器因为某些原因没有收到心跳，例如节点宕机）时，
将节点状态的 `NodeReady` 状况更新为 "`Unknown`"。
如果节点接下来持续处于不可达状态，节点控制器将逐出节点上的所有 Pod（使用体面终止）。
默认情况下 40 秒后开始报告 "`Unknown`"，在那之后 5 分钟开始逐出 Pod。
第三个是监控节点的健康状况。 节点控制器是负责：
- 在节点节点不可达的情况下，在 Node 的 `.status` 中更新 `NodeReady` 状况。
在这种情况下，节点控制器将 `NodeReady` 状况更新为 `ConditionUnknown` 。
- 如果节点仍然无法访问：对于不可达节点上的所有 Pod触发
[API-发起的逐出](/zh/docs/concepts/scheduling-eviction/api-eviction/)。
默认情况下，节点控制器 在将节点标记为 `ConditionUnknown` 后等待 5 分钟 提交第一个驱逐请求。
节点控制器每隔 `--node-monitor-period` 秒检查每个节点的状态。
<!--
#### Heartbeats
Heartbeats, sent by Kubernetes nodes, help determine the availability of a node.
There are two forms of heartbeats: updates of `NodeStatus` and the
[Lease object](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/#lease-v1-coordination-k8s-io).
Each Node has an associated Lease object in the `kube-node-lease`
{{< glossary_tooltip term_id="namespace" text="namespace">}}.
Lease is a lightweight resource, which improves the performance
of the node heartbeats as the cluster scales.
-->
#### 心跳机制 {#heartbeats}
Kubernetes 节点发送的心跳（Heartbeats）有助于确定节点的可用性。
心跳有两种形式：`NodeStatus` 和 [`Lease` 对象](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#lease-v1-coordination-k8s-io)。
每个节点在 `kube-node-lease`{{< glossary_tooltip term_id="namespace" text="名字空间">}}
中都有一个与之关联的 `Lease` 对象。
`Lease` 是一种轻量级的资源，可在集群规模扩大时提高节点心跳机制的性能。
<!--
The kubelet is responsible for creating and updating the `NodeStatus` and
a Lease object.
-->
`kubelet` 负责创建和更新 `NodeStatus` 和 `Lease` 对象。
<!--
- The kubelet updates the `NodeStatus` either when there is change in status,
or if there has been no update for a configured interval. The default interval
for `NodeStatus` updates is 5 minutes (much longer than the 40 second default
timeout for unreachable nodes).
- The kubelet creates and then updates its Lease object every 10 seconds
(the default update interval). Lease updates occur independently from the
`NodeStatus` updates. If the Lease update fails, the kubelet retries with
exponential backoff starting at 200 milliseconds and capped at 7 seconds.
-->
- 当状态发生变化时，或者在配置的时间间隔内没有更新事件时，kubelet 会更新 `NodeStatus`。
`NodeStatus` 更新的默认间隔为 5 分钟（比不可达节点的 40 秒默认超时时间长很多）。
- `kubelet` 会每 10 秒（默认更新间隔时间）创建并更新其 `Lease` 对象。
`Lease` 更新独立于 `NodeStatus` 更新而发生。
如果 `Lease` 的更新操作失败，`kubelet` 会采用指数回退机制，从 200 毫秒开始
重试，最长重试间隔为 7 秒钟。
<!--
#### Reliability
### Rate limits on eviction
In most cases, the node controller limits the eviction rate to
`-node-eviction-rate` (default 0.1) per second, meaning it won't evict pods
from more than 1 node per 10 seconds.
-->
#### 可靠性 {#reliability}
### 逐出速率限制 {#rate-limits-on-eviction}
大部分情况下，节点控制器把逐出速率限制在每秒 `--node-eviction-rate` 个（默认为 0.1）。
这表示它每 10 秒钟内至多从一个节点驱逐 Pod。
@@ -503,25 +540,28 @@ from more than 1 node per 10 seconds.
<!--
The node eviction behavior changes when a node in a given availability zone
becomes unhealthy. The node controller checks what percentage of nodes in the zone
are unhealthy (NodeReady condition is ConditionUnknown or ConditionFalse) at
the same time. If the fraction of unhealthy nodes is at least
`-unhealthy-zone-threshold` (default 0.55) then the eviction rate is reduced:
if the cluster is small (i.e. has less than or equal to
`-large-cluster-size-threshold` nodes - default 50) then evictions are
stopped, otherwise the eviction rate is reduced to
`-secondary-node-eviction-rate` (default 0.01) per second.
are unhealthy (NodeReady condition is `ConditionUnknown` or `ConditionFalse`) at
the same time:
- If the fraction of unhealthy nodes is at least `--unhealthy-zone-threshold`
(default 0.55), then the eviction rate is reduced.
- If the cluster is small (i.e. has less than or equal to
`--large-cluster-size-threshold` nodes - default 50), then evictions are stopped.
- Otherwise, the eviction rate is reduced to `--secondary-node-eviction-rate`
(default 0.01) per second.
The reason these policies are implemented per availability zone is because one availability zone
might become partitioned from the master while the others remain connected. If
your cluster does not span multiple cloud provider availability zones, then
there is only one availability zone (the whole cluster).
The reason these policies are implemented per availability zone is because one
availability zone might become partitioned from the master while the others remain
connected. If your cluster does not span multiple cloud provider availability zones,
then the eviction mechanism does not take per-zone unavailability into account.
-->
当一个可用区域（Availability Zone）中的节点变为不健康时，节点的驱逐行为将发生改变。
节点控制器会同时检查可用区域中不健康（NodeReady 状况为 Unknown 或 False）
的节点的百分比。如果不健康节点的比例超过 `--unhealthy-zone-threshold` （默认为 0.55），
驱逐速率将会降低：如果集群较小（意即小于等于 `--large-cluster-size-threshold`
个节点 - 默认为 50），驱逐操作将会停止，否则驱逐速率将降为每秒
`--secondary-node-eviction-rate` 个（默认为 0.01）。
节点控制器会同时检查可用区域中不健康（NodeReady 状况为 `ConditionUnknown` 或 `ConditionFalse`）
的节点的百分比：
- 如果不健康节点的比例超过 `--unhealthy-zone-threshold` （默认为 0.55），
驱逐速率将会降低。
- 如果集群较小（意即小于等于 `--large-cluster-size-threshold`
个节点 - 默认为 50），驱逐操作将会停止。
- 否则驱逐速率将降为每秒 `--secondary-node-eviction-rate` 个（默认为 0.01）。
在单个可用区域实施这些策略的原因是当一个可用区域可能从控制面脱离时其它可用区域
可能仍然保持连接。
@@ -532,17 +572,19 @@ A key reason for spreading your nodes across availability zones is so that the
workload can be shifted to healthy zones when one entire zone goes down.
Therefore, if all nodes in a zone are unhealthy then node controller evicts at
the normal rate `-node-eviction-rate`. The corner case is when all zones are
completely unhealthy (i.e. there are no healthy nodes in the cluster). In such
case, the node controller assumes that there's some problem with master
connectivity and stops all evictions until some connectivity is restored.
completely unhealthy (none of the nodes in the cluster are healthy). In such a
case, the node controller assumes that there is some problem with connectivity
between the control plane and the nodes, and doesn't perform any evictions.
(If there has been an outage and some nodes reappear, the node controller does
evict pods from the remaining nodes that are unhealthy or unreachable).
-->
跨多个可用区域部署你的节点的一个关键原因是当某个可用区域整体出现故障时，
工作负载可以转移到健康的可用区域。
因此，如果一个可用区域中的所有节点都不健康时，节点控制器会以正常的速率
`--node-eviction-rate` 进行驱逐操作。
在所有的可用区域都不健康（也即集群中没有健康节点）的极端情况下，
节点控制器将假设控制面节点的连接出了某些问题，
它将停止所有驱逐动作直到一些连接恢复。
节点控制器将假设控制面与节点间的连接出了某些问题，它将停止所有驱逐动作（如果故障后部分节点重新连接，
节点控制器会从剩下不健康或者不可达节点中驱逐 `pods`）。
<!--
The Node Controller is also responsible for evicting pods running on nodes with
@@ -558,7 +600,7 @@ that the scheduler won't place Pods onto unhealthy nodes.
这意味着调度器不会将 Pod 调度到不健康的节点上。
<!--
### Node capacity
## Resource capacity tracking {#node-capacity}
Node objects track information about the Node's resource capacity (for example: the amount
of memory available, and the number of CPUs).
@@ -566,7 +608,7 @@ Nodes that [self register](#self-registration-of-nodes) report their capacity du
registration. If you [manually](#manual-node-administration) add a Node, then
you need to set the node's capacity information when you add it.
-->
### 节点容量 {#node-capacity}
### 资源容量跟踪 {#node-capacity}
Node 对象会跟踪节点上资源的容量（例如可用内存和 CPU 数量）。
通过[自注册](#self-registration-of-nodes)机制生成的 Node 对象会在注册期间报告自身容量。
@@ -701,6 +743,117 @@ reserved for terminating [critical pods](/docs/tasks/administer-cluster/guarante
而保留最后 10 秒用于终止
[关键 Pod](/zh/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)。
<!--
When pods were evicted during the graceful node shutdown, they are marked as failed.
Running `kubectl get pods` shows the status of the the evicted pods as `Shutdown`.
And `kubectl describe pod` indicates that the pod was evicted because of node shutdown:
```
Status: Failed
Reason: Shutdown
Message: Node is shutting, evicting pods
```
Failed pod objects will be preserved until explicitly deleted or [cleaned up by the GC](/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection).
This is a change of behavior compared to abrupt node termination.
-->
{{< note >}}
当 Pod 在正常节点关闭期间被驱逐时，它们会被标记为 `failed`。
运行 `kubectl get pods` 将被驱逐的 pod 的状态显示为 `Shutdown`。
并且 `kubectl describe pod` 表示 pod 因节点关闭而被驱逐：
```
Status: Failed
Reason: Shutdown
Message: Node is shutting, evicting pods
```
`Failed` 的 pod 对象将被保留，直到被明确删除或
[由 GC 清理](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection)。
与突然的节点终止相比这是一种行为变化。
{{< /note >}}
<!--
## Swap memory management {#swap-memory}
{{< feature-state state="alpha" for_k8s_version="v1.22" >}}
Prior to Kubernetes 1.22, nodes did not support the use of swap memory, and a
kubelet would by default fail to start if swap was detected on a node. In 1.22
onwards, swap memory support can be enabled on a per-node basis.
To enable swap on a node, the `NodeSwap` feature gate must be enabled on
the kubelet, and the `--fail-swap-on` command line flag or `failSwapOn`
[configuration setting](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)
must be set to false.
A user can also optionally configure `memorySwap.swapBehavior` in order to
specify how a node will use swap memory. For example,
-->
## 交换内存管理 {#swap-memory}
{{< feature-state state="alpha" for_k8s_version="v1.22" >}}
在 Kubernetes 1.22 之前，节点不支持使用交换内存，并且
默认情况下，如果在节点上检测到交换内存配置，kubelet 将无法启动。 在 1.22
以后，可以在每个节点的基础上启用交换内存支持。
要在节点上启用交换内存，必须启用kubelet 的 `NodeSwap` 特性门控，
同时使用 `--fail-swap-on` 命令行参数或者将 `failSwapOn`
[配置](/zh/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)
设置为false。
用户还可以选择配置 `memorySwap.swapBehavior` 以指定节点使用交换内存的方式。 例如:
```yaml
memorySwap:
swapBehavior: LimitedSwap
```
<!--
The available configuration options for `swapBehavior` are:
- `LimitedSwap`: Kubernetes workloads are limited in how much swap they can
use. Workloads on the node not managed by Kubernetes can still swap.
- `UnlimitedSwap`: Kubernetes workloads can use as much swap memory as they
request, up to the system limit.
If configuration for `memorySwap` is not specified and the feature gate is
enabled, by default the kubelet will apply the same behaviour as the
`LimitedSwap` setting.
The behaviour of the `LimitedSwap` setting depends if the node is running with
v1 or v2 of control groups (also known as "cgroups"):
- **cgroupsv1:** Kubernetes workloads can use any combination of memory and
swap, up to the pod's memory limit, if set.
- **cgroupsv2:** Kubernetes workloads cannot use swap memory.
For more information, and to assist with testing and provide feedback, please
see [KEP-2400](https://github.com/kubernetes/enhancements/issues/2400) and its
[design proposal](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/2400-node-swap/README.md).
-->
已有的 `swapBehavior` 的配置选项有：
- `LimitedSwap`：Kubernetes 工作负载的交换内存会受限制。
不受 Kubernetes 管理的节点上的工作负载仍然可以交换。
- `UnlimitedSwap`：Kubernetes 工作负载可以使用尽可能多的交换内存
请求，一直到系统限制。
如果启用了特性门控但是未指定 `memorySwap` 的配置，默认情况下 kubelet 将使用
`LimitedSwap` 设置。
`LimitedSwap` 设置的行为还取决于节点运行的是 v1 还是 v2 的控制组（也就是 `cgroups`）：
- **cgroupsv1:** Kubernetes 工作负载可以使用内存和
交换，达到 pod 的内存限制（如果设置）。
- **cgroupsv2:** Kubernetes 工作负载不能使用交换内存。
如需更多信息以及协助测试和提供反馈，请
参见 [KEP-2400](https://github.com/kubernetes/enhancements/issues/2400) 及其
[设计方案](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/2400-node-swap/README.md)。
## {{% heading "whatsnext" %}}
<!--