[zh] Sync changes from English site (10)

This commit is contained in:
Qiming Teng 2020-11-20 18:47:35 +08:00
parent 1e38b53fc8
commit f42b28f864
4 changed files with 202 additions and 155 deletions

View File

@ -4,15 +4,24 @@ content_type: task
weight: 20
---
<!--
reviewers:
- danwent
- aanm
title: Use Cilium for NetworkPolicy
content_type: task
weight: 20
-->
<!-- overview -->
<!--
This page shows how to use Cilium for NetworkPolicy.
For background on Cilium, read the [Introduction to Cilium](https://cilium.readthedocs.io/en/latest/intro).
For background on Cilium, read the [Introduction to Cilium](https://docs.cilium.io/en/stable/intro).
-->
本页展示如何使用 Cilium 提供 NetworkPolicy。
关于 Cilium 的背景知识,请阅读 [Cilium 介绍](https://cilium.readthedocs.io/en/latest/intro)。
关于 Cilium 的背景知识,请阅读 [Cilium 介绍](https://docs.cilium.io/en/stable/intro)。
## {{% heading "prerequisites" %}}
@ -86,7 +95,7 @@ deployment.apps/cilium-operator created
The remainder of the Getting Started Guide explains how to enforce both L3/L4
(i.e., IP address + port) security policies, as well as L7 (e.g., HTTP) security
policies using an example application.
-->
-->
入门指南其余的部分用一个示例应用说明了如何强制执行 L3/L4即 IP 地址+端口)的安全策略
以及L7 (如 HTTP的安全策略。
@ -94,14 +103,14 @@ policies using an example application.
## Deploying Cilium for Production Use
For detailed instructions around deploying Cilium for production, see:
[Cilium Kubernetes Installation Guide](https://cilium.readthedocs.io/en/latest/gettingstarted/#installation)
[Cilium Kubernetes Installation Guide](https://docs.cilium.io/en/stable/concepts/kubernetes/intro/)
This documentation includes detailed requirements, instructions and example
production DaemonSet files.
-->
## 部署 Cilium 用于生产用途
关于部署 Cilium 用于生产的详细说明,请见
[Cilium Kubernetes 安装指南](https://cilium.readthedocs.io/en/latest/gettingstarted/#installation)
[Cilium Kubernetes 安装指南](https://docs.cilium.io/en/stable/concepts/kubernetes/intro/)
此文档包括详细的需求、说明和生产用途 DaemonSet 文件示例。
<!-- discussion -->

View File

@ -4,15 +4,27 @@ content_type: task
weight: 40
---
<!--
reviewers:
- chrismarino
title: Romana for NetworkPolicy
content_type: task
weight: 40
-->
<!-- overview -->
<!-- This page shows how to use Romana for NetworkPolicy. -->
<!--
This page shows how to use Romana for NetworkPolicy.
-->
本页展示如何使用 Romana 作为 NetworkPolicy。
## {{% heading "prerequisites" %}}
<!-- Complete steps 1, 2, and 3 of the [kubeadm getting started guide](/docs/getting-started-guides/kubeadm/). -->
完成 [kubeadm 入门指南](/zh/docs/reference/setup-tools/kubeadm/kubeadm/)中的 1、2、3 步。
<!--
Complete steps 1, 2, and 3 of the [kubeadm getting started guide](/docs/getting-started-guides/kubeadm/).
-->
完成 [kubeadm 入门指南](/zh/docs/reference/setup-tools/kubeadm/)中的 1、2、3 步。
<!-- steps -->
<!--
@ -30,14 +42,15 @@ To apply network policies use one of the following:
-->
## 使用 kubeadm 安装 Romana
按照[容器化安装指南](https://github.com/romana/romana/tree/master/containerize),使用 kubeadm 安装。
按照[容器化安装指南](https://github.com/romana/romana/tree/master/containerize)
使用 kubeadm 安装。
## 应用网络策略
使用以下的一种方式应用网络策略:
* [Romana 网络策略](https://github.com/romana/romana/wiki/Romana-policies)
* [Romana 网络策略例子](https://github.com/romana/core/blob/master/doc/policy.md)
* [Romana 网络策略例子](https://github.com/romana/core/blob/master/doc/policy.md)
* NetworkPolicy API
## {{% heading "whatsnext" %}}

View File

@ -4,6 +4,14 @@ content_type: task
weight: 50
---
<!--
reviewers:
- bboreham
title: Weave Net for NetworkPolicy
content_type: task
weight: 50
-->
<!-- overview -->
<!--
@ -14,10 +22,11 @@ This page shows how to use Weave Net for NetworkPolicy.
## {{% heading "prerequisites" %}}
<!--
You need to have a Kubernetes cluster. Follow the [kubeadm getting started guide](/docs/getting-started-guides/kubeadm/) to bootstrap one.
You need to have a Kubernetes cluster. Follow the
[kubeadm getting started guide](/docs/reference/setup-tools/kubeadm/) to bootstrap one.
-->
你需要拥有一个 Kubernetes 集群。按照
[kubeadm 入门指南](/zh/docs/reference/setup-tools/kubeadm/kubeadm/)
[kubeadm 入门指南](/zh/docs/reference/setup-tools/kubeadm/)
来启动一个。
@ -28,8 +37,11 @@ You need to have a Kubernetes cluster. Follow the [kubeadm getting started guide
Follow the [Integrating Kubernetes via the Addon](https://www.weave.works/docs/net/latest/kubernetes/kube-addon/) guide.
The Weave Net addon for Kubernetes comes with a [Network Policy Controller](https://www.weave.works/docs/net/latest/kubernetes/kube-addon/#npc) that automatically monitors Kubernetes for any NetworkPolicy annotations on all namespaces and configures `iptables` rules to allow or block traffic as directed by the policies.
-->
The Weave Net addon for Kubernetes comes with a
[Network Policy Controller](https://www.weave.works/docs/net/latest/kubernetes/kube-addon/#npc)
that automatically monitors Kubernetes for any NetworkPolicy annotations on all
namespaces and configures `iptables` rules to allow or block traffic as directed by the policies.
-->
## 安装 Weave Net 插件
按照[通过插件集成 Kubernetes](https://www.weave.works/docs/net/latest/kubernetes/kube-addon/)

View File

@ -8,7 +8,6 @@ content_type: task
min-kubernetes-server-version: 1.8
---
<!--
---
reviewers:
- vishh
- derekwaynecarr
@ -16,7 +15,6 @@ reviewers:
title: Reserve Compute Resources for System Daemons
content_type: task
min-kubernetes-server-version: 1.8
---
-->
<!-- overview -->
@ -49,30 +47,15 @@ Your Kubernetes server must be at or later than version 1.17 to use
the kubelet command line option `--reserved-cpus` to set an
[explicitly reserved CPU list](#explicitly-reserved-cpu-list).
-->
您的 kubernetes 服务器版本必须至少是 1.17 版本,才能使用 kubelet 命令行选项 `--reserved-cpus` 来设置 [显式 CPU 保留列表](#explicitly-reserved-cpu-list)
你的 kubernetes 服务器版本必须至少是 1.17 版本,才能使用 kubelet
命令行选项 `--reserved-cpus` 设置
[显式预留 CPU 列表](#explicitly-reserved-cpu-list)。
<!-- steps -->
<!--
## Node Allocatable
```text
Node Capacity
---------------------------
| kube-reserved |
|-------------------------|
| system-reserved |
|-------------------------|
| eviction-threshold |
|-------------------------|
| |
| allocatable |
| (available for pods) |
| |
| |
---------------------------
```
`Allocatable` on a Kubernetes node is defined as the amount of compute resources
that are available for pods. The scheduler does not over-subscribe
`Allocatable`. `CPU`, `memory` and `ephemeral-storage` are supported as of now.
@ -82,29 +65,16 @@ of `kubectl describe node` in the CLI.
Resources can be reserved for two categories of system daemons in the `kubelet`.
-->
## 可分配的节点
## 节点可分配 {#node-allocatable}
```text
Node Capacity
---------------------------
| kube-reserved |
|-------------------------|
| system-reserved |
|-------------------------|
| eviction-threshold |
|-------------------------|
| |
| allocatable |
| (available for pods) |
| |
| |
---------------------------
```
![节点容量](/images/docs/node-capacity.svg)
Kubernetes 节点上的 `Allocatable` 被定义为 pod 可用计算资源量。调度器不会超额申请 `Allocatable`
Kubernetes 节点上的 `Allocatable` 被定义为 pod 可用计算资源量。
调度器不会超额申请 `Allocatable`
目前支持 `CPU`, `memory``ephemeral-storage` 这几个参数。
可分配的节点暴露为 API 中 `v1.Node` 对象的一部分,也是 CLI 中 `kubectl describe node` 的一部分。
可分配的节点暴露为 API 中 `v1.Node` 对象的一部分,也是 CLI 中
`kubectl describe node` 的一部分。
`kubelet` 中,可以为两类系统守护进程预留资源。
@ -118,8 +88,9 @@ under a cgroup hierarchy managed by the `kubelet`.
-->
### 启用 QoS 和 Pod 级别的 cgroups
为了恰当的在节点范围实施 node allocatable您必须通过 `--cgroups-per-qos` 标志启用新的 cgroup 层次结构。
这个标志是默认启用的。启用后,`kubelet` 将在其管理的 cgroup 层次结构中创建所有终端用户的 Pod。
为了恰当的在节点范围实施节点可分配约束,你必须通过 `--cgroups-per-qos`
标志启用新的 cgroup 层次结构。这个标志是默认启用的。
启用后,`kubelet` 将在其管理的 cgroup 层次结构中创建所有终端用户的 Pod。
<!--
### Configuring a cgroup driver
@ -143,15 +114,20 @@ be configured to use the `systemd` cgroup driver.
-->
### 配置 cgroup 驱动
`kubelet` 支持在主机上使用 cgroup 驱动操作 cgroup 层次结构。驱动通过 `--cgroup-driver` 标志配置。
`kubelet` 支持在主机上使用 cgroup 驱动操作 cgroup 层次结构。
驱动通过 `--cgroup-driver` 标志配置。
支持的参数值如下:
* `cgroupfs` 是默认的驱动,在主机上直接操作 cgroup 文件系统以对 cgroup 沙箱进行管理。
* `systemd` 是可选的驱动,使用 init 系统支持的资源的瞬时切片管理 cgroup 沙箱。
* `cgroupfs` 是默认的驱动,在主机上直接操作 cgroup 文件系统以对 cgroup
沙箱进行管理。
* `systemd` 是可选的驱动,使用 init 系统支持的资源的瞬时切片管理
cgroup 沙箱。
取决于相关容器运行时的配置,操作员可能需要选择一个特定的 cgroup 驱动来保证系统正常运行。
例如如果操作员使用 `docker` 运行时提供的 `systemd` cgroup 驱动时,必须配置 `kubelet` 使用 `systemd` cgroup 驱动。
取决于相关容器运行时的配置,操作员可能需要选择一个特定的 cgroup 驱动
来保证系统正常运行。
例如,如果操作员使用 `docker` 运行时提供的 `systemd` cgroup 驱动时,
必须配置 `kubelet` 使用 `systemd` cgroup 驱动。
<!--
### Kube Reserved
@ -167,7 +143,21 @@ It is not meant to reserve resources for system daemons that are run as pods.
In addition to `cpu`, `memory`, and `ephemeral-storage`, `pid` may be
specified to reserve the specified number of process IDs for
kubernetes system daemons.
-->
### Kube 预留值 {#kube-reserved}
- **Kubelet 标志**: `--kube-reserved=[cpu=100m][,][memory=100Mi][,][ephemeral-storage=1Gi][,][pid=1000]`
- **Kubelet 标志**: `--kube-reserved-cgroup=`
`kube-reserved` 用来给诸如 `kubelet`、容器运行时、节点问题监测器等
kubernetes 系统守护进程记述其资源预留值。
该配置并非用来给以 Pod 形式运行的系统守护进程保留资源。`kube-reserved`
通常是节点上 `pod 密度` 的函数。
除了 `cpu``内存` 和 `ephemeral-storage` 之外,`pid` 可用来指定为
kubernetes 系统守护进程预留指定数量的进程 ID。
<!--
To optionally enforce `kube-reserved` on system daemons, specify the parent
control group for kube daemons as the value for `--kube-reserved-cgroup` kubelet
flag.
@ -175,30 +165,24 @@ flag.
It is recommended that the kubernetes system daemons are placed under a top
level control group (`runtime.slice` on systemd machines for example). Each
system daemon should ideally run within its own child control group. Refer to
[this
doc](https://git.k8s.io/community/contributors/design-proposals/node/node-allocatable.md#recommended-cgroups-setup)
[this doc](https://git.k8s.io/community/contributors/design-proposals/node/node-allocatable.md#recommended-cgroups-setup)
for more details on recommended control group hierarchy.
Note that Kubelet **does not** create `--kube-reserved-cgroup` if it doesn't
exist. Kubelet will fail if an invalid cgroup is specified.
-->
### Kube 预留值
要选择性地对系统守护进程上执行 `kube-reserved` 保护,需要把 kubelet 的
`--kube-reserved-cgroup` 标志的值设置为 kube 守护进程的父控制组。
- **Kubelet Flag**: `--kube-reserved=[cpu=100m][,][memory=100Mi][,][ephemeral-storage=1Gi][,][pid=1000]`
- **Kubelet Flag**: `--kube-reserved-cgroup=`
`kube-reserved` 是为了给诸如 `kubelet`、`container runtime`、`node problem detector` 等 kubernetes 系统守护进程争取资源预留。
这并不代表要给以 pod 形式运行的系统守护进程保留资源。`kube-reserved` 通常是节点上的一个 `pod 密度` 功能。
除了 `cpu``内存` 和 `ephemeral-storage` 之外,`pid` 可能是指定为 kubernetes 系统守护进程预留指定数量的进程 ID。
要选择性的在系统守护进程上执行 `kube-reserved`,需要把 kubelet 的 `--kube-reserved-cgroup` 标志的值设置为 kube 守护进程的父控制组。
推荐将 kubernetes 系统守护进程放置于顶级控制组之下(例如 systemd 机器上的 `runtime.slice`)。
推荐将 kubernetes 系统守护进程放置于顶级控制组之下(例如 systemd 机器上的
`runtime.slice`)。
理想情况下每个系统守护进程都应该在其自己的子控制组中运行。
请参考[这篇文档](https://git.k8s.io/community/contributors/design-proposals/node/node-allocatable.md#recommended-cgroups-setup),获取更过关于推荐控制组层次结构的细节。
请参考
[这篇文档](https://git.k8s.io/community/contributors/design-proposals/node/node-allocatable.md#recommended-cgroups-setup)
进一步了解关于推荐控制组层次结构的细节。
请注意,如果 `--kube-reserved-cgroup` 不存在Kubelet 将**不会**创建它。如果指定了一个无效的 cgroupKubelet 将会失败。
请注意,如果 `--kube-reserved-cgroup` 不存在Kubelet 将 **不会** 创建它。
如果指定了一个无效的 cgroupKubelet 将会失败。
<!--
### System Reserved
@ -216,7 +200,21 @@ systemd world).
In addition to `cpu`, `memory`, and `ephemeral-storage`, `pid` may be
specified to reserve the specified number of process IDs for OS system
daemons.
-->
### 系统预留值 {#system-reserved}
- **Kubelet 标志**: `--system-reserved=[cpu=100m][,][memory=100Mi][,][ephemeral-storage=1Gi][,][pid=1000]`
- **Kubelet 标志**: `--system-reserved-cgroup=`
`system-reserved` 用于为诸如 `sshd`、`udev` 等系统守护进程记述其资源预留值。
`system-reserved` 也应该为 `kernel` 预留 `内存`,因为目前 `kernel`
使用的内存并不记在 Kubernetes 的 Pod 上。
同时还推荐为用户登录会话预留资源systemd 体系中的 `user.slice`)。
除了 `cpu``内存` 和 `ephemeral-storage` 之外,`pid` 可用来指定为
kubernetes 系统守护进程预留指定数量的进程 ID。
<!--
To optionally enforce `system-reserved` on system daemons, specify the parent
control group for OS system daemons as the value for `--system-reserved-cgroup`
kubelet flag.
@ -227,43 +225,41 @@ control group (`system.slice` on systemd machines for example).
Note that Kubelet **does not** create `--system-reserved-cgroup` if it doesn't
exist. Kubelet will fail if an invalid cgroup is specified.
-->
### 系统预留值
要想为系统守护进程上可选地实施 `system-reserved` 约束,请指定 kubelet 的
`--system-reserved-cgroup` 标志值为 OS 系统守护进程的父级控制组。
- **Kubelet Flag**: `--system-reserved=[cpu=100m][,][memory=100Mi][,][ephemeral-storage=1Gi][,][pid=1000]`
- **Kubelet Flag**: `--system-reserved-cgroup=`
推荐将 OS 系统守护进程放在一个顶级控制组之下(例如 systemd 机器上的
`system.slice`)。
`system-reserved` 用于为诸如 `sshd`、`udev` 等系统守护进程争取资源预留。
`system-reserved` 也应该为 `kernel` 预留 `内存`,因为目前 `kernel` 使用的内存并不记在 Kubernetes 的 pod 上。
同时还推荐为用户登录会话预留资源systemd 体系中的 `user.slice`)。
除了 `cpu``内存` 和 `ephemeral-storage` 之外,`pid` 可能是指定为 kubernetes 系统守护进程预留指定数量的进程 ID。
要想在系统守护进程上可选地执行 `system-reserved`,请指定 `--system-reserved-cgroup` kubelet 标志的值为 OS 系统守护进程的父级控制组。
推荐将 OS 系统守护进程放在一个顶级控制组之下(例如 systemd 机器上的 `system.slice`)。
请注意,如果 `--system-reserved-cgroup` 不存在Kubelet **不会**创建它。如果指定了无效的 cgroupKubelet 将会失败。
请注意,如果 `--system-reserved-cgroup` 不存在Kubelet **不会** 创建它。
如果指定了无效的 cgroupKubelet 将会失败。
<!--
### Explicitly Reserved CPU List
-->
### 显式保留的 CPU 列表 {#explicitly-reserved-cpu-list}
{{< feature-state for_k8s_version="v1.17" state="stable" >}}
- **Kubelet Flag**: `--reserved-cpus=0-3`
-->
### 显式保留的 CPU 列表 {#explicitly-reserved-cpu-list}
{{< feature-state for_k8s_version="v1.17" state="stable" >}}
- **Kubelet 标志**: `--reserved-cpus=0-3`
<!--
`reserved-cpus` is meant to define an explicit CPU set for OS system daemons and
kubernetes system daemons. This option is added in 1.17 release. `reserved-cpus`
is for systems that do not intent to define separate top level cgroups for
OS system daemons and kubernetes system daemons with regard to cpuset resource.
kubernetes system daemons. `reserved-cpus` is for systems that do not intend to
define separate top level cgroups for OS system daemons and kubernetes system daemons
with regard to cpuset resource.
If the Kubelet **does not** have `--system-reserved-cgroup` and `--kube-reserved-cgroup`,
the explicit cpuset provided by `reserved-cpus` will take precedence over the CPUs
defined by `--kube-reserved` and `--system-reserved` options.
-->
`reserved-cpus` 旨在为操作系统守护程序和 kubernetes 系统守护程序定义一个显式 cpuset。此选项在 kubernetes 1.17 版本中添加。
`reserved-cpus` 适用于不打算针对 cpuset 资源为操作系统守护程序和 kubernetes 系统守护程序定义单独的顶级 cgroups 的系统。
如果 Kubelet **没有** 指定参数 `--system-reserved-cgroup``--kube-reserved-cgroup`,则 `reserved-cpus` 提供的显式 cpuset 将优先于 `--kube-reserved``--system-reserved` 选项定义的 cpuset。
`reserved-cpus` 旨在为操作系统守护程序和 kubernetes 系统守护程序定义一个显式 CPU
集合。`reserved-cpus` 适用于不打算针对 cpuset 资源为操作系统守护程序和 kubernetes
系统守护程序定义独立的顶级 cgroups 的系统。
如果 Kubelet **没有** 指定参数 `--system-reserved-cgroup``--kube-reserved-cgroup`
`reserved-cpus` 提供的显式 cpuset 将优先于 `--kube-reserved``--system-reserved`
选项定义的 cpuset。
<!--
This option is specifically designed for Telco/NFV use cases where uncontrolled
@ -275,11 +271,13 @@ system daemon, kubernetes daemons and interrupts/timers to the explicit cpuset
defined by this option, other mechanism outside Kubernetes should be used.
For example: in Centos, you can do this using the tuned toolset.
-->
此选项是专门为 Telco 或 NFV 用例设计的,在这些用例中不受控制的中断或计时器可能会影响其工作负载性能。
可以使用此选项为系统或 kubernetes 守护程序以及中断或计时器定义显式的 cpuset因此系统上的
其余 CPU 可以专门用于工作负载,而不受不受控制的中断或计时器的影响较小。
要将系统守护程序、kubernetes 守护程序和中断或计时器移动到此选项定义的显式 cpuset 上,
应使用 Kubernetes 之外的其他机制。
此选项是专门为电信/NFV 用例设计的,在这些用例中不受控制的中断或计时器可能会
影响其工作负载性能。
你可以使用此选项为系统或 kubernetes 守护程序以及中断或计时器显式定义 cpuset
这样系统上的其余 CPU 可以专门用于工作负载,因不受控制的中断或计时器的影响得以
降低。
要将系统守护程序、kubernetes 守护程序和中断或计时器移动到此选项定义的显式
cpuset 上,应使用 Kubernetes 之外的其他机制。
例如:在 Centos 系统中,可以使用 tuned 工具集来执行此操作。
<!--
@ -298,16 +296,19 @@ system daemons did not exist on a node, pods cannot use more than `capacity -
eviction-hard`. For this reason, resources reserved for evictions are not
available for pods.
-->
### 驱逐阈值
### 驱逐阈值 {#eviction-Thresholds}
- **Kubelet Flag**: `--eviction-hard=[memory.available<500Mi]`
- **Kubelet 标志**: `--eviction-hard=[memory.available<500Mi]`
节点级别的内存压力将导致系统内存不足,这将影响到整个节点及其上运行的所有 pod。节点可以暂时离线直到内存已经回收为止。
节点级别的内存压力将导致系统内存不足,这将影响到整个节点及其上运行的所有 Pod。
节点可以暂时离线直到内存已经回收为止。
为了防止或减少可能性系统内存不足kubelet 提供了
[资源不足](/zh/docs/tasks/administer-cluster/out-of-resource/)管理。
驱逐操作只支持 `memory``ephemeral-storage`
通过 `--eviction-hard` 标志预留一些内存后,当节点上的可用内存降至保留值以下时,`kubelet` 将尝试`驱逐` pod。
假设如果节点上不存在系统守护进程pod 将不能使用超过 `capacity-eviction-hard` 的资源。因此,为驱逐而预留的资源对 pod 是不可用的。
通过 `--eviction-hard` 标志预留一些内存后,当节点上的可用内存降至保留值以下时,
`kubelet` 将尝试`驱逐` Pod。
如果节点上不存在系统守护进程Pod 将不能使用超过 `capacity-eviction-hard`
指定的资源量。因此,为驱逐而预留的资源对 Pod 是不可用的。
<!--
### Enforcing Node Allocatable
@ -322,27 +323,28 @@ by evicting pods whenever the overall usage across all pods exceeds
[here](/docs/tasks/administer-cluster/out-of-resource/#eviction-policy). This enforcement is controlled by
specifying `pods` value to the kubelet flag `--enforce-node-allocatable`.
Optionally, `kubelet` can be made to enforce `kube-reserved` and
`system-reserved` by specifying `kube-reserved` & `system-reserved` values in
the same flag. Note that to enforce `kube-reserved` or `system-reserved`,
`--kube-reserved-cgroup` or `--system-reserved-cgroup` needs to be specified
respectively.
-->
### 执行节点分配
### 实施节点可分配约束 {#enforcing-node-allocatable}
- **Kubelet Flag**: `--enforce-node-allocatable=pods[,][system-reserved][,][kube-reserved]`
- **Kubelet 标志**: `--enforce-node-allocatable=pods[,][system-reserved][,][kube-reserved]`
调度器将 `Allocatable` 按 pod 的可用 `capacity` 对待
调度器将 `Allocatable` 视为 Pod 可用的 `capacity`(资源容量)
`kubelet` 默认在 Pod 中执行 `Allocatable`。无论何时,如果所有 pod 的总用量超过了 `Allocatable`
驱逐 pod 的措施将被执行。有关驱逐策略的更多细节可以在
[这里](/zh/docs/tasks/administer-cluster/out-of-resource/#eviction-policy).找到。
请通过设置 kubelet `--enforce-node-allocatable` 标志值为 `pods` 控制这个措施。
`kubelet` 默认对 Pod 执行 `Allocatable` 约束。
无论何时,如果所有 Pod 的总用量超过了 `Allocatable`,驱逐 Pod 的措施将被执行。
有关驱逐策略的更多细节可以在
[这里](/zh/docs/tasks/administer-cluster/out-of-resource/#eviction-policy)找到。
可通过设置 kubelet `--enforce-node-allocatable` 标志值为 `pods` 控制这个措施。
可选的,通过在相同标志中同时指定 `kube-reserved``system-reserved` 值能够使 `kubelet`
执行 `kube-reserved``system-reserved`。请注意,要想执行 `kube-reserved` 或者 `system-reserved` 时,
需要分别指定 `--kube-reserved-cgroup` 或者 `--system-reserved-cgroup`
可选地,通过在同一标志中同时指定 `kube-reserved``system-reserved` 值,
可以使 `kubelet` 强制实施 `kube-reserved``system-reserved`约束。
请注意,要想执行 `kube-reserved` 或者 `system-reserved` 约束,
需要对应设置 `--kube-reserved-cgroup` 或者 `--system-reserved-cgroup`
<!--
## General Guidelines
@ -353,7 +355,17 @@ to be managed as part of kubernetes deployments. For example, `kubelet` should
have its own control group and share `Kube-reserved` resources with the
container runtime. However, Kubelet cannot burst and use up all available Node
resources if `kube-reserved` is enforced.
-->
## 一般原则 {#general-guidelines}
系统守护进程一般会被按照类似 `Guaranteed` Pod 一样对待。
系统守护进程可以在与其对应的控制组中出现突发资源用量,这一行为要作为
kubernetes 部署的一部分进行管理。
例如,`kubelet` 应该有它自己的控制组并和容器运行时共享 `Kube-reserved` 资源。
不过,如果执行了 `kube-reserved` 约束,则 kubelet 不可出现突发负载并用光
节点的所有可用资源。
<!--
Be extra careful while enforcing `system-reserved` reservation since it can lead
to critical system services being CPU starved, OOM killed, or unable
to fork on the node. The
@ -365,33 +377,28 @@ ability to recover if any process in that group is oom_killed.
* Once adequate monitoring and alerting is in place to track kube system
daemons, attempt to enforce `kube-reserved` based on usage heuristics.
* If absolutely necessary, enforce `system-reserved` over time.
-->
在执行 `system-reserved` 预留策略时请加倍小心,因为它可能导致节点上的
关键系统服务出现 CPU 资源短缺、因为内存不足而被终止或者无法在节点上创建进程。
建议只有当用户详尽地描述了他们的节点以得出精确的估计值,
并且对该组中进程因内存不足而被杀死时,有足够的信心将其恢复时,
才可以强制执行 `system-reserved` 策略。
* 作为起步,可以先针对 `pods` 上执行 `Allocatable` 约束。
* 一旦用于追踪系统守护进程的监控和告警的机制到位,可尝试基于用量估计的
方式执行 `kube-reserved`策略。
* 随着时间推进,在绝对必要的时候可以执行 `system-reserved` 策略。
<!--
The resource requirements of kube system daemons may grow over time as more and
more features are added. Over time, kubernetes project will attempt to bring
down utilization of node system daemons, but that is not a priority as of now.
So expect a drop in `Allocatable` capacity in future releases.
-->
## 一般原则
系统守护进程期望被按照类似 `Guaranteed` pod 一样对待。系统守护进程可以在其范围控制组中爆发式增长,
您需要将这个行为作为 kubernetes 部署的一部分进行管理。
例如,`kubelet` 应该有它自己的控制组并和容器运行时共享 `Kube-reserved` 资源。
然而,如果执行了 `kube-reserved`,则 kubelet 不能突然爆发并耗尽节点的所有可用资源。
在执行 `system-reserved` 预留操作时请加倍小心,因为它可能导致节点上的关键系统服务 CPU 资源短缺
或因为内存不足而被终止。
建议只有当用户详尽地描述了他们的节点以得出精确的估计时才强制执行 `system-reserved`
并且如果该组中的任何进程都是 oom_killed则对他们恢复的能力充满信心。
* 在 `pods` 上执行 `Allocatable` 作为开始。
* 一旦足够用于追踪系统守护进程的监控和告警的机制到位,请尝试基于用量探索方式执行 `kube-reserved`
* 随着时间推进,如果绝对必要,可以执行 `system-reserved`
随着时间的增长以及越来越多特性的加入kube 系统守护进程对资源的需求可能也会增加。
以后 kubernetes 项目将尝试减少对节点系统守护进程的利用,但目前那并不是优先事项。
所以,请期待在将来的发布中将 `Allocatable` 容量降低。
随着时间推进和越来越多特性被加入kube 系统守护进程对资源的需求可能也会增加。
以后 kubernetes 项目将尝试减少对节点系统守护进程的利用,但目前这件事的优先级
并不是最高。
所以,将来的发布版本中 `Allocatable` 容量是有可能降低的。
<!-- discussion -->
@ -404,7 +411,17 @@ Here is an example to illustrate Node Allocatable computation:
* `--kube-reserved` is set to `cpu=1,memory=2Gi,ephemeral-storage=1Gi`
* `--system-reserved` is set to `cpu=500m,memory=1Gi,ephemeral-storage=1Gi`
* `--eviction-hard` is set to `memory.available<500Mi,nodefs.available<10%`
-->
## 示例场景 {#example-scenario}
这是一个用于说明节点可分配Node Allocatable计算方式的示例
* 节点拥有 `32Gi` `memeory``16 CPU` 和 `100Gi` `Storage` 资源
* `--kube-reserved` 被设置为 `cpu=1,memory=2Gi,ephemeral-storage=1Gi`
* `--system-reserved` 被设置为 `cpu=500m,memory=1Gi,ephemeral-storage=1Gi`
* `--eviction-hard` 被设置为 `memory.available<500Mi,nodefs.available<10%`
<!--
Under this scenario, `Allocatable` will be `14.5 CPUs`, `28.5Gi` of memory and
`88Gi` of local storage.
Scheduler ensures that the total memory `requests` across all pods on this node does
@ -417,19 +434,15 @@ If `kube-reserved` and/or `system-reserved` is not enforced and system daemons
exceed their reservation, `kubelet` evicts pods whenever the overall node memory
usage is higher than `31.5Gi` or `storage` is greater than `90Gi`
-->
## 示例场景
这是一个用于说明节点分配计算方式的示例:
* 节点拥有 `32Gi 内存``16 核 CPU` 和 `100Gi 存储`
* `--kube-reserved` 设置为 `cpu=1,memory=2Gi,ephemeral-storage=1Gi`
* `--system-reserved` 设置为 `cpu=500m,memory=1Gi,ephemeral-storage=1Gi`
* `--eviction-hard` 设置为 `memory.available<500Mi,nodefs.available<10%`
在这个场景下,`Allocatable` 将会是 `14.5 CPUs`、`28.5Gi` 内存以及 `88Gi` 本地存储。
调度器保证这个节点上的所有 pod `请求`的内存总量不超过 `28.5Gi`,存储不超过 `88Gi`
当 pod 的内存使用总量超过 `28.5Gi` 或者磁盘使用总量超过 `88Gi`Kubelet 将会驱逐它们。
如果节点上的所有进程都尽可能多的使用 CPU则 pod 加起来不能使用超过 `14.5 CPUs` 的资源。
调度器保证这个节点上的所有 Pod 的内存 `requests` 总量不超过 `28.5Gi`
存储不超过 `88Gi`
当 Pod 的内存使用总量超过 `28.5Gi` 或者磁盘使用总量超过 `88Gi` 时,
kubelet 将会驱逐它们。
如果节点上的所有进程都尽可能多地使用 CPU则 Pod 加起来不能使用超过
`14.5 CPUs` 的资源。
当没有执行 `kube-reserved` 和/或 `system-reserved` 策略且系统守护进程
使用量超过其预留时,如果节点内存用量高于 `31.5Gi` 或`存储`大于 `90Gi`
kubelet 将会驱逐 Pod。
当没有执行 `kube-reserved` 和/或 `system-reserved` 且系统守护进程使用量超过其预留时,
如果节点内存用量高于 `31.5Gi` 或`存储`大于 `90Gi`kubelet 将会驱逐 pod。