diff --git a/content/zh/docs/concepts/architecture/cloud-controller.md b/content/zh/docs/concepts/architecture/cloud-controller.md
index 5b218567e2..18b599225a 100644
--- a/content/zh/docs/concepts/architecture/cloud-controller.md
+++ b/content/zh/docs/concepts/architecture/cloud-controller.md
@@ -1,153 +1,400 @@
 ---
-title: 云控制器管理器的基本概念
+title: 云控制器管理器的基础概念
 content_template: templates/concept
 weight: 30
 ---
 
+<!--
+---
+title: Concepts Underlying the Cloud Controller Manager
+content_template: templates/concept
+weight: 30
+---
+-->
+
+
 {{% capture overview %}}
 
-云控制器管理器（CCM）这个概念创建的初衷是为了让特定的云服务供应商代码和 Kubernetes 核心相互独立演化。云控制器管理器与其他主要组件如 Kubernetes 控制器管理器，API 服务器和调度程序同时运行。云控制器管理器也可以作为 Kubernetes 的插件启动，这种情况下，CCM 运行在 Kubernetes 系统之上。
+<!--
+The cloud controller manager (CCM) concept (not to be confused with the binary) was originally created to allow cloud specific vendor code and the Kubernetes core to evolve independent of one another. The cloud controller manager runs alongside other master components such as the Kubernetes controller manager, the API server, and scheduler. It can also be started as a Kubernetes addon, in which case it runs on top of Kubernetes.
+-->
+
+云控制器管理器（cloud controller manager，CCM）这个概念 （不要与二进制文件混淆）创建的初衷是为了让特定的云服务供应商代码和 Kubernetes 核心相互独立演化。云控制器管理器与其他主要组件（如 Kubernetes 控制器管理器，API 服务器和调度程序）一起运行。它也可以作为 Kubernetes 的插件启动，在这种情况下，它会运行在 Kubernetes 之上。
+
+<!--
+The cloud controller manager's design is based on a plugin mechanism that allows new cloud providers to integrate with Kubernetes easily by using plugins. There are plans in place for on-boarding new cloud providers on Kubernetes and for migrating cloud providers from the old model to the new CCM model.
+-->
 
 云控制器管理器基于插件机制设计，允许新的云服务供应商通过插件轻松地与 Kubernetes 集成。目前已经有在 Kubernetes 上加入新的云服务供应商计划，并为云服务供应商提供从原先的旧模式迁移到新 CCM 模式的方案。
 
+<!--
+This document discusses the concepts behind the cloud controller manager and gives details about its associated functions.
+-->
+
 本文讨论了云控制器管理器背后的概念，并提供了相关功能的详细信息。
 
-下面这张图描述了没有云控制器管理器的 Kubernetes 集群架构：
+<!--
+Here's the architecture of a Kubernetes cluster without the cloud controller manager: -->
 
-![无云控制器管理器的 K8s 集群架构](/images/docs/pre-ccm-arch.png)
+这是没有云控制器管理器的 Kubernetes 集群的架构：
+
+<!--
+![Pre CCM Kube Arch](/images/docs/pre-ccm-arch.png)
+-->
+
+![没有云控制器管理器的 Kubernetes 架构](/images/docs/pre-ccm-arch.png)
 
 {{% /capture %}}
 
 
 {{% capture body %}}
 
+<!--
+## Design
+-->
+
+
 ## 设计
 
+<!--
+In the preceding diagram, Kubernetes and the cloud provider are integrated through several different components:
+-->
+
 在上图中，Kubernetes 和云服务供应商通过几个不同的组件进行了集成，分别是：
 
+<!--
+* Kubelet
+* Kubernetes controller manager
+* Kubernetes API server
+-->
+
 * Kubelet
 * Kubernetes 控制管理器
 * Kubernetes API 服务器
 
-而 CCM 整合了前三个组件中的所有依赖于云的逻辑，用来创建与云的单点集成。新架构如下图所示：
+<!--
+The CCM consolidates all of the cloud-dependent logic from the preceding three components to create a single point of integration with the cloud. The new architecture with the CCM looks like this:
+-->
 
