Merge pull request #33708 from mengjiao-liu/cluster-term-zh

[zh] Part1:updated the term "群集" to "集群"
2022-05-16 20:49:35 -07:00
parent 76d91f11ec fb1a2cb54a
commit 534732f312
33 changed files with 46 additions and 46 deletions
@@ -41,7 +41,7 @@ To start things off, here's a roundup of recent Kubernetes posts from other site
 -->

 - [使用 Vitess 和 Kubernetes 在云中扩展 MySQL](http://googlecloudplatform.blogspot.com/2015/03/scaling-MySQL-in-the-cloud-with-Vitess-and-Kubernetes.html)
- [虚拟机上的容器群集](http://googlecloudplatform.blogspot.com/2015/02/container-clusters-on-vms.html)
+- [虚拟机上的容器集群](http://googlecloudplatform.blogspot.com/2015/02/container-clusters-on-vms.html)
 - [想知道的关于 kubernetes 的一切，却又不敢问](http://googlecloudplatform.blogspot.com/2015/01/everything-you-wanted-to-know-about-Kubernetes-but-were-afraid-to-ask.html)
 - [什么构成容器集群？](http://googlecloudplatform.blogspot.com/2015/01/what-makes-a-container-cluster.html)
 - [将 OpenStack 和 Kubernetes 与 Murano 集成](https://www.mirantis.com/blog/integrating-openstack-and-kubernetes-with-murano/)
@@ -41,7 +41,7 @@ The Dashboard UI now handles all workload resources. This means that no matter w
 [![](https://lh3.googleusercontent.com/p9bMGxPx4jE6_Z2KB-MktmyuAxyFst-bEk29M_Bn0Bj5ul7uzinH6u5WjHsMmqhGvBwlABZt06dwQ5qkBZiLq_EM1oddCmpwChvXDNXZypaS5l8uzkKuZj3PBUmzTQT4dgDxSXgz) ](https://lh3.googleusercontent.com/p9bMGxPx4jE6_Z2KB-MktmyuAxyFst-bEk29M_Bn0Bj5ul7uzinH6u5WjHsMmqhGvBwlABZt06dwQ5qkBZiLq_EM1oddCmpwChvXDNXZypaS5l8uzkKuZj3PBUmzTQT4dgDxSXgz)
 -->

-Dashboard UI 现在处理所有工作负载资源。这意味着无论您运行什么工作负载类型，它都在 web 界面中可见，并且您可以对其进行操作更改。例如，可以使用[Pet Sets](/docs/user-guide/petset/)修改有状态的 mysql 安装，使用部署对 web 服务器进行滚动更新，或使用守护程序安装群集监视。
+Dashboard UI 现在处理所有工作负载资源。这意味着无论您运行什么工作负载类型，它都在 web 界面中可见，并且您可以对其进行操作更改。例如，可以使用[Pet Sets](/docs/user-guide/petset/)修改有状态的 mysql 安装，使用部署对 web 服务器进行滚动更新，或使用守护程序安装集群监视。



@@ -105,9 +105,9 @@ Here is a list of our focus areas for the following months:

 以下是我们接下来几个月的重点领域：

- [Handle more Kubernetes resources](https://github.com/kubernetes/dashboard/issues/961) - 显示群集用户可能与之交互的所有资源。一旦完成，dashboard 就可以完全替代cli。
+- [Handle more Kubernetes resources](https://github.com/kubernetes/dashboard/issues/961) - 显示集群用户可能与之交互的所有资源。一旦完成，dashboard 就可以完全替代cli。
 - [Monitoring and troubleshooting](https://github.com/kubernetes/dashboard/issues/962) - 将资源使用统计信息/图表添加到 Dashboard 中显示的对象。这个重点领域将允许对云应用程序进行可操作的调试和故障排除。
- [Security, auth and logging in](https://github.com/kubernetes/dashboard/issues/964) - 使仪表板可从群集外部的网络访问，并使用自定义身份验证系统。
+- [Security, auth and logging in](https://github.com/kubernetes/dashboard/issues/964) - 使仪表板可从集群外部的网络访问，并使用自定义身份验证系统。

 <!--
 **Connect With Us**
@@ -85,7 +85,7 @@ It’s easy to imagine powerful multi-cluster use cases with cross-cluster feder
 很容易想象在将来的版本中具有跨集群联邦服务的强大多集群用例。
 一个示例是根据治理，安全性和性能要求调度容器。
 Diamanti 的调度程序扩展是在考虑了这一概念的基础上开发的。
-我们的[第一个实现](https://github.com/kubernetes/kubernetes/pull/13580)使 Kubernetes 调度程序意识到每个群集节点本地的网络和存储资源。
+我们的[第一个实现](https://github.com/kubernetes/kubernetes/pull/13580)使 Kubernetes 调度程序意识到每个集群节点本地的网络和存储资源。
 将来，类似的概念可以应用于跨集群联邦服务的更广泛的放置控件。

 <!--
@@ -545,7 +545,7 @@ Kubernetes Executor是另一种Airflow功能，允许动态分配任务已解决



-最后，我们在您的群集上创建完整的Airflow部署。这包括Airflow配置，postgres后端，webserver +调度程序以及之间的所有必要服务。需要注意的一点是，提供的角色绑定是集群管理员，因此如果您没有该集群的权限级别，可以在scripts / ci / kubernetes / kube / airflow.yaml中进行修改。
+最后，我们在您的集群上创建完整的Airflow部署。这包括Airflow配置，postgres后端，webserver +调度程序以及之间的所有必要服务。需要注意的一点是，提供的角色绑定是集群管理员，因此如果您没有该集群的权限级别，可以在scripts / ci / kubernetes / kube / airflow.yaml中进行修改。



@@ -143,7 +143,7 @@ can do beyond that specification.
 --->
 ## 一些特殊功能

-标准的 CoreDNS Kubernetes 配置旨在与以前的 kube-dns 在行为上向后兼容。但是，通过进行一些配置更改，CoreDNS 允许您修改 DNS 服务发现在群集中的工作方式。这些功能中的许多功能仍要符合 [Kubernetes DNS规范](https://github.com/kubernetes/dns/blob/master/docs/specification.md)；它们在增强了功能的同时保持向后兼容。由于 CoreDNS 并非 *仅* 用于 Kubernetes，而是通用的 DNS 服务器，因此您可以做很多超出该规范的事情。
+标准的 CoreDNS Kubernetes 配置旨在与以前的 kube-dns 在行为上向后兼容。但是，通过进行一些配置更改，CoreDNS 允许您修改 DNS 服务发现在集群中的工作方式。这些功能中的许多功能仍要符合 [Kubernetes DNS规范](https://github.com/kubernetes/dns/blob/master/docs/specification.md)；它们在增强了功能的同时保持向后兼容。由于 CoreDNS 并非 *仅* 用于 Kubernetes，而是通用的 DNS 服务器，因此您可以做很多超出该规范的事情。

 <!--
 ### Pods verified mode
@@ -93,7 +93,7 @@ Dynamic Kubelet configuration provides the following core features:
 <!--
 To use the dynamic Kubelet configuration feature, a cluster administrator or service provider will first post a ConfigMap containing the desired configuration, then set each Node.Spec.ConfigSource.ConfigMap reference to refer to the new ConfigMap. Operators can update these references at their preferred rate, giving them the ability to perform controlled rollouts of new configurations.
 -->
-要使用动态 Kubelet 配置功能，群集管理员或服务提供商将首先发布包含所需配置的 ConfigMap，
+要使用动态 Kubelet 配置功能，集群管理员或服务提供商将首先发布包含所需配置的 ConfigMap，
 然后设置每个 Node.Spec.ConfigSource.ConfigMap 引用以指向新的 ConfigMap。
 运营商可以以他们喜欢的速率更新这些参考，从而使他们能够执行新配置的受控部署。

@@ -85,7 +85,7 @@ Kubernetes 资源模型期望 Pod 中的容器之间可以共享某些资源。
 The RuntimeClass resource is an important foundation for surfacing runtime properties to the control plane. For example, to implement scheduler support for clusters with heterogeneous nodes supporting different runtimes, we might add [NodeAffinity](/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity) terms to the RuntimeClass definition. Another area to address is managing the variable resource requirements to run pods of different runtimes. The [Pod Overhead proposal](https://docs.google.com/document/d/1EJKT4gyl58-kzt2bnwkv08MIUZ6lkDpXcxkHqCvvAp4/preview) was an early take on this that aligns nicely with the RuntimeClass design, and may be pursued further.
 -->
 RuntimeClass 资源是将运行时属性显示到控制平面的重要基础。
-例如，要对具有支持不同运行时间的异构节点的群集实施调度程序支持，我们可以在 RuntimeClass 定义中添加
+例如，要对具有支持不同运行时间的异构节点的集群实施调度程序支持，我们可以在 RuntimeClass 定义中添加
 [NodeAffinity](/zh/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity)条件。
 另一个需要解决的领域是管理可变资源需求以运行不同运行时的 Pod。
 [Pod Overhead 提案](https://docs.google.com/document/d/1EJKT4gyl58-kzt2bnwkv08MIUZ6lkDpXcxkHqCvvAp4/preview)
@@ -107,7 +107,7 @@ Many other RuntimeClass extensions have also been proposed, and will be revisite
 - 提供运行时支持的可选功能，并更好地查看由不兼容功能导致的错误。
 - 自动运行时或功能发现，支持无需手动配置的调度决策。
 - 标准化或一致的 RuntimeClass 名称，用于定义一组具有相同名称的 RuntimeClass 的集群应支持的属性。
- 动态注册附加的运行时，因此用户可以在不停机的情况下在现有群集上安装新的运行时。
+- 动态注册附加的运行时，因此用户可以在不停机的情况下在现有集群上安装新的运行时。
 - 根据 Pod 的要求“匹配”  RuntimeClass。
  例如，指定运行时属性并使系统与适当的 RuntimeClass 匹配，而不是通过名称显式分配 RuntimeClass。

@@ -34,7 +34,7 @@ In such a scenario, it’s possible for something akin to a fork bomb taking pla

 在这里，我们谈论的是某些容器的贪婪性。 在理想情况之外，失控进程有时会发生，特别是在测试集群中。 因此，在这些集群中会发生一些混乱的非生产环境准备就绪的事情。

-在这种情况下，可能会在节点内部发生类似于 fork 炸弹耗尽 PID 的攻击。随着资源的缓慢腐蚀，被一些不断产生子进程的僵尸般的进程所接管，其他正常的工作负载会因为这些像气球般不断膨胀的浪费的处理能力而开始受到冲击。这可能导致同一 Pod 上的其他进程缺少所需的 PID。这也可能导致有趣的副作用，因为节点可能会发生故障，并且该Pod的副本将安排到新的机器上，至此，该过程将在整个群集中重复进行。
+在这种情况下，可能会在节点内部发生类似于 fork 炸弹耗尽 PID 的攻击。随着资源的缓慢腐蚀，被一些不断产生子进程的僵尸般的进程所接管，其他正常的工作负载会因为这些像气球般不断膨胀的浪费的处理能力而开始受到冲击。这可能导致同一 Pod 上的其他进程缺少所需的 PID。这也可能导致有趣的副作用，因为节点可能会发生故障，并且该Pod的副本将安排到新的机器上，至此，该过程将在整个集群中重复进行。

 <!--
 ## Fixing the Problem
@@ -61,7 +61,7 @@ For example, you can enforce policies like:
 <!--
 Kubernetes allows decoupling policy decisions from the API server by means of [admission controller webhooks](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/) to intercept admission requests before they are persisted as objects in Kubernetes. [Gatekeeper](https://github.com/open-policy-agent/gatekeeper) was created to enable users to customize admission control via configuration, not code and to bring awareness of the cluster’s state, not just the single object under evaluation at admission time. Gatekeeper is a customizable admission webhook for Kubernetes that enforces policies executed by the [Open Policy Agent (OPA)](https://www.openpolicyagent.org), a policy engine for Cloud Native environments hosted by CNCF.
 --->
-在接收请求被持久化为 Kubernetes 中的对象之前，Kubernetes 允许通过 [admission controller webhooks](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/) 将策略决策与 API 服务器分离，从而拦截这些请求。[Gatekeeper](https://github.com/open-policy-agent/gatekeeper) 创建的目的是使用户能够通过配置（而不是代码）自定义控制许可，并使用户了解群集的状态，而不仅仅是针对评估状态的单个对象，在这些对象准许加入的时候。Gatekeeper 是 Kubernetes 的一个可定制的许可 webhook ，它由 [Open Policy Agent (OPA)](https://www.openpolicyagent.org) 强制执行， OPA 是 Cloud Native 环境下的策略引擎，由 CNCF 主办。
+在接收请求被持久化为 Kubernetes 中的对象之前，Kubernetes 允许通过 [admission controller webhooks](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/) 将策略决策与 API 服务器分离，从而拦截这些请求。[Gatekeeper](https://github.com/open-policy-agent/gatekeeper) 创建的目的是使用户能够通过配置（而不是代码）自定义控制许可，并使用户了解集群的状态，而不仅仅是针对评估状态的单个对象，在这些对象准许加入的时候。Gatekeeper 是 Kubernetes 的一个可定制的许可 webhook ，它由 [Open Policy Agent (OPA)](https://www.openpolicyagent.org) 强制执行， OPA 是 Cloud Native 环境下的策略引擎，由 CNCF 主办。

 <!--
 ## Evolution 
@@ -206,7 +206,7 @@ As you can see, with the Constraint framework, we can reliably share Regos via t
 The audit functionality enables periodic evaluations of replicated resources against the Constraints enforced in the cluster to detect pre-existing misconfigurations. Gatekeeper stores audit results as `violations` listed in the `status` field of the relevant Constraint.  --->
 ### 审核 

-根据群集中强制执行的 Constraint，审核功能可定期评估复制的资源，并检测先前存在的错误配置。Gatekeeper 将审核结果存储为 `violations`，在相关 Constraint 的 `status` 字段中列出。
+根据集群中强制执行的 Constraint，审核功能可定期评估复制的资源，并检测先前存在的错误配置。Gatekeeper 将审核结果存储为 `violations`，在相关 Constraint 的 `status` 字段中列出。

 ```yaml
 apiVersion: constraints.gatekeeper.sh/v1beta1
@@ -271,7 +271,7 @@ With this toolset DANM is able to provide multiple separated network interfaces,
 它由以下几个组件构成：

 * 能够配置具有高级功能的 IPVLAN 接口的 CNI 插件
-* 一个内置的 IPAM 模块，能够管理多个、群集内的、不连续的 L3 网络，并按请求提供动态、静态或无 IP 分配方案
+* 一个内置的 IPAM 模块，能够管理多个、集群内的、不连续的 L3 网络，并按请求提供动态、静态或无 IP 分配方案
 * CNI 元插件能够通过自己的 CNI 或通过将任务授权给其他任何流行的 CNI 解决方案（例如 SRI-OV 或 Flannel）来实现将多个网络接口连接到容器
 * Kubernetes 控制器能够集中管理所有 Kubernetes 主机的 VxLAN 和 VLAN 接口
 * 另一个 Kubernetes 控制器扩展了 Kubernetes 的基于服务的服务发现概念，以在 Pod 的所有网络接口上工作
@@ -59,7 +59,7 @@ There are several different proxies you may encounter when using Kubernetes:
 2. [apiserver proxy](/zh/docs/tasks/access-application-cluster/access-cluster/#discovering-builtin-services)：

    - 是一个建立在 apiserver 内部的“堡垒”
-    - 将集群外部的用户与群集 IP 相连接，这些IP是无法通过其他方式访问的
+    - 将集群外部的用户与集群 IP 相连接，这些IP是无法通过其他方式访问的
    - 运行在 apiserver 进程内
    - 客户端到代理使用 HTTPS 协议 (如果配置 apiserver 使用 HTTP 协议，则使用 HTTP 协议)
    - 通过可用信息进行选择，代理到目的地可能使用 HTTP 或 HTTPS 协议
@@ -163,7 +163,7 @@ Dynamic provisioning can be enabled on a cluster such that all claims are
 dynamically provisioned if no storage class is specified. A cluster administrator
 can enable this behavior by:
 -->
-可以在群集上启用动态卷供应，以便在未指定存储类的情况下动态设置所有声明。
+可以在集群上启用动态卷供应，以便在未指定存储类的情况下动态设置所有声明。
 集群管理员可以通过以下方式启用此行为：

 <!--
@@ -191,7 +191,7 @@ Note that there can be at most one *default* storage class on a cluster, or
 a `PersistentVolumeClaim` without `storageClassName` explicitly specified cannot
 be created.
 -->
-请注意，群集上最多只能有一个 *默认* 存储类，否则无法创建没有明确指定
+请注意，集群上最多只能有一个 *默认* 存储类，否则无法创建没有明确指定
 `storageClassName` 的 `PersistentVolumeClaim`。

 <!--
@@ -1107,7 +1107,7 @@ parameters:
 * `location`：Azure 存储帐户位置。默认为空。
 * `storageAccount`：Azure 存储帐户名称。
  如果提供存储帐户，它必须位于与集群相同的资源组中，并且 `location`
-  是被忽略的。如果未提供存储帐户，则会在与群集相同的资源组中创建新的存储帐户。
+  是被忽略的。如果未提供存储帐户，则会在与集群相同的资源组中创建新的存储帐户。

 <!--
 #### Azure Disk Storage Class (starting from v1.7.2) {#azure-disk-storage-class}
@@ -38,5 +38,5 @@ scale the cluster; performing software upgrades; implementing security
 controls; adding or removing storage; configuring cluster networking;
 managing cluster-wide observability; and responding to events.
 -->															  
-群集操作工作的示例包括：部署新节点来扩容集群；执行软件升级；实施安全控制；
+集群操作工作的示例包括：部署新节点来扩容集群；执行软件升级；实施安全控制；
 添加或删除存储；配置集群网络；管理集群范围的可观测性；响应集群事件。
@@ -99,7 +99,7 @@ By using kubectl, you can create a [Deployment](/docs/concepts/workloads/control
 在 kubectl 命令中，我们创建了一个 [Deployment](/zh/docs/concepts/workloads/controllers/deployment/)，
 这将保证有 N 个运行 nginx 的 Pod(N 代表 spec 中声明的 replica 数，默认为 1)。
 我们还创建了一个 [service](/zh/docs/concepts/services-networking/service/)，其选择器与容器标签匹配。
-查看[使用服务访问群集中的应用程序](/zh/docs/tasks/access-application-cluster/service-access-application-cluster) 获取更多信息。
+查看[使用服务访问集群中的应用程序](/zh/docs/tasks/access-application-cluster/service-access-application-cluster) 获取更多信息。

 <!--
 By default images run in the background, similar to `docker run -d ...`. To run things in the foreground, use [`kubectl run`](/docs/reference/generated/kubectl/kubectl-commands/#run) to create pod:
@@ -11,7 +11,7 @@ Upgrade the kubelet configuration for this node
 Download the kubelet configuration from the kubelet-config ConfigMap stored in the cluster
 -->

-从群集中 ConfigMap kubelet-config 下载 kubelet 配置
+从集群中 ConfigMap kubelet-config 下载 kubelet 配置

 ```
 kubeadm upgrade node phase kubelet-config [flags]
@@ -204,7 +204,7 @@ no longer get your clusters confused, you can share clusters with your colleague
 and you can reach them without relying on remembering an IP address.
 -->
 kops 对集群名称有明显的要求：它应该是有效的 DNS 名称。这样一来，你就不会再使集群混乱，
-可以与同事明确共享集群，并且无需依赖记住 IP 地址即可访问群集。
+可以与同事明确共享集群，并且无需依赖记住 IP 地址即可访问集群。

 <!--
 You can, and probably should, use subdomains to divide your clusters.  As our example we will use
@@ -791,7 +791,7 @@ However, if you want to deprovision your cluster more cleanly, you should
 first [drain the node](/docs/reference/generated/kubectl/kubectl-commands#drain)
 and make sure that the node is empty, then deconfigure the node.
 -->
-但是，如果要更干净地取消配置群集，
+但是，如果要更干净地取消配置集群，
 则应首先[清空节点](/docs/reference/generated/kubectl/kubectl-commands#drain)并确保该节点为空，
 然后取消配置该节点。

@@ -379,7 +379,7 @@ option. Your cluster requirements may need a different configuration.
   As stated in the command output, the certificate key gives access to cluster sensitive data, keep it secret!
   -->
   {{< caution >}}
-   正如命令输出中所述，证书密钥可访问群集敏感数据。请妥善保管！
+   正如命令输出中所述，证书密钥可访问集群敏感数据。请妥善保管！
   {{< /caution >}}

 <!--
@@ -367,7 +367,7 @@ on Kubernetes dual-stack support see [Dual-stack support with kubeadm](/docs/set
 <!--
 1. Optional: Check the cluster health
 -->
-8. 可选：检查群集运行状况
+8. 可选：检查集群运行状况

   ```shell
   docker run --rm -it \
@@ -122,7 +122,7 @@ your configuration file:
 配置文件描述了集群、用户名和上下文。`config-demo` 文件中含有描述两个集群、
 两个用户和三个上下文的框架。

-进入 `config-exercise` 目录。输入以下命令，将群集详细信息添加到配置文件中：
+进入 `config-exercise` 目录。输入以下命令，将集群详细信息添加到配置文件中：

 ```shell
 kubectl config --kubeconfig=config-demo set-cluster development --server=https://1.2.3.4 --certificate-authority=fake-ca-file
@@ -65,7 +65,7 @@ Once you have upgraded the cluster, remember to
 [install the latest version of `kubectl`](/docs/tasks/tools/).
 -->
 如果你的集群是使用 `kubeadm` 安装工具部署而来，
-那么升级群集的详细信息，请参阅
+那么升级集群的详细信息，请参阅
 [升级 kubeadm 集群](/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)。

 升级集群之后，要记得
@@ -111,7 +111,7 @@ kubelet on that node and bring the node back into service.
 现在，你应该
 [安装最新版本的 `kubectl`](/zh/docs/tasks/tools/).

-对于群集中的每个节点，
+对于集群中的每个节点，
 [排空](/zh/docs/tasks/administer-cluster/safely-drain-node/)
 节点，然后，或者用一个运行了 {{< skew latestVersion >}} kubelet 的新节点替换它；
 或者升级此节点的 kubelet，并使节点恢复服务。
@@ -132,7 +132,7 @@ up steps for maintenance.

 ## 升级后的任务 {#post-upgrade-tasks}

-### 切换群集的存储 API 版本 {#switch-your-clusters-storage-api-version}
+### 切换集群的存储 API 版本 {#switch-your-clusters-storage-api-version}

 <!-- 
 The objects that are serialized into etcd for a cluster's internal
@@ -15,8 +15,8 @@ vacated by the evicted critical add-on pod or the amount of resources available
 -->
 Kubernetes 核心组件（如 API 服务器、调度器、控制器管理器）在控制平面节点上运行。
 但是插件必须在常规集群节点上运行。
-其中一些插件对于功能完备的群集至关重要，例如 Heapster、DNS 和 UI。
-如果关键插件被逐出（手动或作为升级等其他操作的副作用）或者变成挂起状态，群集可能会停止正常工作。
+其中一些插件对于功能完备的集群至关重要，例如 Heapster、DNS 和 UI。
+如果关键插件被逐出（手动或作为升级等其他操作的副作用）或者变成挂起状态，集群可能会停止正常工作。
 关键插件进入挂起状态的例子有：集群利用率过高；被逐出的关键插件 Pod 释放了空间，但该空间被之前悬决的 Pod 占用；由于其它原因导致节点上可用资源的总量发生变化。

 <!--
@@ -48,7 +48,7 @@ isolated from the rest of your cluster.
 -->
 ## 创建命名空间

-创建一个命名空间，以便在此练习中创建的资源与群集的其余资源隔离。
+创建一个命名空间，以便在此练习中创建的资源与集群的其余资源隔离。

 ```shell
 kubectl create namespace constraints-mem-example
@@ -36,7 +36,7 @@ This example demonstrates how to use Kubernetes namespaces to subdivide your clu
 -->
 使用多个名字空间是可选的。

-此示例演示了如何使用 Kubernetes 名字空间细分群集。
+此示例演示了如何使用 Kubernetes 名字空间细分集群。

 ## {{% heading "prerequisites" %}}

@@ -478,7 +478,7 @@ Use cases include:
 1.  作为集群运营者, 我希望能在单个集群上支持多个用户社区。
 2.  作为集群运营者，我希望将集群分区的权限委派给这些社区中的受信任用户。
 3.  作为集群运营者，我希望能限定每个用户社区可使用的资源量，以限制对使用同一集群的其他用户社区的影响。
-4.  作为群集用户，我希望与我的用户社区相关的资源进行交互，而与其他用户社区在该集群上执行的操作无关。
+4.  作为集群用户，我希望与我的用户社区相关的资源进行交互，而与其他用户社区在该集群上执行的操作无关。

 <!--
 ## Understanding namespaces and DNS
@@ -78,7 +78,7 @@ Successfully running cloud-controller-manager requires some changes to your clus
 <!--
 Keep in mind that setting up your cluster to use cloud controller manager will change your cluster behaviour in a few ways:
 -->
-请记住，设置群集使用云管理控制器将用多种方式更改群集行为：
+请记住，设置集群使用云管理控制器将用多种方式更改集群行为：

 <!--
 * kubelets specifying `--cloud-provider=external` will add a taint `node.cloudprovider.kubernetes.io/uninitialized` with an effect `NoSchedule` during initialization. This marks the node as needing a second initialization from an external controller before it can be scheduled work. Note that in the event that cloud controller manager is not available, new nodes in the cluster will be left unschedulable. The taint is important since the scheduler may require cloud specific information about nodes such as their region or type (high cpu, gpu, high memory, spot instance, etc).
@@ -249,7 +249,7 @@ prevent cross talk, or advanced networking policy.
 在很多集群上，节点端口和负载均衡服务也可控制用户的应用程序是否在集群之外可见。

 此外也可能存在一些基于插件或基于环境的网络规则，能够提供额外的保护能力。
-例如各节点上的防火墙、物理隔离群集节点以防止串扰或者高级的网络策略等。
+例如各节点上的防火墙、物理隔离集群节点以防止串扰或者高级的网络策略等。

 <!--
 ### Restricting cloud metadata API access
@@ -334,7 +334,7 @@ access to a subset of the keyspace is strongly recommended.

 {{< caution >}}
 允许集群中其它组件对整个主键空间（keyspace）拥有读或写权限去访问 etcd 实例，
-相当于授予这些组件群集管理员的访问权限。
+相当于授予这些组件集群管理员的访问权限。
 对于非主控组件，强烈推荐使用不同的 etcd 实例，或者使用 etcd 的访问控制列表
 来限制这些组件只能读或写主键空间的一个子集。
 {{< /caution >}}
@@ -39,7 +39,7 @@ There are a few setup requirements for getting the aggregation layer working in
 Reusing the same CA for different client types can negatively impact the cluster's ability to function. For more information, see [CA Reusage and Conflicts](#ca-reusage-and-conflicts).
 -->
 {{< caution >}}
-对不同的客户端类型重复使用相同的 CA 会对群集的功能产生负面影响。
+对不同的客户端类型重复使用相同的 CA 会对集群的功能产生负面影响。
 有关更多信息，请参见 [CA 重用和冲突](#ca-reusage-and-conflicts)。
 {{< /caution >}}

@@ -233,7 +233,7 @@ Kubernetes apiserver 使用它的标准认证和授权配置来对用户认证

 有关对 Kubernetes 集群认证的概述，请参见
 [对集群认证](/zh/docs/reference/access-authn-authz/authentication/)。
-有关对Kubernetes群集资源的访问鉴权的概述，请参见
+有关对Kubernetes集群资源的访问鉴权的概述，请参见
 [鉴权概述](/zh/docs/reference/access-authn-authz/authorization/)。

 到目前为止，所有内容都是标准的 Kubernetes API 请求，认证与鉴权。
@@ -45,7 +45,7 @@ weight: 10
                  </p>

                <!-- <p>Once the application instances are created, a Kubernetes Deployment Controller continuously monitors those instances. If the Node hosting an instance goes down or is deleted, the Deployment controller replaces the instance with an instance on another Node in the cluster. <b>This provides a self-healing mechanism to address machine failure or maintenance.</b></p> -->
-                <p>创建应用程序实例后，Kubernetes Deployment 控制器会持续监视这些实例。 如果托管实例的节点关闭或被删除，则 Deployment 控制器会将该实例替换为群集中另一个节点上的实例。 <b>这提供了一种自我修复机制来解决机器故障维护问题。</b></p>
+                <p>创建应用程序实例后，Kubernetes Deployment 控制器会持续监视这些实例。 如果托管实例的节点关闭或被删除，则 Deployment 控制器会将该实例替换为集群中另一个节点上的实例。 <b>这提供了一种自我修复机制来解决机器故障维护问题。</b></p>

                <!-- <p>In a pre-orchestration world, installation scripts would often be used to start applications, but they did not allow recovery from machine failure.  By both creating your application instances and keeping them running across Nodes, Kubernetes Deployments provide a fundamentally different approach to application management. </p> -->
                <p>在没有 Kubernetes 这种编排系统之前，安装脚本通常用于启动应用程序，但它们不允许从机器故障中恢复。通过创建应用程序实例并使它们在节点之间运行， Kubernetes Deployments 提供了一种与众不同的应用程序管理方法。</p>
@@ -63,7 +63,7 @@ weight: 10
 <!--
        <p>Pods are the atomic unit on the Kubernetes platform. When we create a Deployment on Kubernetes, that Deployment creates Pods with containers inside them (as opposed to creating containers directly). Each Pod is tied to the Node where it is scheduled, and remains there until termination (according to restart policy) or deletion. In case of a Node failure, identical Pods are scheduled on other available Nodes in the cluster.</p>
 -->
-        <p>Pod是 Kubernetes 平台上的原子单元。 当我们在 Kubernetes 上创建 Deployment 时，该 Deployment 会在其中创建包含容器的 Pod （而不是直接创建容器）。每个 Pod 都与调度它的工作节点绑定，并保持在那里直到终止（根据重启策略）或删除。 如果工作节点发生故障，则会在群集中的其他可用工作节点上调度相同的 Pod。</p>
+        <p>Pod是 Kubernetes 平台上的原子单元。 当我们在 Kubernetes 上创建 Deployment 时，该 Deployment 会在其中创建包含容器的 Pod （而不是直接创建容器）。每个 Pod 都与调度它的工作节点绑定，并保持在那里直到终止（根据重启策略）或删除。 如果工作节点发生故障，则会在集群中的其他可用工作节点上调度相同的 Pod。</p>

      </div>
      <div class="col-md-4">
@@ -124,7 +124,7 @@ weight: 10
        </ul>
 -->
        <h2>工作节点</h2>
-        <p>一个 pod 总是运行在 <b>工作节点</b>。工作节点是 Kubernetes 中的参与计算的机器，可以是虚拟机或物理计算机，具体取决于集群。每个工作节点由主节点管理。工作节点可以有多个 pod ，Kubernetes 主节点会自动处理在群集中的工作节点上调度 pod 。 主节点的自动调度考量了每个工作节点上的可用资源。</p>
+        <p>一个 pod 总是运行在 <b>工作节点</b>。工作节点是 Kubernetes 中的参与计算的机器，可以是虚拟机或物理计算机，具体取决于集群。每个工作节点由主节点管理。工作节点可以有多个 pod ，Kubernetes 主节点会自动处理在集群中的工作节点上调度 pod 。 主节点的自动调度考量了每个工作节点上的可用资源。</p>

        <p>每个 Kubernetes 工作节点至少运行:</p>
        <ul>
@@ -199,7 +199,7 @@ weight: 10
 <!--
          <p><i> A node is a worker machine in Kubernetes and may be a VM or physical machine, depending on the cluster. Multiple Pods can run on one Node. </i></p>
 -->
-          <p><i>工作节点是 Kubernetes 中的负责计算的机器，可能是VM或物理计算机，具体取决于群集。多个 Pod 可以在一个工作节点上运行。 </i></p>
+          <p><i>工作节点是 Kubernetes 中的负责计算的机器，可能是VM或物理计算机，具体取决于集群。多个 Pod 可以在一个工作节点上运行。 </i></p>
        </div>
      </div>
    </div>
@@ -520,7 +520,7 @@ PodSecurityPolicy 在 Kubernetes v1.21 版本中已被废弃，将在 v1.25 版
 If the PodSecurityPolicy extension is enabled, cluster-wide AppArmor restrictions can be applied. To
 enable the PodSecurityPolicy, the following flag must be set on the `apiserver`: 
 -->
-如果启用了 PodSecurityPolicy 扩展，则可以应用群集范围的 AppArmor 限制。
+如果启用了 PodSecurityPolicy 扩展，则可以应用集群范围的 AppArmor 限制。
 要启用 PodSecurityPolicy，必须在 `apiserver` 上设置以下标志：

 ```
@@ -117,7 +117,7 @@ When a PersistentVolumeClaim is created, a PersistentVolume is dynamically provi

 MySQL 和 Wordpress 都需要一个 PersistentVolume 来存储数据。他们的 PersistentVolumeClaims 将在部署步骤中创建。

-许多群集环境都安装了默认的 StorageClass。如果在 PersistentVolumeClaim 中未指定 StorageClass，则使用群集的默认 StorageClass。
+许多集群环境都安装了默认的 StorageClass。如果在 PersistentVolumeClaim 中未指定 StorageClass，则使用集群的默认 StorageClass。

 创建 PersistentVolumeClaim 时，将根据 StorageClass 配置动态设置 PersistentVolume。

@@ -126,7 +126,7 @@ MySQL 和 Wordpress 都需要一个 PersistentVolume 来存储数据。他们的
 In local clusters, the default StorageClass uses the `hostPath` provisioner.  `hostPath` volumes are only suitable for development and testing. With `hostPath` volumes, your data lives in `/tmp` on the node the Pod is scheduled onto and does not move between nodes. If a Pod dies and gets scheduled to another node in the cluster, or the node is rebooted, the data is lost.
 -->

-在本地群集中，默认的 StorageClass 使用`hostPath`供应器。 `hostPath`卷仅适用于开发和测试。使用 `hostPath` 卷，你的数据位于 Pod 调度到的节点上的`/tmp`中，并且不会在节点之间移动。如果 Pod 死亡并被调度到群集中的另一个节点，或者该节点重新启动，则数据将丢失。
+在本地集群中，默认的 StorageClass 使用`hostPath`供应器。 `hostPath`卷仅适用于开发和测试。使用 `hostPath` 卷，你的数据位于 Pod 调度到的节点上的`/tmp`中，并且不会在节点之间移动。如果 Pod 死亡并被调度到群集中的另一个节点，或者该节点重新启动，则数据将丢失。
 {{< /warning >}}

 {{< note >}}