Merge pull request #29814 from steven-my/29329-translation-for-admin-2

[zh] translation for admin2
2021-09-29 01:34:48 -07:00
parent 41896a5426 864a3808b8
commit 9a5dc73a16
7 changed files with 147 additions and 87 deletions
@@ -30,6 +30,7 @@ This document helps you get started using the Kubernetes [NetworkPolicy API](/do
 <!--
 Make sure you've configured a network provider with network policy support. There are a number of network providers that support NetworkPolicy, including:
 * [Antrea](/docs/tasks/administer-cluster/network-policy-provider/antrea-network-policy/)
 * [Calico](/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy/)
 * [Cilium](/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy/)
 * [Kube-router](/docs/tasks/administer-cluster/network-policy-provider/kube-router-network-policy/)
@@ -38,6 +39,7 @@ Make sure you've configured a network provider with network policy support. Ther
 -->
 你首先需要有一个支持网络策略的 Kubernetes 集群。已经有许多支持 NetworkPolicy 的网络提供商，包括：
 * [Antrea](/zh/docs/tasks/administer-cluster/network-policy-provider/antrea-network-policy/)
 * [Calico](/zh/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy/)
 * [Cilium](/zh/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy/)
 * [Kube-router](/zh/docs/tasks/administer-cluster/network-policy-provider/kube-router-network-policy/)
@@ -67,13 +67,13 @@ Host: k8s-master:8080
 <!--
 Note that Kubernetes does not need to know what a dongle is or what a dongle is for.
-The preceding PATCH request just tells Kubernetes that your Node has four things that
+The preceding PATCH request tells Kubernetes that your Node has four things that
 you call dongles.
 Start a proxy, so that you can easily send requests to the Kubernetes API server:
 -->
 注意：Kubernetes 不需要了解 dongle 资源的含义和用途。
-前面的 PATCH 请求仅仅告诉 Kubernetes 你的节点拥有四个你称之为 dongle 的东西。
+前面的 PATCH 请求告诉 Kubernetes 你的节点拥有四个你称之为 dongle 的东西。
 启动一个代理（proxy），以便你可以很容易地向 Kubernetes API server 发送请求：
@@ -345,9 +345,9 @@ Apply the manifest to create a Deployment
 应用清单文件来创建 Deployment。
 <!--
-We have just created a deployment whose replica size is 2 that is running the pod called `snowflake` with a basic container that just serves the hostname.
+We have created a deployment whose replica size is 2 that is running the pod called `snowflake` with a basic container that serves the hostname.
 -->
-我们刚刚创建了一个副本大小为 2 的 Deployment，该 Deployment 运行名为 `snowflake` 的 Pod，
+我们创建了一个副本大小为 2 的 Deployment，该 Deployment 运行名为 `snowflake` 的 Pod，
 其中包含一个仅提供主机名服务的基本容器。
 ```shell
@@ -0,0 +1,49 @@
 <!--
 ---
 title: Use Antrea for NetworkPolicy
 content_type: task
 weight: 10
 ---
 -->
 ---
 title: 使用 Antrea 提供 NetworkPolicy
 content_type: task
 weight: 10
 ---
 <!-- overview -->
 <!--
 This page shows how to install and use Antrea CNI plugin on Kubernetes.
 For background on Project Antrea, read the [Introduction to Antrea](https://antrea.io/docs/).
 -->
 本页展示了如何在 kubernetes 中安装和使用 Antrea CNI 插件。
 要了解 Antrea 项目的背景，请阅读 [Antrea 介绍](https://antrea.io/docs/)。
 ## {{% heading "prerequisites" %}}
 <!--
 You need to have a Kubernetes cluster. Follow the
 [kubeadm getting started guide](/docs/reference/setup-tools/kubeadm/) to bootstrap one.
 -->
 你需要拥有一个 kuernetes 集群。
 遵循 [kubeadm 入门指南](/zh/docs/reference/setup-tools/kubeadm/)自行创建一个。
 <!-- steps -->
 <!--
 ## Deploying Antrea with kubeadm
 Follow [Getting Started](https://github.com/vmware-tanzu/antrea/blob/main/docs/getting-started.md) guide to deploy Antrea for kubeadm.
 -->
 ## 使用 kubeadm 部署 Antrea
 遵循[入门](https://github.com/vmware-tanzu/antrea/blob/main/docs/getting-started.md)指南
 为 kubeadm 部署 Antrea 。
 ## {{% heading "whatsnext" %}}
 <!--
 Once your cluster is running, you can follow the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) to try out Kubernetes NetworkPolicy.
 -->
 一旦你的集群已经运行，你可以遵循 
 [声明网络策略](/zh/docs/tasks/administer-cluster/declare-network-policy/)
 来尝试 Kubernetes NetworkPolicy。
@@ -29,9 +29,9 @@ Decide whether you want to deploy a [cloud](#creating-a-calico-cluster-with-goog
 **先决条件**: [gcloud](https://cloud.google.com/sdk/docs/quickstarts)
 <!--
-1.  To launch a GKE cluster with Calico, just include the `--enable-network-policy` flag.
+1.  To launch a GKE cluster with Calico, include the `--enable-network-policy` flag.
 -->
-1.  启动一个带有 Calico 的 GKE 集群，只需加上参数 `--enable-network-policy`。
+1.  启动一个带有 Calico 的 GKE 集群，需要加上参数 `--enable-network-policy`。
    **语法**
    ```shell
@@ -33,25 +33,25 @@ For background on Cilium, read the [Introduction to Cilium](https://docs.cilium.
 ## Deploying Cilium on Minikube for Basic Testing
 To get familiar with Cilium easily you can follow the
-[Cilium Kubernetes Getting Started Guide](https://docs.cilium.io/en/stable/gettingstarted/minikube/)
+[Cilium Kubernetes Getting Started Guide](https://docs.cilium.io/en/stable/gettingstarted/k8s-install-default/)
 to perform a basic DaemonSet installation of Cilium in minikube.
-To start minikube, minimal version required is >= v1.3.1, run the with the
+To start minikube, minimal version required is >= v1.5.2, run the with the
 following arguments:
 -->
 ## 在 Minikube 上部署 Cilium 用于基本测试
 为了轻松熟悉 Cilium 你可以根据
-[Cilium Kubernetes 入门指南](https://docs.cilium.io/en/stable/gettingstarted/minikube/)
+[Cilium Kubernetes 入门指南](https://docs.cilium.io/en/stable/gettingstarted/k8s-install-default/s)
 在 minikube 中执行一个 cilium 的基本 DaemonSet 安装。
-要启动 minikube，需要的最低版本为 1.3.1，使用下面的参数运行：
+要启动 minikube，需要的最低版本为 1.5.2，使用下面的参数运行：
 ```shell
 minikube version
 ```
 ```
-minikube version: v1.3.1
+minikube version: v1.5.2
 ```
 ```shell
@@ -59,36 +59,45 @@ minikube start --network-plugin=cni --memory=4096
 ```
 <!--
-Mount the BPF filesystem:
+For minikube you can install Cilium using its CLI tool. Cilium will
 automatically detect the cluster configuration and will install the appropriate
 components for a successful installation:
 -->
-挂载 BPF 文件系统：
+对于 minikube 你可以使用 Cilium 的 CLI 工具安装它。
 Cilium 将自动检测集群配置并为成功的集群部署选择合适的组件。
 ```shell
-minikube ssh -- sudo mount bpffs -t bpf /sys/fs/bpf
+curl -LO https://github.com/cilium/cilium-cli/releases/latest/download/cilium-linux-amd64.tar.gz
 sudo tar xzvfC cilium-linux-amd64.tar.gz /usr/local/bin
 rm cilium-linux-amd64.tar.gz
 cilium install
 ```
 <!--
 For minikube you can deploy this simple ''all-in-one'' YAML file that includes
 DaemonSet configurations for Cilium as well as appropriate RBAC settings:
 -->
 在 minikube 环境中，你可以部署下面的"一体化" YAML 文件，其中包含 Cilium
 的 DaemonSet 配置以及适当的 RBAC 配置：
 ```shell
 kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.8/install/kubernetes/quick-install.yaml
 ```
-
+🔮 Auto-detected Kubernetes kind: minikube
-```
+✨ Running "minikube" validation checks
-configmap/cilium-config created
+✅ Detected minikube version "1.20.0"
-serviceaccount/cilium created
+ℹ️  Cilium version not set, using default version "v1.10.0"
-serviceaccount/cilium-operator created
+🔮 Auto-detected cluster name: minikube
-clusterrole.rbac.authorization.k8s.io/cilium created
+🔮 Auto-detected IPAM mode: cluster-pool
-clusterrole.rbac.authorization.k8s.io/cilium-operator created
+🔮 Auto-detected datapath mode: tunnel
-clusterrolebinding.rbac.authorization.k8s.io/cilium created
+🔑 Generating CA...
-clusterrolebinding.rbac.authorization.k8s.io/cilium-operator created
+2021/05/27 02:54:44 [INFO] generate received request
-daemonset.apps/cilium create
+2021/05/27 02:54:44 [INFO] received CSR
-deployment.apps/cilium-operator created
+2021/05/27 02:54:44 [INFO] generating key: ecdsa-256
 2021/05/27 02:54:44 [INFO] encoded CSR
 2021/05/27 02:54:44 [INFO] signed certificate with serial number 48713764918856674401136471229482703021230538642
 🔑 Generating certificates for Hubble...
 2021/05/27 02:54:44 [INFO] generate received request
 2021/05/27 02:54:44 [INFO] received CSR
 2021/05/27 02:54:44 [INFO] generating key: ecdsa-256
 2021/05/27 02:54:44 [INFO] encoded CSR
 2021/05/27 02:54:44 [INFO] signed certificate with serial number 3514109734025784310086389188421560613333279574
 🚀 Creating Service accounts...
 🚀 Creating Cluster roles...
 🚀 Creating ConfigMap...
 🚀 Creating Agent DaemonSet...
 🚀 Creating Operator Deployment...
 ⌛ Waiting for Cilium to be installed...
 ```
 <!--
@@ -126,15 +135,15 @@ this list of Pods run:
 部署使用 Cilium 的集群会添加 Pods 到 `kube-system` 命名空间。要查看 Pod 列表，运行：
 ```shell
-kubectl get pods --namespace=kube-system
+kubectl get pods --namespace=kube-system -l k8s-app=cilium
 ```
 <!-- You'll see a list of Pods similar to this: -->
 你将看到像这样的 Pods 列表：
 ```console
-NAME            READY   STATUS    RESTARTS   AGE
+NAME           READY   STATUS    RESTARTS   AGE
-cilium-6rxbd    1/1     Running   0          1m
+cilium-kkdhz   1/1     Running   0          3m23s
 ...
 ```
@@ -26,7 +26,7 @@ itself. Unless resources are set aside for these system daemons, pods and system
 daemons compete for resources and lead to resource starvation issues on the
 node.
-The `kubelet` exposes a feature named `Node Allocatable` that helps to reserve
+The `kubelet` exposes a feature named 'Node Allocatable' that helps to reserve
 compute resources for system daemons. Kubernetes recommends cluster
 administrators to configure `Node Allocatable` based on their workload density
 on each node.
@@ -35,12 +35,11 @@ Kubernetes 的节点可以按照 `Capacity` 调度。默认情况下 pod 能够
 这是个问题，因为节点自己通常运行了不少驱动 OS 和 Kubernetes 的系统守护进程。
 除非为这些系统守护进程留出资源，否则它们将与 pod 争夺资源并导致节点资源短缺问题。
-`kubelet` 公开了一个名为 `Node Allocatable` 的特性，有助于为系统守护进程预留计算资源。
+`kubelet` 公开了一个名为 'Node Allocatable' 的特性，有助于为系统守护进程预留计算资源。
 Kubernetes 推荐集群管理员按照每个节点上的工作负载密度配置 `Node Allocatable`。
 ## {{% heading "prerequisites" %}}
 {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
 <!-- 
 Your Kubernetes server must be at or later than version 1.17 to use
@@ -58,9 +57,9 @@ the kubelet command line option `--reserved-cpus` to set an
 ![node capacity](/images/docs/node-capacity.svg)
-`Allocatable` on a Kubernetes node is defined as the amount of compute resources
+'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.
+'Allocatable'. 'CPU', 'memory' and 'ephemeral-storage' are supported as of now.
 Node Allocatable is exposed as part of `v1.Node` object in the API and as part
 of `kubectl describe node` in the CLI.
@@ -71,9 +70,9 @@ Resources can be reserved for two categories of system daemons in the `kubelet`.
 ![节点容量](/images/docs/node-capacity.svg)
-Kubernetes 节点上的 `Allocatable` 被定义为 pod 可用计算资源量。
+Kubernetes 节点上的 'Allocatable' 被定义为 pod 可用计算资源量。
-调度器不会超额申请 `Allocatable`。
+调度器不会超额申请 'Allocatable'。
-目前支持 `CPU`, `memory` 和 `ephemeral-storage` 这几个参数。
+目前支持 'CPU', 'memory' 和 'ephemeral-storage' 这几个参数。
 可分配的节点暴露为 API 中 `v1.Node` 对象的一部分，也是 CLI 中
 `kubectl describe node` 的一部分。
@@ -167,8 +166,7 @@ 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
+[the design proposal](https://git.k8s.io/community/contributors/design-proposals/node/node-allocatable.md#recommended-cgroups-setup)
 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
@@ -181,7 +179,7 @@ exist. Kubelet will fail if an invalid cgroup is specified.
 `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 将 **不会** 创建它。
@@ -225,8 +223,8 @@ kubelet flag.
 It is recommended that the OS system daemons are placed under a top level
 control group (`system.slice` on systemd machines for example).
-Note that Kubelet **does not** create `--system-reserved-cgroup` if it doesn't
+Note that `kubelet` **does not** create `--system-reserved-cgroup` if it doesn't
-exist. Kubelet will fail if an invalid cgroup is specified.
+exist. `kubelet` will fail if an invalid cgroup is specified.
 -->
 要想为系统守护进程上可选地实施 `system-reserved` 约束，请指定 kubelet 的
 `--system-reserved-cgroup` 标志值为 OS 系统守护进程的父级控制组。
@@ -234,19 +232,19 @@ exist. Kubelet will fail if an invalid cgroup is specified.
 推荐将 OS 系统守护进程放在一个顶级控制组之下（例如 systemd 机器上的
 `system.slice`）。
-请注意，如果 `--system-reserved-cgroup` 不存在，Kubelet **不会** 创建它。
+请注意，如果 `--system-reserved-cgroup` 不存在，`kubelet` **不会** 创建它。
-如果指定了无效的 cgroup，Kubelet 将会失败。
+如果指定了无效的 cgroup，`kubelet` 将会失败。
 <!--
 ### Explicitly Reserved CPU List
- **Kubelet Flag**: `--reserved-cpus=0-3`
+-**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`
+-**Kubelet 标志**: `--reserved-cpus=0-3`
 <!--
 `reserved-cpus` is meant to define an explicit CPU set for OS system daemons and
@@ -290,9 +288,10 @@ cpuset 上，应使用 Kubernetes 之外的其他机制。
 Memory pressure at the node level leads to System OOMs which affects the entire
 node and all pods running on it. Nodes can go offline temporarily until memory
 has been reclaimed. To avoid (or reduce the probability of) system OOMs kubelet
-provides [`Out of Resource`](/docs/tasks/administer-cluster/out-of-resource/) management. Evictions are
+provides [out of resource](/docs/concepts/scheduling-eviction/node-pressure-eviction/)
 management. Evictions are
 supported for `memory` and `ephemeral-storage` only. By reserving some memory via
-`--eviction-hard` flag, the `kubelet` attempts to `evict` pods whenever memory
+`--eviction-hard` flag, the `kubelet` attempts to evict pods whenever memory
 availability on the node drops below the reserved value. Hypothetically, if
 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
@@ -305,24 +304,25 @@ available for pods.
 节点级别的内存压力将导致系统内存不足，这将影响到整个节点及其上运行的所有 Pod。
 节点可以暂时离线直到内存已经回收为止。
 为了防止（或减少可能性）系统内存不足，kubelet 提供了
-[资源不足](/zh/docs/tasks/administer-cluster/out-of-resource/)管理。
+[资源不足](/zh/docs/concepts/scheduling-eviction/node-pressure-eviction/)管理。
 驱逐操作只支持 `memory` 和 `ephemeral-storage`。
 通过 `--eviction-hard` 标志预留一些内存后，当节点上的可用内存降至保留值以下时，
-`kubelet` 将尝试`驱逐` Pod。
+`kubelet` 将尝试驱逐 Pod。
 如果节点上不存在系统守护进程，Pod 将不能使用超过 `capacity-eviction-hard` 所
 指定的资源量。因此，为驱逐而预留的资源对 Pod 是不可用的。
 <!--
 ### Enforcing Node Allocatable
- **Kubelet Flag**: `--enforce-node-allocatable=pods[,][system-reserved][,][kube-reserved]`
+-**Kubelet Flag**: `--enforce-node-allocatable=pods[,][system-reserved][,][kube-reserved]`
-The scheduler treats `Allocatable` as the available `capacity` for pods.
+The scheduler treats 'Allocatable' as the available `capacity` for pods.
-`kubelet` enforce `Allocatable` across pods by default. Enforcement is performed
+`kubelet` enforce 'Allocatable' across pods by default. Enforcement is performed
 by evicting pods whenever the overall usage across all pods exceeds
-`Allocatable`. More details on eviction policy can be found
+'Allocatable'. More details on eviction policy can be found
-[here](/docs/tasks/administer-cluster/out-of-resource/#eviction-policy). This enforcement is controlled by
+on the [node pressure eviction](/docs/concepts/scheduling-eviction/node-pressure-eviction/)
 page. 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
@@ -333,14 +333,14 @@ respectively.
 -->
 ### 实施节点可分配约束   {#enforcing-node-allocatable}
- **Kubelet 标志**: `--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` 约束。
+`kubelet` 默认对 Pod 执行 'Allocatable' 约束。
-无论何时，如果所有 Pod 的总用量超过了 `Allocatable`，驱逐 Pod 的措施将被执行。
+无论何时，如果所有 Pod 的总用量超过了 'Allocatable'，驱逐 Pod 的措施将被执行。
 有关驱逐策略的更多细节可以在
-[这里](/zh/docs/tasks/administer-cluster/out-of-resource/#eviction-policy)找到。
+[节点压力驱逐](/zh/docs/concepts/scheduling-eviction/node-pressure-eviction/)页找到。
 可通过设置 kubelet `--enforce-node-allocatable` 标志值为 `pods` 控制这个措施。
 可选地，通过在同一标志中同时指定 `kube-reserved` 和 `system-reserved` 值，
@@ -351,7 +351,7 @@ respectively.
 <!--
 ## General Guidelines
-System daemons are expected to be treated similar to `Guaranteed` pods. System
+System daemons are expected to be treated similar to 'Guaranteed' pods. System
 daemons can burst within their bounding control groups and this behavior needs
 to be managed as part of kubernetes deployments. For example, `kubelet` should
 have its own control group and share `Kube-reserved` resources with the
@@ -360,7 +360,7 @@ resources if `kube-reserved` is enforced.
 -->
 ## 一般原则   {#general-guidelines}
-系统守护进程一般会被按照类似 `Guaranteed` Pod 一样对待。
+系统守护进程一般会被按照类似 'Guaranteed' Pod 一样对待。
 系统守护进程可以在与其对应的控制组中出现突发资源用量，这一行为要作为
 kubernetes 部署的一部分进行管理。
 例如，`kubelet` 应该有它自己的控制组并和容器运行时共享 `Kube-reserved` 资源。
@@ -373,9 +373,9 @@ to critical system services being CPU starved, OOM killed, or unable
 to fork on the node. The
 recommendation is to enforce `system-reserved` only if a user has profiled their
 nodes exhaustively to come up with precise estimates and is confident in their
-ability to recover if any process in that group is oom_killed.
+ability to recover if any process in that group is oom-killed.
-* To begin with enforce `Allocatable` on `pods`.
+* To begin with enforce 'Allocatable' on `pods`.
 * 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.
@@ -386,7 +386,7 @@ ability to recover if any process in that group is oom_killed.
 并且对该组中进程因内存不足而被杀死时，有足够的信心将其恢复时，
 才可以强制执行 `system-reserved` 策略。
-* 作为起步，可以先针对 `pods` 上执行 `Allocatable` 约束。
+* 作为起步，可以先针对 `pods` 上执行 'Allocatable' 约束。
 * 一旦用于追踪系统守护进程的监控和告警的机制到位，可尝试基于用量估计的
  方式执行 `kube-reserved`策略。
 * 随着时间推进，在绝对必要的时候可以执行 `system-reserved` 策略。
@@ -424,27 +424,27 @@ Here is an example to illustrate Node Allocatable computation:
 * `--eviction-hard` 被设置为 `memory.available<500Mi,nodefs.available<10%`
 <!--
-Under this scenario, `Allocatable` will be `14.5 CPUs`, `28.5Gi` of memory and
+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
-not exceed `28.5Gi` and storage doesn't exceed `88Gi`.
+not exceed 28.5Gi and storage doesn't exceed 88Gi.
-Kubelet evicts pods whenever the overall memory usage across pods exceeds `28.5Gi`,
+Kubelet evicts pods whenever the overall memory usage across pods exceeds 28.5Gi,
-or if overall disk usage exceeds `88Gi` If all processes on the node consume as
+or if overall disk usage exceeds 88Gi If all processes on the node consume as
-much CPU as they can, pods together cannot consume more than `14.5 CPUs`.
+much CPU as they can, pods together cannot consume more than 14.5 CPUs.
 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`
+usage is higher than 31.5Gi or `storage` is greater than 90Gi
 -->
-在这个场景下，`Allocatable` 将会是 `14.5 CPUs`、`28.5Gi` 内存以及 `88Gi` 本地存储。
+在这个场景下，'Allocatable' 将会是 14.5 CPUs、28.5Gi 内存以及 `88Gi` 本地存储。
-调度器保证这个节点上的所有 Pod 的内存 `requests` 总量不超过 `28.5Gi`，
+调度器保证这个节点上的所有 Pod 的内存 `requests` 总量不超过 28.5Gi，
-存储不超过 `88Gi`。
+存储不超过 '88Gi'。
-当 Pod 的内存使用总量超过 `28.5Gi` 或者磁盘使用总量超过 `88Gi` 时，
+当 Pod 的内存使用总量超过 28.5Gi 或者磁盘使用总量超过 88Gi 时，
 kubelet 将会驱逐它们。
 如果节点上的所有进程都尽可能多地使用 CPU，则 Pod 加起来不能使用超过
-`14.5 CPUs` 的资源。
+14.5 CPUs 的资源。
 当没有执行 `kube-reserved` 和/或 `system-reserved` 策略且系统守护进程
-使用量超过其预留时，如果节点内存用量高于 `31.5Gi` 或`存储`大于 `90Gi`，
+使用量超过其预留时，如果节点内存用量高于 31.5Gi 或`存储`大于 90Gi，
 kubelet 将会驱逐 Pod。