-![有云控制器管理器的 Kubernetes 集群架构](/images/docs/post-ccm-arch.png)
+CCM 整合了前三个组件中的所有依赖于云的逻辑，以创建与云的单一集成点。CCM 的新架构如下所示：
 
-## CCM 的组件
+<!-- ![CCM Kube Arch](/images/docs/post-ccm-arch.png) -->
 
-CCM 突破了 Kubernetes 控制器管理器（KCM）的一些功能，并将其作为一个独立的进程运行。具体而言，它打破了 KCM 中与云相关的控制器。KCM 具有以下依赖于云的控制器引擎：
+![含有云控制器管理器的 Kubernetes 架构](/images/docs/post-ccm-arch.png)
+
+<!--
+## Components of the CCM
+-->
+## CCM 的组成部分
+
+<!--
+The CCM breaks away some of the functionality of Kubernetes controller manager (KCM) and runs it as a separate process. Specifically, it breaks away those controllers in the KCM that are cloud dependent. The KCM has the following cloud dependent controller loops:
+ -->
+
+CCM 打破了 Kubernetes 控制器管理器（KCM）的一些功能，并将其作为一个单独的进程运行。具体来说，它打破了 KCM 中依赖于云的控制器。KCM 具有以下依赖于云的控制器：
+
+<!--
+ * Node controller
+ * Volume controller
+ * Route controller
+ * Service controller
+-->
 
 * 节点控制器
 * 卷控制器
 * 路由控制器
 * 服务控制器
+<!--
+In version 1.9, the CCM runs the following controllers from the preceding list:
+ -->
 
-在1.8版本中，当前运行中的 CCM 从上面的列表中运行以下控制器：
+在 1.9 版本中，CCM 运行前述列表中的以下控制器：
+
+<!--
+* Node controller
+* Route controller
+* Service controller
+-->
 
 * 节点控制器
 * 路由控制器
 * 服务控制器
 
-另外，它运行另一个名为 PersistentVolumeLabels Controller 的控制器。这个控制器负责对在 GCP 和 AWS 云里创建的 PersistentVolumes 的域（Zone）和区（Region）标签进行设置。
+<!--
+Additionally, it runs another controller called the PersistentVolumeLabels controller. This controller is responsible for setting the zone and region labels on PersistentVolumes created in GCP and AWS clouds.
+-->
 
-**注意**：卷控制器被特意设计为 CCM 之外的一部分。由于其中涉及到的复杂性和对现有供应商特定卷的逻辑抽象，因此决定了卷控制器不会被移动到 CCM 之中。
+此外，它还运行另一个名为 PersistentVolumeLabels Controller 的控制器，这个控制器负责在 GCP 和 AWS 云中创建的 PersistentVolumes 的域（zone）和区（region）标签进行设置。
 
-原本计划使用 CCM 来支持卷的目的是为了引入 FlexVolume 卷来支持可插拔卷。然而，官方正在计划使用更具备竞争力的 CSI 来取代 FlexVolume 卷。
+{{< note >}}
+<!--
+Volume controller was deliberately chosen to not be a part of CCM. Due to the complexity involved and due to the existing efforts to abstract away vendor specific volume logic, it was decided that volume controller will not be moved to CCM.
+-->
 
-考虑到这些正在进行中的变化，我们决定暂时停止当前工作直至 CSI 准备就绪。
+注意卷控制器不属于 CCM，由于其中涉及到的复杂性和对现有供应商特定卷的逻辑抽象，因此决定了卷控制器不会被移动到 CCM 之中。
 
