[zh-cn] sync running-cloud-controller.md

Signed-off-by: xin.li <xin.li@daocloud.io>

content/zh-cn/docs/tasks/administer-cluster/running-cloud-controller.md

@@ -18,14 +18,23 @@ weight: 110
 {{< feature-state state="beta" for_k8s_version="v1.11" >}}
 
 <!--
-Since cloud providers develop and release at a different pace compared to the Kubernetes project, abstracting the provider-specific code to the `{{< glossary_tooltip text="cloud-controller-manager" term_id="cloud-controller-manager" >}}` binary allows cloud vendors to evolve independently from the core Kubernetes code.
+Since cloud providers develop and release at a different pace compared to the
+Kubernetes project, abstracting the provider-specific code to the
+`{{< glossary_tooltip text="cloud-controller-manager" term_id="cloud-controller-manager" >}}`
+binary allows cloud vendors to evolve independently from the core Kubernetes code.
 -->
 由于云驱动的开发和发布的步调与 Kubernetes 项目不同，将服务提供商专用代码抽象到
 `{{< glossary_tooltip text="cloud-controller-manager" term_id="cloud-controller-manager" >}}`
 二进制中有助于云服务厂商在 Kubernetes 核心代码之外独立进行开发。
 
 <!--
-The `cloud-controller-manager` can be linked to any cloud provider that satisfies [cloudprovider.Interface](https://github.com/kubernetes/cloud-provider/blob/master/cloud.go). For backwards compatibility, the [cloud-controller-manager](https://github.com/kubernetes/kubernetes/tree/master/cmd/cloud-controller-manager) provided in the core Kubernetes project uses the same cloud libraries as `kube-controller-manager`. Cloud providers already supported in Kubernetes core are expected to use the in-tree cloud-controller-manager to transition out of Kubernetes core.
+The `cloud-controller-manager` can be linked to any cloud provider that satisfies
+[cloudprovider.Interface](https://github.com/kubernetes/cloud-provider/blob/master/cloud.go). 
+For backwards compatibility, the
+[cloud-controller-manager](https://github.com/kubernetes/kubernetes/tree/master/cmd/cloud-controller-manager)
+provided in the core Kubernetes project uses the same cloud libraries as `kube-controller-manager`.
+Cloud providers already supported in Kubernetes core are expected to use the in-tree
+cloud-controller-manager to transition out of Kubernetes core.
 -->
 `cloud-controller-manager` 可以被链接到任何满足
 [cloudprovider.Interface](https://github.com/kubernetes/cloud-provider/blob/master/cloud.go)
@@ -42,11 +51,16 @@ The `cloud-controller-manager` can be linked to any cloud provider that satisfie
 
 ### Requirements
 
-Every cloud has their own set of requirements for running their own cloud provider integration, it should not be too different from the requirements when running `kube-controller-manager`. As a general rule of thumb you'll need:
+Every cloud has their own set of requirements for running their own cloud provider
+integration, it should not be too different from the requirements when running
+`kube-controller-manager`. As a general rule of thumb you'll need:
 
-* cloud authentication/authorization: your cloud may require a token or IAM rules to allow access to their APIs
-* kubernetes authentication/authorization: cloud-controller-manager may need RBAC rules set to speak to the kubernetes apiserver
-* high availability: like kube-controller-manager, you may want a high available setup for cloud controller manager using leader election (on by default).
+* cloud authentication/authorization: your cloud may require a token or IAM rules
+  to allow access to their APIs
+* kubernetes authentication/authorization: cloud-controller-manager may need RBAC
+  rules set to speak to the kubernetes apiserver
+* high availability: like kube-controller-manager, you may want a high available
+  setup for cloud controller manager using leader election (on by default).
 -->
 ## 管理
 
@@ -69,21 +83,33 @@ Successfully running cloud-controller-manager requires some changes to your clus
 你需要对集群配置做适当的修改以成功地运行云管理控制器：
 
 <!--
-* `kube-apiserver` and `kube-controller-manager` MUST NOT specify the `--cloud-provider` flag. This ensures that it does not run any cloud specific loops that would be run by cloud controller manager. In the future, this flag will be deprecated and removed.
-* `kubelet` must run with `--cloud-provider=external`. This is to ensure that the kubelet is aware that it must be initialized by the cloud controller manager before it is scheduled any work.
+* `kube-apiserver` and `kube-controller-manager` MUST NOT specify the `--cloud-provider`
+  flag. This ensures that it does not run any cloud specific loops that would be run by
+  cloud controller manager. In the future, this flag will be deprecated and removed.
+* `kubelet` must run with `--cloud-provider=external`. This is to ensure that the
+  kubelet is aware that it must be initialized by the cloud controller manager
+  before it is scheduled any work.
 -->
 * 一定不要为 `kube-apiserver` 和 `kube-controller-manager` 指定 `--cloud-provider` 标志。
   这将保证它们不会运行任何云服务专用循环逻辑，这将会由云管理控制器运行。未来这个标记将被废弃并去除。
 * `kubelet` 必须使用 `--cloud-provider=external` 运行。
   这是为了保证让 kubelet 知道在执行任何任务前，它必须被云管理控制器初始化。
 
 <!--
-Keep in mind that setting up your cluster to use cloud controller manager will change your cluster behaviour in a few ways:
+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).
+* 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).
 -->
 * 指定了 `--cloud-provider=external` 的 kubelet 将被添加一个 `node.cloudprovider.kubernetes.io/uninitialized`
   的污点，导致其在初始化过程中不可调度（`NoSchedule`）。
@@ -93,7 +119,12 @@ Keep in mind that setting up your cluster to use cloud controller manager will c
   （高端 CPU、GPU 支持、内存较大、临时实例等）。
 
 <!--
-* cloud information about nodes in the cluster will no longer be retrieved using local metadata, but instead all API calls to retrieve node information will go through cloud controller manager. This may mean you can restrict access to your cloud API on the kubelets for better security. For larger clusters you may want to consider if cloud controller manager will hit rate limits since it is now responsible for almost all API calls to your cloud from within the cluster.
+* cloud information about nodes in the cluster will no longer be retrieved using
+  local metadata, but instead all API calls to retrieve node information will go
+  through cloud controller manager. This may mean you can restrict access to your
+  cloud API on the kubelets for better security. For larger clusters you may want
+  to consider if cloud controller manager will hit rate limits since it is now
+  responsible for almost all API calls to your cloud from within the cluster.
 -->
 * 集群中节点的云服务信息将不再能够从本地元数据中获取，取而代之的是所有获取节点信息的
   API 调用都将通过云管理控制器。这意味着你可以通过限制到 kubelet 云服务 API 的访问来提升安全性。
@@ -103,8 +134,10 @@ Keep in mind that setting up your cluster to use cloud controller manager will c
 <!--
 Cloud controller manager can implement:
 
-* node controller - responsible for updating kubernetes nodes using cloud APIs and deleting kubernetes nodes that were deleted on your cloud.
-* service controller - responsible for loadbalancers on your cloud against services of type LoadBalancer.
+* node controller - responsible for updating kubernetes nodes using cloud APIs
+  and deleting kubernetes nodes that were deleted on your cloud.
+* service controller - responsible for loadbalancers on your cloud against
+  services of type LoadBalancer.
 * route controller - responsible for setting up network routes on your cloud
 * any other features you would like to implement if you are running an out-of-tree provider.
 -->
@@ -118,9 +151,12 @@ Cloud controller manager can implement:
 <!--
 ## Examples
 
-If you are using a cloud that is currently supported in Kubernetes core and would like to adopt cloud controller manager, see the [cloud controller manager in kubernetes core](https://github.com/kubernetes/kubernetes/tree/master/cmd/cloud-controller-manager).
+If you are using a cloud that is currently supported in Kubernetes core and would
+like to adopt cloud controller manager, see the
+[cloud controller manager in kubernetes core](https://github.com/kubernetes/kubernetes/tree/master/cmd/cloud-controller-manager).
 
-For cloud controller managers not in Kubernetes core, you can find the respective projects in repos maintained by cloud vendors or sig leads.
+For cloud controller managers not in Kubernetes core, you can find the respective
+projects in repos maintained by cloud vendors or sig leads.
 -->
 ## 示例
 
@@ -135,7 +171,8 @@ For cloud controller managers not in Kubernetes core, you can find the respectiv
 * [Rancher](https://github.com/rancher/rancher-cloud-controller-manager)
 
 <!--
-For providers already in Kubernetes core, you can run the in-tree cloud controller manager as a Daemonset in your cluster, use the following as a guideline:
+For providers already in Kubernetes core, you can run the in-tree cloud controller
+manager as a Daemonset in your cluster, use the following as a guideline:
 -->
 对于已经存在于 Kubernetes 内核中的提供商，你可以在集群中将 in-tree 云管理控制器作为守护进程运行。请使用如下指南：
 
@@ -144,7 +181,9 @@ For providers already in Kubernetes core, you can run the in-tree cloud controll
 <!--
 ## Limitations
 
-Running cloud controller manager comes with a few possible limitations. Although these limitations are being addressed in upcoming releases, it's important that you are aware of these limitations for production workloads.
+Running cloud controller manager comes with a few possible limitations. Although
+these limitations are being addressed in upcoming releases, it's important that
+you are aware of these limitations for production workloads.
 -->
 ## 限制
 
@@ -153,25 +192,44 @@ Running cloud controller manager comes with a few possible limitations. Although
 <!--
 ### Support for Volumes
 
-Cloud controller manager does not implement any of the volume controllers found in `kube-controller-manager` as the volume integrations also require coordination with kubelets. As we evolve CSI (container storage interface) and add stronger support for flex volume plugins, necessary support will be added to cloud controller manager so that clouds can fully integrate with volumes. Learn more about out-of-tree CSI volume plugins [here](https://github.com/kubernetes/features/issues/178).
+Cloud controller manager does not implement any of the volume controllers found
+in `kube-controller-manager` as the volume integrations also require coordination
+with kubelets. As we evolve CSI (container storage interface) and add stronger
+support for flex volume plugins, necessary support will be added to cloud
+controller manager so that clouds can fully integrate with volumes. Learn more
+about out-of-tree CSI volume plugins [here](https://github.com/kubernetes/features/issues/178).
 -->
 ### 对 Volume 的支持
 
-云管理控制器未实现 `kube-controller-manager` 中的任何 volume 控制器，因为和 volume 的集成还需要与 kubelet 协作。由于我们引入了 CSI (容器存储接口，container storage interface) 并对弹性 volume 插件添加了更强大的支持，云管理控制器将添加必要的支持，以使云服务同 volume 更好的集成。请在 [这里](https://github.com/kubernetes/features/issues/178) 了解更多关于 out-of-tree CSI volume 插件的信息。
+云管理控制器未实现 `kube-controller-manager` 中的任何 volume 控制器，
+因为和 volume 的集成还需要与 kubelet 协作。由于我们引入了 CSI (容器存储接口，
+container storage interface) 并对弹性 volume 插件添加了更强大的支持，
+云管理控制器将添加必要的支持，以使云服务同 volume 更好的集成。
+请在[这里](https://github.com/kubernetes/features/issues/178)了解更多关于
+out-of-tree CSI volume 插件的信息。
 
 <!--
 ### Scalability
 
-In the previous architecture for cloud providers, we relied on kubelets using a local metadata service to retrieve node information about itself. With this new architecture, we now fully rely on the cloud controller managers to retrieve information for all nodes. For very larger clusters, you should consider possible bottle necks such as resource requirements and API rate limiting.
+The cloud-controller-manager queries your cloud provider's APIs to retrieve
+information for all nodes. For very large clusters, consider possible
+bottlenecks such as resource requirements and API rate limiting.
 -->
 ### 可扩展性
 
-在以前为云服务提供商提供的架构中，我们依赖 kubelet 的本地元数据服务来获取关于它本身的节点信息。通过这个新的架构，现在我们完全依赖云管理控制器来获取所有节点的信息。对于非常大的集群，你需要考虑可能的瓶颈，例如资源需求和 API 速率限制。
+通过云管理控制器查询你的云提供商的 API 以检索所有节点的信息。
+对于非常大的集群，请考虑可能的瓶颈，例如资源需求和 API 速率限制。
 
 <!--
 ### Chicken and Egg
 
-The goal of the cloud controller manager project is to decouple development of cloud features from the core Kubernetes project. Unfortunately, many aspects of the Kubernetes project has assumptions that cloud provider features are tightly integrated into the project. As a result, adopting this new architecture can create several situations where a request is being made for information from a cloud provider, but the cloud controller manager may not be able to return that information without the original request being complete.
+The goal of the cloud controller manager project is to decouple development
+of cloud features from the core Kubernetes project. Unfortunately, many aspects
+of the Kubernetes project has assumptions that cloud provider features are tightly
+integrated into the project. As a result, adopting this new architecture can create
+several situations where a request is being made for information from a cloud provider,
+but the cloud controller manager may not be able to return that information without
+the original request being complete.
 -->
 ### 鸡和蛋的问题
 
@@ -181,7 +239,12 @@ The goal of the cloud controller manager project is to decouple development of c
 在该请求没有完成的情况下云管理控制器不能返回那些信息。
 
 <!--
-A good example of this is the TLS bootstrapping feature in the Kubelet. Currently, TLS bootstrapping assumes that the Kubelet has the ability to ask the cloud provider (or a local metadata service) for all its address types (private, public, etc) but cloud controller manager cannot set a node's address types without being initialized in the first place which requires that the kubelet has TLS certificates to communicate with the apiserver.
+A good example of this is the TLS bootstrapping feature in the Kubelet.
+Currently, TLS bootstrapping assumes that the Kubelet has the ability to ask the cloud provider
+(or a local metadata service) for all its address types (private, public, etc)
+but cloud controller manager cannot set a node's address types without being
+initialized in the first place which requires that the kubelet has TLS certificates
+to communicate with the apiserver.
 
 As this initiative evolves, changes will be made to address these issues in upcoming releases.
 -->
@@ -195,7 +258,8 @@ TLS 证书以和 API 服务器通信。
 ## {{% heading "whatsnext" %}}
 
 <!--
-To build and develop your own cloud controller manager, read the [Developing Cloud Controller Manager](/docs/tasks/administer-cluster/developing-cloud-controller-manager.md) doc.
+To build and develop your own cloud controller manager, read
+the [Developing Cloud Controller Manager](/docs/tasks/administer-cluster/developing-cloud-controller-manager.md) doc.
 -->
 要构建和开发你自己的云管理控制器，请阅读
 [开发云管理控制器](/zh-cn/docs/tasks/administer-cluster/developing-cloud-controller-manager/)