diff --git a/content/zh/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md b/content/zh/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md index 5f2724bbad..8266031e0a 100644 --- a/content/zh/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md +++ b/content/zh/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md @@ -4,15 +4,24 @@ content_type: task weight: 20 --- + + 本页展示如何使用 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 文件示例。 diff --git a/content/zh/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md b/content/zh/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md index ca64910989..50771fa68a 100644 --- a/content/zh/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md +++ b/content/zh/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md @@ -4,15 +4,27 @@ content_type: task weight: 40 --- + + - + 本页展示如何使用 Romana 作为 NetworkPolicy。 ## {{% heading "prerequisites" %}} - -完成 [kubeadm 入门指南](/zh/docs/reference/setup-tools/kubeadm/kubeadm/)中的 1、2、3 步。 + +完成 [kubeadm 入门指南](/zh/docs/reference/setup-tools/kubeadm/)中的 1、2、3 步。 ## 使用 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" %}} diff --git a/content/zh/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md b/content/zh/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md index dc0600615c..02339cbc61 100644 --- a/content/zh/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md +++ b/content/zh/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md @@ -4,6 +4,14 @@ content_type: task weight: 50 --- + + 你需要拥有一个 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/) diff --git a/content/zh/docs/tasks/administer-cluster/reserve-compute-resources.md b/content/zh/docs/tasks/administer-cluster/reserve-compute-resources.md index 8e68d12845..104c845855 100644 --- a/content/zh/docs/tasks/administer-cluster/reserve-compute-resources.md +++ b/content/zh/docs/tasks/administer-cluster/reserve-compute-resources.md @@ -8,7 +8,6 @@ content_type: task min-kubernetes-server-version: 1.8 --- @@ -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)。 -## 可分配的节点 +## 节点可分配 {#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。 ### 配置 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 预留值 {#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。 + + -### 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 将**不会**创建它。如果指定了一个无效的 cgroup，Kubelet 将会失败。 +请注意，如果 `--kube-reserved-cgroup` 不存在，Kubelet 将 **不会** 创建它。 +如果指定了一个无效的 cgroup，Kubelet 将会失败。 +### 系统预留值 {#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。 + + -### 系统预留值 +要想为系统守护进程上可选地实施 `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 **不会**创建它。如果指定了无效的 cgroup，Kubelet 将会失败。 +请注意，如果 `--system-reserved-cgroup` 不存在，Kubelet **不会** 创建它。 +如果指定了无效的 cgroup，Kubelet 将会失败。 -### 显式保留的 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` 旨在为操作系统守护程序和 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。 -此选项是专门为 Telco 或 NFV 用例设计的，在这些用例中不受控制的中断或计时器可能会影响其工作负载性能。 -可以使用此选项为系统或 kubernetes 守护程序以及中断或计时器定义显式的 cpuset，因此系统上的 -其余 CPU 可以专门用于工作负载，而不受不受控制的中断或计时器的影响较小。 -要将系统守护程序、kubernetes 守护程序和中断或计时器移动到此选项定义的显式 cpuset 上， -应使用 Kubernetes 之外的其他机制。 +此选项是专门为电信/NFV 用例设计的，在这些用例中不受控制的中断或计时器可能会 +影响其工作负载性能。 +你可以使用此选项为系统或 kubernetes 守护程序以及中断或计时器显式定义 cpuset， +这样系统上的其余 CPU 可以专门用于工作负载，因不受控制的中断或计时器的影响得以 +降低。 +要将系统守护程序、kubernetes 守护程序和中断或计时器移动到此选项定义的显式 +cpuset 上，应使用 Kubernetes 之外的其他机制。 例如：在 Centos 系统中，可以使用 tuned 工具集来执行此操作。 -### 驱逐阈值 +### 驱逐阈值 {#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} -- **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} +系统守护进程一般会被按照类似 `Guaranteed` Pod 一样对待。 +系统守护进程可以在与其对应的控制组中出现突发资源用量，这一行为要作为 +kubernetes 部署的一部分进行管理。 +例如，`kubelet` 应该有它自己的控制组并和容器运行时共享 `Kube-reserved` 资源。 +不过，如果执行了 `kube-reserved` 约束，则 kubelet 不可出现突发负载并用光 +节点的所有可用资源。 + + +在执行 `system-reserved` 预留策略时请加倍小心，因为它可能导致节点上的 +关键系统服务出现 CPU 资源短缺、因为内存不足而被终止或者无法在节点上创建进程。 +建议只有当用户详尽地描述了他们的节点以得出精确的估计值， +并且对该组中进程因内存不足而被杀死时，有足够的信心将其恢复时， +才可以强制执行 `system-reserved` 策略。 +* 作为起步，可以先针对 `pods` 上执行 `Allocatable` 约束。 +* 一旦用于追踪系统守护进程的监控和告警的机制到位，可尝试基于用量估计的 + 方式执行 `kube-reserved`策略。 +* 随着时间推进，在绝对必要的时候可以执行 `system-reserved` 策略。 + + -## 一般原则 - -系统守护进程期望被按照类似 `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` 容量是有可能降低的。 @@ -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%` + + -## 示例场景 - -这是一个用于说明节点分配计算方式的示例： - -* 节点拥有 `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。