Merge pull request #34113 from LeeLin2602/main

[zh] improve chinese translation for control plane components

Author: k8s-ci-robot

content/zh/docs/concepts/overview/components.md

@@ -33,10 +33,10 @@ a complete and working Kubernetes cluster.
 
 -->
 <!-- overview -->
-当你部署完 Kubernetes，即拥有了一个完整的集群。
+当你部署完 Kubernetes，便拥有了一个完整的集群。
 {{< glossary_definition term_id="cluster" length="all" prepend="一个 Kubernetes">}}
 
-本文档概述了交付正常运行的 Kubernetes 集群所需的各种组件。
+本文档概述了一个正常运行的 Kubernetes 集群所需的各种组件。
 
 {{< figure src="/images/docs/components-of-kubernetes.svg" alt="Kubernetes 的组件" caption="Kubernetes 集群的组件" class="diagram-large" >}}
 
@@ -49,8 +49,9 @@ The control plane's components make global decisions about the cluster (for exam
  -->
 ## 控制平面组件（Control Plane Components）    {#control-plane-components}
 
-控制平面的组件对集群做出全局决策（比如调度），以及检测和响应集群事件（例如，当不满足部署的
-`replicas` 字段时，启动新的 {{< glossary_tooltip text="pod" term_id="pod">}}）。
+控制平面组件会为集群做出全局决策，比如资源的调度。
+以及检测和响应集群事件，例如当不满足部署的 `replicas` 字段时，
+要启动新的 {{< glossary_tooltip text="pod" term_id="pod">}}）。
 
 <!--
 Control plane components can be run on any machine in the cluster. However,
@@ -93,7 +94,7 @@ Some types of these controllers are:
 这些控制器包括：
 
 * 节点控制器（Node Controller）：负责在节点出现故障时进行通知和响应
-* 任务控制器（Job controller）：监测代表一次性任务的 Job 对象，然后创建 Pods 来运行这些任务直至完成
+* 任务控制器（Job Controller）：监测代表一次性任务的 Job 对象，然后创建 Pods 来运行这些任务直至完成
 * 端点控制器（Endpoints Controller）：填充端点（Endpoints）对象（即加入 Service 与 Pod）
 * 服务帐户和令牌控制器（Service Account & Token Controllers）：为新的命名空间创建默认帐户和 API 访问令牌
 
@@ -118,12 +119,13 @@ The following controllers can have cloud provider dependencies:
 
 {{< glossary_definition term_id="cloud-controller-manager" length="short" >}}
 
-`cloud-controller-manager` 仅运行特定于云平台的控制回路。
-如果你在自己的环境中运行 Kubernetes，或者在本地计算机中运行学习环境，
-所部署的环境中不需要云控制器管理器。
+`cloud-controller-manager` 仅运行特定于云平台的控制器。
+因此如果你在自己的环境中运行 Kubernetes，或者在本地计算机中运行学习环境，
+所部署的集群不需要有云控制器管理器。
 
-与 `kube-controller-manager` 类似，`cloud-controller-manager` 将若干逻辑上独立的
-控制回路组合到同一个可执行文件中，供你以同一进程的方式运行。
+与 `kube-controller-manager` 类似，`cloud-controller-manager`
+将若干逻辑上独立的控制回路组合到同一个可执行文件中，
+供你以同一进程的方式运行。
 你可以对其执行水平扩容（运行不止一个副本）以提升性能或者增强容错能力。
 
 下面的控制器都包含对云平台驱动的依赖：

content/zh/docs/reference/glossary/cloud-controller-manager.md

@@ -33,18 +33,17 @@ that embeds cloud-specific control logic. The cloud controller manager lets you
 cluster into your cloud provider's API, and separates out the components that interact
 with that cloud platform from components that only interact with your cluster.
 -->
