diff --git a/content/zh/docs/concepts/cluster-administration/_index.md b/content/zh/docs/concepts/cluster-administration/_index.md index f901bc55f1..a494f4f42b 100644 --- a/content/zh/docs/concepts/cluster-administration/_index.md +++ b/content/zh/docs/concepts/cluster-administration/_index.md @@ -1,4 +1,136 @@ --- -title: "计算、存储和网络扩展" -weight: 30 +title: "集群管理" +weight: 100 +content_type: concept +description: > + 关于创建和管理 Kubernetes 集群的底层细节。 +no_list: true --- + + + + + +集群管理概述面向任何创建和管理 Kubernetes 集群的读者人群。 +我们假设你对一些核心的 Kubernetes [概念](/zh/docs/concepts/)大概了解。 + + + + +## 规划集群 + +查阅[安装](/zh/docs/setup/)中的指导，获取如何规划、建立以及配置 Kubernetes 集群的示例。本文所列的文章称为*发行版* 。 + +{{< note >}} +并非所有发行版都是被积极维护的。 +请选择使用最近 Kubernetes 版本测试过的发行版。 +{{< /note >}} + +在选择一个指南前，有一些因素需要考虑： + + +- 你是打算在你的计算机上尝试 Kubernetes，还是要构建一个高可用的多节点集群？请选择最适合你需求的发行版。 +- 您正在使用类似 [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) 这样的**被托管的 Kubernetes 集群**, 还是**管理您自己的集群**？ +- 你的集群是在**本地**还是**云（IaaS）**上？Kubernetes 不能直接支持混合集群。作为代替，你可以建立多个集群。 +- **如果你在本地配置 Kubernetes**，需要考虑哪种[网络模型](/zh/docs/concepts/cluster-administration/networking/)最适合。 +- 你的 Kubernetes 在**裸金属硬件**上还是**虚拟机（VMs）**上运行？ +- 你**只想运行一个集群**，还是打算**参与开发 Kubernetes 项目代码**？如果是后者，请选择一个处于开发状态的发行版。某些发行版只提供二进制发布版，但提供更多的选择。 +- 让你自己熟悉运行一个集群所需的[组件](/zh/docs/admin/cluster-components)。 + + +## 管理集群 + +* [管理集群](/zh/docs/tasks/administer-cluster/cluster-management/)叙述了和集群生命周期相关的几个主题： +创建新集群、升级集群的控制节点和工作节点、执行节点维护（例如内核升级）以及升级运行中的集群的 Kubernetes API 版本。 + +* 学习如何[管理节点](/zh/docs/concepts/nodes/node/)。 + +* 学习如何设定和管理集群共享的[资源配额](/zh/docs/concepts/policy/resource-quotas/) 。 + + +## 保护集群 + +* [证书](/zh/docs/concepts/cluster-administration/certificates/)节描述了使用不同的工具链生成证书的步骤。 +* [Kubernetes 容器环境](/zh/docs/concepts/containers/container-environment-variables/)描述了 Kubernetes 节点上由 Kubelet 管理的容器的环境。 +* [控制到 Kubernetes API 的访问](/zh/docs/reference/access-authn-authz/controlling-access/)描述了如何为用户和 service accounts 建立权限许可。 +* [认证](/zh/docs/reference/access-authn-authz/authentication/)节阐述了 Kubernetes 中的身份认证功能，包括许多认证选项。 +* [鉴权](/zh/docs/admin/authorization/)从认证中分离出来，用于控制如何处理 HTTP 请求。 +* [使用准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers) 阐述了在认证和授权之后拦截到 Kubernetes API 服务的请求的插件。 +* [在 Kubernetes 集群中使用 Sysctls](/zh/docs/concepts/cluster-administration/sysctl-cluster/) 描述了管理员如何使用 `sysctl` 命令行工具来设置内核参数。 +* [审计](/zh/docs/tasks/debug-application-cluster/audit/)描述了如何与 Kubernetes 的审计日志交互。 + + +### 保护 kubelet + +* [主控节点通信](/zh/docs/concepts/cluster-administration/master-node-communication/) +* [TLS 引导](/zh/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) +* [Kubelet 认证/授权](/zh/docs/admin/kubelet-authentication-authorization/) + + + +## 可选集群服务 + +* [DNS 集成](/zh/docs/concepts/services-networking/dns-pod-service/)描述了如何将一个 DNS 名解析到一个 Kubernetes service。 +* [记录和监控集群活动](/zh/docs/concepts/cluster-administration/logging/)阐述了 Kubernetes 的日志如何工作以及怎样实现。 + diff --git a/content/zh/docs/concepts/cluster-administration/cluster-administration-overview.md b/content/zh/docs/concepts/cluster-administration/cluster-administration-overview.md deleted file mode 100644 index 365ed8f7ac..0000000000 --- a/content/zh/docs/concepts/cluster-administration/cluster-administration-overview.md +++ /dev/null @@ -1,145 +0,0 @@ ---- -title: 集群管理概述 -content_type: concept -weight: 10 ---- - - - - - -集群管理概述面向任何创建和管理 Kubernetes 集群的读者人群。 -我们假设你对[用户指南](/docs/user-guide/)中的概念大概了解。 - - - - - - -## 规划集群 - -查阅[安装](/docs/setup/)中的指导，获取如何规划、建立以及配置 Kubernetes 集群的示例。本文所列的文章称为*发行版* 。 - -在选择一个指南前，有一些因素需要考虑： - - - - - 你是打算在你的电脑上尝试 Kubernetes，还是要构建一个高可用的多节点集群？请选择最适合你需求的发行版。 - - **如果你正在设计一个高可用集群**，请了解[在多个 zones 中配置集群](/docs/concepts/cluster-administration/federation/)。 - - 您正在使用类似 [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) 这样的 **被托管的Kubernetes集群**, 还是 **管理您自己的集群**？ - - 你的集群是在 **本地** 还是 **云（IaaS）** 上？Kubernetes 不能直接支持混合集群。作为代替，你可以建立多个集群。 - - **如果你在本地配置 Kubernetes**，需要考虑哪种[网络模型](/docs/concepts/cluster-administration/networking/)最适合。 - - 你的 Kubernetes 在 **裸金属硬件** 还是 **虚拟机（VMs）** 上运行？ - - 你 **只想运行一个集群**，还是打算 **活动开发 Kubernetes 项目代码**？如果是后者，请选择一个活动开发的发行版。某些发行版只提供二进制发布版，但提供更多的选择。 - - 让你自己熟悉运行一个集群所需的[组件](/docs/admin/cluster-components)。 - - - -请注意：不是所有的发行版都被积极维护着。请选择测试过最近版本的 Kubernetes 的发行版。 - - - -## 管理集群 - -* [管理集群](/docs/concepts/cluster-administration/cluster-management/)叙述了和集群生命周期相关的几个主题：创建一个新集群、升级集群的 master 和 worker 节点、执行节点维护（例如内核升级）以及升级活动集群的 Kubernetes API 版本。 - -* 学习如何[管理节点](/docs/concepts/nodes/node/)。 - -* 学习如何设定和管理集群共享的[资源配额](/docs/concepts/policy/resource-quotas/) 。 - - - -## 集群安全 - -* [Certificates](/docs/concepts/cluster-administration/certificates/) 描述了使用不同的工具链生成证书的步骤。 - -* [Kubernetes 容器环境](/docs/concepts/containers/container-environment-variables/)描述了 Kubernetes 节点上由 Kubelet 管理的容器的环境。 - -* [控制到 Kubernetes API 的访问](/docs/reference/access-authn-authz/controlling-access/)描述了如何为用户和 service accounts 建立权限许可。 - -* [用户认证](/docs/reference/access-authn-authz/authentication/)阐述了 Kubernetes 中的认证功能，包括许多认证选项。 - -* [授权](/docs/admin/authorization)从认证中分离出来，用于控制如何处理 HTTP 请求。 - -* [使用 Admission Controllers](/docs/admin/admission-controllers) 阐述了在认证和授权之后拦截到 Kubernetes API 服务的请求的插件。 - -* [在 Kubernetes Cluster 中使用 Sysctls](/docs/concepts/cluster-administration/sysctl-cluster/) 描述了管理员如何使用 `sysctl` 命令行工具来设置内核参数。 - -* [审计](/docs/tasks/debug-application-cluster/audit/)描述了如何与 Kubernetes 的审计日志交互。 - - - -### 保护 kubelet - - * [Master 节点通信](/docs/concepts/cluster-administration/master-node-communication/) - * [TLS 引导](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) - * [Kubelet 认证/授权](/docs/admin/kubelet-authentication-authorization/) - - - -## 可选集群服务 - -* [DNS 与 SkyDNS 集成](/docs/concepts/services-networking/dns-pod-service/)描述了如何将一个 DNS 名解析到一个 Kubernetes service。 - -* [记录和监控集群活动](/docs/concepts/cluster-administration/logging/)阐述了 Kubernetes 的日志如何工作以及怎样实现。 - - diff --git a/content/zh/docs/concepts/cluster-administration/federation.md b/content/zh/docs/concepts/cluster-administration/federation.md deleted file mode 100644 index e0f86e8823..0000000000 --- a/content/zh/docs/concepts/cluster-administration/federation.md +++ /dev/null @@ -1,118 +0,0 @@ ---- -title: 联邦 -content_type: concept ---- - - -本页面阐明了为何以及如何使用联邦创建Kubernetes集群。 - - - -## 为何使用联邦 - -联邦可以使多个集群的管理简单化。它提供了两个主要构件模块： - - * 跨集群同步资源：联邦能够让资源在多个集群中同步。例如，你可以确保在多个集群中存在同样的部署。 - * 跨集群发现：联邦能够在所有集群的后端自动配置DNS服务和负载均衡。例如，通过多个集群的后端，你可以确保全局的VIP或DNS记录可用。 - -联邦技术的其他应用场景： - -* 高可用性：通过跨集群分摊负载，自动配置DNS服务和负载均衡，联邦将集群失败所带来的影响降到最低。 -* 避免供应商锁定：跨集群使迁移应用程序变得更容易，联邦服务避免了供应商锁定。 - - -只有在多个集群的场景下联邦服务才是有帮助的。这里列出了一些你会使用多个集群的原因： - -* 降低延迟：在多个区域含有集群，可使用离用户最近的集群来服务用户，从而最大限度降低延迟。 -* 故障隔离：对于故障隔离，也许有多个小的集群比有一个大的集群要更好一些（例如：一个云供应商的不同可用域里有多个集群）。详细信息请参阅[多集群指南](/docs/admin/multi-cluster)。 -* 可伸缩性：对于单个kubernetes集群是有伸缩性限制的（但对于大多数用户来说并非如此。更多细节参考[Kubernetes扩展和性能目标](https://git.k8s.io/community/sig-scalability/goals.md)）。 -* [混合云](#混合云的能力)：可以有多个集群，它们分别拥有不同的云供应商或者本地数据中心。 - -### 注意事项 - -虽然联邦有很多吸引人的场景，但这里还是有一些需要关注的事项： - -* 增加网络的带宽和损耗：联邦控制面会监控所有的集群，来确保集群的当前状态与预期一致。那么当这些集群运行在一个或者多个云提供者的不同区域中，则会带来重大的网络损耗。 -* 降低集群的隔离：当联邦控制面中存在一个故障时，会影响所有的集群。把联邦控制面的逻辑降到最小可以缓解这个问题。 无论何时，它都是kubernetes集群里控制面的代表。设计和实现也使其变得更安全,避免多集群运行中断。 -* 完整性：联邦项目相对较新，还不是很成熟。不是所有资源都可用，且很多资源才刚刚开始。[Issue 38893](https://github.com/kubernetes/kubernetes/issues/38893) 列举了一些团队正忙于解决的系统已知问题。 - -### 混合云的能力 - -Kubernetes集群里的联邦包括运行在不同云供应商上的集群（例如，谷歌云、亚马逊），和本地部署的集群（例如，OpenStack）。只需在适当的云供应商和/或位置创建所需的所有集群，并将每个集群的API endpoint和凭据注册到您的联邦API服务中（详情参考[联邦管理指南](/docs/admin/federation/)）。 - -在此之后，您的[API资源](#api资源)就可以跨越不同的集群和云供应商。 - -## 建立联邦 - -若要能联合多个集群，首先需要建立一个联邦控制面。参照[安装指南](/docs/tutorials/federation/set-up-cluster-federation-kubefed/) 建立联邦控制面。 - -## API资源 - -控制面建立完成后，就可以开始创建联邦API资源了。 -以下指南详细介绍了一些资源： - -* [Cluster](/docs/tasks/administer-federation/cluster/) -* [ConfigMap](/docs/tasks/administer-federation/configmap/) -* [DaemonSets](/docs/tasks/administer-federation/daemonset/) -* [Deployment](/docs/tasks/administer-federation/deployment/) -* [Events](/docs/tasks/administer-federation/events/) -* [Ingress](/docs/tasks/administer-federation/ingress/) -* [Namespaces](/docs/tasks/administer-federation/namespaces/) -* [ReplicaSets](/docs/tasks/administer-federation/replicaset/) -* [Secrets](/docs/tasks/administer-federation/secret/) -* [Services](/docs/concepts/cluster-administration/federation-service-discovery/) - -[API参考文档](/docs/reference/federation/)列举了联邦API服务支持的所有资源。 - -## 级联删除 - -Kubernetes1.6版本支持联邦资源级联删除。使用级联删除，即当删除联邦控制面的一个资源时，也删除了所有底层集群中的相应资源。 - -当使用REST API时，级联删除功能不是默认开启的。若使用REST API从联邦控制面删除一个资源时，要开启级联删除功能，即需配置选项 `DeleteOptions.orphanDependents=false`。使用`kubectl delete`使级联删除功能默认开启。使用`kubectl delete --cascade=false`禁用级联删除功能。 - -注意：Kubernetes1.5版本开始支持联邦资源子集的级联删除。 - -## 单个集群的范围 - -对于IaaS供应商如谷歌计算引擎或亚马逊网络服务，一个虚拟机存在于一个[域](https://cloud.google.com/compute/docs/zones)或[可用域](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html)中。 -我们建议一个Kubernetes集群里的所有虚机应该在相同的可用域里，因为： - - - 与单一的全局Kubernetes集群对比，该方式有较少的单点故障。 - - 与跨可用域的集群对比，该方式更容易推断单区域集群的可用性属性。 - - 当Kubernetes开发者设计一个系统(例如，对延迟、带宽或相关故障进行假设)，他们也会假设所有的机器都在一个单一的数据中心，或者以其他方式紧密相连。 - -每个可用区域里包含多个集群当然是可以的，但是总的来说我们认为集群数越少越好。 -偏爱较少集群数的原因是： - - - 在某些情况下，在一个集群里有更多的节点，可以改进Pods的装箱问题（更少的资源碎片）。 - - 减少操作开销（尽管随着OPS工具和流程的成熟而降低了这块的优势）。 - - 为每个集群的固定资源花费降低开销，例如，使用apiserver的虚拟机（但是在全体集群开销中，中小型集群的开销占比要小的多）。 - -多集群的原因包括： - - - 严格的安全性策略要求隔离一类工作与另一类工作（但是，请参见下面的集群分割）。 - - 测试集群或其他集群软件直至最优的新Kubernetes版本发布。 - -## 选择合适的集群数 - -Kubernetes集群数量选择也许是一个相对静止的选择，因为对其重新审核的情况很少。相比之下，一个集群中的节点数和一个服务中的pods数可能会根据负载和增长频繁变化。 - -选择集群的数量，首先，需要决定哪些区域对于将要运行在Kubernetes上的服务，可以有足够的时间到达所有的终端用户（如果使用内容分发网络，则不需要考虑CDN-hosted内容的延迟需求）。法律问题也可能影响这一点。例如，拥有全球客户群的公司可能会对于在美国、欧盟、亚太和南非地区拥有集群起到决定权。使用`R`代表区域的数量。 - -其次，决定有多少集群在同一时间不可用，而一些仍然可用。使用`U`代表不可用的数量。如果不确定，最好选择1。 - -如果允许负载均衡在集群故障发生时将通信引导到任何区域，那么至少需要较大的`R`或`U + 1`集群。若非如此（例如，若要在集群故障发生时确保所有用户的低延迟），则需要`R * (U + 1)`集群(在每一个`R`区域里都有`U + 1`)。在任何情况下，尝试将每个集群放在不同的区域中。 - -最后，如果你的集群需求超过一个Kubernetes集群推荐的最大节点数，那么你可能需要更多的集群。Kubernetes1.3版本支持多达1000个节点的集群规模。 - - - -## {{% heading "whatsnext" %}} - -* 进一步学习[联邦提案](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/multicluster/federation.md)。 -* 集群联邦参考该[配置指导](/docs/tutorials/federation/set-up-cluster-federation-kubefed/)。 -* 查看[Kubecon2016浅谈联邦](https://www.youtube.com/watch?v=pq9lbkmxpS8) - - - - diff --git a/content/zh/docs/concepts/services-networking/connect-applications-service.md b/content/zh/docs/concepts/services-networking/connect-applications-service.md index d49d61294b..a4985549c1 100644 --- a/content/zh/docs/concepts/services-networking/connect-applications-service.md +++ b/content/zh/docs/concepts/services-networking/connect-applications-service.md @@ -602,15 +602,11 @@ LoadBalancer Ingress: a320587ffd19711e5a37606cf4a74574-1142138393.us-east-1.el ## {{% heading "whatsnext" %}} - - -Kubernetes 也支持联合 Service，能够跨多个集群和云提供商，为 Service 提供逐步增强的可用性、更优的容错、更好的可伸缩性。 -查看 [联合 Service 用户指南](/docs/concepts/cluster-administration/federation-service-discovery/) 获取更进一步信息。 - +* 进一步了解如何[使用 Service 访问集群中的应用](/zh/docs/tasks/access-application-cluster/service-access-application-cluster/) +* 进一步了解如何[使用 Service 将前端连接到后端](/zh/docs/tasks/access-application-cluster/connecting-frontend-backend/) +* 进一步了解如何[创建外部负载均衡器](/zh/docs/tasks/access-application-cluster/create-external-load-balancer/) diff --git a/content/zh/docs/concepts/services-networking/ingress.md b/content/zh/docs/concepts/services-networking/ingress.md index 24b2acd5dc..502abfcbc4 100644 --- a/content/zh/docs/concepts/services-networking/ingress.md +++ b/content/zh/docs/concepts/services-networking/ingress.md @@ -4,13 +4,11 @@ content_type: concept weight: 40 --- diff --git a/content/zh/docs/reference/_index.md b/content/zh/docs/reference/_index.md index 2c49c689d1..64091816a7 100644 --- a/content/zh/docs/reference/_index.md +++ b/content/zh/docs/reference/_index.md @@ -7,7 +7,6 @@ content_type: concept --- @@ -25,20 +23,8 @@ This section of the Kubernetes documentation contains references. --> 这是 Kubernetes 文档的参考部分。 - - -## API 参考 - -* [Kubernetes API 概述](/docs/reference/using-api/api-overview/) - Kubernetes API 概述。 -* Kubernetes API 版本 - * [1.17](/docs/reference/generated/kubernetes-api/v1.17/) - * [1.16](/docs/reference/generated/kubernetes-api/v1.16/) - * [1.15](/docs/reference/generated/kubernetes-api/v1.15/) - * [1.14](/docs/reference/generated/kubernetes-api/v1.14/) - * [1.13](/docs/reference/generated/kubernetes-api/v1.13/) - +## API 参考 -## API 客户端库 - -如果您需要通过编程语言调用 Kubernetes API，您可以使用 -[客户端库](/docs/reference/using-api/client-libraries/)。以下是官方支持的客户端库： - -- [Kubernetes Go 语言客户端库](https://github.com/kubernetes/client-go/) -- [Kubernetes Python 语言客户端库](https://github.com/kubernetes-client/python) -- [Kubernetes Java 语言客户端库](https://github.com/kubernetes-client/java) -- [Kubernetes JavaScript 语言客户端库](https://github.com/kubernetes-client/javascript) +* [Kubernetes API 概述](/docs/reference/using-api/api-overview/) - Kubernetes API 概述。 +* Kubernetes API 版本 + * [1.17](/docs/reference/generated/kubernetes-api/v1.17/) + * [1.16](/docs/reference/generated/kubernetes-api/v1.16/) + * [1.15](/docs/reference/generated/kubernetes-api/v1.15/) + * [1.14](/docs/reference/generated/kubernetes-api/v1.14/) + * [1.13](/docs/reference/generated/kubernetes-api/v1.13/) +## API 客户端库 -## CLI 参考 +如果您需要通过编程语言调用 Kubernetes API，您可以使用 +[客户端库](/docs/reference/using-api/client-libraries/)。以下是官方支持的客户端库： -* [kubectl](/docs/user-guide/kubectl-overview) - 主要的 CLI 工具，用于运行命令和管理 Kubernetes 集群。 - * [JSONPath](/docs/user-guide/jsonpath/) - 通过 kubectl 使用 [JSONPath 表达式](http://goessner.net/articles/JsonPath/) 的语法指南。 -* [kubeadm](/docs/admin/kubeadm/) - 此 CLI 工具可轻松配置安全的 Kubernetes 集群。 -* [kubefed](/docs/admin/kubefed/) - 此 CLI 工具可帮助您管理集群联邦。 +- [Kubernetes Go 语言客户端库](https://github.com/kubernetes/client-go/) +- [Kubernetes Python 语言客户端库](https://github.com/kubernetes-client/python) +- [Kubernetes Java 语言客户端库](https://github.com/kubernetes-client/java) +- [Kubernetes JavaScript 语言客户端库](https://github.com/kubernetes-client/javascript) +## CLI 参考 -## 配置参考 - -* [kubelet](/docs/admin/kubelet/) - 在每个节点上运行的主 *节点代理* 。kubelet 采用一组 PodSpecs 并确保所描述的容器健康地运行。 -* [kube-apiserver](/docs/admin/kube-apiserver/) - REST API，用于验证和配置 API 对象（如 pod，服务，副本控制器）的数据。 -* [kube-controller-manager](/docs/admin/kube-controller-manager/) - 一个守护进程，它嵌入到了 Kubernetes 的附带的核心控制循环。 -* [kube-proxy](/docs/admin/kube-proxy/) - 可以跨一组后端进行简单的 TCP/UDP 流转发或循环 TCP/UDP 转发。 -* [kube-scheduler](/docs/admin/kube-scheduler/) - 一个调度程序，用于管理可用性、性能和容量。 -* [federation-apiserver](/docs/admin/federation-apiserver/) - 联邦集群的 API 服务器。 -* [federation-controller-manager](/docs/admin/federation-controller-manager/) - 一个守护进程，它嵌入到了 Kubernetes 联邦的附带的核心控制循环。 +* [kubectl](/docs/user-guide/kubectl-overview) - 主要的 CLI 工具，用于运行命令和管理 Kubernetes 集群。 + * [JSONPath](/docs/user-guide/jsonpath/) - 通过 kubectl 使用 [JSONPath 表达式](http://goessner.net/articles/JsonPath/) 的语法指南。 +* [kubeadm](/docs/admin/kubeadm/) - 此 CLI 工具可轻松配置安全的 Kubernetes 集群。 +* [kubefed](/docs/admin/kubefed/) - 此 CLI 工具可帮助您管理集群联邦。 +## 配置参考 -## 设计文档 - -Kubernetes 功能的设计文档归档，不妨考虑从 [Kubernetes 架构](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md) 和 [Kubernetes 设计概述](https://git.k8s.io/community/contributors/design-proposals)开始阅读。 +* [kubelet](/docs/admin/kubelet/) - 在每个节点上运行的主 *节点代理* 。kubelet 采用一组 PodSpecs 并确保所描述的容器健康地运行。 +* [kube-apiserver](/docs/admin/kube-apiserver/) - REST API，用于验证和配置 API 对象（如 pod，服务，副本控制器）的数据。 +* [kube-controller-manager](/docs/admin/kube-controller-manager/) - 一个守护进程，它嵌入到了 Kubernetes 的附带的核心控制循环。 +* [kube-proxy](/docs/admin/kube-proxy/) - 可以跨一组后端进行简单的 TCP/UDP 流转发或循环 TCP/UDP 转发。 +* [kube-scheduler](/docs/admin/kube-scheduler/) - 一个调度程序，用于管理可用性、性能和容量。 +## 设计文档 + +Kubernetes 功能的设计文档归档，不妨考虑从 [Kubernetes 架构](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md) 和 [Kubernetes 设计概述](https://git.k8s.io/community/contributors/design-proposals)开始阅读。 diff --git a/content/zh/docs/reference/tools.md b/content/zh/docs/reference/tools.md index fa41dcaf8c..caec8028c9 100644 --- a/content/zh/docs/reference/tools.md +++ b/content/zh/docs/reference/tools.md @@ -38,15 +38,6 @@ Kubernetes 包含一些内置工具，可以帮助用户更好的使用 Kubernet --> [`kubeadm`](/docs/tasks/tools/install-kubeadm/) 是一个命令行工具，可以用来在物理机、云服务器或虚拟机（目前处于 alpha 阶段）上轻松部署一个安全可靠的 Kubernetes 集群。 -## Kubefed - - -[`kubefed`](/docs/tasks/federation/set-up-cluster-federation-kubefed/) 是一个命令行工具，可以用来帮助用户管理联邦集群。 - - ## Minikube - Kubernetes 的安装并不会默认配置节点的 `resolv.conf` 文件来使用集群的 DNS 服务，因为这个配置对于不同的发行版本是不一样的。这个问题应该迟早会被解决的。 Linux 的 libc 会在仅有三个 DNS 的 `nameserver` 和六个 DNS 的`search` 记录时会不可思议的卡死 ([详情请查阅这个2005年的bug](https://bugzilla.redhat.com/show_bug.cgi?id=168253))。Kubernetes 需要占用一个 `nameserver` 记录和三个`search`记录。这意味着如果一个本地的安装已经使用了三个`nameserver`或者使用了超过三个的 `search`记录，那有些配置很可能会丢失。有一个不完整的解决方案就是在节点上使用`dnsmasq`来提供更多的`nameserver`配置，但是无法提供更多的`search`记录。您也可以使用kubelet 的 `--resolv-conf` 标签来解决这个问题。 @@ -532,24 +529,6 @@ Linux 的 libc 会在仅有三个 DNS 的 `nameserver` 和六个 DNS 的`search` 如果您是使用 Alpine 3.3 或者更早版本作为您的基础镜像，DNS 可能会由于Alpine 一个已知的问题导致无法正常工作，请查看[这里](https://github.com/kubernetes/kubernetes/issues/30215)获取更多资料。 - -## Kubernetes Federation (支持多区域部署) - -自从 1.3 版本支持了多个 Kubernetes 的联邦集群后，集群 DNS 服务在处理 DNS 请求时需要有一些微弱的调整 (这是向下兼容的)，从而可以使用跨越多个 Kubernetes 集群的联邦服务。请看 [联邦集群管理向导](/docs/concepts/cluster-administration/federation/) 获取更多关于联邦集群和多点支持的信息。 - - +--> ## 参考 @@ -572,6 +548,3 @@ for more details on Cluster Federation and multi-site support. - [集群里自动伸缩 DNS Service](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/). - - - diff --git a/content/zh/docs/tasks/federation/_index.md b/content/zh/docs/tasks/federation/_index.md deleted file mode 100755 index 41b5f58674..0000000000 --- a/content/zh/docs/tasks/federation/_index.md +++ /dev/null @@ -1,4 +0,0 @@ ---- -title: "联邦 - 在多个集群上运行一个应用" -weight: 120 ---- diff --git a/content/zh/docs/tasks/federation/administer-federation/_index.md b/content/zh/docs/tasks/federation/administer-federation/_index.md deleted file mode 100644 index 72d12f92fc..0000000000 --- a/content/zh/docs/tasks/federation/administer-federation/_index.md +++ /dev/null @@ -1,4 +0,0 @@ ---- -title: "管理联邦控制平面" -weight: 160 ---- diff --git a/content/zh/docs/tasks/federation/administer-federation/configmap.md b/content/zh/docs/tasks/federation/administer-federation/configmap.md deleted file mode 100644 index 0c2e619338..0000000000 --- a/content/zh/docs/tasks/federation/administer-federation/configmap.md +++ /dev/null @@ -1,148 +0,0 @@ ---- -title: 联邦 ConfigMap -content_type: task ---- - - - - -{{< deprecationfilewarning >}} -{{< include "federation-deprecation-warning-note.md" >}} -{{< /deprecationfilewarning >}} - -本指南介绍如何在联邦控制平面中使用 ConfigMap。 - -联邦 ConfigMap 与传统 [Kubernetes -ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) 非常相似且提供相同的功能。 -在联邦控制平面中创建它们可以确保它们在联邦的所有集群中同步。 - - - -## {{% heading "prerequisites" %}} - - -* {{< include "federated-task-tutorial-prereqs.md" >}} - -* 通常我们还期望您拥有基本的 [Kubernetes 应用知识](/docs/tutorials/kubernetes-basics/)， -特别是 [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) 相关的应用知识。 - - - - - -## 创建联邦 ConfigMap - -联邦 ConfigMap 的 API 100% 兼容传统 Kubernetes ConfigMap 的 API。您可以通过向联邦 apiserver 发送请求来创建 ConfigMap。 -您可以通过使用 [kubectl](/docs/user-guide/kubectl/) 运行下面的指令来创建联邦 ConfigMap： - -``` shell -kubectl --context=federation-cluster create -f myconfigmap.yaml -``` - -`--context=federation-cluster` 参数告诉 kubectl 将请求提交到联邦 apiserver 而不是发送给某一个 Kubernetes 集群。 - -一旦联邦 ConfigMap 被创建，联邦控制平面就会在所有底层 Kubernetes 集群中创建匹配的 ConfigMap。 -您可以通过检查底层每个集群来对其进行验证，例如： - -``` shell -kubectl --context=gce-asia-east1a get configmap myconfigmap -``` - -上面的命令假定您在客户端中配置了一个叫做 ‘gce-asia-east1a’ 的上下文。 - -这些底层集群中的 ConfigMap 将与 联邦 ConfigMap 相匹配。 - - -## 更新联邦 ConfigMap - -您可以像更新 Kubernetes ConfigMap 一样更新联邦 ConfigMap。 -但是对于联邦 ConfigMap，您必须发送请求到联邦 apiserver 而不是某个特定的 Kubernetes 集群。 -联邦控制平面会确保每当联邦 ConfigMap 更新时，它会更新所有底层集群中的 ConfigMap 来和更新后的内容保持一致。 - - -## 删除联邦 ConfigMap - -您可以像删除 Kubernetes ConfigMap 一样删除联邦 ConfigMap。 -但是，对于联邦 ConfigMap，您必须发送请求到联邦 apiserver 而不是某个特定的 Kubernetes 集群。 -例如，您可以使用 kubectl 运行下面的命令来删除联邦 ConfigMap： - -```shell -kubectl --context=federation-cluster delete configmap -``` - -{{< note >}} - -要注意的是这时删除联邦 ConfigMap 并不会删除底层集群中对应的 ConfigMap。您必须自己手动删除底层集群中的 ConfigMap。 -{{< /note >}} - - - - diff --git a/content/zh/docs/tasks/federation/administer-federation/daemonset.md b/content/zh/docs/tasks/federation/administer-federation/daemonset.md deleted file mode 100644 index 88ed66d090..0000000000 --- a/content/zh/docs/tasks/federation/administer-federation/daemonset.md +++ /dev/null @@ -1,136 +0,0 @@ ---- -title: 联邦 DaemonSet -content_type: task ---- - - - - -{{< deprecationfilewarning >}} -{{< include "federation-deprecation-warning-note.md" >}} -{{< /deprecationfilewarning >}} - - -本指南说明了如何在联邦控制平面中使用 DaemonSet。 - -联邦控制平面中的 DaemonSet（在本指南中称为 “联邦 DaemonSet”）与传统的 Kubernetes [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) 非常类似，并提供相同的功能。在联邦控制平面中创建联邦 DaemonSet 可以确保它们同步到联邦的所有集群中。 - - - -## {{% heading "prerequisites" %}} - - -* {{< include "federated-task-tutorial-prereqs.md" >}} - -* 你还应该具备基本的 [Kubernetes 应用知识](/docs/tutorials/kubernetes-basics/)，特别是 [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) 相关的应用知识。 - - - - - - -## 创建联邦 Daemonset - -联邦 Daemonset 的 API 和传统的 Kubernetes Daemonset API 是 100% 兼容的。您可以通过向联邦 apiserver 发送请求来创建一个 DaemonSet。 - -您可以通过使用 [kubectl](/docs/user-guide/kubectl/) 运行下面的指令来创建联邦 Daemonset： - -``` shell -kubectl --context=federation-cluster create -f mydaemonset.yaml -``` - -`--context=federation-cluster` 参数告诉 kubectl 发送请求到联邦 apiserver 而不是某个 Kubernetes 集群。 - -一旦联邦 Daemonset 被创建，联邦控制平面就会在所有底层 Kubernetes 集群中创建匹配的 Daemonset。您可以通过检查底层每个集群来对其进行验证，例如： - -``` shell -kubectl --context=gce-asia-east1a get daemonset mydaemonset -``` - -上面的命令假定您在客户端中配置了一个叫做 ‘gce-asia-east1a’ 的上下文。 - - - -## 更新联邦 Daemonset - -您可以像更新 Kubernetes Daemonset 一样更新联邦 Daemonset。但是，对于联邦 Daemonset，您必须发送请求到联邦 apiserver 而不是某个特定的 Kubernetes 集群。联邦控制平面会确保每当联邦 Daemonset 更新时，它会更新所有底层集群中的 Daemonset 来和更新后的内容保持一致。 - - -## 删除联邦 Daemonset - -您可以像删除 Kubernetes Daemonset 一样删除联邦 Daemonset。但是，对于联邦 Daemonset，您必须发送请求到联邦 apiserver 而不是某个特定的 Kubernetes 集群。 - -例如，您可以使用 kubectl 运行下面的命令来删除联邦 Daemonset： - -```shell -kubectl --context=federation-cluster delete daemonset mydaemonset -``` - - - - diff --git a/content/zh/docs/tasks/federation/administer-federation/deployment.md b/content/zh/docs/tasks/federation/administer-federation/deployment.md deleted file mode 100644 index 1d4e53ffa4..0000000000 --- a/content/zh/docs/tasks/federation/administer-federation/deployment.md +++ /dev/null @@ -1,177 +0,0 @@ ---- -title: 联邦 Deployment -content_type: task ---- - - - - -{{< deprecationfilewarning >}} -{{< include "federation-deprecation-warning-note.md" >}} -{{< /deprecationfilewarning >}} - - -本指南说明了如何在联邦控制平面中使用 Deployment。 - -联邦控制平面中的 Deployment（在本指南中称为 “联邦 Deployment”）与传统的 [Kubernetes -Deployment](/docs/concepts/workloads/controllers/deployment/) 非常类似，并提供相同的功能。在联邦控制平面中创建联邦 Deployment 确保所需的副本数存在于注册的群集中。 - -{{< feature-state for_k8s_version="1.5" state="alpha" >}} - - -一些特性（例如完整的 rollout 兼容性）仍在开发中。 - - -## {{% heading "prerequisites" %}} - - -* {{< include "federated-task-tutorial-prereqs.md" >}} - -* 您还应当拥有基本的 [Kubernetes 应用知识](/docs/tutorials/kubernetes-basics/)，特别是在 [Deployments](/docs/concepts/workloads/controllers/deployment/) 方面。 - - - - - -## 创建联邦 Deployment - -联邦 Deployment 的 API 和传统的 Kubernetes Deployment API 是兼容的。 您可以通过向联邦 apiserver 发送请求来创建一个 Deployment。 - -您可以通过使用 [kubectl](/docs/user-guide/kubectl/) 运行下面的指令： - -``` shell -kubectl --context=federation-cluster create -f mydeployment.yaml -``` - -`--context=federation-cluster` 参数告诉 kubectl 发送请求到联邦 apiserver 而不是某个 Kubernetes 集群。 - -一旦联邦 Deployment 被创建，联邦控制平面会在所有底层 Kubernetes 集群中创建一个 Deployment。 您可以通过检查底层每个集群来对其进行验证，例如： - -``` shell -kubectl --context=gce-asia-east1a get deployment mydep -``` - -上面的命令假定您在客户端中配置了一个叫做 ‘gce-asia-east1a’ 的上下文， - -底层集群中的这些 Deployment 会匹配联邦 Deployment 中副本数和修订版本相关注解_之外_的信息。 联邦控制平面确保所有集群中的副本总数与联邦 Deployment 中请求的副本数量匹配。 - - -### 在底层集群中分布副本 - -默认情况下，副本会被平均分布到所有的底层集群中。例如：如果您有 3 个注册的集群并且创建了一个副本数为 9(`spec.replicas = 9`) 的联邦 Deployment，那么这 3 个集群中的每个 Deployment 都将有 3 个副本 (`spec.replicas=3`)。 -为修改每个集群中的副本数，您可以在联邦 Deployment 中以注解的形式指定 [FederatedReplicaSetPreference](https://github.com/kubernetes/federation/blob/{{< param "githubbranch" >}}/apis/federation/types.go)，其中注解的键为 `federation.kubernetes.io/deployment-preferences`。 - - - -## 更新联邦 Deployment - -您可以像更新 Kubernetes Deployment 一样更新联邦 Deployment。但是，对于联邦 Deployment，您必须发送请求到联邦 apiserver 而不是某个特定的 Kubernetes 集群。联邦控制平面会确保每当联邦 Deployment 更新时，它会更新所有底层集群中相应的 Deployment 来和更新后的内容保持一致。 所以如果（在联邦 Deployment 中）选择了滚动更新，那么底层集群会独立地进行滚动更新，并且联邦 Deployment 中的 `maxSurge` 和 `maxUnavailable` 只会应用于独立的集群中。将来这种行为可能会改变。 - -如果您的更新包括副本数量的变化，联邦控制平面会改变底层集群中的副本数量，以确保它们的总数等于联邦 Deployment 中请求的数量。 - - -## 删除联邦 Deployment - -您可以像删除 Kubernetes Deployment 一样删除联邦 Deployment。但是，对于联邦 Deployment，您必须发送请求到联邦 apiserver 而不是某个特定的 Kubernetes 集群。 - -例如，您可以使用 kubectl 运行下面的命令来删除联邦 Deployment： - -```shell -kubectl --context=federation-cluster delete deployment mydep -``` - - - - diff --git a/content/zh/docs/tasks/federation/administer-federation/events.md b/content/zh/docs/tasks/federation/administer-federation/events.md deleted file mode 100644 index 56f0a644f6..0000000000 --- a/content/zh/docs/tasks/federation/administer-federation/events.md +++ /dev/null @@ -1,87 +0,0 @@ ---- -title: 联邦事件 -content_type: concept ---- - - - - - -{{< deprecationfilewarning >}} -{{< include "federation-deprecation-warning-note.md" >}} -{{< /deprecationfilewarning >}} - - -本指南介绍如何在联邦控制平面中使用事件来帮助调试。 - - - - - - - - -## 先决条件 - - - -本指南假定您正在运行 Kubernetes 集群联邦安装。 -如果没有，请转到[联邦管理员指南](/docs/concepts/cluster-administration/federation/)，了解如何启动集群联邦（或让集群管理员为您执行此操作）。 -其他教程，例如[这个](https://github.com/kelseyhightower/kubernetes-cluster-federation)由 Kelsey Hightower，也可为您提供帮助。 - - -你还应该具备 [kubernetes 基本工作知识](/docs/tutorials/kubernetes-basics/)。 - - - -## 查看联邦事件 - - -联邦控制平面中的事件（本指南中称为“联邦事件”）与提供相同功能的传统 Kubernetes 事件非常相似。 -联邦事件仅存储在联邦控制平面中，不会传递给基础 Kubernetes 集群。 - - -联邦控制器在处理 API 资源时创建事件，以便向用户显示它们所处的状态。您可以通过运行以下命令从联邦 apiserver 获取所有事件： - -```shell -kubectl --context=federation-cluster get events -``` - - -标准的 kubectl get，update，delete 命令都可以正常工作。 - - diff --git a/content/zh/docs/tasks/federation/administer-federation/job.md b/content/zh/docs/tasks/federation/administer-federation/job.md deleted file mode 100644 index 27983d7924..0000000000 --- a/content/zh/docs/tasks/federation/administer-federation/job.md +++ /dev/null @@ -1,191 +0,0 @@ ---- -title: 联邦 Job -content_type: task ---- - - - - - -{{< deprecationfilewarning >}} -{{< include "federation-deprecation-warning-note.md" >}} -{{< /deprecationfilewarning >}} - - -本指南解释了如何在联邦控制平面中使用 job。 - -联邦控制平面中的一次性任务（在本指南中称为“联邦一次性任务”）类似于传统的 [Kubernetes 一次性任务](/docs/concepts/workloads/controllers/job/)，并且提供相同的功能。 -在联邦控制平面中创建 job 可以确保在已注册的集群中存在所需的并行性和完成数。 - - - -## {{% heading "prerequisites" %}} - - -* {{< include "federated-task-tutorial-prereqs.md" >}} -* 你需要具备基本的 [Kubernetes 的工作知识](/docs/tutorials/kubernetes-basics/)，特别是 [job](/docs/concepts/workloads/controllers/jobs-run-to-completion/)。 - - - - - - - - - -## 创建一个联邦 job - - - -用于联邦 job 的 API 与用于传统 Kubernetes job 的 API 完全兼容。您可以通过向联邦 apiserver 发送请求来创建 job。 - -你可以使用 [kubectl](/docs/user-guide/kubectl/) 来运行： - -``` shell -kubectl --context=federation-cluster create -f myjob.yaml -``` - - -`--context=federation-cluster` 参数告诉 kubectl 将请求提交到联邦 API 服务器，而不是发送到 Kubernetes 集群。 - - -一旦创建了联邦 job，联邦控制平面将在所有底层 Kubernetes 集群中创建一个 job。 -你可以通过检查每个集群底层来验证这一点，例如： - -``` shell -kubectl --context=gce-asia-east1a get job myjob -``` - - -前面的示例假设你的客户端中为该区域中的集群配置了一个名为 `gce-asia-east1a` 的上下文。 - - -集群底层中的 job 与联邦 job 匹配，但并行性和完成数不匹配。 -联邦控制平面确保每个集群中的并行性和完成数之和与联合作业中所需的并行度和完成数匹配。 - - - -### 将 job 任务分散到集群底层中 - - -默认情况下，并行性和完成数在所有底层集群中平均分布。例如： -如果你有 3 个已注册的集群，并且创建了一个联邦 job -`spec.parallelism = 9` 和 `spec.completions = 18`，那么 3 个集群中的每个 job 都有 `spec.parallelism = 3` 和 `spec.completions = 6`。 -要修改每个集群中的并行性和完成数，可以指定 [ReplicaAllocationPreferences](https://github.com/kubernetes/federation/blob/{{< param "githubbranch" >}}/apis/federation/types.go) -作为 `federation.kubernetes.io/job-preferences` 联邦 job 上的 key 的注释。 - - - -## 更新联邦 job - - -可以像更新 Kubernetes job 一样更新联邦 job；但是，对于联邦 job，必须将请求发送到联邦 API 服务器，不是发送到指定的 Kubernetes 集群。 -联邦控制平面确保无论何时更新联邦 job，它都会更新所有集群底层中的相应 job 以匹配它。 - - -如果您的更新包含并行性和完成数的更改，则联邦控制平面将更改集群底层中的并行性和完成数， -确保它们的总和仍然等于联邦 job 中所需的并行性和完成数。 - - - -## 删除联邦 job - - -可以删除联邦 job，就像删除 Kubernetes job 一样;但是，对于联邦 job，必须将请求发送到联邦 API 服务器，不是发送到指定的 Kubernetes 集群。 - - -例如，使用 kubectl： - -```shell -kubectl --context=federation-cluster delete job myjob -``` - -{{< note >}} - - -删除联邦作业不会从基础集群中删除相应的 job。 -您必须手动删除基础 job。 - -{{< /note >}} - - - - diff --git a/content/zh/docs/tasks/federation/administer-federation/namespaces.md b/content/zh/docs/tasks/federation/administer-federation/namespaces.md deleted file mode 100644 index f5032b52f3..0000000000 --- a/content/zh/docs/tasks/federation/administer-federation/namespaces.md +++ /dev/null @@ -1,158 +0,0 @@ ---- -title: 联邦命名空间 -content_type: task ---- - - - - - -{{< deprecationfilewarning >}} -{{< include "federation-deprecation-warning-note.md" >}} -{{< /deprecationfilewarning >}} - - -本指南介绍如何在联邦控制平面中使用命名空间。 - - -联邦控制平面中的命名空间（本指南中称为“联邦命名空间”）与提供相同功能的传统 Kubernetes 命名空间非常相似。 -在联邦控制平面中创建它们可确保它们在联邦中的所有集群之间同步 - - - -## {{% heading "prerequisites" %}} - - -* {{< include "federated-task-tutorial-prereqs.md" >}} -* 您还需要具备基本的 [Kubernetes 工作知识](/docs/tutorials/Kubernetes-basics/)， -特别是[命名空间](/docs/concepts/overview/working-objects/Namespaces/)。 - - - - - - - - - -## 创建联邦命名空间 - - -联邦命名空间的 API 与传统 Kubernetes 命名空间的 API 100％ 兼容。您可以通过向联邦身份验证程序发送请求来创建命名空间。 - - -您可以通过运行以下命令使用 kubectl 执行此操作： - -``` shell -kubectl --context=federation-cluster create -f myns.yaml -``` - - -`--context=federation-cluster` 参数通知 kubectl 将请求提交给联邦 apiserver，而不是将其发送到 Kubernetes 集群。 - - -创建联邦命名空间后，联邦控制平面将在所有基础 Kubernetes 集群中创建匹配的命名空间。您可以通过检查每个基础集群来验证这一点，例如： - -``` shell -kubectl --context=gce-asia-east1a get namespaces myns -``` - - -以上假设您在客户端中为该区域中的集群配置了名为 “gce-asia-east1a” 的上下文。 -基础命名空间的名称和规范将与您在上面创建的联邦命名空间的名称和规范相匹配。 - - - -## 更新联邦命名空间 - - -您可以像更新 Kubernetes 命名空间一样更新联邦命名空间，只需将请求发送到联邦身份验证程序，而不是将其发送到指定的 Kubernetes 集群。 -联邦控制平面将确保每当更新联邦命名空间时，它都会更新所有基础集群中的相应命名空间以与其匹配。 - - - -## 删除联邦命名空间 - - -你可以删除联邦命名空间，就像删除 Kubernetes 命名空间一样，只需将请求发送到联邦身份验证器，而不是发送到指定的 Kubernetes 群集。 - - -例如，您可以通过运行以下命令使用 kubectl 执行此操作： - -```shell -kubectl --context=federation-cluster delete ns myns -``` - - -与在 Kubernetes 中一样，删除联邦命名空间将从联邦控制平面中删除该命名空间中的所有资源。 - -{{< note >}} - - -此时，删除联邦命名空间，不会从底层集群中删除相应的命名空间或这些命名空间中的资源。用户必须手动删除它们。我们打算将来解决这个问题。 - -{{< /note >}} - - - - diff --git a/content/zh/docs/tasks/federation/administer-federation/replicaset.md b/content/zh/docs/tasks/federation/administer-federation/replicaset.md deleted file mode 100644 index af7ae0efe9..0000000000 --- a/content/zh/docs/tasks/federation/administer-federation/replicaset.md +++ /dev/null @@ -1,220 +0,0 @@ ---- -title: 联邦 ReplicaSet -content_type: task ---- - - - - -{{< deprecationfilewarning >}} -{{< include "federation-deprecation-warning-note.md" >}} -{{< /deprecationfilewarning >}} - - -本指南阐述了如何在联邦控制平面中使用 ReplicaSet。 -在联邦控制平面中的 ReplicaSet (在本指南中称为”联邦 ReplicaSet”) 和传统的 [Kubernetes -ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) 很相似，提供了一样的功能。在联邦控制平面中创建联邦 ReplicaSet 可以确保在联邦的所有集群中都有预期数量的副本。 - - -## {{% heading "prerequisites" %}} - - -* {{< include "federated-task-tutorial-prereqs.md" >}} - -* 你还应该具备基本的 [Kubernetes 应用知识](/docs/tutorials/kubernetes-basics/)，特别是 [ReplicaSets](/docs/concepts/workloads/controllers/replicaset/) 相关的应用知识。 - - - - - - -## 创建联邦 ReplicaSet - -联邦 ReplicaSet 的 API 和传统的 Kubernetes ReplicaSet API 是 100% 兼容的。您可以通过请求联邦 apiserver 来创建联邦 ReplicaSet。 - -您可以通过使用 [kubectl](/docs/user-guide/kubectl/) 运行下面的指令来创建联邦 ReplicaSet： - -``` shell -kubectl --context=federation-cluster create -f myrs.yaml -``` - -`--context=federation-cluster` 参数告诉 kubectl 发送请求到联邦 apiserver 而不是某个 Kubernetes 集群。 - -一旦联邦 ReplicaSet 被创建了，联邦控制平面就会在所有底层 Kubernetes 集群中创建一个 ReplicaSet。您可以通过检查底层每个集群来对其进行验证，例如： - -``` shell -kubectl --context=gce-asia-east1a get rs myrs -``` - -上面的命令假定您在客户端中配置了一个叫做 ‘gce-asia-east1a’ 的上下文。 - -底层集群中的 ReplicaSet 的副本数将会和联邦 ReplicaSet 的副本数保持一致。联邦控制平面将确保联邦的所有集群都和联邦 ReplicaSet 有同样的副本数。 - - -### 底层集群中副本的分布 - -默认情况下，副本在所有底层集群中是均匀分布的。例如：如果您有 3 个注册的集群并且用 `spec.replicas = 9` 参数创建了一个联邦 ReplicaSet，然后在这 3 个集群中每个 ReplicaSet 的副本数会是 `spec.replicas=3`。 -如果要修改每个集群中的副本数，您可以在联邦 ReplicaSet 中使用 `federation.kubernetes.io/replica-set-preferences` 作为注解键值来修改联合副本集。 -注解的键值是序列化的 JSON，其中包含以下示例中显示的字段： - -``` -{ - "rebalance": true, - "clusters": { - "foo": { - "minReplicas": 10, - "maxReplicas": 50, - "weight": 100 - }, - "bar": { - "minReplicas": 10, - "maxReplicas": 100, - "weight": 200 - } - } -} -``` -`rebalance` 布尔字段指定是否可以移动已调度和正在运行的副本，以便将当前状态与指定的首选项相匹配。 -`clusters` 对象字段包含一个映射，用户可以在其中指定跨集群的副本放置的约束（示例中为 `foo` 和 `bar`）。 -对于每个集群，您可以指定应分配给它的最小副本数（默认值为零），集群可以接受的最大副本数（默认为无限制）以及表示要添加该群集的副本的首选项的相对权重的数字。 - - -## 更新联邦 ReplicaSet - -您可以像更新 Kubernetes ReplicaSet 一样更新联邦 ReplicaSet。但是对于联邦 ReplicaSet，您必须发送请求到联邦 apiserver 而不是某个特定的 Kubernetes 集群。联邦控制平面会确保任何时候联邦 ReplicaSet 更新后，它会将对应的 ReplicaSet 更新到所有的底层集群中来和它保持一致。 - -如果您做了包含副本数量的更改，联邦控制平面将会更改底层集群中的副本数以确保它们的总数和联邦 ReplicaSet 期望的副本数保持一致。 - - -## 删除联邦 ReplicaSet - -您可以像删除 Kubernetes ReplicaSet 一样删除联邦 ReplicaSet。但是对于联邦 ReplicaSet ，您必须发送请求到联邦 apiserver 而不是某个特定的 Kubernetes 集群。 - -例如，您可以使用 kubectl 运行下面的命令来删除联邦 ReplicaSet： - -```shell -kubectl --context=federation-cluster delete rs myrs -``` - -{{< note >}} - -要注意的是这时删除联邦 ReplicaSet 并不会删除底层集群中对应的 ReplicaSet。您必须自己手动删除底层集群中的 ReplicaSet。我们打算在将来修复这个问题。 -{{< /note >}} - - - - diff --git a/content/zh/docs/tasks/federation/administer-federation/secret.md b/content/zh/docs/tasks/federation/administer-federation/secret.md deleted file mode 100644 index 5b185ddb29..0000000000 --- a/content/zh/docs/tasks/federation/administer-federation/secret.md +++ /dev/null @@ -1,164 +0,0 @@ ---- -title: 联邦 Secret -content_type: concept ---- - - - - - -{{< deprecationfilewarning >}} -{{< include "federation-deprecation-warning-note.md" >}} -{{< /deprecationfilewarning >}} - - -本指南解释了如何在联邦控制平面中使用 secret。 - -联邦控制平面中的 Secret（在本指南中称为“联邦 secret”）与提供相同功能的传统 [Kubernetes Secret](/docs/concepts/configuration/secret/) 非常相似。 -在联邦控制平面中创建它们可以确保它们跨联邦中的所有集群同步。 - - - - - - - - -## 先决条件 - - -本指南假设你有一个正在运行的 Kubernetes 集群联邦安装。 -如果没有，请访问[联邦管理指南](/docs/admin/federation/)，了解如何启动联邦集群（或者让集群管理员为你做这件事）。 -其他教程，例如[这里](https://github.com/kelseyhightower/kubernetes-cluster-federation) Kelsey Hightower，也可以帮助您。 - - -你还应该具有一个基本的 [Kubernetes 工作知识](/docs/tutorials/kubernetes-basics/)， -特别是 [Secret](/docs/concepts/configuration/secret/)。 - - - -## 创建联邦 Secret - - -用于联邦 Secret 的 API 与用于传统的 Kubernetes Secret 的 API 100% 兼容。 -您可以通过向联邦 apiserver 发送请求来创建一个 Secret。 - - -你可以使用 [kubectl](/docs/user-guide/kubectl/) 来运行： - -``` shell -kubectl --context=federation-cluster create -f mysecret.yaml -``` - - -`--context=federation-cluster` 参数通知 kubectl 将请求提交给联邦 apiserver，而不是将其发送到 Kubernetes 集群。 - - -创建联邦命名空间后，联邦控制平面将在所有基础 Kubernetes 集群中创建匹配的命名空间。您可以通过检查每个基础集群来验证这一点，例如： - -``` shell -kubectl --context=gce-asia-east1a get secret mysecret -``` - - -以上假设您在客户端中为该区域中的集群配置了名为 “gce-asia-east1a” 的上下文。 -集群底层中的这些 secret 将与联邦 secret 匹配。 - - - -## 更新联邦 Secret - - -您可以像更新 Kubernetes secret 一样更新联邦 secret，但是，对于联邦 secret 必须将请求发送到联邦 apiserver， -而不是将其发送到指定的 Kubernetes 集群。联邦控制平面将确保每当更新联邦 secret 时，它都会更新所有基础集群中的相应 secret 以与其匹配。 - - - -## 删除联邦 Secret - - -你可以删除一个联邦 secret，就像删除一个 Kubernetes secret 一样；但是， -对于联邦 secret，必须将请求发送到联邦 apiserver，而不是发送到指定的 Kubernetes 集群。 - - -例如，您可以通过运行以下命令使用 kubectl 执行此操作： - -```shell -kubectl --context=federation-cluster delete secret mysecret -``` - -{{< note >}} - - -此时，删除联邦 secret 不会从集群底层中删除相应的 secret。你必须手动删除底层 secret。我们打算将来解决这个问题。 - -{{< /note >}} - - diff --git a/content/zh/docs/tasks/federation/federation-service-discovery.md b/content/zh/docs/tasks/federation/federation-service-discovery.md deleted file mode 100644 index b3237e0122..0000000000 --- a/content/zh/docs/tasks/federation/federation-service-discovery.md +++ /dev/null @@ -1,509 +0,0 @@ ---- -title: 使用联合服务来实现跨集群的服务发现 -content_type: task -weight: 140 ---- - - - - -{{< deprecationfilewarning >}} -{{< include "federation-deprecation-warning-note.md" >}} -{{< /deprecationfilewarning >}} - - -本指南说明了如何使用 Kubernetes 联合服务跨多个 Kubernetes 集群部署通用服务。这样可以轻松实现 Kubernetes 应用程序的跨集群服务发现和可用区容错。 - - - -联合服务的创建与传统服务几乎相同 [Kubernetes Services](/docs/concepts/services-networking/service/) 即通过 API 调用来指定所需的服务属性。对于联合服务，此 API 调用定向到联合身份验证 API 接入点，而不是 Kubernetes 集群 API 接入点。联合服务的 API 与传统 Kubernetes 服务的 API 是 100% 兼容的。 - - -创建后，联合服务会自动: - - -1. 在基础集群联合的每个集群中创建匹配的 Kubernetes 服务, -2. 监视那些服务 "分片"(及其驻留的集群)的运行状况,以及 -3. 在公共 DNS 提供商(例如 Google Cloud DNS 或 AWS Route 53)中管理一组 DNS 记录,即使在集群可用区域中断的情况下，也能确保您联合服务的客户端始终可以无缝地定位合适的健康服务接入点。 - - -如果存在健康的分片，联合 Kubernetes 集群(即 Pods )中的客户端将自动在其中找到联合服务的本地分片集群或者集群中最接近的健康分片;如果不存在，则使用最接近的其他集群的健康分片。 - - - -{{< toc >}} - -## {{% heading "prerequisites" %}} - - -{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} - - - - - - -## 前提 - - -本指南假设您已经安装 Kubernetes 联合集群。如果没有，则访问 [联合集群管理指南](/docs/admin/federation/)了解如何建立联合集群(或让您的集群管理员为您执行此操作)。其他教程，例如 Kelsey Hightower 编写的 [案例](https://github.com/kelseyhightower/kubernetes-cluster-federation)或许有用。 - - -一般而言，您应该还有基本的 [Kubernetes 工作常识](/docs/tutorials/kubernetes-basics/)，特别是 [Services](/docs/concepts/services-networking/service/)。 - - -## 混合云功能 - - -Kubernetes 联合集群需要可以在不同的云提供商(例如 Google Cloud 或 AWS)和本地(例如 OpenStack)环境中运行。只需在合适的云提供商创建所需的所有集群，向您的联合身份验证 API 服务器注册每个集群的 API 接入点和凭据(有关详细信息，请参见 [联合管理指南](/docs/admin/federation/))。 - - -此后，您的应用程序和服务可以跨越不同的集群和云提供商，如下所述。 - - -## 创建联合服务 - - -常见方式创建，例如: - -``` shell -kubectl --context=federation-cluster create -f services/nginx.yaml -``` - - -'--context=federation-cluster' 标志通知 kubectl 使用合适的凭据将请求提交到联合 API 接入点。如果您尚未配置此类上下文，请访问 [联合管理指南](/docs/admin/federation/)或者 [管理教程](https://github.com/kelseyhightower/kubernetes-cluster-federation)找出解决方案。 - - -如上所述，联合服务将自动创建并在所有集群中维护匹配的 Kubernetes 服务以支持联合。 - - -您可以通过核对每个基础集群的信息来验证这一点, 例如: - -``` shell -kubectl --context=gce-asia-east1a get services nginx -NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE -nginx ClusterIP 10.63.250.98 104.199.136.89 80/TCP 9m -``` - - -以上假设您有一个名为 'gce-asia-east1a' 上下文在客户端中为该区域中的集群配置。基础服务的名称和命名空间将自动与您在上面创建的联合服务匹配(如果服务的名称和命名空间与集群中任意一个服务器的名称和命名空间相同，它们将被联合并更新为符合您的规范联合服务 - 无论哪种方式，最终结果都是相同的)。 - - -联合服务的状态将自动反映基础 Kubernetes 服务的实时状态，例如: - -``` shell -kubectl --context=federation-cluster describe services nginx -``` -``` -Name: nginx -Namespace: default -Labels: run=nginx -Annotations: -Selector: run=nginx -Type: LoadBalancer -IP: 10.63.250.98 -LoadBalancer Ingress: 104.197.246.190, 130.211.57.243, 104.196.14.231, 104.199.136.89, ... -Port: http 80/TCP -Endpoints: -Session Affinity: None -Events: -``` - - -{{< note >}} -联合服务的 'LoadBalancer Ingress' 地址与所有基础 Kubernetes 服务的 'LoadBalancer Ingress' 地址相对应(一旦分配了这些地址，这可能需要几秒钟)。为了使服务分片之间的集群和云提供商之间的网络正常工作，您的服务需要具有一个外部可见的 IP 地址。[Service Type:Loadbalancer](/docs/concepts/services-networking/service/#loadbalancer)。尽管存在其他选项(例如 [外部 IP](/docs/concepts/services-networking/service/#external-ips)),但通常会使用 [Service 类型:Loadbalancer](/docs/concepts/services-networking/service/#loadbalancer)。 -{{< /note >}} - - -还要注意，我们尚未设置任何后端 Pod 来接收定向到这些地址的网络流量(即 'Service Endpoints')，因此联合服务尚未将它们视为健康的服务分片，并且尚未将其地址添加到联合服务的 DNS 记录中(稍后在此方面进行介绍)。 - - -## 添加后端 pods - - -为了使基础服务分片健康，我们需要在它们后面添加后端 Pod。当前，这是直接针对基础集群 API 接入点完成的(尽管将来，联合服务将能够通过单个命令为您完成所有这些操作，从而省去了麻烦)。例如，在13个基础集群中创建后端 Pod: - -``` shell -for CLUSTER in asia-east1-c asia-east1-a asia-east1-b \ - europe-west1-d europe-west1-c europe-west1-b \ - us-central1-f us-central1-a us-central1-b us-central1-c \ - us-east1-d us-east1-c us-east1-b -do - kubectl --context=$CLUSTER run nginx --image=nginx:1.11.1-alpine --port=80 -done -``` - - -注意，`kubectl run` 会自动添加 `run=nginx` 标签，这是将后端 pod 与其服务关联起来所必需的。 - - -## 验证公共 DNS 记录 - - -一旦上述 Pod 成功启动并开始侦听连接，Kubernetes 就会将它们报告为该集群中服务的正常接入点(通过自动运行状况检查)。反过来，联合集群会将这些服务 '分片' 中的每一个视为健康，并通过自动配置相应的公共 DNS 记录将其置于服务中。您可以使用首选接口访问已配置的 DNS 提供程序来进行验证。例如，如果您的联邦配置为使用 Google Cloud DNS 和托管 DNS 域名 'example.com'。 - -``` shell -gcloud dns managed-zones describe example-dot-com -``` -``` -creationTime: '2016-06-26T18:18:39.229Z' -description: Example domain for Kubernetes Cluster Federation -dnsName: example.com. -id: '3229332181334243121' -kind: dns#managedZone -name: example-dot-com -nameServers: -- ns-cloud-a1.googledomains.com. -- ns-cloud-a2.googledomains.com. -- ns-cloud-a3.googledomains.com. -- ns-cloud-a4.googledomains.com. -``` - -```shell -gcloud dns record-sets list --zone example-dot-com -``` -``` -NAME TYPE TTL DATA -example.com. NS 21600 ns-cloud-e1.googledomains.com., ns-cloud-e2.googledomains.com. -example.com. OA 21600 ns-cloud-e1.googledomains.com. cloud-dns-hostmaster.google.com. 1 21600 3600 1209600 300 -nginx.mynamespace.myfederation.svc.example.com. A 180 104.197.246.190, 130.211.57.243, 104.196.14.231, 104.199.136.89,... -nginx.mynamespace.myfederation.svc.us-central1-a.example.com. A 180 104.197.247.191 -nginx.mynamespace.myfederation.svc.us-central1-b.example.com. A 180 104.197.244.180 -nginx.mynamespace.myfederation.svc.us-central1-c.example.com. A 180 104.197.245.170 -nginx.mynamespace.myfederation.svc.us-central1-f.example.com. CNAME 180 nginx.mynamespace.myfederation.svc.us-central1.example.com. -nginx.mynamespace.myfederation.svc.us-central1.example.com. A 180 104.197.247.191, 104.197.244.180, 104.197.245.170 -nginx.mynamespace.myfederation.svc.asia-east1-a.example.com. A 180 130.211.57.243 -nginx.mynamespace.myfederation.svc.asia-east1-b.example.com. CNAME 180 nginx.mynamespace.myfederation.svc.asia-east1.example.com. -nginx.mynamespace.myfederation.svc.asia-east1-c.example.com. A 180 130.211.56.221 -nginx.mynamespace.myfederation.svc.asia-east1.example.com. A 180 130.211.57.243, 130.211.56.221 -nginx.mynamespace.myfederation.svc.europe-west1.example.com. CNAME 180 nginx.mynamespace.myfederation.svc.example.com. -nginx.mynamespace.myfederation.svc.europe-west1-d.example.com. CNAME 180 nginx.mynamespace.myfederation.svc.europe-west1.example.com. -... etc. -``` - - -{{< note >}} -如果您的联邦配置为使用 AWS Route53，则可以使用类似的 AWS 工具，例如: - -``` shell -aws route53 list-hosted-zones -``` -和 - -``` shell -aws route53 list-resource-record-sets --hosted-zone-id Z3ECL0L9QLOVBX -``` -{{< /note >}} - - -无论使用哪种 DNS 提供商，任何 DNS 查询工具(例如 'dig' 或者 'nslookup')都将允许您查看联邦会为您创建的记录。请注意，您应该将这些工具直接指向您的 DNS 提供商(例如 `dig @ ns-cloud-e1.googledomains.com ...`),或者由于中间 DNS 服务器进行了缓存，因此在看到更新之前，预计延迟会按照配置的 TTL 顺序(默认为 180 秒)进行。 - - -### 有关上述示例的一些注意事项 - - -1. 请注意，每个具有至少一个正常后端端点的服务分片都有一条正常('A')记录。例如，在 us-central1-a 中，104.197.247.191 是该区域中服务分片的外部 IP 地址，在 asia-east1-a 中，该地址是 130.211.56.221。 -2. 同样，也有区域 'A' 记录，其中包括该区域中所有健康的分片。例如，'us-central1'。这些区域记录对于没有特定区域首选项的客户很有用，并且作为下文所述的自动位置和故障转移机制的基础。 -3. 对于当前没有健康后端终结点的区域，将使用 CNAME ('Canonical Name') 记录将这些查询别名(自动重定向)到下一个最接近的健康区域。在此示例中，us-central1-f 中的服务分片当前没有健康的后端端点(即Pods)，因此已创建 CNAME 记录来自动将查询重定向到该区域中的其他分片(在本例中为 us-central1)。 -4. 类似地，如果封闭区域中不存在健康分片，则搜索将进一步进行。在 europe-west1-d 可用性区域中,没有健康的后端,因此查询将重定向到更广阔的 Europe-west1 区域(也没有健康的后端),然后再重定向到全局的健康地址集('nginx.mynamespace.myfederation.svc.example.com.')。 - - -上面的 DNS 记录集由联邦服务系统自动与全球所有服务分片的当前健康状况保持同步。DNS 解析库(由所有客户端调用)自动遍历 'CNAME' 与 'A' 记录的层次结构，以返回正确健康的 IP 地址集。然后，客户端可以选择任何返回的地址来启动网络连接(并根据需要自动故障转移到其他等效地址之一)。 - - -## 发现联合服务 - - -### 从联合集群内的 Pods 来发现 - - -默认情况下，Kubernetes 集群预先配置了本地集群 DNS 服务器('KubeDNS')以及智能构建的 DNS 搜索路径，这些路径共同确保由 Pods 内部运行软件发出的 DNS 查询如 "myservice", "myservice.mynamespace","bobsservice.othernamespace" 等，会自动扩展并正确解析为本地集群运行服务的相应服务 IP。 - - -随着联合服务和跨集群服务发现的引入，该概念已扩展到涵盖在全球集群联盟中任何其他集群中运行的 Kubernetes 服务。要利用此扩展范围，您可以使用形式稍有不同的 DNS 名称，形式为 ```".."``` 来解析联合服务。例如，您可以使用 `myservice.mynamespace.myfederation`。使用不同的 DNS 名称还可以避免现有应用程序意外穿越跨区域或跨区域网络，并且可能招致不必要的网络费用或延迟，而无需您明确选择采取这种行为。 - - -因此，使用上面的 NGINX 示例服务和刚才描述的联合服务 DNS 名称表单，让我们考虑一个示例:`us-central1-f` 可用性区域集群中的 Pod 需要联系我们的 NGINX 服务。现在，可以使用服务的联合 DNS 名称，而不是使用服务的传统集群本地 DNS 名称(`"nginx.mynamespace"` 会自动扩展为 `"nginx.mynamespace.svc.cluster.local"`)。无论位于世界何处，它都会自动扩展并解析为我的 NGINX 服务中最接近的健康分片。如果本地集群中存在健康的分片，则将返回该服务的集群本地(通常为10.x.y.z)的 IP 地址(由集群本地的 KubeDNS)。这几乎完全等同于非联合服务解析(几乎是因为 KubeDNS 实际上为本地联合服务返回了 CNAME 和 A 记录，但是应用程序将忽略这种微小的技术差异)。 - - -但是，如果服务在本地集群中不存在(或者存在但没有正常的后端 Pod),则 DNS 查询会自动扩展为 ```"nginx.mynamespace.myfederation.svc.us-central1-f.example.com"```(也就是说，从逻辑上 "找到最接近我可用区的一个分片的外部 IP")。此扩展由 KubeDNS 自动执行，它返回关联的 CNAME 记录。这将导致在上面的示例中自动遍历 DNS 记录的层次结构，并最终到达本地 us-central1 区域中联合服务的外部 IP 之一(即 104.197.247.191, 104.197.244.180 或 104.197.245.170 )。 - - -当然，可以通过明确地指定合适的 DNS 名称而不依赖于自动 DNS 扩展，在 Pod 本地的可用区域和可用区域之外的区域中明确地定位服务分片。例如，即使发出查询的 Pod 位于美国，"nginx.mynamespace.myfederation.svc.europe-west1.example.com" 也将解析欧洲目前所有健康的服务分片,并且无论美国是否有健康的服务分片。这对于远程监视和其他类似应用程序很有用。 - - -### 来自联合集群之外的其他客户端 - - -上面大部分讨论都同样适用于外部客户端，除了不再描述所描述的自动 DNS 扩展。因此，外部客户端需要指定联合服务的标准 DNS 名称，可以是地带名称，区域名称或者全局名称。为了方便起见，通常最好在服务中手动配置其他静态 CNAME 记录，例如: - -``` shell -eu.nginx.acme.com CNAME nginx.mynamespace.myfederation.svc.europe-west1.example.com. -us.nginx.acme.com CNAME nginx.mynamespace.myfederation.svc.us-central1.example.com. -nginx.acme.com CNAME nginx.mynamespace.myfederation.svc.example.com. -``` - -这样，您的客户就可以始终使用左侧的缩写形式，并始终被自动路由到其本国大陆上最接近的健康分片。Kubernetes 联邦集群自动为您处理所有必需的故障转移。将来的发行版将对此进行进一步改进。 - - -## 处理后端 Pod 和整个集群的故障 - - -标准的 Kubernetes 服务集群 IP 已确保无响应的单个 Pod 端点以低延迟(几秒钟)自动退出服务。此外，如上所述，Kubernetes 联邦集群系统会自动监视集群的状态以及联合服务的所有分片后面的端点，并根据需要使分片进入和退出服务(例如，当服务后面的所有端点或者整个集群或可用性区域出现故障时，或者相反地从中断中恢复时)。由于 DNS 缓存固有的延迟(默认情况下,缓存超时或联合服务 DNS 记录的 TTL 配置为3分钟，可以调整),在灾难性故障的情况下，所有客户端可能要花费很长时间才能完全故障转移到备用集群。但是，鉴于每个区域服务端点可以返回的离散 IP 地址数量(例如上面的 us-central1，它有三个替代方案),与给定的合适配置相比，许多客户端将在更少的时间内自动故障转移到其他 IP。 - - - - - - -## 故障排除 - - -### 我无法连接到联合集群 API - -检查您的 - - -1. 客户端(通常是 kubectl)已正确配置(包括 API 端点和登录凭据)。 -2. 联合集群 API 服务器正在运行并且可以访问网络。 - - -请参阅 [联合集群管理员指南](/docs/admin/federation/)了解如何正确启动联邦集群(或让您的集群管理员为您执行此操作),以及如何正确配置客户端。 - - -### 我可以针对联合集群 API 成功创建联合服务,但是在我的基础集群中没有创建匹配的服务。 - -检查: - - -1. 您的集群已在联合集群 API 中正确注册(`kubectl describe clusters`)。 -2. 您的集群都是 "活跃的"。这意味着集群联合身份验证系统能够针对集群的端点进行连接和身份验证。如果不是，请查阅federation-controller-manager pod 的日志，以确定可能是什么故障。 - ``` - kubectl --namespace=federation logs $(kubectl get pods --namespace=federation -l module=federation-controller-manager -o name) - ``` -3. 集群提供给联合集群 API 的登录凭据具有正确的授权和配额，可以在集群的相关命名空间中创建服务。如果不是这种情况，您将再次在上述日志文件中看到相关的错误消息，以提供更多详细信息。 -4. 是否有其他错误阻止服务创建操作成功(请在 `kubectl logs federation-controller-manager --namespace federation` 的输出中查找 `service-controller` 错误)。 - - -### 我可以成功创建联合服务，但是在我的 DNS 提供程序中没有创建匹配的 DNS 记录。 -检查: - - -1. 您的联邦集群名称，DNS 提供程序，DNS 域名已正确配置。请参阅 [联邦集群管理指南](/docs/admin/federation/)或者 [教程](https://github.com/kelseyhightower/kubernetes-cluster-federation)了解如何配置联合集群系统的 DNS 提供程序(或让您的集群管理员为您执行此操作)。 -2. 确认联合集群的服务控制器已成功连接到所选的 DNS 提供程序并对其进行身份验证(在 `kubectl logs federation-controller-manager --namespace federation` 的输出中查找 `service-controller` 错误或者成功)。 -3. 确认联合集群的服务控制器已在您的 DNS 提供程序中成功创建了 DNS 记录(或在其日志中输出错误，以更详细地解释失败原因)。 - - -### 在我的 DNS 提供程序中创建了匹配的 DNS 记录，但是客户端无法根据这些名称进行解析 -检查: - - -1. 已正确配置用于管理联合 DNS 域名的 DNS 注册器，使其指向已配置的 DNS 提供程序的名称服务器。例如，请参见 [Google Domains 文档](https://support.google.com/domains/answer/3290309?hl=en&ref_topic=3251230)与 [Google Cloud DNS 文档](https://cloud.google.com/dns/update-name-servers),或者域名注册商和 DNS 提供商的等效指南。 - - -### 此疑难解答指南没有帮助我解决问题 - - -1. 请使用我们的 [支持渠道](/docs/tasks/debug-application-cluster/troubleshooting/)寻求帮助。 - - -## 更多信息 - - - * [联合提议](https://git.k8s.io/community/contributors/design-proposals/multicluster/federation.md) 详细介绍了促进这项工作的用例。 - diff --git a/content/zh/docs/tasks/federation/set-up-coredns-provider-federation.md b/content/zh/docs/tasks/federation/set-up-coredns-provider-federation.md deleted file mode 100644 index 8193d928dc..0000000000 --- a/content/zh/docs/tasks/federation/set-up-coredns-provider-federation.md +++ /dev/null @@ -1,254 +0,0 @@ ---- -title: 将 CoreDNS 设置为联邦集群的 DNS 提供者 -content_type: tutorial -weight: 130 ---- - - - - - -{{< deprecationfilewarning >}} -{{< include "federation-deprecation-warning-note.md" >}} -{{< /deprecationfilewarning >}} - - -此页面显示如何配置和部署 CoreDNS，将其用作联邦集群的 DNS 提供者 - - - - -## {{% heading "objectives" %}} - - - - -* 配置和部署 CoreDNS 服务器 -* 使用 CoreDNS 作为 dns 提供者设置联邦 -* 在 nameserver 查找链中设置 CoreDNS 服务器 - - - - -## {{% heading "prerequisites" %}} - - - - -* 你需要有一个正在运行的 Kubernetes 集群（作为主机集群引用）。请参阅[入门指南](/docs/setup/)，了解平台的安装说明。 -* 必须在联邦的集群成员中支持 `LoadBalancer` 服务，用来支持跨联邦集群的 `CoreDNS` 服务发现。 - - - - - - - - -## 部署 CoreDNS 和 etcd 图表 - - -CoreDNS 可以部署在各种配置中。下面解释的是一个参考，可以根据平台和联邦集群的需要进行调整。 - - -为了部署 CoreDNS，我们将利用图表。 -CoreDNS 将部署 [etcd](https://coreos.com/etcd) 作为后端，并且应该预先安装。etcd 也可以使用图表进行部署。下面显示了部署 etcd 的说明。 - - helm install --namespace my-namespace --name etcd-operator stable/etcd-operator - helm upgrade --namespace my-namespace --set cluster.enabled=true etcd-operator stable/etcd-operator - - -*注意：etcd 默认部署配置可以被覆盖，适合主机集群。* - - -部署成功后，可以使用主机集群中的 [http://etcd-cluster.my-namespace:2379](http://etcd-cluster.my-namespace:2379) 端点访问 etcd。 - - -应该定制 CoreDNS 默认配置适应联邦。 -下面显示的是 Values.yaml，它覆盖了 CoreDNS 图表上的默认配置参数。 - -```yaml -isClusterService: false -serviceType: "LoadBalancer" -plugins: - kubernetes: - enabled: false - etcd: - enabled: true - zones: - - "example.com." - endpoint: "http://etcd-cluster.my-namespace:2379" -``` - - -以上配置文件需要说明： - - - - `isClusterService` 指定是否应该将 CoreDNS 部署为集群服务，这是默认值。 -你需要将其设置为 false，以便将 CoreDNS 部署为 Kubernetes 应用程序服务。 - - `serviceType` 指定为核心用户创建的 Kubernetes 服务的类型。 -你需要选择 `LoadBalancer` 或 `NodePort`，以便在 Kubernetes 集群之外访问 CoreDNS 服务。 - - 禁用 `plugins.kubernetes`，默认情况下通过设置 `plugins.kubernetes.enabled` 为 false。 - - 启用 `plugins.etcd`，通过设置 `plugins.etcd.enabled` 为 true。 - - 通过设置 `plugins.etcd.zones` 来配置 CoreDNS 具有权威性的 DNS 域（联邦域）。如上所示。 - - 通过设置 `plugins.etcd.endpoint` 来配置早期部署的 etcd 端点 - - -现在部署 CoreDNS 来运行 - - helm install --namespace my-namespace --name coredns -f Values.yaml stable/coredns - -验证 etcd 和 CoreDNS，pod 都按预期运行。 - - - -## 使用 CoreDNS 作为 DNS 提供者部署联邦 - - -可以使用 `kubefed init` 部署联邦控制平面。通过指定两个附加参数，可以选择 CoreDNS 作为 DNS 提供者。 - - --dns-provider=coredns - --dns-provider-config=coredns-provider.conf - - -coredns-provider.conf 的格式如下： - - [Global] - etcd-endpoints = http://etcd-cluster.my-namespace:2379 - zones = example.com. - coredns-endpoints = : - - - - - `etcd-endpoints` 是访问 etcd 的端点。 - - `zones` 是 CoreDNS 具有权威性的联邦域，它与 `kubefed init` 的 --dns-zone-name 参数相同。 - - `coredns-endpoints` 是访问 CoreDNS 服务器的端点。这是从 v1.7 开始引入的一个可选参数。 - -{{< note >}} - -CoreDNS 配置中的 `plugins.etcd.zones` 和 `kubefed init` 的 `--dns-zone-name` 参数应该匹配。 -{{< /note >}} - - - -## 在 nameserver resolv.conf 链中设置 CoreDNS 服务器 - -{{< note >}} - -下面的部分只适用于 v1.7 之前的版本，如果 `coredns-endpoint` 参数是 -在 `coredns-provider.conf` 中配置的，就会自动处理。 - -{{< /note >}} - - -一旦部署了联邦控制平面并将联邦集群连接到联邦， -你需要将 CoreDNS 服务器添加到所有联邦集群中 pod 的 nameserver resolv.conf 链，因为这个自托管的 CoreDNS 服务器是不可公开发现的。 -这可以通过在 `kube-dns` 部署中将下面的行添加到 `dnsmasq` 容器的参数中来实现。 - - - --server=/example.com./ - - -将上面的 `example.com` 替换为联邦域。 - - -现在联邦集群已经为跨集群服务发现做好了准备！ - - - - diff --git a/content/zh/docs/tasks/federation/set-up-placement-policies-federation.md b/content/zh/docs/tasks/federation/set-up-placement-policies-federation.md deleted file mode 100644 index 1dfc62e3fd..0000000000 --- a/content/zh/docs/tasks/federation/set-up-placement-policies-federation.md +++ /dev/null @@ -1,331 +0,0 @@ ---- -title: 在联邦中设置放置策略 -content_type: task ---- - - - - - -{{< deprecationfilewarning >}} -{{< include "federation-deprecation-warning-note.md" >}} -{{< /deprecationfilewarning >}} - - -此页面显示如何使用外部策略引擎对联邦资源强制执行基于策略的放置决策。 - - - -## {{% heading "prerequisites" %}} - - - -您需要一个正在运行的 Kubernetes 集群(它被引用为主机集群)。有关您的平台的安装说明，请参阅[入门](/docs/setup/)指南。 - - - - - - -## Deploying 联邦并配置外部策略引擎 - - -可以使用 `kubefed init` 部署联邦控制平面。 - - -Deploying 联邦控制平面之后，必须在联邦 API 服务器中配置一个准入控制器，该控制器强制执行从外部策略引擎接收到的放置决策。 - - - kubectl create -f scheduling-policy-admission.yaml - - -下图是准入控制器的 ConfigMap 示例： - -{{< codenew file="federation/scheduling-policy-admission.yaml" >}} - - -ConfigMap 包含三个文件： - - -* `config.yml` 指定 `调度策略` 准入控制器配置文件的位置。 -* `scheduling-policy-config.yml` 指定与外部策略引擎联系所需的 kubeconfig 文件的位置。 -该文件还可以包含一个 `retryBackoff` 值，该值以毫秒为单位控制初始重试 backoff 延迟。 -* `opa-kubeconfig` 是一个标准的 kubeconfig，包含联系外部策略引擎所需的 URL 和凭证。 - - -编辑联邦 API 服务器部署以启用 `SchedulingPolicy` 准入控制器。 - - kubectl -n federation-system edit deployment federation-apiserver - - -更新 Federation API 服务器命令行参数以启用准入控制器， -并将 ConfigMap 挂载到容器中。如果存在现有的 `-enable-admissionplugins` 参数，则追加 `SchedulingPolicy` 而不是添加另一行。 - - - --enable-admission-plugins=SchedulingPolicy - --admission-control-config-file=/etc/kubernetes/admission/config.yml - - -将以下卷添加到联邦 API 服务器 pod： - - - name: admission-config - configMap: - name: admission - - -添加以下卷挂载联邦 API 服务器的 `apiserver` 容器： - - volumeMounts: - - name: admission-config - mountPath: /etc/kubernetes/admission - - - -## Deploying 外部策略引擎 - - -[Open Policy Agent (OPA)](http://openpolicyagent.org) 是一个开源的通用策略引擎， -您可以使用它在联邦控制平面中执行基于策略的放置决策。 - - -在主机群集中创建服务以联系外部策略引擎： - - kubectl create -f policy-engine-service.yaml - - -下面显示的是 OPA 的示例服务。 - -{{< codenew file="federation/policy-engine-service.yaml" >}} - - -使用联邦控制平面在主机群集中创建部署： - - kubectl create -f policy-engine-deployment.yaml - - -下面显示的是 OPA 的部署示例。 - -{{< codenew file="federation/policy-engine-deployment.yaml" >}} - - - -## 通过 ConfigMaps 配置放置策略 - - -外部策略引擎将发现在 Federation API 服务器的 `kube-federation-scheduling-policy` -命名空间中创建的放置策略。 - - -如果命名空间尚不存在，请创建它： - - kubectl --context=federation create namespace kube-federation-scheduling-policy - - -配置一个示例策略来测试外部策略引擎: - -``` -# OPA supports a high-level declarative language named Rego for authoring and -# enforcing policies. For more information on Rego, visit -# http://openpolicyagent.org. - -# Rego policies are namespaced by the "package" directive. -package kubernetes.placement - -# Imports provide aliases for data inside the policy engine. In this case, the -# policy simply refers to "clusters" below. -import data.kubernetes.clusters - -# The "annotations" rule generates a JSON object containing the key -# "federation.kubernetes.io/replica-set-preferences" mapped to . -# The preferences values is generated dynamically by OPA when it evaluates the -# rule. -# -# The SchedulingPolicy Admission Controller running inside the Federation API -# server will merge these annotations into incoming Federated resources. By -# setting replica-set-preferences, we can control the placement of Federated -# ReplicaSets. -# -# Rules are defined to generate JSON values (booleans, strings, objects, etc.) -# When OPA evaluates a rule, it generates a value IF all of the expressions in -# the body evaluate successfully. All rules can be understood intuitively as -# if where is true if AND AND ... -# is true (for some set of data.) -annotations["federation.kubernetes.io/replica-set-preferences"] = preferences { - input.kind = "ReplicaSet" - value = {"clusters": cluster_map, "rebalance": true} - json.marshal(value, preferences) -} - -# This "annotations" rule generates a value for the "federation.alpha.kubernetes.io/cluster-selector" -# annotation. -# -# In English, the policy asserts that resources in the "production" namespace -# that are not annotated with "criticality=low" MUST be placed on clusters -# labelled with "on-premises=true". -annotations["federation.alpha.kubernetes.io/cluster-selector"] = selector { - input.metadata.namespace = "production" - not input.metadata.annotations.criticality = "low" - json.marshal([{ - "operator": "=", - "key": "on-premises", - "values": "[true]", - }], selector) -} - -# Generates a set of cluster names that satisfy the incoming Federated -# ReplicaSet's requirements. In this case, just PCI compliance. -replica_set_clusters[cluster_name] { - clusters[cluster_name] - not insufficient_pci[cluster_name] -} - -# Generates a set of clusters that must not be used for Federated ReplicaSets -# that request PCI compliance. -insufficient_pci[cluster_name] { - clusters[cluster_name] - input.metadata.annotations["requires-pci"] = "true" - not pci_clusters[cluster_name] -} - -# Generates a set of clusters that are PCI certified. In this case, we assume -# clusters are annotated to indicate if they have passed PCI compliance audits. -pci_clusters[cluster_name] { - clusters[cluster_name].metadata.annotations["pci-certified"] = "true" -} - -# Helper rule to generate a mapping of desired clusters to weights. In this -# case, weights are static. -cluster_map[cluster_name] = {"weight": 1} { - replica_set_clusters[cluster_name] -} -``` - - -下面显示的是创建示例策略的命令： - - kubectl --context=federation -n kube-federation-scheduling-policy create configmap scheduling-policy --from-file=policy.rego - - -这个示例策略说明了一些关键思想： - - - -* 位置策略可以引用联邦资源中的任何字段。 -* 放置策略可以利用外部上下文(例如，集群元数据)来做出决策。 -* 管理策略可以集中管理。 -* 策略可以定义简单的接口(例如 `requirements -pci` 注解)，以避免在清单中重复逻辑。 - - - -## 测试放置政策 - - -注释其中一个集群以表明它是经过 PCI 认证的。 - - kubectl --context=federation annotate clusters cluster-name-1 pci-certified=true - - -部署联邦副本来测试放置策略。 - -{{< codenew file="federation/replicaset-example-policy.yaml" >}} - - -下面显示的命令用于部署与策略匹配的副本集。 - - kubectl --context=federation create -f replicaset-example-policy.yaml - - -检查副本集以确认已应用适当的注解： - - kubectl --context=federation get rs nginx-pci -o jsonpath='{.metadata.annotations}' - - - -