-云服务供应商工作组（wg-cloud-provider）正在开展相关工作，以实现通过 CCM 支持 PersistentVolume 的功能。详细信息请参见[kubernetes/kubernetes＃52371](https://github.com/kubernetes/kubernetes/pull/52371)。
+{{< /note >}}
+
+<!--
+The original plan to support volumes using CCM was to use Flex volumes to support pluggable volumes. However, a competing effort known as CSI is being planned to replace Flex.
+-->
+
+使用 CCM 支持 volume 的最初计划是使用 Flex volume 来支持可插拔卷，但是现在正在计划一项名为 CSI 的项目以取代 Flex。
+
+<!--
+Considering these dynamics, we decided to have an intermediate stop gap measure until CSI becomes ready.
+-->
+
+考虑到这些正在进行中的变化，在 CSI 准备就绪之前，我们决定停止当前的工作。
+
+<!--
+## Functions of the CCM
+-->
 
 ## CCM 的功能
 
-CCM 从 Kubernetes 组件中继承了与云服务供应商相关的功能。本节基于被 CCM 继承其功能的组件展开描述。
+<!--
+The CCM inherits its functions from components of Kubernetes that are dependent on a cloud provider. This section is structured based on those components.
+-->
+
+CCM 从依赖于云提供商的 Kubernetes 组件继承其功能，本节基于这些组件组织。
+
+<!--
+### 1. Kubernetes controller manager
+-->
 
 ### 1. Kubernetes 控制器管理器
 
-CCM 的大部分功能都来自 KCM。 如上一节所述，CCM 运行以下控制引擎：
+<!--
+The majority of the CCM's functions are derived from the KCM. As mentioned in the previous section, the CCM runs the following control loops:
+-->
+
+CCM 的大多数功能都来自 KCM，如上一节所述，CCM 运行以下控制器。
+
+<!--
+* Node controller
+* Route controller
+* Service controller
+* PersistentVolumeLabels controller
+-->
 
 * 节点控制器
 * 路由控制器
 * 服务控制器
 * PersistentVolumeLabels 控制器
 
+<!--
+#### Node controller
+-->
+
 #### 节点控制器
 
-节点控制器负责通过从云服务供应商获得有关在集群中运行的节点的信息来初始化节点。节点控制器执行以下功能：
+<!--
+The Node controller is responsible for initializing a node by obtaining information about the nodes running in the cluster from the cloud provider. The node controller performs the following functions:
+-->
 
-1.使用云特定域（Zone）/区（Region）标签初始化节点。
+节点控制器负责通过从云提供商获取有关在集群中运行的节点的信息来初始化节点，节点控制器执行以下功能：
 
-1.使用特定于云的实例详细信息初始化节点，例如类型和大小。
+<!--
+1. Initialize a node with cloud specific zone/region labels.
+2. Initialize a node with cloud specific instance details, for example, type and size.
+3. Obtain the node's network addresses and hostname.
+4. In case a node becomes unresponsive, check the cloud to see if the node has been deleted from the cloud.
+If the node has been deleted from the cloud, delete the Kubernetes Node object.
+-->
 
-1.获取节点的网络地址和主机名。
+1. 使用特定于云的域（zone）/区（region）标签初始化节点；
+2. 使用特定于云的实例详细信息初始化节点，例如，类型和大小；
+3. 获取节点的网络地址和主机名；
+4. 如果节点无响应，请检查云以查看该节点是否已从云中删除。如果已从云中删除该节点，请删除 Kubernetes 节点对象。
 
-1.如果节点无响应，检查该节点是否已从云中删除。如果该节点已从云中删除，则删除 Kubernetes 节点对象。
+<!--
+#### Route controller
+-->
 
 #### 路由控制器
 
-路由控制器负责为云配置正确的路由，以便 Kubernetes 集群中不同节点上的容器可以相互通信。路由控制器仅适用于 Google Compute Engine 平台。
+<!--
+The Route controller is responsible for configuring routes in the cloud appropriately so that containers on different nodes in the Kubernetes cluster can communicate with each other. The route controller is only applicable for Google Compute Engine clusters.
+-->
+
+Route 控制器负责适当地配置云中的路由，以便 Kubernetes 集群中不同节点上的容器可以相互通信。route 控制器仅适用于 Google Compute Engine 群集。
+
+<!--
+#### Service Controller
+-->
 
 #### 服务控制器
 
-服务控制器负责监听服务的创建、更新和删除事件。根据Kubernetes中各个服务的当前状态，它将配置云负载平衡器（如 ELB 或 Google LB）以反映 Kubernetes 中的服务状态。此外，它还确保云负载均衡器的服务后端保持最新。
+<!--
+The Service controller is responsible for listening to service create, update, and delete events. Based on the current state of the services in Kubernetes, it configures cloud load balancers (such as ELB or Google LB) to reflect the state of the services in Kubernetes. Additionally, it ensures that service backends for cloud load balancers are up to date.
+-->
+
+服务控制器负责监听服务的创建、更新和删除事件。根据 Kubernetes 中各个服务的当前状态，它配置云负载均衡器（如 ELB 或 Google LB）以反映 Kubernetes 中的服务状态。此外，它还确保云负载均衡器的服务后端是最新的。
+
+<!--
+#### PersistentVolumeLabels controller
+-->
 
 #### PersistentVolumeLabels 控制器
 
-PersistentVolumeLabels 控制器在 AWS 的 EBS 卷、GCE 的 PD 卷创建时申请标签，这使得用户不再需要手动设置这些卷标签。
+<!--
+The PersistentVolumeLabels controller applies labels on AWS EBS/GCE PD volumes when they are created. This removes the need for users to manually set the labels on these volumes.
+-->
 
-这些标签对于pod的调度工作是非常重要的，因为这些卷只能在它们所在的域（Zone）/区（Region）内工作，因此所有使用这些卷的pod都必须要在同一个域/区中才能保证进行调度正常进行。
+PersistentVolumeLabels 控制器在创建 AWS EBS/GCE PD 卷时应用标签，这样就无需用户手动设置这些卷上的标签。
 
-PersistentVolumeLabels 控制器是专门为 CCM 创建的; 也就是说，在 CCM 创建之前它是不存在的。这样做是为了将 Kubernetes API 服务器（它是一个许可控制器）中的PV标签逻辑移动到 CCM。 它不在 KCM 上运行。
+<!--
+These labels are essential for the scheduling of pods as these volumes are constrained to work only within the region/zone that they are in. Any Pod using these volumes needs to be scheduled in the same region/zone.
+-->
+
+这些标签对于 pod 的调度至关重要，因为这些卷仅限于在它们所在的域（zone）/区（region）内工作，使用这些卷的任何 Pod 都需要在同一域（zone）/区（region）中进行调度。
+
+<!--
+The PersistentVolumeLabels controller was created specifically for the CCM; that is, it did not exist before the CCM was created. This was done to move the PV labelling logic in the Kubernetes API server (it was an admission controller) to the CCM. It does not run on the KCM.
+-->
+
+PersistentVolumeLabels 控制器专门为 CCM 创建； 也就是说，在创建 CCM 之前它不存在。这样做是为了将 Kubernetes API 服务器（它是一个准入控制器）中的 PV 标记逻辑移动到 CCM，它不在 KCM 上运行。
+
+<!--
+### 2. Kubelet
+-->
 
 ### 2. Kubelet
 
-Node控制器包含kubelet中依赖于云的功能。在系统引入 CCM 组件之前，是由 kubelet 采用包含云特定信息的方式对节点进行初始化，如 IP 地址、区（Region）/域（Zone）标签和实例类型信息；引入 CCM 之后，这部分的初始化操作就从 kubelet 转移到了 CCM 中。
+<!--
+The Node controller contains the cloud-dependent functionality of the kubelet. Prior to the introduction of the CCM, the kubelet was responsible for initializing a node with cloud-specific details such as IP addresses, region/zone labels and instance type information. The introduction of the CCM has moved this initialization operation from the kubelet into the CCM.
+-->
 
-在引入CCM后的新的模型中，kubelet 采用不包含云特定信息的方式初始化一个节点。但是，它会为新创建的节点添加一个污点，使得该节点不可被立即调度，直到 CCM 使用包含云的特定信息初始化节点后，才会删除该污点，使得该节点可被调度。
+节点控制器包含 kubelet 中依赖于云的功能，在引入 CCM 之前，kubelet 负责使用特定于云的详细信息（如 IP 地址，域/区标签和实例类型信息）初始化节点。CCM 的引入已将此初始化操作从 kubelet 转移到 CCM 中。
+
+<!--
+In this new model, the kubelet initializes a node without cloud-specific information. However, it adds a taint to the newly created node that makes the node unschedulable until the CCM initializes the node with cloud-specific information. It then removes this taint.
+-->
+
+在这个新模型中，kubelet 初始化一个没有特定于云的信息的节点。但是，它会为新创建的节点添加污点，使节点不可调度，直到 CCM 使用特定于云的信息初始化节点后，才会清除这种污点，便得该节点可被调度。
+
+<!--
+### 3. Kubernetes API server
+-->
 
 ### 3. Kubernetes API 服务器
 
+<!--
+The PersistentVolumeLabels controller moves the cloud-dependent functionality of the Kubernetes API server to the CCM as described in the preceding sections.
+-->
+
 PersistentVolumeLabels 控制器将 Kubernetes API 服务器的依赖于云的功能移至 CCM，如前面部分所述。
 
+<!--
+## Plugin mechanism
+-->
+
+
 ## 插件机制
 
-云控制器管理器使用 Go 接口与外部对接从而实现功能扩展。具体来说，它使用了[这里](https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/cloud.go)定义的 CloudProvider 接口。
+<!--
+The cloud controller manager uses Go interfaces to allow implementations from any cloud to be plugged in. Specifically, it uses the CloudProvider Interface defined [here](https://github.com/kubernetes/cloud-provider/blob/9b77dc1c384685cb732b3025ed5689dd597a5971/cloud.go#L42-L62).
+-->
 
-上面强调的四个共享控制器的实现，以及一些辅助设施（scaffolding）和共享的云服务供应商接口，将被保留在 Kubernetes 核心当中。但云服务供应商特有的实现将会建立在核心之外，并实现核心中定义的接口。
+云控制器管理器使用 Go 接口允许插入任何云的实现。具体来说，它使用[此处](https://github.com/kubernetes/cloud-provider/blob/9b77dc1c384685cb732b3025ed5689dd597a5971/cloud.go#L42-L62)定义的 CloudProvider 接口。
 
-有关开发插件的更多信息，请参阅
-[开发云控制器管理器](/docs/tasks/administrators-cluster/developing-cloud-controller-manager/)。
+
+<!--
+The implementation of the four shared controllers highlighted above, and some scaffolding along with the shared cloudprovider interface, will stay in the Kubernetes core. Implementations specific to cloud providers will be built outside of the core and implement interfaces defined in the core.
+-->
+
+上面强调的四个共享控制器的实现，以及一些辅助设施（scaffolding）和共享的 cloudprovider 接口，将被保留在 Kubernetes 核心中。但特定于云提供商的实现将在核心之外构建，并实现核心中定义的接口。
+
+<!--
+For more information about developing plugins, see [Developing Cloud Controller Manager](/docs/tasks/administer-cluster/developing-cloud-controller-manager/).
+ -->
+
+有关开发插件的更多信息，请参阅[开发云控制器管理器](/docs/tasks/administer-cluster/developing-cloud-controller-manager/)。
+
+<!--
+## Authorization
+-->
 
 ## 授权
 
-本节分解了 CCM 对各种 API 对象的访问，以执行其操作。
+<!--
+This section breaks down the access required on various API objects by the CCM to perform its operations.
+-->
+
+本节分解了 CCM 执行其操作时各种 API 对象所需的访问权限。
+
+<!--
+### Node Controller
+-->
 
 ### 节点控制器
 
-节点控制器仅适用于节点对象。它需要完全访问权限来获取、列出、创建、更新、修补、监视和删除节点对象。
+<!--
+The Node controller only works with Node objects. It requires full access to get, list, create, update, patch, watch, and delete Node objects.
+-->
+
+Node 控制器仅适用于 Node 对象，它需要完全访问权限来获取、列出、创建、更新、修补、监视和删除 Node 对象。
+
+<!--
+v1/Node:
 
-v1/Node: 
 - Get
 - List
 - Create
 - Update
 - Patch
 - Watch
+- Delete
+-->
+
+v1/Node:
+- Get
+- List
+- Create
+- Update
+- Patch
+- Watch
+- Delete
+
+<!--
+### Route controller
+-->
 
 ### 路由控制器
 
-路由控制器监听节点对象的创建并配置合适的路由。它需要对节点对象的访问权限。
+<!--
+The route controller listens to Node object creation and configures routes appropriately. It requires get access to Node objects.
+-->
 
-v1/Node: 
+路由控制器侦听 Node 对象创建并适当地配置路由，它需要访问 Node 对象。
+
+v1/Node:
 - Get
 
+<!--
+### Service controller
+-->
+
 ### 服务控制器
 
-服务控制器侦听服务对象创建、更新和删除事件，然后对这些服务的端点进行恰当的配置。
+<!--
+The service controller listens to Service object create, update and delete events and then configures endpoints for those Services appropriately.
+-->
 
-要访问服务，它需要罗列和监控权限。要更新服务，它需要修补和更新权限。
+服务控制器侦听 Service 对象创建、更新和删除事件，然后适当地为这些服务配置端点。
 
-要为服务设置端点，需要访问创建、列表、获取、监视和更新。
+<!--
+To access Services, it requires list, and watch access. To update Services, it requires patch and update access.
+-->
+
+要访问服务，它需要列表和监视访问权限。要更新服务，它需要修补和更新访问权限。
+
+<!--
+To set up endpoints for the Services, it requires access to create, list, get, watch, and update.
+-->
+
+要为服务设置端点，需要访问 create、list、get、watch 和 update。
 
 v1/Service:
 - List
@@ -156,9 +403,17 @@ v1/Service:
 - Patch
 - Update
 
+<!--
+### PersistentVolumeLabels controller
+-->
+
 ### PersistentVolumeLabels 控制器
 
-PersistentVolumeLabels 控制器监听 PersistentVolume（PV）创建事件并更新它们。该控制器需要访问列表、查看、获取和更新 PV 的权限。
+<!--
+The PersistentVolumeLabels controller listens on PersistentVolume (PV) create events and then updates them. This controller requires access to get and update PVs.
+-->
+
+PersistentVolumeLabels 控制器侦听 PersistentVolume（PV）创建事件并更新它们，该控制器需要访问以获取和更新 PV。
 
 v1/PersistentVolume:
 - Get
@@ -166,9 +421,17 @@ v1/PersistentVolume:
 - Watch
 - Update
 
+<!--
+### Others
+-->
+
 ### 其它
 
-CCM 核心的实现需要创建事件的权限，为了确保安全操作，需要创建 ServiceAccounts 的权限。
+<!--
+The implementation of the core of CCM requires access to create events, and to ensure secure operation, it requires access to create ServiceAccounts.
+-->
+
+CCM 核心的实现需要访问权限以创建事件，并且为了确保安全操作，它需要访问权限以创建服务账户。
 
 v1/Event:
 - Create
@@ -178,7 +441,12 @@ v1/Event:
 v1/ServiceAccount:
 - Create
 
-针对 CCM 的 RBAC ClusterRole 如下所示：
+<!--
+The RBAC ClusterRole for the CCM looks like this:
+-->
+
+
+针对 CCM 的 RBAC ClusterRole 看起来像这样：
 
 ```yaml
 apiVersion: rbac.authorization.k8s.io/v1
@@ -242,9 +510,18 @@ rules:
   - update
 ```
 
+<!--
+## Vendor Implementations
+-->
+
+
 ## 供应商实施
 
-以下云服务供应商为自己的云部署了 CCM。
+<!--
+The following cloud providers have implemented CCMs:
+-->
+
+以下云服务提供商已实现了 CCM：
 
 <!--
 * [Digital Ocean](https://github.com/digitalocean/digitalocean-cloud-controller-manager)
@@ -260,6 +537,17 @@ rules:
 * [GCE](https://github.com/kubernetes/kubernetes/tree/master/pkg/cloudprovider/providers/gce)
 * [AWS](https://github.com/kubernetes/kubernetes/tree/master/pkg/cloudprovider/providers/aws)
 
+<!--
+## Cluster Administration
+-->
+
 ## 群集管理
 
-[这里](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)提供了配置和运行 CCM 的完整说明。
+<!--
+Complete instructions for configuring and running the CCM are provided
+[here](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager). -->
+
+[这里](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)提供了有关配置和运行 CCM 的完整说明。
+
+{{% /capture %}}
+