-云控制器管理器是指嵌入特定云的控制逻辑的
+`cloud-controller-manager` 是指嵌入特定云的控制逻辑之
 {{< glossary_tooltip text="控制平面" term_id="control-plane" >}}组件。
-云控制器管理器使得你可以将你的集群连接到云提供商的 API 之上，
+`cloud-controller-manager` 允许你将你的集群连接到云提供商的 API 之上，
 并将与该云平台交互的组件同与你的集群交互的组件分离开来。
 
 <!--more--> 
-
 <!--
 By decoupling the interoperability logic between Kubernetes and the underlying cloud
 infrastructure, the cloud-controller-manager component enables cloud providers to release
 features at a different pace compared to the main Kubernetes project.
 -->
 通过分离 Kubernetes 和底层云基础设置之间的互操作性逻辑，
-云控制器管理器组件使云提供商能够以不同于 Kubernetes 主项目的
+`cloud-controller-manager` 组件使云提供商能够以不同于 Kubernetes 主项目的
 步调发布新特征。

content/zh/docs/reference/glossary/cluster.md

@@ -32,7 +32,8 @@ tags:
 A set of worker machines, called {{< glossary_tooltip text="nodes" term_id="node" >}},
 that run containerized applications. Every cluster has at least one worker node.
 -->
-集群由一组被称作节点的机器组成。这些节点上运行 Kubernetes 所管理的容器化应用。集群具有至少一个工作节点。
+集群是由一组被称作节点的机器组成，这些节点上会运行由 Kubernetes 所管理的容器化应用。
+且每个集群至少有一个工作节点。
 
 <!--more-->
 <!-- 
@@ -43,5 +44,7 @@ nodes and the Pods in the cluster. In production environments, the control plane
 runs across multiple computers and a cluster usually runs multiple nodes, providing
 fault-tolerance and high availability.
 -->
-工作节点托管作为应用负载的组件的 Pod 。控制平面管理集群中的工作节点和 Pod 。
-为集群提供故障转移和高可用性，这些控制平面一般跨多主机运行，集群跨多个节点运行。
+工作节点会托管所谓的 Pods，而 Pod 就是作为应用负载的组件。
+控制平面管理集群中的工作节点和 Pods。
+为集群提供故障转移和高可用性，
+这些控制平面一般跨多主机运行，而集群也会跨多个节点运行。

content/zh/docs/reference/glossary/etcd.md

@@ -32,17 +32,17 @@ tags:
  Consistent and highly-available key value store used as Kubernetes' backing store for all cluster data.
 -->
 
