From 6f9e464bcc2ce8ba524c2bf2ee0fa01dd7a8aa09 Mon Sep 17 00:00:00 2001 From: Linus Lee <708863861@qq.com> Date: Tue, 27 Nov 2018 12:50:13 +0800 Subject: [PATCH] zh_trans: Fix the page: docs/concepts/architecture/cloud-controller/ display issues (#11344) * zh_trans: Fix the page: docs/concepts/architecture/cloud-controller/ display issues * zh_trans: Fix the page: docs/concepts/architecture/cloud-controller/ display issues * zh_trans: Fix the page: docs/concepts/architecture/cloud-controller/ display issues --- .../zh/docs/concepts/architecture/_index.md | 11 +++ .../concepts/architecture/cloud-controller.md | 83 ++++++++++--------- 2 files changed, 57 insertions(+), 37 deletions(-) create mode 100755 content/zh/docs/concepts/architecture/_index.md diff --git a/content/zh/docs/concepts/architecture/_index.md b/content/zh/docs/concepts/architecture/_index.md new file mode 100755 index 0000000000..93d61ea5ff --- /dev/null +++ b/content/zh/docs/concepts/architecture/_index.md @@ -0,0 +1,11 @@ +--- +title: "Kubernetes 架构" +weight: 30 +--- + + \ No newline at end of file diff --git a/content/zh/docs/concepts/architecture/cloud-controller.md b/content/zh/docs/concepts/architecture/cloud-controller.md index 15840fd8b5..a13a66b0d3 100644 --- a/content/zh/docs/concepts/architecture/cloud-controller.md +++ b/content/zh/docs/concepts/architecture/cloud-controller.md @@ -1,66 +1,75 @@ +--- title: 云控制器管理器的基本概念 +content_template: templates/concept +weight: 30 +--- -## 云控制器管理器 +{{% capture overview %}} -云控制器管理器（CCM）这个概念创建的初衷是为了让特定的云服务供应商代码和Kubernetes核心相互独立演化。云控制器管理器与其他主要组件如Kubernetes控制器管理器，API服务器和调度程序同时运行。云控制器管理器也可以作为Kubernetes的插件启动，这种情况下，CCM运行在Kubernetes系统之上。 +云控制器管理器（CCM）这个概念创建的初衷是为了让特定的云服务供应商代码和 Kubernetes 核心相互独立演化。云控制器管理器与其他主要组件如 Kubernetes 控制器管理器，API 服务器和调度程序同时运行。云控制器管理器也可以作为 Kubernetes 的插件启动，这种情况下，CCM 运行在 Kubernetes 系统之上。 -云控制器管理器基于插件机制设计，允许新的云服务供应商通过插件轻松地与Kubernetes集成。目前已经有在Kubernetes上加入新的云服务供应商计划，并为云服务供应商提供从原先的旧模式迁移到新CCM模式的方案。 +云控制器管理器基于插件机制设计，允许新的云服务供应商通过插件轻松地与 Kubernetes 集成。目前已经有在 Kubernetes 上加入新的云服务供应商计划，并为云服务供应商提供从原先的旧模式迁移到新 CCM 模式的方案。 本文讨论了云控制器管理器背后的概念，并提供了相关功能的详细信息。 -下面这张图描述了没有云控制器管理器的Kubernetes集群架构： +下面这张图描述了没有云控制器管理器的 Kubernetes 集群架构： ![无云控制器管理器的 K8s 集群架构](/images/docs/pre-ccm-arch.png) +{{% /capture %}} + + +{{% capture body %}} + ## 设计 -在上图中，Kubernetes和云服务供应商通过几个不同的组件进行了集成，分别是： +在上图中，Kubernetes 和云服务供应商通过几个不同的组件进行了集成，分别是： * Kubelet * Kubernetes 控制管理器 -* Kubernetes API服务器 +* Kubernetes API 服务器 -而CCM整合了前三个组件中的所有依赖于云的逻辑，用来创建与云的单点集成。新架构如下图所示： +而 CCM 整合了前三个组件中的所有依赖于云的逻辑，用来创建与云的单点集成。新架构如下图所示： -![有云控制器管理器的 K8s 集群架构](/images/docs/post-ccm-arch.png) +![有云控制器管理器的 Kubernetes 集群架构](/images/docs/post-ccm-arch.png) -## CCM的组件 +## CCM 的组件 -CCM突破了Kubernetes控制器管理器（KCM）的一些功能，并将其作为一个独立的进程运行。具体而言，它打破了KCM中与云相关的控制器。KCM具有以下依赖于云的控制器引擎： +CCM 突破了 Kubernetes 控制器管理器（KCM）的一些功能，并将其作为一个独立的进程运行。具体而言，它打破了 KCM 中与云相关的控制器。KCM 具有以下依赖于云的控制器引擎： * 节点控制器 * 卷控制器 * 路由控制器 * 服务控制器 -在1.8版本中，当前运行中的CCM从上面的列表中运行以下控制器： +在1.8版本中，当前运行中的 CCM 从上面的列表中运行以下控制器： * 节点控制器 * 路由控制器 * 服务控制器 -另外，它运行另一个名为 PersistentVolumeLabels Controller 的控制器。这个控制器负责对在GCP和AWS云里创建的PersistentVolumes的域（Zone）和区（Region）标签进行设置。 +另外，它运行另一个名为 PersistentVolumeLabels Controller 的控制器。这个控制器负责对在 GCP 和 AWS 云里创建的 PersistentVolumes 的域（Zone）和区（Region）标签进行设置。 -**注意**：卷控制器被特意设计为CCM之外的一部分。由于其中涉及到的复杂性和对现有供应商特定卷的逻辑抽象，因此决定了卷控制器不会被移动到CCM之中。 +**注意**：卷控制器被特意设计为 CCM 之外的一部分。由于其中涉及到的复杂性和对现有供应商特定卷的逻辑抽象，因此决定了卷控制器不会被移动到 CCM 之中。 -原本计划使用CCM来支持卷的目的是为了引入FlexVolume卷来支持可插拔卷。然而，官方正在计划使用更具备竞争力的CSI来取代FlexVolume卷。 +原本计划使用 CCM 来支持卷的目的是为了引入 FlexVolume 卷来支持可插拔卷。然而，官方正在计划使用更具备竞争力的 CSI 来取代 FlexVolume 卷。 -考虑到这些正在进行中的变化，我们决定暂时停止当前工作直至CSI准备就绪。 +考虑到这些正在进行中的变化，我们决定暂时停止当前工作直至 CSI 准备就绪。 -云服务供应商工作组（wg-cloud-provider）正在开展相关工作，以实现通过CCM支持PersistentVolume的功能。详细信息请参见[kubernetes/kubernetes＃52371](https://github.com/kubernetes/kubernetes/pull/52371)。 +云服务供应商工作组（wg-cloud-provider）正在开展相关工作，以实现通过 CCM 支持 PersistentVolume 的功能。详细信息请参见[kubernetes/kubernetes＃52371](https://github.com/kubernetes/kubernetes/pull/52371)。 -## CCM功能 +## CCM 的功能 -CCM从Kubernetes组件中继承了与云服务供应商相关的功能。本节基于被CCM继承其功能的组件展开描述。 +CCM 从 Kubernetes 组件中继承了与云服务供应商相关的功能。本节基于被 CCM 继承其功能的组件展开描述。 ### 1. Kubernetes 控制器管理器 -CCM的大部分功能都来自KCM。 如上一节所述，CCM运行以下控制引擎： +CCM 的大部分功能都来自 KCM。 如上一节所述，CCM 运行以下控制引擎： * 节点控制器 * 路由控制器 * 服务控制器 -* PersistentVolumeLabels控制器 +* PersistentVolumeLabels 控制器 #### 节点控制器 @@ -72,46 +81,46 @@ CCM的大部分功能都来自KCM。 如上一节所述，CCM运行以下控制 1.获取节点的网络地址和主机名。 -1.如果节点无响应，检查该节点是否已从云中删除。如果该节点已从云中删除，则删除Kubernetes节点对象。 +1.如果节点无响应，检查该节点是否已从云中删除。如果该节点已从云中删除，则删除 Kubernetes 节点对象。 #### 路由控制器 -路由控制器负责为云配置正确的路由，以便Kubernetes集群中不同节点上的容器可以相互通信。路由控制器仅适用于Google Compute Engine平台。 +路由控制器负责为云配置正确的路由，以便 Kubernetes 集群中不同节点上的容器可以相互通信。路由控制器仅适用于 Google Compute Engine 平台。 #### 服务控制器 -服务控制器负责监听服务的创建、更新和删除事件。根据Kubernetes中各个服务的当前状态，它将配置云负载平衡器（如ELB或Google LB）以反映Kubernetes中的服务状态。此外，它还确保云负载均衡器的服务后端保持最新。 +服务控制器负责监听服务的创建、更新和删除事件。根据Kubernetes中各个服务的当前状态，它将配置云负载平衡器（如 ELB 或 Google LB）以反映 Kubernetes 中的服务状态。此外，它还确保云负载均衡器的服务后端保持最新。 #### PersistentVolumeLabels 控制器 -PersistentVolumeLabels控制器在AWS的EBS卷、GCE的PD卷创建时申请标签，这使得用户不再需要手动设置这些卷标签。 +PersistentVolumeLabels 控制器在 AWS 的 EBS 卷、GCE 的 PD 卷创建时申请标签，这使得用户不再需要手动设置这些卷标签。 这些标签对于pod的调度工作是非常重要的，因为这些卷只能在它们所在的域（Zone）/区（Region）内工作，因此所有使用这些卷的pod都必须要在同一个域/区中才能保证进行调度正常进行。 -PersistentVolumeLabels控制器是专门为CCM创建的; 也就是说，在CCM创建之前它是不存在的。这样做是为了将Kubernetes API服务器（它是一个许可控制器）中的PV标签逻辑移动到CCM。 它不在KCM上运行。 +PersistentVolumeLabels 控制器是专门为 CCM 创建的; 也就是说，在 CCM 创建之前它是不存在的。这样做是为了将 Kubernetes API 服务器（它是一个许可控制器）中的PV标签逻辑移动到 CCM。 它不在 KCM 上运行。 ### 2. Kubelet -Node控制器包含kubelet中依赖于云的功能。在系统引入CCM组件之前，是由kubelet采用包含云特定信息的方式对节点进行初始化，如IP地址、区（Region）/域（Zone）标签和实例类型信息；引入CCM之后，这部分的初始化操作就从kubelet转移到了CCM中。 +Node控制器包含kubelet中依赖于云的功能。在系统引入 CCM 组件之前，是由 kubelet 采用包含云特定信息的方式对节点进行初始化，如 IP 地址、区（Region）/域（Zone）标签和实例类型信息；引入 CCM 之后，这部分的初始化操作就从 kubelet 转移到了 CCM 中。 -在引入CCM后的新的模型中，kubelet采用不包含云特定信息的方式初始化一个节点。但是，它会为新创建的节点添加一个污点，使得该节点不可被立即调度，直到CCM使用包含云的特定信息初始化节点后，才会删除该污点，使得该节点可被调度。 +在引入CCM后的新的模型中，kubelet 采用不包含云特定信息的方式初始化一个节点。但是，它会为新创建的节点添加一个污点，使得该节点不可被立即调度，直到 CCM 使用包含云的特定信息初始化节点后，才会删除该污点，使得该节点可被调度。 -### 3. Kubernetes API服务器 +### 3. Kubernetes API 服务器 -PersistentVolumeLabels控制器将Kubernetes API服务器的依赖于云的功能移至CCM，如前面部分所述。 +PersistentVolumeLabels 控制器将 Kubernetes API 服务器的依赖于云的功能移至 CCM，如前面部分所述。 ## 插件机制 -云控制器管理器使用Go接口与外部对接从而实现功能扩展。具体来说，它使用了[这里](https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/cloud.go)定义的CloudProvider接口。 +云控制器管理器使用 Go 接口与外部对接从而实现功能扩展。具体来说，它使用了[这里](https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/cloud.go)定义的 CloudProvider 接口。 -上面强调的四个共享控制器的实现，以及一些辅助设施（scaffolding）和共享的云服务供应商接口，将被保留在Kubernetes核心当中。但云服务供应商特有的实现将会建立在核心之外，并实现核心中定义的接口。 +上面强调的四个共享控制器的实现，以及一些辅助设施（scaffolding）和共享的云服务供应商接口，将被保留在 Kubernetes 核心当中。但云服务供应商特有的实现将会建立在核心之外，并实现核心中定义的接口。 有关开发插件的更多信息，请参阅 [开发云控制器管理器](/docs/tasks/administrators-cluster/developing-cloud-controller-manager/)。 ## 授权 -本节分解了CCM对各种API对象的访问，以执行其操作。 +本节分解了 CCM 对各种 API 对象的访问，以执行其操作。 ### 节点控制器 @@ -149,7 +158,7 @@ v1/Service: ### PersistentVolumeLabels 控制器 -PersistentVolumeLabels控制器监听PersistentVolume（PV）创建事件并更新它们。该控制器需要访问列表、查看、获取和更新PV的权限。 +PersistentVolumeLabels 控制器监听 PersistentVolume（PV）创建事件并更新它们。该控制器需要访问列表、查看、获取和更新 PV 的权限。 v1/PersistentVolume: - Get @@ -159,7 +168,7 @@ v1/PersistentVolume: ### 其它 -CCM核心的实现需要创建事件的权限，为了确保安全操作，需要创建ServiceAccounts的权限。 +CCM 核心的实现需要创建事件的权限，为了确保安全操作，需要创建 ServiceAccounts 的权限。 v1/Event: - Create @@ -169,7 +178,7 @@ v1/Event: v1/ServiceAccount: - Create -针对CCM的RBAC ClusterRole如下所示： +针对 CCM 的 RBAC ClusterRole 如下所示： ```yaml apiVersion: rbac.authorization.k8s.io/v1 @@ -235,7 +244,7 @@ rules: ## 供应商实施 -以下云服务供应商为自己的云部署了CCM。 +以下云服务供应商为自己的云部署了 CCM。 * [Digital Ocean]() * [Oracle]() @@ -245,4 +254,4 @@ rules: ## 群集管理 -[这里](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)提供了配置和运行CCM的完整说明。 +[这里](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)提供了配置和运行 CCM 的完整说明。