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

[zh] Tidy up and fix links in tasks section (6/10)

Browse Source
This commit is contained in:
Qiming Teng
2020-08-14 15:14:21 +08:00
parent fcd8af988c
commit 2c8a55a6e6
8 changed files with 689 additions and 650 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/zh/docs/tasks/administer-cluster/out-of-resource.md
+186 -138
View File
@@ -1,20 +1,14 @@
---
reviewers:
- derekwaynecarr
- vishh
- timstclair
title: 配置资源不足时的处理方式
content_type: concept
---
<!--
---
reviewers:
- derekwaynecarr
- vishh
- timstclair
title: Configure Out Of Resource Handling
content_type: concept
---
-->
<!-- overview -->
@@ -27,13 +21,11 @@ are low. This is especially important when dealing with incompressible
compute resources, such as memory or disk space. If such resources are exhausted,
nodes become unstable.
-->
本页介绍如何使用 `kubelet` 配置资源不足时的处理方式。
本页介绍了如何使用`kubelet`配置资源不足时的处理方式。
当可用计算资源较少时，`kubelet`需要保证节点稳定性。这在处理如内存和硬盘之类的不可压缩资源时尤为重要。如果任意一种资源耗尽，节点将会变得不稳定。
当可用计算资源较少时，`kubelet`需要保证节点稳定性。
这在处理如内存和硬盘之类的不可压缩资源时尤为重要。
如果任意一种资源耗尽，节点将会变得不稳定。
<!-- body -->
@@ -47,11 +39,12 @@ a Pod, it terminates all of its containers and transitions its `PodPhase` to `Fa
If the evicted Pod is managed by a Deployment, the Deployment will create another Pod
to be scheduled by Kubernetes.
-->
## 驱逐策略
`kubelet` 能够主动监测和防止计算资源的全面短缺。在那种情况下，`kubelet`可以主动地结束一个或多个 pod 以回收短缺的资源。当 `kubelet` 结束一个 pod 时，它将终止 pod 中的所有容器，而 pod 的 `PodPhase` 将变为 `Failed`。
`kubelet` 能够主动监测和防止计算资源的全面短缺。
在那种情况下，`kubelet` 可以主动地结束一个或多个 Pod 以回收短缺的资源。
当 `kubelet` 结束一个 Pod 时，它将终止 Pod 中的所有容器，而 Pod 的 `PodPhase` 将变为 `Failed`。
如果被驱逐的 Pod 由 Deployment 管理，这个 Deployment 会创建另一个 Pod 给 Kubernetes 来调度。
@@ -61,7 +54,13 @@ to be scheduled by Kubernetes.
The `kubelet` supports eviction decisions based on the signals described in the following
table. The value of each signal is described in the Description column, which is based on
the `kubelet` summary API.
-->
### 驱逐信号
`kubelet` 支持按照以下表格中描述的信号触发驱逐决定。
每个信号的值在 description 列描述，基于 `kubelet` 摘要 API。
<!--
| Eviction Signal | Description |
|----------------------------|-----------------------------------------------------------------------|
| `memory.available` | `memory.available` := `node.status.capacity[memory]` - `node.stats.memory.workingSet` |
@@ -69,11 +68,23 @@ the `kubelet` summary API.
| `nodefs.inodesFree` | `nodefs.inodesFree` := `node.stats.fs.inodesFree` |
| `imagefs.available` | `imagefs.available` := `node.stats.runtime.imagefs.available` |
| `imagefs.inodesFree` | `imagefs.inodesFree` := `node.stats.runtime.imagefs.inodesFree` |
-->
| 驱逐信号 | 描述 |
|----------------------------|-----------------------------------------------------------------------|
| `memory.available` | `memory.available` := `node.status.capacity[memory]` - `node.stats.memory.workingSet` |
| `nodefs.available` | `nodefs.available` := `node.stats.fs.available` |
| `nodefs.inodesFree` | `nodefs.inodesFree` := `node.stats.fs.inodesFree` |
| `imagefs.available` | `imagefs.available` := `node.stats.runtime.imagefs.available` |
| `imagefs.inodesFree` | `imagefs.inodesFree` := `node.stats.runtime.imagefs.inodesFree` |
<!--
Each of the above signals supports either a literal or percentage based value.
The percentage based value is calculated relative to the total capacity
associated with each signal.
-->
上面的每个信号都支持字面值或百分比的值。基于百分比的值的计算与每个信号对应的总容量相关。
<!--
The value for `memory.available` is derived from the cgroupfs instead of tools
like `free -m`. This is important because `free -m` does not work in a
container, and if users use the [node
@@ -85,13 +96,30 @@ reproduces the same set of steps that the `kubelet` performs to calculate
`memory.available`. The `kubelet` excludes inactive_file (i.e. # of bytes of
file-backed memory on inactive LRU list) from its calculation as it assumes that
memory is reclaimable under pressure.
-->
`memory.available` 的值从 cgroupfs 获取，而不是通过类似 `free -m` 的工具。
这很重要，因为 `free -m` 不能在容器中工作，并且如果用户使用了
[节点可分配资源](/zh/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)
特性，资源不足的判定将同时在本地 cgroup 层次结构的终端用户 Pod 部分和根节点做出。
这个[脚本](/zh/docs/tasks/administer-cluster/out-of-resource/memory-available.sh)
复现了与 `kubelet` 计算 `memory.available` 相同的步骤。
`kubelet` 将 `inactive_file`（意即活动 LRU 列表上基于文件后端的内存字节数）从计算中排除，
因为它假设内存在出现压力时将被回收。
<!--
`kubelet` supports only two filesystem partitions.
1. The `nodefs` filesystem that kubelet uses for volumes, daemon logs, etc.
2. The `imagefs` filesystem that container runtimes uses for storing images and
container writable layers.
-->
`kubelet` 只支持两种文件系统分区。
1. `nodefs` 文件系统，kubelet 将其用于卷和守护程序日志等。
2. `imagefs` 文件系统，容器运行时用于保存镜像和容器可写层。
<!--
`imagefs` is optional. `kubelet` auto-discovers these filesystems using
cAdvisor. `kubelet` does not care about any other filesystems. Any other types
of configurations are not currently supported by the kubelet. For example, it is
@@ -101,30 +129,13 @@ In future releases, the `kubelet` will deprecate the existing [garbage
collection](/docs/concepts/cluster-administration/kubelet-garbage-collection/)
support in favor of eviction in response to disk pressure.
-->
### 驱逐信号
`imagefs` 可选。`kubelet` 使用 cAdvisor 自动发现这些文件系统。
`kubelet` 不关心其它文件系统。当前不支持配置任何其它类型。
例如，在专用 `filesytem` 中存储卷和日志是不可以的。
`kubelet` 支持按照以下表格中描述的信号触发驱逐决定。每个信号的值在 description 列描述，基于 `kubelet` 摘要 API。
| 驱逐信号 | 描述 |
|----------------------------|-----------------------------------------------------------------------|
| `memory.available` | `memory.available` := `node.status.capacity[memory]` - `node.stats.memory.workingSet` |
| `nodefs.available` | `nodefs.available` := `node.stats.fs.available` |
| `nodefs.inodesFree` | `nodefs.inodesFree` := `node.stats.fs.inodesFree` |
| `imagefs.available` | `imagefs.available` := `node.stats.runtime.imagefs.available` |
| `imagefs.inodesFree` | `imagefs.inodesFree` := `node.stats.runtime.imagefs.inodesFree` |
上面的每个信号都支持字面值或百分比的值。基于百分比的值的计算与每个信号对应的总容量相关。
`memory.available` 的值从 cgroupfs 获取，而不是通过类似 `free -m` 的工具。这很重要，因为 `free -m` 不能在容器中工作，并且如果用户使用了 [可分配节点](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)特性，资源不足的判定将同时在本地 cgroup 层次结构的终端用户 pod 部分和根节点做出。这个 [脚本](/docs/tasks/administer-cluster/out-of-resource/memory-available.sh)复现了与 `kubelet` 计算 `memory.available` 相同的步骤。`kubelet`将`inactive_file`（意即活动 LRU 列表上基于文件后端的内存字节数）从计算中排除，因为它假设内存在出现压力时将被回收。
`kubelet` 只支持两种文件系统分区。
1. `nodefs` 文件系统，kubelet 将其用于卷和守护程序日志等。
2. `imagefs` 文件系统，容器运行时用于保存镜像和容器可写层。
`imagefs`可选。`kubelet`使用 cAdvisor 自动发现这些文件系统。`kubelet`不关心其它文件系统。当前不支持配置任何其它类型。例如，在专用`文件系统`中存储卷和日志是不可以的。
在将来的发布中，`kubelet`将废除当前存在的 [垃圾回收](/docs/concepts/cluster-administration/kubelet-garbage-collection/) 机制，这种机制目前支持将驱逐操作作为对磁盘压力的响应。
在将来的发布中，`kubelet`将废除当前存在的
[垃圾回收](/zh/docs/concepts/cluster-administration/kubelet-garbage-collection/)
机制，这种机制目前支持将驱逐操作作为对磁盘压力的响应。
<!--
### Eviction Thresholds
@@ -157,9 +168,11 @@ either `memory.available<10%` or `memory.available<1Gi`. You cannot use both.
* 合法的 `eviction-signal` 标志如上所示。
* `operator` 是所需的关系运算符，例如 `<`。
* `quantity` 是驱逐阈值值标志，例如 `1Gi`。合法的标志必须匹配 Kubernetes 使用的数量表示。驱逐阈值也可以使用 `%` 标记表示百分比。
* `quantity` 是驱逐阈值值标志，例如 `1Gi`。合法的标志必须匹配 Kubernetes 使用的数量表示。
驱逐阈值也可以使用 `%` 标记表示百分比。
举例说明，如果一个节点有 `10Gi` 内存，希望在可用内存下降到 `1Gi` 以下时引起驱逐操作，则驱逐阈值可以使用下面任意一种方式指定（但不是两者同时）。
举例说明，如果一个节点有 `10Gi` 内存，希望在可用内存下降到 `1Gi` 以下时引起驱逐操作，
则驱逐阈值可以使用下面任意一种方式指定（但不是两者同时）。
* `memory.available<10%`
* `memory.available<1Gi`
@@ -172,14 +185,25 @@ administrator-specified grace period. No action is taken by the `kubelet`
to reclaim resources associated with the eviction signal until that grace
period has been exceeded. If no grace period is provided, the `kubelet`
returns an error on startup.
-->
#### 软驱逐阈值
软驱逐阈值使用一对由驱逐阈值和管理员必须指定的宽限期组成的配置对。在超过宽限期前，`kubelet`不会采取任何动作回收和驱逐信号关联的资源。如果没有提供宽限期，`kubelet`启动时将报错。
<!--
In addition, if a soft eviction threshold has been met, an operator can
specify a maximum allowed Pod termination grace period to use when evicting
pods from the node. If specified, the `kubelet` uses the lesser value among
the `pod.Spec.TerminationGracePeriodSeconds` and the max allowed grace period.
If not specified, the `kubelet` kills Pods immediately with no graceful
termination.
-->
此外，如果达到了软驱逐阈值，操作员可以指定从节点驱逐 pod 时，在宽限期内允许结束的 pod 的最大数量。
如果指定了 `pod.Spec.TerminationGracePeriodSeconds` 值，
`kubelet` 将使用它和宽限期二者中较小的一个。
如果没有指定，`kubelet`将立即终止 pod，而不会优雅结束它们。
<!--
To configure soft eviction thresholds, the following flags are supported:
* `eviction-soft` describes a set of eviction thresholds (e.g. `memory.available<1.5Gi`) that if met over a
@@ -189,12 +213,6 @@ correspond to how long a soft eviction threshold must hold before triggering a P
* `eviction-max-pod-grace-period` describes the maximum allowed grace period (in seconds) to use when terminating
pods in response to a soft eviction threshold being met.
-->
#### 软驱逐阈值
软驱逐阈值使用一对由驱逐阈值和管理员必须指定的宽限期组成的配置对。在超过宽限期前，`kubelet`不会采取任何动作回收和驱逐信号关联的资源。如果没有提供宽限期，`kubelet`启动时将报错。
此外，如果达到了软驱逐阈值，操作员可以指定从节点驱逐 pod 时，在宽限期内允许结束的 pod 的最大数量。如果指定了 `pod.Spec.TerminationGracePeriodSeconds` 值，`kubelet`将使用它和宽限期二者中较小的一个。如果没有指定，`kubelet`将立即终止 pod，而不会优雅结束它们。
软驱逐阈值的配置支持下列标记：
* `eviction-soft` 描述了驱逐阈值的集合（例如 `memory.available<1.5Gi`），如果在宽限期之外满足条件将触发 pod 驱逐。
@@ -223,7 +241,8 @@ The `kubelet` has the following default hard eviction threshold:
-->
#### 硬驱逐阈值
硬驱逐阈值没有宽限期，一旦察觉，`kubelet`将立即采取行动回收关联的短缺资源。如果满足硬驱逐阈值，`kubelet`将立即结束 pod 而不是优雅终止。
硬驱逐阈值没有宽限期，一旦察觉，`kubelet`将立即采取行动回收关联的短缺资源。
如果满足硬驱逐阈值，`kubelet`将立即结束 pod 而不是优雅终止。
硬驱逐阈值的配置支持下列标记：
@@ -257,7 +276,14 @@ The `kubelet` maps one or more eviction signals to a corresponding node conditio
If a hard eviction threshold has been met, or a soft eviction threshold has been met
independent of its associated grace period, the `kubelet` reports a condition that
reflects the node is under pressure.
-->
### 节点状态
`kubelet` 会将一个或多个驱逐信号映射到对应的节点状态。
如果满足硬驱逐阈值，或者满足独立于其关联宽限期的软驱逐阈值时，`kubelet`将报告节点处于压力下的状态。
<!--
The following node conditions are defined that correspond to the specified eviction signal.
| Node Condition | Eviction Signal | Description |
@@ -268,18 +294,12 @@ The following node conditions are defined that correspond to the specified evict
The `kubelet` continues to report node status updates at the frequency specified by
`--node-status-update-frequency` which defaults to `10s`.
-->
### 节点状态
`kubelet` 会将一个或多个驱逐信号映射到对应的节点状态。
如果满足硬驱逐阈值，或者满足独立于其关联宽限期的软驱逐阈值时，`kubelet`将报告节点处于压力下的状态。
下列节点状态根据相应的驱逐信号定义。
| 节点状态 | 驱逐信号 | 描述 |
|-------------------------|-------------------------------|--------------------------------------------|
| `MemoryPressure` | `memory.available` | Available memory on the node has satisfied an eviction threshold |
| `DiskPressure` | `nodefs.available`, `nodefs.inodesFree`, `imagefs.available`, or `imagefs.inodesFree` | Available disk space and inodes on either the node's root filesystem or image filesystem has satisfied an eviction threshold |
| `MemoryPressure` | `memory.available` | 节点上可用内存量达到逐出阈值 |
| `DiskPressure` | `nodefs.available`, `nodefs.inodesFree`, `imagefs.available`, 或 `imagefs.inodesFree` | 节点或者节点的根文件系统或镜像文件系统上可用磁盘空间和 i 节点个数达到逐出阈值 |
`kubelet` 将以 `--node-status-update-frequency` 指定的频率连续报告节点状态更新，其默认值为 `10s`。
@@ -303,7 +323,8 @@ condition back to `false`.
-->
### 节点状态振荡
如果节点在软驱逐阈值的上下振荡，但没有超过关联的宽限期时，将引起对应节点的状态持续在 true 和 false 间跳变，并导致不好的调度结果。
如果节点在软驱逐阈值的上下振荡，但没有超过关联的宽限期时，将引起对应节点的状态持续在
true 和 false 间跳变，并导致不好的调度结果。
为了防止这种振荡，可以定义下面的标志，用于控制 `kubelet` 从压力状态中退出之前必须等待的时间。
@@ -326,7 +347,8 @@ machine has a dedicated `imagefs` configured for the container runtime.
如果满足驱逐阈值并超过了宽限期，`kubelet`将启动回收压力资源的过程，直到它发现低于设定阈值的信号为止。
`kubelet`将尝试在驱逐终端用户 pod 前回收节点层级资源。发现磁盘压力时，如果节点针对容器运行时配置有独占的 `imagefs`，`kubelet`回收节点层级资源的方式将会不同。
`kubelet` 将尝试在驱逐终端用户 pod 前回收节点层级资源。
发现磁盘压力时，如果节点针对容器运行时配置有独占的 `imagefs`，`kubelet`回收节点层级资源的方式将会不同。
<!--
#### With `imagefs`
@@ -342,13 +364,13 @@ If `nodefs` filesystem has met eviction thresholds, `kubelet` frees up disk spac
1. Delete dead Pods and their containers
2. Delete all unused images
-->
#### 使用 `Imagefs`
#### 使用 `imagefs`
如果 `nodefs` 文件系统满足驱逐阈值，`kubelet`通过驱逐 pod 及其容器来释放磁盘空间。
如果 `imagefs` 文件系统满足驱逐阈值，`kubelet`通过删除所有未使用的镜像来释放磁盘空间。
#### 未使用 `Imagefs`
#### 未使用 `imagefs`
如果 `nodefs` 满足驱逐阈值，`kubelet`将以下面的顺序释放磁盘空间：
@@ -363,6 +385,16 @@ If the `kubelet` is unable to reclaim sufficient resource on the node, `kubelet`
The `kubelet` ranks Pods for eviction first by whether or not their usage of the starved resource exceeds requests,
then by [Priority](/docs/concepts/configuration/pod-priority-preemption/), and then by the consumption of the starved compute resource relative to the Pods' scheduling requests.
-->
### 驱逐最终用户的 pod
如果 `kubelet` 在节点上无法回收足够的资源，`kubelet`将开始驱逐 pod。
`kubelet` 首先根据他们对短缺资源的使用是否超过请求来排除 pod 的驱逐行为，
然后通过[优先级](/zh/docs/concepts/configuration/pod-priority-preemption/)，
然后通过相对于 pod 的调度请求消耗急需的计算资源。
<!--
As a result, `kubelet` ranks and evicts Pods in the following order:
* `BestEffort` or `Burstable` Pods whose usage of a starved resource exceeds its request.
@@ -376,25 +408,29 @@ and `journald`) is consuming more resources than were reserved via `system-reser
less than requests remaining, then the node must choose to evict such a Pod in order to
preserve node stability and to limit the impact of the unexpected consumption to other Pods.
In this case, it will choose to evict pods of Lowest Priority first.
-->
`kubelet` 按以下顺序对要驱逐的 pod 排名：
* `BestEffort` 或 `Burstable`，其对短缺资源的使用超过了其请求，此类 pod 按优先级排序，然后使用高于请求。
* `Guaranteed` pod 和 `Burstable` pod，其使用率低于请求，最后被驱逐。
`Guaranteed` Pod 只有为所有的容器指定了要求和限制并且它们相等时才能得到保证。
由于另一个 Pod 的资源消耗，这些 Pod 保证永远不会被驱逐。
如果系统守护进程（例如 `kubelet`、`docker`、和 `journald`）消耗的资源多于通过
`system-reserved` 或 `kube-reserved` 分配保留的资源，并且该节点只有 `Guaranteed` 或
`Burstable` Pod 使用少于剩余的请求，然后节点必须选择驱逐这样的 Pod
以保持节点的稳定性并限制意外消耗对其他 pod 的影响。
在这种情况下，它将首先驱逐优先级最低的 pod。
<!--
If necessary, `kubelet` evicts Pods one at a time to reclaim disk when `DiskPressure`
is encountered. If the `kubelet` is responding to `inode` starvation, it reclaims
`inodes` by evicting Pods with the lowest quality of service first. If the `kubelet`
is responding to lack of available disk, it ranks Pods within a quality of service
that consumes the largest amount of disk and kill those first.
-->
### 驱逐最终用户的 pod
如果 `kubelet` 在节点上无法回收足够的资源，`kubelet`将开始驱逐 pod。
`kubelet` 首先根据他们对短缺资源的使用是否超过请求来排除 pod 的驱逐行为，然后通过 [优先级](/docs/concepts/configuration/pod-priority-preemption/)，然后通过相对于 pod 的调度请求消耗急需的计算资源。
`kubelet` 按以下顺序对要驱逐的 pod 排名：
* `BestEffort` 或 `Burstable`，其对短缺资源的使用超过了其请求，此类 pod 按优先级排序，然后使用高于请求。
* `Guaranteed` pod 和 `Burstable` pod，其使用率低于请求，最后被驱逐。`Guaranteed`pod 只有为所有的容器指定了要求和限制并且它们相等时才能得到保证。由于另一个 pod 的资源消耗，这些 pod 保证永远不会被驱逐。如果系统守护进程（例如 `kubelet`、`docker`、和 `journald`）消耗的资源多于通过 `system-reserved` 或 `kube-reserved` 分配保留的资源，并且该节点只有 `Guaranteed` 或 `Burstable` pod 使用少于剩余的请求，然后节点必须选择驱逐这样的 pod 以保持节点的稳定性并限制意外消耗对其他 pod 的影响。在这种情况下，它将首先驱逐优先级最低的 pod。
必要时，`kubelet`会在遇到 `DiskPressure` 时驱逐一个 pod 来回收磁盘空间。如果 `kubelet` 响应 `inode` 短缺，它会首先驱逐服务质量最低的 pod 来回收 `inodes`。如果 `kubelet` 响应缺少可用磁盘，它会将 pod 排在服务质量范围内，该服务会消耗大量的磁盘并首先结束这些磁盘。
必要时，`kubelet`会在遇到 `DiskPressure` 时逐个驱逐 Pod 来回收磁盘空间。
如果 `kubelet` 响应 `inode` 短缺，它会首先驱逐服务质量最低的 Pod 来回收 `inodes`。
如果 `kubelet` 响应缺少可用磁盘，它会将 Pod 排在服务质量范围内，该服务会消耗大量的磁盘并首先结束这些磁盘。
<!--
#### With `imagefs`
@@ -425,31 +461,20 @@ If `nodefs` is triggering evictions, `kubelet` sorts Pods based on their total d
In certain scenarios, eviction of Pods could result in reclamation of small amount of resources. This can result in
`kubelet` hitting eviction thresholds in repeated successions. In addition to that, eviction of resources like `disk`,
is time consuming.
To mitigate these issues, `kubelet` can have a per-resource `minimum-reclaim`. Whenever `kubelet` observes
resource pressure, `kubelet` attempts to reclaim at least `minimum-reclaim` amount of resource below
the configured eviction threshold.
For example, with the following configuration:
```
--eviction-hard=memory.available<500Mi,nodefs.available<1Gi,imagefs.available<100Gi
--eviction-minimum-reclaim="memory.available=0Mi,nodefs.available=500Mi,imagefs.available=2Gi"`
```
If an eviction threshold is triggered for `memory.available`, the `kubelet` works to ensure
that `memory.available` is at least `500Mi`. For `nodefs.available`, the `kubelet` works
to ensure that `nodefs.available` is at least `1.5Gi`, and for `imagefs.available` it
works to ensure that `imagefs.available` is at least `102Gi` before no longer reporting pressure
on their associated resources.
The default `eviction-minimum-reclaim` is `0` for all resources.
-->
### 最小驱逐回收
在某些场景，驱逐 pod 会导致回收少量资源。这将导致 `kubelet` 反复碰到驱逐阈值。除此之外，对如 `disk` 这类资源的驱逐时比较耗时的。
为了减少这类问题，`kubelet`可以为每个资源配置一个 `minimum-reclaim`。当 `kubelet` 发现资源压力时，`kubelet`将尝试至少回收驱逐阈值之下 `minimum-reclaim` 数量的资源。
<!--
To mitigate these issues, `kubelet` can have a per-resource `minimum-reclaim`. Whenever `kubelet` observes
resource pressure, `kubelet` attempts to reclaim at least `minimum-reclaim` amount of resource below
the configured eviction threshold.
For example, with the following configuration:
-->
为了减少这类问题，`kubelet`可以为每个资源配置一个 `minimum-reclaim`。
当 `kubelet` 发现资源压力时，`kubelet`将尝试至少回收驱逐阈值之下 `minimum-reclaim` 数量的资源。
例如使用下面的配置：
@@ -458,7 +483,19 @@ The default `eviction-minimum-reclaim` is `0` for all resources.
--eviction-minimum-reclaim="memory.available=0Mi,nodefs.available=500Mi,imagefs.available=2Gi"`
```
如果 `memory.available` 驱逐阈值被触发，`kubelet`将保证 `memory.available` 至少为 `500Mi`。对于 `nodefs.available`，`kubelet`将保证 `nodefs.available` 至少为 `1.5Gi`。对于 `imagefs.available`，`kubelet`将保证 `imagefs.available` 至少为 `102Gi`，直到不再有相关资源报告压力为止。
<!--
If an eviction threshold is triggered for `memory.available`, the `kubelet` works to ensure
that `memory.available` is at least `500Mi`. For `nodefs.available`, the `kubelet` works
to ensure that `nodefs.available` is at least `1.5Gi`, and for `imagefs.available` it
works to ensure that `imagefs.available` is at least `102Gi` before no longer reporting pressure
on their associated resources.
The default `eviction-minimum-reclaim` is `0` for all resources.
-->
如果 `memory.available` 驱逐阈值被触发，`kubelet` 将保证 `memory.available` 至少为 `500Mi`。
对于 `nodefs.available`，`kubelet` 将保证 `nodefs.available` 至少为 `1.5Gi`。
对于 `imagefs.available`，`kubelet` 将保证 `imagefs.available` 至少为 `102Gi`，
直到不再有相关资源报告压力为止。
所有资源的默认 `eviction-minimum-reclaim` 值为 `0`。
@@ -480,8 +517,8 @@ pods on the node.
| 节点状态 | 调度器行为 |
| ---------------- | ------------------------------------------------ |
| `MemoryPressure` | No new `BestEffort` Pods are scheduled to the node. |
| `DiskPressure` | No new Pods are scheduled to the node. |
| `MemoryPressure` | 新的 `BestEffort` Pod 不会被调度到该节点 |
| `DiskPressure` | 没有新的 Pod 会被调度到该节点 |
<!--
## Node OOM Behavior
@@ -490,13 +527,29 @@ If the node experiences a system OOM (out of memory) event prior to the `kubelet
the node depends on the [oom_killer](https://lwn.net/Articles/391222/) to respond.
The `kubelet` sets a `oom_score_adj` value for each container based on the quality of service for the Pod.
-->
## 节点 OOM 行为
如果节点在 `kubelet` 回收内存之前经历了系统 OOM（内存不足）事件，它将基于
[oom-killer](https://lwn.net/Articles/391222/) 做出响应。
`kubelet` 基于 pod 的 service 质量为每个容器设置一个 `oom_score_adj` 值。
<!--
| Quality of Service | oom_score_adj |
|----------------------------|-----------------------------------------------------------------------|
| `Guaranteed` | -998 |
| `BestEffort` | 1000 |
| `Burstable` | min(max(2, 1000 - (1000 * memoryRequestBytes) / machineMemoryCapacityBytes), 999) |
-->
| Service 质量 | oom_score_adj |
|----------------------------|-----------------------------------------------------------------------|
| `Guaranteed` | -998 |
| `BestEffort` | 1000 |
| `Burstable` | min(max(2, 1000 - (1000 * memoryRequestBytes) / machineMemoryCapacityBytes), 999) |
<!--
If the `kubelet` is unable to reclaim memory prior to a node experiencing system OOM, the `oom_killer` calculates
an `oom_score` based on the percentage of memory it's using on the node, and then add the `oom_score_adj` to get an
effective `oom_score` for the container, and then kills the container with the highest score.
@@ -507,23 +560,14 @@ to reclaim memory.
Unlike Pod eviction, if a Pod container is OOM killed, it may be restarted by the `kubelet` based on its `RestartPolicy`.
-->
## 节点 OOM 行为
如果 `kubelet` 在节点经历系统 OOM 之前无法回收内存，`oom_killer` 将基于它在节点上
使用的内存百分比算出一个 `oom_score`，并加上 `oom_score_adj` 得到容器的有效
`oom_score`，然后结束得分最高的容器。
如果节点在 `kubelet` 回收内存之前经历了系统 OOM（内存不足）事件，它将基于 [oom-killer](https://lwn.net/Articles/391222/) 做出响应。
预期的行为应该是拥有最低服务质量并消耗和调度请求相关内存量最多的容器第一个被结束，以回收内存。
`kubelet` 基于 pod 的 service 质量为每个容器设置一个 `oom_score_adj` 值。
| Service 质量 | oom_score_adj |
|----------------------------|-----------------------------------------------------------------------|
| `Guaranteed` | -998 |
| `BestEffort` | 1000 |
| `Burstable` | min(max(2, 1000 - (1000 * memoryRequestBytes) / machineMemoryCapacityBytes), 999) |
如果 `kubelet` 在节点经历系统 OOM 之前无法回收内存，`oom_killer`将基于它在节点上使用的内存百分比算出一个 `oom_score`，并加上 `oom_score_adj` 得到容器的有效 `oom_score`，然后结束得分最高的容器。
预期的行为应该是拥有最低 service 质量并消耗和调度请求相关内存量最多的容器第一个被结束，以回收内存。
和 pod 驱逐不同，如果一个 pod 的容器是被 OOM 结束的，基于其 `RestartPolicy`，它可能会被 `kubelet` 重新启动。
和 pod 驱逐不同，如果一个 Pod 的容器是被 OOM 结束的，基于其 `RestartPolicy`，
它可能会被 `kubelet` 重新启动。
<!--
## Best Practices
@@ -539,19 +583,6 @@ Consider the following scenario:
* Operator wants to evict Pods at 95% memory utilization to reduce incidence of system OOM.
To facilitate this scenario, the `kubelet` would be launched as follows:
```
--eviction-hard=memory.available<500Mi
--system-reserved=memory=1.5Gi
```
Implicit in this configuration is the understanding that "System reserved" should include the amount of memory
covered by the eviction threshold.
To reach that capacity, either some Pod is using more than its request, or the system is using more than `1.5Gi - 500Mi = 1Gi`.
This configuration ensures that the scheduler does not place Pods on a node that immediately induce memory pressure
and trigger eviction assuming those Pods use less than their configured request.
-->
## 最佳实践
@@ -572,6 +603,15 @@ and trigger eviction assuming those Pods use less than their configured request.
--system-reserved=memory=1.5Gi
```
<!--
Implicit in this configuration is the understanding that "System reserved" should include the amount of memory
covered by the eviction threshold.
To reach that capacity, either some Pod is using more than its request, or the system is using more than `1.5Gi - 500Mi = 1Gi`.
This configuration ensures that the scheduler does not place Pods on a node that immediately induce memory pressure
and trigger eviction assuming those Pods use less than their configured request.
-->
这个配置的暗示是理解系统保留应该包含被驱逐阈值覆盖的内存数量。
要达到这个容量，要么某些 pod 使用了超过它们请求的资源，要么系统使用的内存超过 `1.5Gi - 500Mi = 1Gi`。
@@ -595,11 +635,13 @@ for eviction. Instead `DaemonSet` should ideally launch `Guaranteed` Pods.
-->
### DaemonSet
我们永远都不希望 `kubelet` 驱逐一个从 `DaemonSet` 派生的 pod，因为这个 pod 将立即被重建并调度回相同的节点。
我们永远都不希望 `kubelet` 驱逐一个从 `DaemonSet` 派生的 Pod，因为这个 Pod 将立即被重建并调度回相同的节点。
目前，`kubelet`没有办法区分一个 pod 是由 `DaemonSet` 还是其他对象创建。如果/当这个信息可用时，`kubelet`可能会预先将这些 pod 从提供给驱逐策略的候选集合中过滤掉。
目前，`kubelet`没有办法区分一个 Pod 是由 `DaemonSet` 还是其他对象创建。
如果/当这个信息可用时，`kubelet` 可能会预先将这些 pod 从提供给驱逐策略的候选集合中过滤掉。
总之，强烈推荐 `DaemonSet` 不要创建 `BestEffort` 的 pod，防止其被识别为驱逐的候选 pod。相反，理想情况下 `DaemonSet` 应该启动 `Guaranteed` 的 pod。
总之，强烈推荐 `DaemonSet` 不要创建 `BestEffort` 的 Pod，防止其被识别为驱逐的候选 Pod。
相反，理想情况下 `DaemonSet` 应该启动 `Guaranteed` 的 pod。
<!--
## Deprecation of existing feature flags to reclaim disk
@@ -608,7 +650,14 @@ for eviction. Instead `DaemonSet` should ideally launch `Guaranteed` Pods.
As disk based eviction matures, the following `kubelet` flags are marked for deprecation
in favor of the simpler configuration supported around eviction.
-->
## 现有的回收磁盘特性标签已被弃用
`kubelet` 已经按需求清空了磁盘空间以保证节点稳定性。
当磁盘驱逐成熟时，下面的 `kubelet` 标志将被标记为废弃的，以简化支持驱逐的配置。
<!--
| Existing Flag | New Flag |
| ------------- | -------- |
| `--image-gc-high-threshold` | `--eviction-hard` or `eviction-soft` |
@@ -619,11 +668,6 @@ in favor of the simpler configuration supported around eviction.
| `--low-diskspace-threshold-mb` | `--eviction-hard` or `eviction-soft` |
| `--outofdisk-transition-frequency` | `--eviction-pressure-transition-period` |
-->
## 弃用现有特性标签以回收磁盘
`kubelet` 已经按需求清空了磁盘空间以保证节点稳定性。
当磁盘驱逐成熟时，下面的 `kubelet` 标志将被标记为废弃的，以简化支持驱逐的配置。
| 现有标签 | 新标签 |
| ------------- | -------- |
@@ -639,26 +683,28 @@ in favor of the simpler configuration supported around eviction.
## Known issues
The following sections describe known issues related to out of resource handling.
-->
## 已知问题
以下部分描述了与资源外处理有关的已知问题。
<!--
### kubelet may not observe memory pressure right away
The `kubelet` currently polls `cAdvisor` to collect memory usage stats at a regular interval. If memory usage
increases within that window rapidly, the `kubelet` may not observe `MemoryPressure` fast enough, and the `OOMKiller`
will still be invoked. We intend to integrate with the `memcg` notification API in a future release to reduce this
latency, and instead have the kernel tell us when a threshold has been crossed immediately.
If you are not trying to achieve extreme utilization, but a sensible measure of overcommit, a viable workaround for
this issue is to set eviction thresholds at approximately 75% capacity. This increases the ability of this feature
to prevent system OOMs, and promote eviction of workloads so cluster state can rebalance.
-->
## 已知问题
以下部分描述了与资源外处理有关的已知问题。
### kubelet 可能无法立即发现内存压力
`kubelet`当前通过以固定的时间间隔轮询 `cAdvisor` 来收集内存使用数据。如果内存使用在那个时间窗口内迅速增长，`kubelet`可能不能足够快的发现 `MemoryPressure`，`OOMKiller`将不会被调用。我们准备在将来的发行版本中通过集成 `memcg` 通知 API 来减小这种延迟。当超过阈值时，内核将立即告诉我们。
<!--
If you are not trying to achieve extreme utilization, but a sensible measure of overcommit, a viable workaround for
this issue is to set eviction thresholds at approximately 75% capacity. This increases the ability of this feature
to prevent system OOMs, and promote eviction of workloads so cluster state can rebalance.
-->
如果您想处理可察觉的超量使用而不要求极端精准，可以设置驱逐阈值为大约 75% 容量作为这个问题的变通手段。这将增强这个特性的能力，防止系统 OOM，并提升负载卸载能力，以再次平衡集群状态。
<!--
@@ -669,5 +715,7 @@ the ability to get root container stats on an on-demand basis [(https://github.c
-->
### kubelet 可能会驱逐超过需求数量的 pod
由于状态采集的时间差，驱逐操作可能驱逐比所需的更多的 pod。将来可通过添加从根容器获取所需状态的能力 [https://github.com/google/cadvisor/issues/1247](https://github.com/google/cadvisor/issues/1247) 来减缓这种状况。
由于状态采集的时间差，驱逐操作可能驱逐比所需的更多的 pod。将来可通过添加从根容器获取所需状态的能力
[https://github.com/google/cadvisor/issues/1247](https://github.com/google/cadvisor/issues/1247)
来减缓这种状况。