-etcd 是兼具一致性和高可用性的键值数据库，可以作为保存 Kubernetes 所有集群数据的后台数据库。
+`etcd` 是兼顾一致性与高可用性的键值数据库，可以作为保存 Kubernetes 所有集群数据的后台数据库。
 
 <!--more--> 
 <!--
 If your Kubernetes cluster uses etcd as its backing store, make sure you have a
 [back up](/docs/tasks/administer-cluster/configure-upgrade-etcd/#backing-up-an-etcd-cluster) plan
 for those data.
 -->	
-你的 Kubernetes 集群的 etcd 数据库通常需要有个备份计划。
+你的 Kubernetes 集群的 `etcd` 数据库通常需要有个[备份](/zh/docs/tasks/administer-cluster/configure-upgrade-etcd/#backing-up-an-etcd-cluster)计划。
 <!--
 You can find in-depth information about etcd in the official [documentation](https://etcd.io/docs/).
 -->
 
-要了解 etcd 更深层次的信息，请参考 [etcd 文档](https://etcd.io/docs/)。
+如果想要更深入的了解 `etcd`，请参考 [etcd 文档](https://etcd.io/docs/)。

content/zh/docs/reference/glossary/kube-apiserver.md

@@ -31,9 +31,9 @@ tags:
 {{< glossary_tooltip text="control plane" term_id="control-plane" >}} that exposes the Kubernetes API.
 The API server is the front end for the Kubernetes control plane.
 -->
-API 服务器是 Kubernetes {{< glossary_tooltip text="控制面" term_id="control-plane" >}}的组件，
-该组件公开了 Kubernetes API。
-API 服务器是 Kubernetes 控制面的前端。
+API 服务器是 Kubernetes {{< glossary_tooltip text="控制平面" term_id="control-plane" >}}的组件，
+该组件负责公开了 Kubernetes API，负责处理接受请求的工作。
+API 服务器是 Kubernetes 控制平面的前端。
 
 <!--more--> 
 
@@ -43,5 +43,5 @@ kube-apiserver is designed to scale horizontally&mdash;that is, it scales by dep
 You can run several instances of kube-apiserver and balance traffic between those instances.
 -->
 Kubernetes API 服务器的主要实现是 [kube-apiserver](/zh/docs/reference/command-line-tools-reference/kube-apiserver/)。
-kube-apiserver 设计上考虑了水平伸缩，也就是说，它可通过部署多个实例进行伸缩。
-你可以运行 kube-apiserver 的多个实例，并在这些实例之间平衡流量。
+`kube-apiserver` 设计上考虑了水平扩缩，也就是说，它可通过部署多个实例来进行扩缩。
+你可以运行 `kube-apiserver` 的多个实例，并在这些实例之间平衡流量。

content/zh/docs/reference/glossary/kube-controller-manager.md

@@ -31,10 +31,13 @@ tags:
 <!--
  Control plane component that runs {{< glossary_tooltip text="controller" term_id="controller" >}} processes.
 -->
-运行{{< glossary_tooltip text="控制器" term_id="controller" >}}进程的控制平面组件。
-
-<!--more--> 
+`kube-controller-manager` 是{{< glossary_tooltip text="控制平面" term_id="control-plane" >}}的组件，
+负责运行{{< glossary_tooltip text="控制器" term_id="controller" >}}进程。
 
+<!--more-->
+<!--
+Logically, each controller is a separate process, but to reduce complexity, they are all compiled into a single binary and run in a single process.
+--> 
 从逻辑上讲，每个{{< glossary_tooltip text="控制器" term_id="controller" >}}都是一个单独的进程，
-但是为了降低复杂性，它们都被编译到同一个可执行文件，并在一个进程中运行。
+但是为了降低复杂性，它们都被编译到同一个可执行文件，并在同一个进程中运行。
 

content/zh/docs/reference/glossary/kube-scheduler.md

@@ -33,12 +33,15 @@ Control plane component that watches for newly created
 {{< glossary_tooltip term_id="node" text="node">}}, and selects a node for them
 to run on.-->
 
-  控制平面组件，负责监视新创建的、未指定运行{{< glossary_tooltip term_id="node" text="节点（node）">}}的 {{< glossary_tooltip term_id="pod" text="Pods" >}}，选择节点让 Pod 在上面运行。
+  `kube-scheduler` 是{{< glossary_tooltip text="控制平面" term_id="control-plane" >}}的组件，
+  负责监视新创建的、未指定运行{{< glossary_tooltip term_id="node" text="节点（node）">}}的 {{< glossary_tooltip term_id="pod" text="Pods" >}}，
+  并选择节点来让 Pod 在上面运行。
 
 <!--more--> 
 
 <!--
 Factors taken into account for scheduling decisions include individual and collective resource requirements,  hardware/software/policy constraints, affinity and anti-affinity specifications, data locality, inter-workload interference and deadlines.
 -->
 
-调度决策考虑的因素包括单个 Pod 和 Pod 集合的资源需求、硬件/软件/策略约束、亲和性和反亲和性规范、数据位置、工作负载间的干扰和最后时限。
+调度决策考虑的因素包括单个 Pod 及 Pods 集合的资源需求、软硬件及策略约束、
+亲和性及反亲和性规范、数据位置、工作负载间的干扰及最后时限。