whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge remote-tracking branch 'upstream/master' into dev-1.19

Browse Source
This commit is contained in:
Savitha Raghunathan
2020-07-27 19:10:42 -04:00
parent c5a2bb2edd e1485cd5d7
commit e2a861c2f9
556 changed files with 9174 additions and 6944 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/zh/docs/concepts/architecture/_index.md
+2
View File
@@ -1,4 +1,6 @@
---
title: "Kubernetes 架构"
weight: 30
description: >
Kubernetes 背后的架构概念。
---
content/zh/docs/concepts/cluster-administration/_index.md
+134 -2
View File
@@ -1,4 +1,136 @@
---
title: "计算、存储和网络扩展"
weight: 30
title: "集群管理"
weight: 100
content_type: concept
description: >
关于创建和管理 Kubernetes 集群的底层细节。
no_list: true
---
<!--
title: Cluster Administration
reviewers:
- davidopp
- lavalamp
weight: 100
content_type: concept
description: >
Lower-level detail relevant to creating or administering a Kubernetes cluster.
no_list: true
-->
<!-- overview -->
<!--
The cluster administration overview is for anyone creating or administering a Kubernetes cluster.
It assumes some familiarity with core Kubernetes [concepts](/docs/concepts/).
-->
集群管理概述面向任何创建和管理 Kubernetes 集群的读者人群。
我们假设你对一些核心的 Kubernetes [概念](/zh/docs/concepts/)大概了解。
<!-- body -->
<!--
## Planning a cluster
See the guides in [Setup](/docs/setup/) for examples of how to plan, set up, and configure Kubernetes clusters. The solutions listed in this article are called *distros*.
Not all distros are actively maintained. Choose distros which have been tested with a recent version of Kubernetes.
Before choosing a guide, here are some considerations:
-->
## 规划集群
查阅[安装](/zh/docs/setup/)中的指导，获取如何规划、建立以及配置 Kubernetes 集群的示例。本文所列的文章称为*发行版* 。
{{< note >}}
并非所有发行版都是被积极维护的。
请选择使用最近 Kubernetes 版本测试过的发行版。
{{< /note >}}
在选择一个指南前，有一些因素需要考虑：
<!--
- Do you just want to try out Kubernetes on your computer, or do you want to build a high-availability, multi-node cluster? Choose distros best suited for your needs.
- Will you be using **a hosted Kubernetes cluster**, such as [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/), or **hosting your own cluster**?
- Will your cluster be **on-premises**, or **in the cloud (IaaS)**? Kubernetes does not directly support hybrid clusters. Instead, you can set up multiple clusters.
- **If you are configuring Kubernetes on-premises**, consider which [networking model](/docs/concepts/cluster-administration/networking/) fits best.
- Will you be running Kubernetes on **"bare metal" hardware** or on **virtual machines (VMs)**?
- Do you **just want to run a cluster**, or do you expect to do **active development of Kubernetes project code**? If the
latter, choose an actively-developed distro. Some distros only use binary releases, but
offer a greater variety of choices.
- Familiarize yourself with the [components](/docs/admin/cluster-components/) needed to run a cluster.
-->
- 你是打算在你的计算机上尝试 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)。
<!--
## Managing a cluster
* [Managing a cluster](/docs/tasks/administer-cluster/cluster-management/) describes several topics related to the lifecycle of a cluster: creating a new cluster, upgrading your cluster’s master and worker nodes, performing node maintenance (e.g. kernel upgrades), and upgrading the Kubernetes API version of a running cluster.
* Learn how to [manage nodes](/docs/concepts/nodes/node/).
* Learn how to set up and manage the [resource quota](/docs/concepts/policy/resource-quotas/) for shared clusters.
-->
## 管理集群
* [管理集群](/zh/docs/tasks/administer-cluster/cluster-management/)叙述了和集群生命周期相关的几个主题：
创建新集群、升级集群的控制节点和工作节点、执行节点维护（例如内核升级）以及升级运行中的集群的 Kubernetes API 版本。
* 学习如何[管理节点](/zh/docs/concepts/nodes/node/)。
* 学习如何设定和管理集群共享的[资源配额](/zh/docs/concepts/policy/resource-quotas/) 。
<!--
## Securing a cluster
* [Certificates](/docs/concepts/cluster-administration/certificates/) describes the steps to generate certificates using different tool chains.
* [Kubernetes Container Environment](/docs/concepts/containers/container-environment/) describes the environment for Kubelet managed containers on a Kubernetes node.
* [Controlling Access to the Kubernetes API](/docs/reference/access-authn-authz/controlling-access/) describes how to set up permissions for users and service accounts.
* [Authenticating](/docs/reference/access-authn-authz/authentication/) explains authentication in Kubernetes, including the various authentication options.
* [Authorization](/docs/reference/access-authn-authz/authorization/) is separate from authentication, and controls how HTTP calls are handled.
* [Using Admission Controllers](/docs/reference/access-authn-authz/admission-controllers/) explains plug-ins which intercepts requests to the Kubernetes API server after authentication and authorization.
* [Using Sysctls in a Kubernetes Cluster](/docs/concepts/cluster-administration/sysctl-cluster/) describes to an administrator how to use the `sysctl` command-line tool to set kernel parameters .
* [Auditing](/docs/tasks/debug-application-cluster/audit/) describes how to interact with Kubernetes' audit logs.
-->
## 保护集群
* [证书](/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 的审计日志交互。
<!--
### Securing the kubelet
* [Master-Node communication](/docs/concepts/architecture/master-node-communication/)
* [TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)
* [Kubelet authentication/authorization](/docs/admin/kubelet-authentication-authorization/)
-->
### 保护 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/)
<!--
## Optional Cluster Services
* [DNS Integration](/docs/concepts/services-networking/dns-pod-service/) describes how to resolve a DNS name directly to a Kubernetes service.
* [Logging and Monitoring Cluster Activity](/docs/concepts/cluster-administration/logging/) explains how logging in Kubernetes works and how to implement it.
-->
## 可选集群服务
* [DNS 集成](/zh/docs/concepts/services-networking/dns-pod-service/)描述了如何将一个 DNS 名解析到一个 Kubernetes service。
* [记录和监控集群活动](/zh/docs/concepts/cluster-administration/logging/)阐述了 Kubernetes 的日志如何工作以及怎样实现。
content/zh/docs/concepts/cluster-administration/cluster-administration-overview.md
-145
View File
@@ -1,145 +0,0 @@
---
title: 集群管理概述
content_type: concept
weight: 10
---
<!-- overview -->
<!--
The cluster administration overview is for anyone creating or administering a Kubernetes cluster.
It assumes some familiarity with core Kubernetes [concepts](/docs/concepts/).
-->
集群管理概述面向任何创建和管理 Kubernetes 集群的读者人群。
我们假设你对[用户指南](/docs/user-guide/)中的概念大概了解。
<!-- body -->
<!--
## Planning a cluster
See the guides in [Setup](/docs/setup/) for examples of how to plan, set up, and configure Kubernetes clusters. The solutions listed in this article are called *distros*.
Before choosing a guide, here are some considerations:
-->
## 规划集群
查阅[安装](/docs/setup/)中的指导，获取如何规划、建立以及配置 Kubernetes 集群的示例。本文所列的文章称为*发行版* 。
在选择一个指南前，有一些因素需要考虑：
<!--
- Do you just want to try out Kubernetes on your computer, or do you want to build a high-availability, multi-node cluster? Choose distros best suited for your needs.
- **If you are designing for high-availability**, learn about configuring [clusters in multiple zones](/docs/concepts/cluster-administration/federation/).
- Will you be using **a hosted Kubernetes cluster**, such as [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/), or **hosting your own cluster**?
- Will your cluster be **on-premises**, or **in the cloud (IaaS)**? Kubernetes does not directly support hybrid clusters. Instead, you can set up multiple clusters.
- **If you are configuring Kubernetes on-premises**, consider which [networking model](/docs/concepts/cluster-administration/networking/) fits best.
- Will you be running Kubernetes on **"bare metal" hardware** or on **virtual machines (VMs)**?
- Do you **just want to run a cluster**, or do you expect to do **active development of Kubernetes project code**? If the
latter, choose an actively-developed distro. Some distros only use binary releases, but
offer a greater variety of choices.
- Familiarize yourself with the [components](/docs/admin/cluster-components/) needed to run a cluster.
-->
- 你是打算在你的电脑上尝试 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)。
<!--
Note: Not all distros are actively maintained. Choose distros which have been tested with a recent version of Kubernetes.
-->
请注意：不是所有的发行版都被积极维护着。请选择测试过最近版本的 Kubernetes 的发行版。
<!--
## Managing a cluster
* [Managing a cluster](/docs/tasks/administer-cluster/cluster-management/) describes several topics related to the lifecycle of a cluster: creating a new cluster, upgrading your cluster’s master and worker nodes, performing node maintenance (e.g. kernel upgrades), and upgrading the Kubernetes API version of a running cluster.
* Learn how to [manage nodes](/docs/concepts/nodes/node/).
* Learn how to set up and manage the [resource quota](/docs/concepts/policy/resource-quotas/) for shared clusters.
-->
## 管理集群
* [管理集群](/docs/concepts/cluster-administration/cluster-management/)叙述了和集群生命周期相关的几个主题：创建一个新集群、升级集群的 master 和 worker 节点、执行节点维护（例如内核升级）以及升级活动集群的 Kubernetes API 版本。
* 学习如何[管理节点](/docs/concepts/nodes/node/)。
* 学习如何设定和管理集群共享的[资源配额](/docs/concepts/policy/resource-quotas/) 。
<!--
## Securing a cluster
* [Certificates](/docs/concepts/cluster-administration/certificates/) describes the steps to generate certificates using different tool chains.
* [Kubernetes Container Environment](/docs/concepts/containers/container-environment-variables/) describes the environment for Kubelet managed containers on a Kubernetes node.
* [Controlling Access to the Kubernetes API](/docs/reference/access-authn-authz/controlling-access/) describes how to set up permissions for users and service accounts.
* [Authenticating](/docs/reference/access-authn-authz/authentication/) explains authentication in Kubernetes, including the various authentication options.
* [Authorization](/docs/reference/access-authn-authz/authorization/) is separate from authentication, and controls how HTTP calls are handled.
* [Using Admission Controllers](/docs/reference/access-authn-authz/admission-controllers/) explains plug-ins which intercepts requests to the Kubernetes API server after authentication and authorization.
* [Using Sysctls in a Kubernetes Cluster](/docs/concepts/cluster-administration/sysctl-cluster/) describes to an administrator how to use the `sysctl` command-line tool to set kernel parameters .
* [Auditing](/docs/tasks/debug-application-cluster/audit/) describes how to interact with Kubernetes' audit logs.
-->
## 集群安全
* [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 的审计日志交互。
<!--
### Securing the kubelet
* [Master-Node communication](/docs/concepts/architecture/master-node-communication/)
* [TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)
* [Kubelet authentication/authorization](/docs/admin/kubelet-authentication-authorization/)
-->
### 保护 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/)
<!--
## Optional Cluster Services
* [DNS Integration](/docs/concepts/services-networking/dns-pod-service/) describes how to resolve a DNS name directly to a Kubernetes service.
* [Logging and Monitoring Cluster Activity](/docs/concepts/cluster-administration/logging/) explains how logging in Kubernetes works and how to implement it.
-->
## 可选集群服务
* [DNS 与 SkyDNS 集成](/docs/concepts/services-networking/dns-pod-service/)描述了如何将一个 DNS 名解析到一个 Kubernetes service。
* [记录和监控集群活动](/docs/concepts/cluster-administration/logging/)阐述了 Kubernetes 的日志如何工作以及怎样实现。
content/zh/docs/concepts/cluster-administration/federation.md
-118
View File
@@ -1,118 +0,0 @@
---
title: 联邦
content_type: concept
---
<!-- overview -->
本页面阐明了为何以及如何使用联邦创建Kubernetes集群。
<!-- body -->
## 为何使用联邦
联邦可以使多个集群的管理简单化。它提供了两个主要构件模块：
* 跨集群同步资源：联邦能够让资源在多个集群中同步。例如，你可以确保在多个集群中存在同样的部署。
* 跨集群发现：联邦能够在所有集群的后端自动配置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)
content/zh/docs/concepts/configuration/secret.md
+2 -2
View File
@@ -167,10 +167,10 @@ This is to protect the secret from being exposed accidentally to an onlooker,
or from being stored in a terminal log.
-->
{{< /note >}}
默认情况下，`kubectl get` 和 `kubectl describe` 避免显示密码的内容。 这是为了防止机密被意外地暴露给旁观者或存储在终端日志中。
{{< /note >}}
<!--
See [decoding a secret](#decoding-a-secret) for how to see the contents of a secret.
-->
content/zh/docs/concepts/containers/container-environment-variables.md
-63
View File
@@ -1,63 +0,0 @@
---
approvers:
- mikedanese
- thockin
title: 容器环境变量
content_type: concept
---
<!-- overview -->
本文介绍容器环境中对容器可用的资源。
{{< toc >}}
<!-- body -->
## 容器环境
Kubernetes 容器环境为容器提供了几类重要的资源：
* 一个文件系统，其中包含一个[镜像](/docs/concepts/containers/images/)和一个或多个[卷](/docs/concepts/storage/volumes/)。
* 容器本身相关的信息。
* 集群中其他对象相关的信息。
### 容器信息
容器的 *hostname* 是容器所在的 Pod 名称。 可以通过 `hostname` 命令或调用 libc 中的
[`gethostname`](http://man7.org/linux/man-pages/man2/gethostname.2.html)
函数来获取。
Pod 名称和名字空间可以通过
[downward API](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/) 以环境变量方式访问。
与 Docker 镜像中静态指定的环境变量一样，Pod 中用户定义的环境变量也可用于容器。
### 集群信息
容器创建时运行的所有服务的列表都会作为环境变量提供给容器。
这些环境变量与 Docker 链接语法相匹配。
对一个名为 *foo* ，映射到名为 *bar* 的容器端口的服务，
会定义如下变量：
```shell
FOO_SERVICE_HOST=<服务所在的主机地址>
FOO_SERVICE_PORT=<服务所启用的端口>
```
服务具有专用 IP 地址，如果启用了 [DNS 插件](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/)，还可以在容器中通过 DNS 进行访问。
## {{% heading "whatsnext" %}}
* 查看[容器生命周期挂钩（hooks）](/docs/concepts/containers/container-lifecycle-hooks/)了解更多。
* 获取[为容器生命周期事件附加处理程序](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)的实践经验。
content/zh/docs/concepts/containers/overview.md
+1 -1
View File
@@ -46,7 +46,7 @@ the change, then recreate the container to start from the updated image.
<!--
## Container runtimes
-->
##容器运行时
## 容器运行时
{{< glossary_definition term_id="container-runtime" length="all" >}}
content/zh/docs/concepts/overview/components.md
+10 -6
View File
@@ -1,8 +1,10 @@
---
title: Kubernetes 组件
content_type: concept
description: >
Kubernetes 集群由代表控制平面的组件和一组称为节点的机器组成。
weight: 20
card:
card:
name: concepts
weight: 20
---
@@ -12,8 +14,11 @@ reviewers:
- lavalamp
title: Kubernetes Components
content_type: concept
description: >
A Kubernetes cluster consists of the components that represent the control plane
and a set of machines called nodes
weight: 20
card:
card:
name: concepts
weight: 20
---
@@ -43,17 +48,17 @@ Here's the diagram of a Kubernetes cluster with all the components tied together
<!-- body -->
<!--
<!--
## Control Plane Components
-->
## 控制平面组件（Control Plane Components）
<!--
<!--
The Control Plane's components make global decisions about the cluster (for example, scheduling), as well as detecting and responding to cluster events (for example, starting up a new {{< glossary_tooltip text="pod" term_id="pod">}} when a deployment's `replicas` field is unsatisfied).
-->
控制平面的组件对集群做出全局决策(比如调度)，以及检测和响应集群事件（例如，当不满足部署的 `replicas` 字段时，启动新的 {{< glossary_tooltip text="pod" term_id="pod">}}）。
<!--
<!--
Control Plane components can be run on any machine in the cluster. However,
for simplicity, set up scripts typically start all Control Plane components on
the same machine, and do not run user containers on this machine. See
@@ -233,4 +238,3 @@ saving container logs to a central log store with search/browsing interface.
* 进一步了解 [Nodes](/docs/concepts/architecture/nodes/)
* 进一步了解 [kube-scheduler](/docs/concepts/scheduling/kube-scheduler/)
* 阅读 etcd 官方[文档](https://etcd.io/docs/)
content/zh/docs/concepts/overview/what-is-kubernetes.md
+4 -2
View File
@@ -1,6 +1,8 @@
---
title: Kubernetes 是什么？
content_type: concept
description: >
Kubernetes 是一个可移植的，可扩展的开源平台，用于管理容器化的工作负载和服务，方便了声明式配置和自动化。它拥有一个庞大且快速增长的生态系统。Kubernetes 的服务，支持和工具广泛可用。
weight: 10
card:
name: concepts
@@ -74,7 +76,7 @@ Each VM is a full machine running all the components, including its own operatin
每个 VM 是一台完整的计算机，在虚拟化硬件之上运行所有组件，包括其自己的操作系统。
<!--
**Container deployment era:**
**Container deployment era:**
Containers are similar to VMs, but they have relaxed isolation properties to share the Operating System (OS) among the applications. Therefore, containers are considered lightweight. Similar to a VM, a container has its own filesystem, CPU, memory, process space, and more. As they are decoupled from the underlying infrastructure, they are portable across clouds and OS distributions.
-->
**容器部署时代：**
@@ -214,4 +216,4 @@ Kubernetes：
* Ready to [Get Started](/docs/setup/)?
-->
* 查阅 [Kubernetes 组件](/zh/docs/concepts/overview/components/)
* 开始 [Kubernetes 入门](/zh/docs/setup/)?
* 开始 [Kubernetes 入门](/zh/docs/setup/)?
content/zh/docs/concepts/overview/working-with-objects/_index.md
+2
View File
@@ -1,4 +1,6 @@
---
title: "使用 Kubernetes 对象"
weight: 40
description: >
Kubernetes 对象是 Kubernetes 系统中的持久性实体。Kubernetes 使用这些实体表示您的集群状态。了解 Kubernetes 对象模型以及如何使用这些对象。
---
content/zh/docs/concepts/services-networking/connect-applications-service.md
+6 -10
View File
@@ -602,15 +602,11 @@ LoadBalancer Ingress: a320587ffd19711e5a37606cf4a74574-1142138393.us-east-1.el
## {{% heading "whatsnext" %}}
<!--
Kubernetes also supports Federated Services, which can span multiple
clusters and cloud providers, to provide increased availability,
better fault tolerance and greater scalability for your services. See
the [Federated Services User Guide](/docs/concepts/cluster-administration/federation-service-discovery/)
for further information.
* Learn more about [Using a Service to Access an Application in a Cluster](/docs/tasks/access-application-cluster/service-access-application-cluster/)
* Learn more about [Connecting a Front End to a Back End Using a Service](/docs/tasks/access-application-cluster/connecting-frontend-backend/)
* Learn more about [Creating an External Load Balancer](/docs/tasks/access-application-cluster/create-external-load-balancer/)
-->
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/)
content/zh/docs/concepts/services-networking/ingress.md
-2
View File
@@ -4,13 +4,11 @@ content_type: concept
weight: 40
---
<!--
---
reviewers:
- bprashanth
title: Ingress
content_type: concept
weight: 40
---
-->
<!-- overview -->
content/zh/docs/concepts/workloads/pods/disruptions.md
+1 -1
View File
@@ -87,7 +87,7 @@ actions initiated by the application owner and those initiated by a Cluster
Administrator. Typical application owner actions include:
-->
我们称其他情况为*自愿干扰*。包括由应用程序所有者发起的操作和由集群管理员发起的操作。典型的应用程序所有者的
我们称其他情况为*自愿干扰*。包括由应用程序所有者发起的操作和由集群管理员发起的操作。典型的应用程序所有者的操
作包括：
<!--
content/zh/docs/contribute/advanced.md
-126
View File
@@ -27,132 +27,6 @@ client and other tools for some of these tasks.
<!-- body -->
<!--
## Be the PR Wrangler for a week
-->
## 做一周的 PR 管理者
<!--
SIG Docs [approvers](/docs/contribute/participating/#approvers) take week-long turns [wrangling PRs](https://github.com/kubernetes/website/wiki/PR-Wranglers) for the repository.
The PR wrangler’s duties include:
-->
SIG Docs 的[批准人（Approvers）](/zh/docs/contribute/participating/#approvers)们每周轮流负责
[管理仓库的 PRs](https://github.com/kubernetes/website/wiki/PR-Wranglers)。
PR 管理者的工作职责包括：
<!--
- Review [open pull requests](https://github.com/kubernetes/website/pulls) daily for quality and adherence to the [style guide](/docs/contribute/style/style-guide/).
- Review the smallest PRs (`size/XS`) first, then iterate towards the largest (`size/XXL`).
- Review as many PRs as you can.
- Ensure that the CLA is signed by each contributor.
- Help new contributors sign the [CLA](https://github.com/kubernetes/community/blob/master/CLA.md).
- Use [this](https://github.com/zparnold/k8s-docs-pr-botherer) script to automatically remind contributors that haven’t signed the CLA to sign the CLA.
- Provide feedback on proposed changes and help facilitate technical reviews from members of other SIGs.
- Provide inline suggestions on the PR for the proposed content changes.
- If you need to verify content, comment on the PR and request more details.
- Assign relevant `sig/` label(s).
- If needed, assign reviewers from the `reviewers:` block in the file's front matter.
- Assign `Docs Review` and `Tech Review` labels to indicate the PR's review status.
- Assign `Needs Doc Review` or `Needs Tech Review` for PRs that haven't yet been reviewed.
- Assign `Doc Review: Open Issues` or `Tech Review: Open Issues` for PRs that have been reviewed and require further input or action before merging.
- Assign `/lgtm` and `/approve` labels to PRs that can be merged.
- Merge PRs when they are ready, or close PRs that shouldn’t be accepted.
- Triage and tag incoming issues daily. See [Intermediate contributing](/docs/contribute/intermediate/) for guidelines on how SIG Docs uses metadata.
-->
- 每天检查[悬决的 PR](https://github.com/kubernetes/website/pulls) 的质量并确保它们遵守[样式指南](/zh/docs/contribute/style/style-guide/)和[内容指南](/zh/docs/contribute/style/content-guide/)。
- 首先查看最小的 PR（`size/XS`），然后逐渐扩展到最大的 PR（`size/XXL`）。
- 尽可能多地审阅 PR。
- 确保每个贡献者完成 CLA 签署。
- 指导新的贡献者签署 [CLA](https://github.com/kubernetes/community/blob/master/CLA.md)。
- 使用[此脚本](https://github.com/zparnold/k8s-docs-pr-botherer)自动提醒尚未签署 CLA 的贡献者签署 CLA。
- 针对所建议的更改提供反馈，并帮助协调其他 SIG 成员进行技术审核。
- 为 PR 所建议的内容更改提供在线反馈。
- 如果您需要验证内容，请在 PR 上发表评论并要求贡献者提供更多细节。
- 设置相关的 `sig/` 标签。
- 如果需要，请从文件开头的 `reviewers:` 块中指定审阅者。
- 设置 `Docs Review` 和 `Tech Review` 标签以标示 PR 的审阅状态。
- 为尚未审阅的 PR 设置 `Needs Doc Review` 或者 `Needs Tech Review` 标签。
- 为已审阅的但在合并前需要更多信息的或采取措施的 PR 设置 `Doc Review: Open Issues` 或者 `Tech Review: Open Issues` 标签。
- 为可以合并的 PR 添加 `/lgtm` 和 `/approve` 标签。
- 合并已经就绪的，或关闭不应该接受的 PR。
- 每天对新增的 Issue 报告进行分类和判别。有关 SIG 文档如何使用 metadata 的准则，请参见
[对 Issue 进行分类](/zh/docs/contribute/review/for-approvers/#triage-and-categorize-issues)。
<!--
### Helpful GitHub queries for wranglers
The following queries are helpful when wrangling. After working through these three queries, the remaining list of PRs to be
reviewed is usually small. These queries specifically exclude localization PRs, and only include the `master` branch (except for the last one).
-->
### 对于管理人有用的 GitHub 查询
执行管理操作时，以下查询很有用。完成以下三个查询后，剩余的要审阅的 PR 列表通常很小。
这些查询都排除了本地化的 PR，并仅包含 `master` 分支上的 PR（除了最后一个查询）。
<!--
- [No CLA, not eligible to merge](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3A%22cncf-cla%3A+no%22+-label%3Ado-not-merge+label%3Alanguage%2Fen):
Remind the contributor to sign the CLA. If they have already been reminded by both the bot and a human, close
the PR and remind them that they can open it after signing the CLA.
**Do not review PRs whose authors have not signed the CLA!**
- [Needs LGTM](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-label%3Algtm+):
If it needs technical review, loop in one of the reviewers suggested by the bot. If it needs docs review
or copy-editing, either suggest changes or add a copyedit commit to the PR to move it along.
- [Has LGTM, needs docs approval](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+label%3Algtm):
Determine whether any additional changes or updates need to be made for the PR to be merged. If you think the PR is ready to be merged, comment `/approve`.
- [Not against master](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-base%3Amaster): If it's against a `dev-` branch, it's for an upcoming release. Make sure the [release meister](https://github.com/kubernetes/sig-release/tree/master/release-team) knows about it by adding a comment with `/assign @<meister's_github-username>`. If it's against an old branch, help the PR author figure out whether it's targeted against the best branch.
-->
- [没有签署 CLA, 不能合并](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3A%22cncf-cla%3A+no%22+-label%3Ado-not-merge+label%3Alanguage%2Fen):
提醒贡献者签署 CLA。如果机器人和审阅者都已经提醒他们，请关闭 PR，并提醒他们在签署 CLA 后可以重新提交。
**在作者没有签署 CLA 之前，不要审阅他们的 PR！**
- [需要 LGTM](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-label%3Algtm+):
如果需要技术审查，请告知机器人所建议的审阅者。如果 PR 需要文档审查或复制编辑，提交更改建议或向 PR 提交一个 copyedit 以使之进入下一步。
- [有 LGTM ，需要批准](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+label%3Algtm):
确定 PR 是否需要进行其他更改或更新才能合并。如果您认为 PR 已准备好合并，请输入 `/approve`。
- [快速批阅](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+base%3Amaster+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3A%22cncf-cla%3A+yes%22+label%3A%22size%2FXS%22+label%3A%22language%2Fen%22+)：对于针对 master 分支的小规模 PR，可以快速审阅。
在浏览 PR 时，可以注意到 size 标签为 "XS" 的 PRs。
- [非 master 分支的 PR](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-base%3Amaster)：
如果 PR 针对 `dev-` 分支，则表示它适用于即将发布的版本。请添加带有 `/assign @<负责人的 github 账号>` 的注释，确保[发行版本负责人](https://github.com/kubernetes/sig-release/tree/master/release-team)注意到该 PR。如果 PR 是针对旧分支，请帮助 PR 作者确定是否所针对的是最合适的分支。
<!--
### When to close Pull Requests
Reviews and approvals are one tool to keep our PR queue short and current. Another tool is closure.
-->
### 什么时候关闭 PR
审查和批准是缩短和更新我们的 PR 队列的一种方式；另一种方式是关闭 PR。
<!--
- Close any PR where the CLA hasn’t been signed for two weeks.
PR authors can reopen the PR after signing the CLA, so this is a low-risk way to make sure nothing gets merged without a signed CLA.
- Close any PR where the author has not responded to comments or feedback in 2 or more weeks.
Don't be afraid to close pull requests. Contributors can easily reopen and resume works in progress. Oftentimes a closure notice is what spurs an author to resume and finish their contribution.
To close a pull request, leave a `/close` comment on the PR.
-->
- 关闭两个星期未签署 CLA 的 PR。
PR 作者可以在签署 CLA 后重新打开 PR，因此这是确保未签署 CLA 的 PR 不会被合并的一种风险较低的方法。
- 如果作者在两周或更长时间内未回复评论或反馈，请关闭 PR。
不要害怕关闭 PR。贡献者可以轻松地重新打开并继续工作。通常，关闭通知会激励作者继续完成其贡献。
要关闭 PR，请在 PR 上输入 `/close`。
<!--
An automated service, [`fejta-bot`](https://github.com/fejta-bot) automatically marks issues as stale after 90 days of inactivity, then closes them after an additional 30 days of inactivity when they become rotten. PR wranglers should close issues after 14-30 days of inactivity.
-->
{{< note >}}
一项名为 [`fejta-bot`](https://github.com/fejta-bot) 的自动服务会在 Issue 停滞 90
天后自动将其标记为过期；然后再等 30 天，如果仍然无人过问，则将其关闭。
PR 管理者应该在 issues 处于无人过问状态 14-30 天后关闭它们。
{{< /note >}}
<!--
## Propose improvements
content/zh/docs/contribute/new-content/blogs-case-studies.md
+159 -43
View File
@@ -22,63 +22,181 @@ Case studies require extensive review before they're approved.
案例分析则在被批准之前需要更多的评阅。
<!-- body -->
<!--
## Write a blog post
## The Kubernetes Blog
Blog posts should not be
vendor pitches. They must contain content that applies broadly to
the Kubernetes community. The SIG Docs [blog subproject](https://github.com/kubernetes/community/tree/master/sig-docs/blog-subproject) manages the review process for blog posts. For more information, see [Submit a post](https://github.com/kubernetes/community/tree/master/sig-docs/blog-subproject#submit-a-post).
The Kubernetes blog is used by the project to communicate new features, community reports, and any news that might be relevant to the Kubernetes community.
This includes end users and developers.
Most of the blog's content is about things happening in the core project, but we encourage you to submit about things happening elsewhere in the ecosystem too!
Anyone can write a blog post and submit it for review.
-->
## 撰写博文 {#write-a-blog-post}
## Kubernetes 博客
博客内容不可以是销售用语。
其中的内容必须是对整个 Kubernetes 社区中很多人都有参考意义。
SIG Docs [blog 子项目](https://github.com/kubernetes/community/tree/master/sig-docs/blog-subproject)
负责管理博客的评阅过程。
Kubernetes 博客用于项目发布新功能特性、社区报告以及其他一些可能对整个社区
很重要的新闻。
其读者包括最终用户和开发人员。
大多数博客的内容是关于核心项目中正在发生的事情，不过我们也鼓励你提交一些
关于生态系统中其他地方发生的事情的博客。
任何人都可以撰写博客并提交评阅。
<!--
### Guidelines and expectations
- Blog posts should not be vendor pitches.
- Articles must contain content that applies broadly to the Kubernetes community. For example, a submission should focus on upstream Kubernetes as opposed to vendor-specific configurations. Check the [Documentation style guide](https://kubernetes.io/docs/contribute/style/content-guide/#what-s-allowed) for what is typically allowed on Kubernetes properties.
- Links should primarily be to the official Kubernetes documentation. When using external references, links should be diverse - For example a submission shouldn't contain only links back to a single company's blog.
- Sometimes this is a delicate balance. The [blog team](https://kubernetes.slack.com/messages/sig-docs-blog/) is there to give guidance on whether a post is appropriate for the Kubernetes blog, so don't hesitate to reach out.
-->
### 指导原则和期望 {#guidelines-and-expectations}
- 博客内容不可以是销售用语。
- 文章内容必须是对整个 Kubernetes 社区中很多人都有参考意义。
例如，所提交的文章应该关注上游的 Kubernetes 项目本身，而不是某个厂商特定的配置。
请参阅[文档风格指南](/zh/docs/contribute/style/content-guide/#what-s-allowed)
以了解哪些内容是 Kubernetes 所允许的。
- 链接应该主要指向官方的 Kubernetes 文档。
当引用外部信息时，链接应该是多样的。
例如，所提交的博客文章中不可以只包含指向某个公司的博客的链接。
- 有些时候，这是一个比较棘手的权衡过程。
[博客团队](https://kubernetes.slack.com/messages/sig-docs-blog/)的存在目的即是为
Kubernetes 博客提供文章是否合适的指导意见。
所以，需要帮助的时候不要犹豫。
<!--
- Blog posts are not published on specific dates.
- Articles are reviewed by community volunteers. We'll try our best to accommodate specific timing, but we make no guarantees.
- Many core parts of the Kubernetes projects submit blog posts during release windows, delaying publication times. Consider submitting during a quieter period of the release cycle.
- If you are looking for greater coordination on post release dates, coordinating with [CNCF marketing](https://www.cncf.io/about/contact/) is a more appropriate choice than submitting a blog post.
- Sometimes reviews can get backed up. If you feel your review isn't getting the attention it needs, you can reach out to the blog team via [this slack channel](https://kubernetes.slack.com/messages/sig-docs-blog/) to ask in real time.
-->
- 博客内容并非在某特定日期发表。
- 文章会交由社区自愿者评阅。我们会尽力满足特定的时限要求，只是无法就此作出承诺。
- Kubernetes 项目的很多核心组件会在发布窗口期内提交博客文章，导致发表时间被推迟。
因此，请考虑在发布周期内较为平静的时间段提交博文。
- 如果你希望就博文发表日期上进行较大范围的协调，请联系
[CNCF 推广团队](https://www.cncf.io/about/contact/)。
这也许是比提交博客文章更合适的一种选择。
- 有时，博客的评审可能会堆积起来。如果你觉得你的文章没有引起该有的重视，
你可以通过[此 Slack 频道](https://kubernetes.slack.com/messages/sig-docs-blog/)
联系博客团队，以获得实时反馈。
<!--
- Blog posts should be relevant to Kubernetes users.
- Topics related to participation in or results of Kubernetes SIGs activities are always on topic (see the work in the [Upstream Marketing Team](https://github.com/kubernetes/community/blob/master/communication/marketing-team/blog-guidelines.md#upstream-marketing-blog-guidelines) for support on these posts).
- The components of Kubernetes are purposely modular, so tools that use existing integration points like CNI and CSI are on topic.
- Posts about other CNCF projects may or may not be on topic. We recommend asking the blog team before submitting a draft.
- Many CNCF projects have their own blog. These are often a better choice for posts. There are times of major feature or milestone for a CNCF project that users would be interested in reading on the Kubernetes blog.
-->
- 博客内容应该对 Kubernetes 用户有用。
- 与参与 Kubernetes SIGs 活动相关，或者与这类活动的结果相关的主题通常是切题的。
请参考[上游推广团队](https://github.com/kubernetes/community/blob/master/communication/marketing-team/blog-guidelines.md#upstream-marketing-blog-guidelines)的工作以获得对此类博文的支持。
- Kubernetes 的组件都有意设计得模块化，因此使用类似 CNI、CSI 等集成点的工具
通常都是切题的。
- 关于其他 CNCF 项目的博客可能切题也可能不切题。
我们建议你在提交草稿之前与博客团队联系。
- 很多 CNCF 项目有自己的博客。这些博客通常是更好的选择。
有些时候，某个 CNCF 项目的主要功能特性或者里程碑的变化可能是用户有兴趣在
Kubernetes 博客上阅读的内容。
<!--
- Blog posts should be original content
- The official blog is not for repurposing existing content from a third party as new content.
- The [license](https://github.com/kubernetes/website/blob/master/LICENSE) for the blog does allow commercial use of the content for commercial purposes, just not the other way around.
- Blog posts should aim to be future proof
- Given the development velocity of the project, we want evergreen content that won't require updates to stay accurate for the reader.
- It can be a better choice to add a tutorial or update official documentation than to write a high level overview as a blog post.
- Consider concentrating the long technical content as a call to action of the blog post, and focus on the problem space or why readers should care.
-->
- 博客文章应该是原创内容。
- 官方博客的目的不是将某第三方已发表的内容重新作为新内容发表。
- 博客的[授权协议](https://github.com/kubernetes/website/blob/master/LICENSE)
的确允许出于商业目的来使用博客内容；但并不是所有可以商用的内容都适合在这里发表。
- 博客文章的内容应该在一段时间内不过期。
- 考虑到项目的开发速度，我们希望读者看到的是不必更新就能保持长期准确的内容。
- 有时候，在官方文档中添加一个教程或者进行内容更新都是比博客更好的选择。
- 可以考虑在博客文章中将较长技术内容的重点放在鼓励读者自行尝试上，或者
放在问题域本身或者为什么读者应该关注某个话题上。
<!--
### Technical Considerations for submitting a blog post
Submissions need to be in Markdown format to be used by the [Hugo](https://gohugo.io/) generator for the blog. There are [many resources available](https://gohugo.io/documentation/) on how to use this technology stack.
We recognize that this requirement makes the process more difficult for less-familiar folks to submit, and we're constantly looking at solutions to lower this bar. If you have ideas on how to lower the barrier, please volunteer to help out.
-->
### 提交博客的技术考虑
所提交的内容应该是 Markdown 格式的，以便能够被[Hugo](https://gohugo.io/) 生成器来处理。
关于如何使用相关技术，有[很多可用的资源](https://gohugo.io/documentation/)。
我们知道这一需求可能给那些对此过程不熟悉的朋友们带来不便，
我们也一直在寻找降低难度的解决方案。
如果你有降低难度的好主意，请自荐帮忙。
<!--
The SIG Docs [blog subproject](https://github.com/kubernetes/community/tree/master/sig-docs/blog-subproject) manages the review process for blog posts. For more information, see [Submit a post](https://github.com/kubernetes/community/tree/master/sig-docs/blog-subproject#submit-a-post).
To submit a blog post follow these directions:
-->
SIG Docs [博客子项目](https://github.com/kubernetes/community/tree/master/sig-docs/blog-subproject) 负责管理博客的评阅过程。
更多信息可参考[提交博文](https://github.com/kubernetes/community/tree/master/sig-docs/blog-subproject#submit-a-post)。
要提交博文，你可以遵从以下指南：
<!--
To submit a blog post, you can either:
- [Open a pull request](/docs/contribute/new-content/new-content/#fork-the-repo) with a new blog post. New blog posts go under the [`content/en/blog/_posts`](https://github.com/kubernetes/website/tree/master/content/en/blog/_posts) directory.
- Use the
[Kubernetes blog submission form](https://docs.google.com/forms/d/e/1FAIpQLSdMpMoSIrhte5omZbTE7nB84qcGBy8XnnXhDFoW0h7p2zwXrw/viewform)
- [Open a pull request](/docs/contribute/new-content/new-content/#fork-the-repo) with a new blog post. Create new blog posts in the [`content/en/blog/_posts`](https://github.com/kubernetes/website/tree/master/content/en/blog/_posts) directory.
- Ensure that your blog post follows the correct naming conventions and the following frontmatter (metadata) information:
If you open a pull request, ensure that your blog post follows the correct naming conventions and frontmatter information:
- The markdown file name must follow the format `YYY-MM-DD-Your-Title-Here.md`. For example, `2020-02-07-Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md`.
- The front matter must include the following:
- The Markdown file name must follow the format `YYYY-MM-DD-Your-Title-Here.md`. For example, `2020-02-07-Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md`.
- Do **not** include dots in the filename. A name like `2020-01-01-whats-new-in-1.19.md` causes failures during a build.
- The front matter must include the following:
-->
要提交博文，你可以：
- 使用 [Kubernetes 博客提交表单](https://docs.google.com/forms/d/e/1FAIpQLSdMpMoSIrhte5omZbTE7nB84qcGBy8XnnXhDFoW0h7p2zwXrw/viewform)
- [发起一个包含博文的 PR](/zh/docs/contribute/new-content/new-content/#fork-the-repo)。
- [发起一个包含博文的 PR](/zh/docs/contribute/new-content/open-a-pr/#fork-the-repo)。
新博文要创建于 [`content/en/blog/_posts`](https://github.com/kubernetes/website/tree/master/content/en/blog/_posts) 目录下。
如果你要发起一个 PR，请确保所提交的博文遵从正确的命名规范和前言信息：
- 确保你的博文遵从合适的命名规范，并带有下面的引言（元数据）信息：
- Markdown 文件名必须遵从 `YYY-MM-DD-Your-Title-Here.md` 格式。
例如，`2020-02-07-Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md`.
- 前言部分必须包含以下内容：
- Markdown 文件名必须符合格式 `YYYY-MM-DD-Your-Title-Here.md`。
例如，`2020-02-07-Deploying-External-OpenStack-Cloud-Provider-With-Kubeadm.md`。
- **不要**在文件名中包含多余的句点。类似 `2020-01-01-whats-new-in-1.19.md`
这类文件名会导致文件无法正确打开。
- 引言部分必须包含以下内容：
```yaml
---
layout: blog
title: "Your Title Here"
date: YYYY-MM-DD
slug: text-for-URL-link-here-no-spaces
---
```
<!--
```yaml
---
layout: blog
title: "Your Title Here"
date: YYYY-MM-DD
slug: text-for-URL-link-here-no-spaces
---
```
- The first or initial commit message should be a short summary of the work being done and should stand alone as a description of the blog post. Please note that subsequent edits to your blog will be squashed into this main commit, so it should be as useful as possible.
- Examples of a good commit message:
- _Add blog post on the foo kubernetes feature_
- _blog: foobar announcement_
- Examples of bad commit message:
- _Add blog post_
- _._
- _initial commit_
- _draft post_
- The blog team will then review your PR and give you comments on things you might need to fix. After that the bot will merge your PR and your blog post will be published.
-->
```yaml
---
layout: blog
title: "博文标题"
date: YYYY-MM-DD
slug: text-for-URL-link-here-no-spaces
---
```
- 第一个或者最初的提交的描述信息中应该包含一个所作工作的简单摘要，
并作为整个博文的一个独立描述。
请注意，对博文的后续修改编辑都会最终合并到此主提交中，所以此提交的描述信息
应该尽量有用。
- 较好的提交消息（Commit Message）示例：
- _Add blog post on the foo kubernetes feature_
- _blog: foobar announcement_
- 较差的提交消息示例：
- _Add blog post_
- _._
- _initial commit_
- _draft post_
- 博客团队会对 PR 内容进行评阅，为你提供一些评语以便修订。
之后，机器人会将你的博文合并并发表。
<!--
## Submit a case study
@@ -104,5 +222,3 @@ Kubernetes 市场化团队和 {{< glossary_tooltip text="CNCF" term_id="cncf" >}
参考[案例分析指南](https://github.com/cncf/foundation/blob/master/case-study-guidelines.md)
根据指南中的注意事项提交你的 PR 请求。
## {{% heading "whatsnext" %}}
content/zh/docs/contribute/participate/pr-wranglers.md
+154
View File
@@ -0,0 +1,154 @@
---
title: PR 管理者
content_type: concept
weight: 20
---
<!--
title: PR wranglers
content_type: concept
weight: 20
-->
<!-- overview -->
<!--
SIG Docs [approvers](/docs/contribute/participating/roles-and-responsibilites/#approvers) take week-long shifts [managing pull requests](https://github.com/kubernetes/website/wiki/PR-Wranglers) for the repository.
This section covers the duties of a PR wrangler. For more information on giving good reviews, see [Reviewing changes](/docs/contribute/review/).
-->
SIG Docs 的[批准人（Approvers）](/zh/docs/contribute/participating/#approvers)们每周轮流负责
[管理仓库的 PRs](https://github.com/kubernetes/website/wiki/PR-Wranglers)。
本节介绍 PR 管理者的职责。关于如何提供较好的评审意见，可参阅
[评审变更](/zh/docs/contribute/review/).
<!-- body -->
<!--
## Duties
Each day in a week-long shift as PR Wrangler:
- Triage and tag incoming issues daily. See [Triage and categorize issues](/docs/contribute/review/for-approvers/#triage-and-categorize-issues) for guidelines on how SIG Docs uses metadata.
- Review [open pull requests](https://github.com/kubernetes/website/pulls) for quality and adherence to the [Style](/docs/contribute/style/style-guide/) and [Content](/docs/contribute/style/content-guide/) guides.
- Start with the smallest PRs (`size/XS`) first, and end with the largest (`size/XXL`). Review as many PRs as you can.
- Make sure PR contributors sign the [CLA](https://github.com/kubernetes/community/blob/master/CLA.md).
- Use [this](https://github.com/zparnold/k8s-docs-pr-botherer) script to remind contributors that haven’t signed the CLA to do so.
- Provide feedback on changes and ask for technical reviews from members of other SIGs.
- Provide inline suggestions on the PR for the proposed content changes.
- If you need to verify content, comment on the PR and request more details.
- Assign relevant `sig/` label(s).
- If needed, assign reviewers from the `reviewers:` block in the file's front matter.
- Use the `/approve` comment to approve a PR for merging. Merge the PR when ready.
- PRs should have a `/lgtm` comment from another member before merging.
- Consider accepting technically accurate content that doesn't meet the [style guidelines](/docs/contribute/style/style-guide/). Open a new issue with the label `good first issue` to address style concerns.
-->
## 职责 {#duties}
在为期一周的轮值期内，PR 管理者要：
- 每天对新增的 Issues 判定和打标签。参见
[对 Issues 进行判定和分类](/zh/docs/contribute/review/for-approvers/#triage-and-categorize-issues)
以了解 SIG Docs 如何使用元数据的详细信息。
- 检查[悬决的 PR](https://github.com/kubernetes/website/pulls) 的质量并确保它们符合
[样式指南](/zh/docs/contribute/style/style-guide/)和
[内容指南](/zh/docs/contribute/style/content-guide/)要求。
- 首先查看最小的 PR（`size/XS`），然后逐渐扩展到最大的
PR（`size/XXL`），尽可能多地评审 PR。
- 确保贡献者完成 [CLA](https://github.com/kubernetes/community/blob/master/CLA.md) 签署。
- 使用[此脚本](https://github.com/zparnold/k8s-docs-pr-botherer)自动提醒尚未签署
CLA 的贡献者签署 CLA。
- 针对提供提供反馈，请求其他 SIG 的成员进行技术审核。
- 为 PR 所建议的内容更改提供就地反馈。
- 如果您需要验证内容，请在 PR 上发表评论并要求贡献者提供更多细节。
- 设置相关的 `sig/` 标签。
- 如果需要，从文件开头的 `reviewers:` 块中指派评阅人。
- 使用 `/approve` 评论来批准可以合并的 PR，在 PR 就绪时将其合并。
- PR 在被合并之前，应该有来自其他成员的 `/lgtm` 评论。
- 可以考虑接受那些技术上准确，但文风上不满足
[风格指南](/zh/docs/contribute/style/style-guide/)要求的 PR。
可以登记一个新的 Issue 来解决文档风格问题，并将其标记为 `good first issue`。
<!--
### Helpful GitHub queries for wranglers
The following queries are helpful when wrangling.
After working through these queries, the remaining list of PRs to review is usually small.
These queries exclude localization PRs. All queries are against the main branch except the last one.
-->
### 对于管理人有用的 GitHub 查询
执行管理操作时，以下查询很有用。完成以下这些查询后，剩余的要审阅的 PR 列表通常很小。
这些查询都不包含本地化的 PR，并仅包含主分支上的 PR（除了最后一个查询）。
<!--
- [No CLA, not eligible to merge](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3A%22cncf-cla%3A+no%22+-label%3Ado-not-merge+label%3Alanguage%2Fen):
Remind the contributor to sign the CLA. If both the bot and a human have reminded them, close
the PR and remind them that they can open it after signing the CLA.
**Do not review PRs whose authors have not signed the CLA!**
- [Needs LGTM](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-label%3Algtm+):
Lists PRs that need an LGTM from a member. If the PR needs technical review, loop in one of the reviewers suggested by the bot. If the content needs work, add suggestions and feedback in-line.
- [Has LGTM, needs docs approval](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+label%3Algtm):
Lists PRs that need an `/approve` comment to merge.
- [Quick Wins](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+base%3Amaster+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3A%22cncf-cla%3A+yes%22+label%3A%22size%2FXS%22+label%3A%22language%2Fen%22+): Lists PRs against the main branch with no clear blockers. (change "XS" in the size label as you work through the PRs [XS, S, M, L, XL, XXL]).
- [Not against the main branch](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-base%3Amaster): If the PR is against a `dev-` branch, it's for an upcoming release. Assign the [docs release manager](https://github.com/kubernetes/sig-release/tree/master/release-team#kubernetes-release-team-roles) using: `/assign @<manager's_github-username>`. If the PR is against an old branch, help the author figure out whether it's targeted against the best branch.
-->
- [未签署 CLA，不可合并的 PR](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3A%22cncf-cla%3A+no%22+-label%3Ado-not-merge+label%3Alanguage%2Fen)：
提醒贡献者签署 CLA。如果机器人和审阅者都已经提醒他们，请关闭 PR，并提醒他们在签署 CLA 后可以重新提交。
**在作者没有签署 CLA 之前，不要审阅他们的 PR！**
- [需要 LGTM](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-label%3Algtm+)：
列举需要来自成员的 LGTM 评论的 PR。
如果需要技术审查，请告知机器人所建议的审阅者。
如果 PR 继续改进，就地提供更改建议或反馈。
- [已有 LGTM标签，需要 Docs 团队批准](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+label%3Algtm)：
列举需要 `/approve` 评论来合并的 PR。
- [快速批阅](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+base%3Amaster+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3A%22cncf-cla%3A+yes%22+label%3A%22size%2FXS%22+label%3A%22language%2Fen%22+)：
列举针对主分支的、没有明确合并障碍的 PR。
在浏览 PR 时，可以将 "XS" 尺寸标签更改为 "S"、"M"、"L"、"XL"、"XXL"。
- [非主分支的 PR](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-base%3Amaster)：
如果 PR 针对 `dev-` 分支，则表示它适用于即将发布的版本。
请添加带有 `/assign @<负责人的 github 账号>`，将其指派给
[发行版本负责人](https://github.com/kubernetes/sig-release/tree/master/release-team)。
如果 PR 是针对旧分支，请帮助 PR 作者确定是否所针对的是最合适的分支。
<!--
### When to close Pull Requests
Reviews and approvals are one tool to keep our PR queue short and current. Another tool is closure.
Close PRs where:
- The author hasn't signed the CLA for two weeks.
Authors can reopen the PR after signing the CLA. This is a low-risk way to make sure nothing gets merged without a signed CLA.
- The author has not responded to comments or feedback in 2 or more weeks.
Don't be afraid to close pull requests. Contributors can easily reopen and resume works in progress. Often a closure notice is what spurs an author to resume and finish their contribution.
To close a pull request, leave a `/close` comment on the PR.
-->
### 何时关闭 PR {#when-to-close-pull-requests}
审查和批准是缩短和更新我们的 PR 队列的一种方式；另一种方式是关闭 PR。
当以下条件满足时，可以关闭 PR：
- 作者两周内未签署 CLA。
PR 作者可以在签署 CLA 后重新打开 PR，因此这是确保未签署 CLA 的 PR 不会被合并的一种风险较低的方法。
- 作者在两周或更长时间内未回复评论或反馈。
不要害怕关闭 PR。贡献者可以轻松地重新打开并继续工作。
通常，关闭通知会激励作者继续完成其贡献。
要关闭 PR，请在 PR 上输入 `/close` 评论。
<!--
The [`fejta-bot`](https://github.com/fejta-bot) bot marks issues as stale after 90 days of inactivity. After 30 more days it marks issues as rotten and closes them. PR wranglers should close issues after 14-30 days of inactivity.
-->
{{< note >}}
一个名为 [`fejta-bot`](https://github.com/fejta-bot) 的自动服务会在 Issue 停滞 90
天后自动将其标记为过期；然后再等 30 天，如果仍然无人过问，则将其关闭。
PR 管理者应该在 issues 处于无人过问状态 14-30 天后关闭它们。
{{< /note >}}
content/zh/docs/contribute/participate/roles-and-responsibilties.md
+13 -5
View File
@@ -133,7 +133,7 @@ After submitting at least 5 substantial pull requests and meeting the other [req
2. Open a GitHub issue in the [`kubernetes/org`](https://github.com/kubernetes/org/) repository. Use the **Organization Membership Request** issue template.
-->
1. 找到两个[评审人](#reviewers)或[批准人](#approvers)为你的成员身份提供
[担保](/docs/contribute/advanced#sponsor-a-new-contributor)。
[担保](/zh/docs/contribute/advanced#sponsor-a-new-contributor)。
通过 [Kubernetes Slack 上的 #sig-docs 频道](https://kubernetes.slack.com) 或者
[SIG Docs 邮件列表](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)
@@ -277,7 +277,8 @@ in the `kubernetes/website` repository.
2. Assign the PR to one or more SIG-Docs approvers (user names listed under `sig-docs-{language}-owners`).
If approved, a SIG Docs lead adds you to the appropriate GitHub team. Once added, [K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home) assigns and suggests you as a reviewer on new pull requests.
If approved, a SIG Docs lead adds you to the appropriate GitHub team. Once added,
[@k8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home) assigns and suggests you as a reviewer on new pull requests.
-->
1. 发起 PR，将你的 GitHub 用户名添加到 `kubernetes/website` 仓库中
[OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS)
@@ -291,7 +292,7 @@ If approved, a SIG Docs lead adds you to the appropriate GitHub team. Once added
下列举的用户名）。
请求被批准之后，SIG Docs Leads 之一会将你添加到合适的 GitHub 团队。
一旦添加完成， [K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home)
一旦添加完成， [@k8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home)
会在处理未来的 PR 时，将 PR 指派给你或者建议你来评审某 PR。
<!--
@@ -354,7 +355,7 @@ Approvers and SIG Docs leads are the only ones who can merge pull requests into
不小心的合并可能会破坏整个站点。在执行合并操作时，务必小心。
{{< /warning >}}
- 确保所提议的变更满足[贡献指南](/docs/contribute/style/content-guide/#contributing-content)要求
- 确保所提议的变更满足[贡献指南](/zh/docs/contribute/style/content-guide/#contributing-content)要求
如果有问题或者疑惑，可以根据需要请他人帮助评审。
@@ -366,7 +367,7 @@ Approvers and SIG Docs leads are the only ones who can merge pull requests into
- 参与 [PR 管理者轮值排班](https://github.com/kubernetes/website/wiki/PR-Wranglers)
执行时长为一周的 PR 管理。SIG Docs 期望所有批准人都参与到此轮值工作中。
更多细节可参见[做一周的 PR 管理者](/docs/contribute/advanced#be-the-pr-wrangler-for-a-week)。
更多细节可参见[做一周的 PR 管理者](/zh/docs/contribute/participate/pr-wranglers/)。
<!--
### Becoming an approver
@@ -407,3 +408,10 @@ If approved, a SIG Docs lead adds you to the appropriate GitHub team. Once added
一旦添加完成， [K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home)
会在处理未来的 PR 时，将 PR 指派给你或者建议你来评审某 PR。
## {{% heading "whatsnext" %}}
<!--
- Read about [PR wrangling](/docs/contribute/participating/pr-wranglers), a role all approvers take on rotation.
-->
- 阅读[管理 PR](/zh/docs/contribute/participate/pr-wranglers/)，了解所有批准人轮值的一个角色。
content/zh/docs/contribute/style/content-guide.md
+1 -1
View File
@@ -60,7 +60,7 @@ Kubernetes 网站（包括其文档）源代码位于
在 `kubernetes/website/content/<语言代码>/docs` 目录下, 绝大多数 Kubernetes
文档都是特定于 [Kubernetes 项目](https://github.com/kubernetes/kubernetes)的。
## 可以发布的内容 {#whats-allowed}
## 可以发布的内容 {#what-s-allowed}
只有当以下条件满足时，Kuberentes 文档才允许第三方项目的内容：
content/zh/docs/reference/_index.md
+29 -43
View File
@@ -7,7 +7,6 @@ content_type: concept
---
<!--
---
title: Reference
approvers:
- chenopis
@@ -15,7 +14,6 @@ linkTitle: "Reference"
main_menu: true
weight: 70
content_type: concept
---
-->
<!-- overview -->
@@ -25,20 +23,8 @@ This section of the Kubernetes documentation contains references.
-->
这是 Kubernetes 文档的参考部分。
<!-- body -->
## 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 Reference
@@ -50,16 +36,15 @@ This section of the Kubernetes documentation contains references.
* [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 Client Libraries
@@ -73,13 +58,15 @@ client libraries:
- [Kubernetes Java client library](https://github.com/kubernetes-client/java)
- [Kubernetes JavaScript client library](https://github.com/kubernetes-client/javascript)
-->
## 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 Reference
@@ -89,16 +76,12 @@ client libraries:
* [kubeadm](/docs/admin/kubeadm/) - CLI tool to easily provision a secure Kubernetes cluster.
* [kubefed](/docs/admin/kubefed/) - CLI tool to help you administrate your federated clusters.
-->
## 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 工具可帮助您管理集群联邦。
<!--
## Config Reference
@@ -108,18 +91,21 @@ client libraries:
* [kube-controller-manager](/docs/admin/kube-controller-manager/) - Daemon that embeds the core control loops shipped with Kubernetes.
* [kube-proxy](/docs/admin/kube-proxy/) - Can do simple TCP/UDP stream forwarding or round-robin TCP/UDP forwarding across a set of back-ends.
* [kube-scheduler](/docs/admin/kube-scheduler/) - Scheduler that manages availability, performance, and capacity.
* [federation-apiserver](/docs/admin/federation-apiserver/) - API server for federated clusters.
* [federation-controller-manager](/docs/admin/federation-controller-manager/) - Daemon that embeds the core control loops shipped with Kubernetes federation.
-->
## 配置参考
## 设计文档
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/) - 一个调度程序，用于管理可用性、性能和容量。
<!--
## Design Docs
An archive of the design docs for Kubernetes functionality. Good starting points are [Kubernetes Architecture](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md) and [Kubernetes Design Overview](https://git.k8s.io/community/contributors/design-proposals).
-->
## 设计文档
Kubernetes 功能的设计文档归档，不妨考虑从 [Kubernetes 架构](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md) 和 [Kubernetes 设计概述](https://git.k8s.io/community/contributors/design-proposals)开始阅读。
content/zh/docs/reference/command-line-tools-reference/kube-controller-manager.md
+1109 -794
View File
File diff suppressed because it is too large Load Diff
content/zh/docs/reference/command-line-tools-reference/kubelet.md
+1 -1
View File
@@ -11,7 +11,7 @@ weight: 28
The kubelet is the primary "node agent" that runs on each node. It can register the node with the apiserver using one of: the hostname; a flag to override the hostname; or specific logic for a cloud provider.
-->
kubelet 是在每个 Node 节点上运行的主要 “节点代理”。它向 apiserver 注册节点时可以使用主机名（hostname）；可以提供用于覆盖主机名的参数；还可以执行特定于某云服务商的逻辑。
kubelet 是在每个 Node 节点上运行的主要 “节点代理”。它可以通过以下方式向 apiserver 进行注册：主机名（hostname）；覆盖主机名的参数；某云服务商的特定逻辑。
<!--
The kubelet works in terms of a PodSpec. A PodSpec is a YAML or JSON object that describes a pod. The kubelet takes a set of PodSpecs that are provided through various mechanisms (primarily through the apiserver) and ensures that the containers described in those PodSpecs are running and healthy. The kubelet doesn't manage containers which were not created by Kubernetes.
content/zh/docs/reference/tools.md
-9
View File
@@ -38,15 +38,6 @@ Kubernetes 包含一些内置工具，可以帮助用户更好的使用 Kubernet
-->
[`kubeadm`](/docs/tasks/tools/install-kubeadm/) 是一个命令行工具，可以用来在物理机、云服务器或虚拟机（目前处于 alpha 阶段）上轻松部署一个安全可靠的 Kubernetes 集群。
## Kubefed
<!--
[`kubefed`](/docs/tasks/federation/set-up-cluster-federation-kubefed/) is the command line tool
to help you administrate your federated clusters.
-->
[`kubefed`](/docs/tasks/federation/set-up-cluster-federation-kubefed/) 是一个命令行工具，可以用来帮助用户管理联邦集群。
## Minikube
<!--
content/zh/docs/setup/production-environment/container-runtimes.md
+234 -22
View File
@@ -41,7 +41,7 @@ Please refer to this link for more information about this issue
我们发现 runc 在运行容器，处理系统文件描述符时存在一个漏洞。
恶意容器可以利用此漏洞覆盖 runc 二进制文件的内容，并以此在主机系统的容器上运行任意的命令。
请参考此链接以获取有关此问题的更多信息 [cve-2019-5736 : runc vulnerability ] (https://access.redhat.com/security/cve/cve-2019-5736)
请参考此链接以获取有关此问题的更多信息 [cve-2019-5736 : runc vulnerability ](https://access.redhat.com/security/cve/cve-2019-5736)
{{< /caution >}}
<!--
@@ -134,7 +134,8 @@ Use the following commands to install Docker on your system:
使用以下命令在您的系统上安装 Docker：
{{< tabs name="tab-cri-docker-installation" >}}
{{< tab name="Ubuntu 16.04+" codelang="bash" >}}
{{% tab name="Ubuntu 16.04+" %}}
<!--
# Install Docker CE
## Set up the repository:
@@ -145,15 +146,19 @@ apt-get update && apt-get install \
### Add Docker’s official GPG key
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add -
-->
```shell
# 安装 Docker CE
## 设置仓库
### 安装软件包以允许 apt 通过 HTTPS 使用存储库
apt-get update && apt-get install \
apt-transport-https ca-certificates curl software-properties-common
```
```shell
### 新增 Docker 的 官方 GPG 秘钥
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add -
```
<!--
### Add Docker apt repository.
add-apt-repository \
@@ -181,15 +186,23 @@ EOF
mkdir -p /etc/systemd/system/docker.service.d
-->
```shell
### 添加 Docker apt 仓库
add-apt-repository \
"deb [arch=amd64] https://download.docker.com/linux/ubuntu \
$(lsb_release -cs) \
stable"
```
```shell
## 安装 Docker CE
apt-get update && apt-get install docker-ce=18.06.2~ce~3-0~ubuntu
apt-get update && apt-get install -y\
containerd.io=1.2.13-2 \
docker-ce=5:19.03.11~3-0~ubuntu-$(lsb_release -cs) \
docker-ce-cli=5:19.03.11~3-0~ubuntu-$(lsb_release -cs)
```
```shell
# 设置 daemon
cat > /etc/docker/daemon.json <<EOF
{
@@ -201,19 +214,23 @@ cat > /etc/docker/daemon.json <<EOF
"storage-driver": "overlay2"
}
EOF
```
```shell
mkdir -p /etc/systemd/system/docker.service.d
```
<!--
# Restart docker.
systemctl daemon-reload
systemctl restart docker
-->
```shell
# 重启 docker.
systemctl daemon-reload
systemctl restart docker
{{< /tab >}}
{{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}}
```
{{% /tab %}}
{{% tab name="CentOS/RHEL 7.4+" %}}
<!--
# Install Docker CE
@@ -252,22 +269,31 @@ EOF
mkdir -p /etc/systemd/system/docker.service.d
-->
```shell
# 安装 Docker CE
## 设置仓库
### 安装所需包
yum install yum-utils device-mapper-persistent-data lvm2
```
```shell
### 新增 Docker 仓库。
yum-config-manager \
--add-repo \
https://download.docker.com/linux/centos/docker-ce.repo
```
```shell
## 安装 Docker CE.
yum update && yum install docker-ce-18.06.2.ce
```
```shell
## 创建 /etc/docker 目录。
mkdir /etc/docker
```
```shell
# 设置 daemon。
cat > /etc/docker/daemon.json <<EOF
{
@@ -282,24 +308,43 @@ cat > /etc/docker/daemon.json <<EOF
]
}
EOF
```
```shell
mkdir -p /etc/systemd/system/docker.service.d
```
<!--
# Restart Docker
systemctl daemon-reload
systemctl restart docker
-->
```shell
# 重启 Docker
systemctl daemon-reload
systemctl restart docker
{{< /tab >}}
{{< /tabs >}}
```
{{% /tab %}}
{{% /tabs %}}
<!--
If you want the docker service to start on boot, run the following command:
```shell
sudo systemctl enable docker
```
-->
如果你想开机即启动 docker 服务，执行以下命令：
```shell
sudo systemctl enable docker
```
<!--
Refer to the [official Docker installation guides](https://docs.docker.com/engine/installation/)
for more information.
-->
请参阅[官方 Docker 安装指南](https://docs.docker.com/engine/installation/)
来获取更多的信息。
@@ -349,7 +394,113 @@ sysctl --system
```
{{< tabs name="tab-cri-cri-o-installation" >}}
{{< tab name="Ubuntu 16.04" codelang="bash" >}}
{{% tab name="Debian" %}}
<!--
```shell
# Debian Unstable/Sid
echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_Unstable/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_Unstable/Release.key -O- | sudo apt-key add -
```
-->
```shell
# Debian Unstable/Sid
echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_Unstable/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_Unstable/Release.key -O- | sudo apt-key add -
```
<!--
```shell
# Debian Testing
echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_Testing/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_Testing/Release.key -O- | sudo apt-key add -
```
-->
```shell
# Debian Testing
echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_Testing/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_Testing/Release.key -O- | sudo apt-key add -
```
<!--
```shell
# Debian 10
echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_10/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_10/Release.key -O- | sudo apt-key add -
```
-->
```shell
# Debian 10
echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_10/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_10/Release.key -O- | sudo apt-key add -
```
<!--
```shell
# Raspbian 10
echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Raspbian_10/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Raspbian_10/Release.key -O- | sudo apt-key add -
```
-->
```shell
# Raspbian 10
echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Raspbian_10/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Raspbian_10/Release.key -O- | sudo apt-key add -
```
<!--
and then install CRI-O:
```shell
sudo apt-get install cri-o-1.17
```
-->
随后安装 CRI-O:
```shell
sudo apt-get install cri-o-1.17
```
{{% /tab %}}
{{% tab name="Ubuntu 18.04, 19.04 and 19.10" %}}
<!--
```shell
# Configure package repository
. /etc/os-release
sudo sh -c "echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/x${NAME}_${VERSION_ID}/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list"
wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/x${NAME}_${VERSION_ID}/Release.key -O- | sudo apt-key add -
sudo apt-get update
```
-->
```shell
# 配置仓库
. /etc/os-release
sudo sh -c "echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/x${NAME}_${VERSION_ID}/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list"
wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/x${NAME}_${VERSION_ID}/Release.key -O- | sudo apt-key add -
sudo apt-get update
```
<!--
```shell
# Install CRI-O
sudo apt-get install cri-o-1.17
```
-->
```shell
# 安装 CRI-O
sudo apt-get install cri-o-1.17
```
{{% /tab %}}
{{% tab name="Ubuntu 16.04" %}}
<!--
# Install prerequisites
@@ -362,6 +513,7 @@ apt-get update
# Install CRI-O
apt-get install cri-o-1.15
-->
```shell
# 安装必备软件
apt-get update
apt-get install software-properties-common
@@ -371,9 +523,9 @@ apt-get update
# 安装 CRI-O
apt-get install cri-o-1.15
{{< /tab >}}
{{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}}
```
{{% /tab %}}
{{% tab name="CentOS/RHEL 7.4+" codelang="bash" %}}
<!--
# Install prerequisites
@@ -382,19 +534,33 @@ yum-config-manager --add-repo=https://cbs.centos.org/repos/paas7-crio-115-releas
# Install CRI-O
yum install --nogpgcheck cri-o
-->
```shell
# 安装必备软件
yum-config-manager --add-repo=https://cbs.centos.org/repos/paas7-crio-115-release/x86_64/os/
```
```shell
# 安装 CRI-O
yum install --nogpgcheck cri-o
```
{{% /tab %}}
{{% tab name="openSUSE Tumbleweed" %}}
```shell
sudo zypper install cri-o
```
{{% /tab %}}
{{< /tab >}}
{{< /tabs >}}
<!--
### Start CRI-O
```
systemctl daemon-reload
systemctl start crio
```
@@ -407,7 +573,7 @@ for more information.
systemctl start crio
```
请参阅[CRI-O 安装指南](https://github.com/kubernetes-sigs/cri-o#getting-started)
请参阅 [CRI-O 安装指南](https://github.com/kubernetes-sigs/cri-o#getting-started)
来获取更多的信息。
<!--
@@ -471,103 +637,150 @@ sysctl --system
### 安装 containerd
{{< tabs name="tab-cri-containerd-installation" >}}
{{< tab name="Ubuntu 16.04" codelang="bash" >}}
{{% tab name="Ubuntu 16.04" %}}
<!--
```shell
# Install containerd
## Set up the repository
### Install packages to allow apt to use a repository over HTTPS
apt-get update && apt-get install -y apt-transport-https ca-certificates curl software-properties-common
```
```shell
### Add Docker’s official GPG key
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add -
```
```shell
### Add Docker apt repository.
add-apt-repository \
"deb [arch=amd64] https://download.docker.com/linux/ubuntu \
$(lsb_release -cs) \
stable"
```
```shell
## Install containerd
apt-get update && apt-get install -y containerd.io
```
```shell
# Configure containerd
mkdir -p /etc/containerd
containerd config default > /etc/containerd/config.toml
```
-->
```shell
# 安装 containerd
## 设置仓库
### 安装软件包以允许 apt 通过 HTTPS 使用存储库
apt-get update && apt-get install -y apt-transport-https ca-certificates curl software-properties-common
```
```shell
### 安装 Docker 的官方 GPG 密钥
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add -
```
```shell
### 新增 Docker apt 仓库。
add-apt-repository \
"deb [arch=amd64] https://download.docker.com/linux/ubuntu \
$(lsb_release -cs) \
stable"
```
```shell
## 安装 containerd
apt-get update && apt-get install -y containerd.io
```
```shell
# 配置 containerd
mkdir -p /etc/containerd
containerd config default > /etc/containerd/config.toml
```
<!--
```shell
# Restart containerd
systemctl restart containerd
```
-->
```shell
# 重启 containerd
systemctl restart containerd
```
{{< /tab >}}
{{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}}
{{% tab name="CentOS/RHEL 7.4+" %}}
<!--
```shell
# Install containerd
## Set up the repository
### Install required packages
yum install yum-utils device-mapper-persistent-data lvm2
```
```shell
### Add docker repository
yum-config-manager \
--add-repo \
https://download.docker.com/linux/centos/docker-ce.repo
```
```shell
## Install containerd
yum update && yum install containerd.io
```
```shell
# Configure containerd
mkdir -p /etc/containerd
containerd config default > /etc/containerd/config.toml
```
-->
```shell
# 安装 containerd
## 设置仓库
### 安装所需包
yum install yum-utils device-mapper-persistent-data lvm2
```
```shell
### 新增 Docker 仓库
yum-config-manager \
--add-repo \
https://download.docker.com/linux/centos/docker-ce.repo
```
```shell
## 安装 containerd
yum update && yum install containerd.io
```
```shell
# 配置 containerd
mkdir -p /etc/containerd
containerd config default > /etc/containerd/config.toml
```
<!--
```shell
# Restart containerd
systemctl restart containerd
```
-->
```shell
# 重启 containerd
systemctl restart containerd
{{< /tab >}}
```
{{% /tab %}}
{{< /tabs >}}
<!--
```shell
### systemd
To use the `systemd` cgroup driver, set `plugins.cri.systemd_cgroup = true` in `/etc/containerd/config.toml`.
@@ -577,6 +790,7 @@ When using kubeadm, manually configure the
## Other CRI runtimes: frakti
Refer to the [Frakti QuickStart guide](https://github.com/kubernetes/frakti#quickstart) for more information.
```
-->
### systemd
@@ -587,5 +801,3 @@ Refer to the [Frakti QuickStart guide](https://github.com/kubernetes/frakti#quic
## 其他的 CRI 运行时：frakti
请参阅 [Frakti 快速开始指南](https://github.com/kubernetes/frakti#quickstart) 来获取更多的信息。
content/zh/docs/tasks/administer-cluster/declare-network-policy.md
+1 -1
View File
@@ -90,7 +90,7 @@ metadata:
spec:
podSelector:
matchLabels:
run: nginx
app: nginx
ingress:
- from:
- podSelector:
content/zh/docs/tasks/administer-cluster/dns-debugging-resolution.md
+1 -28
View File
@@ -504,7 +504,6 @@ Systemd-resolved 会用一个 stub 文件来覆盖 `/etc/resolv.conf`从而在
kubeadm (>= 1.11) 会自动检测`systemd-resolved`并对应的更改 kubelet 的标签。
<!--
Kubernetes installs do not configure the nodes' `resolv.conf` files to use the
cluster DNS by default, because that process is inherently distribution-specific.
This should probably be implemented eventually.
@@ -522,9 +521,7 @@ If you are using Alpine version 3.3 or earlier as your base image, DNS may not
work properly owing to a known issue with Alpine.
Check [here](https://github.com/kubernetes/kubernetes/issues/30215)
for more information.
-->
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 (Multiple Zone support)
Release 1.3 introduced Cluster Federation support for multi-site Kubernetes
installations. This required some minor (backward-compatible) changes to the
way the Kubernetes cluster DNS server processes DNS queries, to facilitate
the lookup of federated services (which span multiple Kubernetes clusters).
See the [Cluster Federation Administrators' Guide](/docs/concepts/cluster-administration/federation/)
for more details on Cluster Federation and multi-site support.
## -->
## Kubernetes Federation (支持多区域部署)
自从 1.3 版本支持了多个 Kubernetes 的联邦集群后，集群 DNS 服务在处理 DNS 请求时需要有一些微弱的调整 (这是向下兼容的)，从而可以使用跨越多个 Kubernetes 集群的联邦服务。请看 [联邦集群管理向导](/docs/concepts/cluster-administration/federation/) 获取更多关于联邦集群和多点支持的信息。
<!--
## References
- [DNS for Services and Pods](/docs/concepts/services-networking/dns-pod-service/)
@@ -557,10 +536,7 @@ for more details on Cluster Federation and multi-site support.
## What's next
- [Autoscaling the DNS Service in a Cluster](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/).
## -->
-->
## 参考
@@ -572,6 +548,3 @@ for more details on Cluster Federation and multi-site support.
- [集群里自动伸缩 DNS Service](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/).
content/zh/docs/tasks/federation/_index.md
-4
View File
@@ -1,4 +0,0 @@
---
title: "联邦 - 在多个集群上运行一个应用"
weight: 120
---
content/zh/docs/tasks/federation/administer-federation/_index.md
-4
View File
@@ -1,4 +0,0 @@
---
title: "管理联邦控制平面"
weight: 160
---
content/zh/docs/tasks/federation/administer-federation/configmap.md
-148
View File
@@ -1,148 +0,0 @@
---
title: 联邦 ConfigMap
content_type: task
---
<!--
---
title: Federated ConfigMap
content_type: task
---
-->
<!-- overview -->
{{< deprecationfilewarning >}}
{{< include "federation-deprecation-warning-note.md" >}}
{{< /deprecationfilewarning >}}
<!--
This guide explains how to use ConfigMaps in a Federation control plane.
Federated ConfigMaps are very similar to the traditional [Kubernetes
ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/) and provide the same functionality.
Creating them in the federation control plane ensures that they are synchronized
across all the clusters in federation.
-->
本指南介绍如何在联邦控制平面中使用 ConfigMap。
联邦 ConfigMap 与传统 [Kubernetes
ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) 非常相似且提供相同的功能。
在联邦控制平面中创建它们可以确保它们在联邦的所有集群中同步。
## {{% heading "prerequisites" %}}
* {{< include "federated-task-tutorial-prereqs.md" >}}
<!--
* You should also have a basic
[working knowledge of Kubernetes](/docs/tutorials/kubernetes-basics/) in
general and [ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/) in particular.
-->
* 通常我们还期望您拥有基本的 [Kubernetes 应用知识](/docs/tutorials/kubernetes-basics/)，
特别是 [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) 相关的应用知识。
<!-- steps -->
<!--
## Creating a Federated ConfigMap
The API for Federated ConfigMap is 100% compatible with the
API for traditional Kubernetes ConfigMap. You can create a ConfigMap by sending
a request to the federation apiserver.
You can do that using [kubectl](/docs/user-guide/kubectl/) by running:
``` shell
kubectl --context=federation-cluster create -f myconfigmap.yaml
```
The `--context=federation-cluster` flag tells kubectl to submit the
request to the Federation apiserver instead of sending it to a Kubernetes
cluster.
Once a Federated ConfigMap is created, the federation control plane will create
a matching ConfigMap in all underlying Kubernetes clusters.
You can verify this by checking each of the underlying clusters, for example:
``` shell
kubectl --context=gce-asia-east1a get configmap myconfigmap
```
The above assumes that you have a context named 'gce-asia-east1a'
configured in your client for your cluster in that zone.
These ConfigMaps in underlying clusters will match the Federated 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 相匹配。
<!--
## Updating a Federated ConfigMap
You can update a Federated ConfigMap as you would update a Kubernetes
ConfigMap; however, for a Federated ConfigMap, you must send the request to
the federation apiserver instead of sending it to a specific Kubernetes cluster.
The federation control plane ensures that whenever the Federated ConfigMap is
updated, it updates the corresponding ConfigMaps in all underlying clusters to
match it.
-->
## 更新联邦 ConfigMap
您可以像更新 Kubernetes ConfigMap 一样更新联邦 ConfigMap。
但是对于联邦 ConfigMap，您必须发送请求到联邦 apiserver 而不是某个特定的 Kubernetes 集群。
联邦控制平面会确保每当联邦 ConfigMap 更新时，它会更新所有底层集群中的 ConfigMap 来和更新后的内容保持一致。
<!--
## Deleting a Federated ConfigMap
You can delete a Federated ConfigMap as you would delete a Kubernetes
ConfigMap; however, for a Federated ConfigMap, you must send the request to
the federation apiserver instead of sending it to a specific Kubernetes cluster.
For example, you can do that using kubectl by running:
```shell
kubectl --context=federation-cluster delete configmap
```
-->
## 删除联邦 ConfigMap
您可以像删除 Kubernetes ConfigMap 一样删除联邦 ConfigMap。
但是，对于联邦 ConfigMap，您必须发送请求到联邦 apiserver 而不是某个特定的 Kubernetes 集群。
例如，您可以使用 kubectl 运行下面的命令来删除联邦 ConfigMap：
```shell
kubectl --context=federation-cluster delete configmap
```
{{< note >}}
<!--
Deleting a Federated ConfigMap does not delete the corresponding ConfigMaps from underlying clusters. You must delete the underlying ConfigMaps manually.
-->
要注意的是这时删除联邦 ConfigMap 并不会删除底层集群中对应的 ConfigMap。您必须自己手动删除底层集群中的 ConfigMap。
{{< /note >}}
content/zh/docs/tasks/federation/administer-federation/daemonset.md
-136
View File
@@ -1,136 +0,0 @@
---
title: 联邦 DaemonSet
content_type: task
---
<!--
---
title: Federated DaemonSet
content_type: task
---
-->
<!-- overview -->
{{< deprecationfilewarning >}}
{{< include "federation-deprecation-warning-note.md" >}}
{{< /deprecationfilewarning >}}
<!--
This guide explains how to use DaemonSets in a federation control plane.
DaemonSets in the federation control plane ("Federated Daemonsets" in
this guide) are very similar to the traditional Kubernetes
[DaemonSets](/docs/concepts/workloads/controllers/daemonset/) and provide the same functionality.
Creating them in the federation control plane ensures that they are synchronized
across all the clusters in federation.
-->
本指南说明了如何在联邦控制平面中使用 DaemonSet。
联邦控制平面中的 DaemonSet（在本指南中称为 “联邦 DaemonSet”）与传统的 Kubernetes [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) 非常类似，并提供相同的功能。在联邦控制平面中创建联邦 DaemonSet 可以确保它们同步到联邦的所有集群中。
## {{% heading "prerequisites" %}}
* {{< include "federated-task-tutorial-prereqs.md" >}}
<!--
* You should also have a basic
[working knowledge of Kubernetes](/docs/tutorials/kubernetes-basics/) in
general and [DaemonSets](/docs/concepts/workloads/controllers/daemonset/) in particular.
-->
* 你还应该具备基本的 [Kubernetes 应用知识](/docs/tutorials/kubernetes-basics/)，特别是 [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) 相关的应用知识。
<!-- steps -->
<!--
## Creating a Federated Daemonset
The API for Federated Daemonset is 100% compatible with the
API for traditional Kubernetes DaemonSet. You can create a DaemonSet by sending
a request to the federation apiserver.
You can do that using [kubectl](/docs/user-guide/kubectl/) by running:
``` shell
kubectl --context=federation-cluster create -f mydaemonset.yaml
```
The `--context=federation-cluster` flag tells kubectl to submit the
request to the Federation apiserver instead of sending it to a Kubernetes
cluster.
Once a Federated Daemonset is created, the federation control plane will create
a matching DaemonSet in all underlying Kubernetes clusters.
You can verify this by checking each of the underlying clusters, for example:
``` shell
kubectl --context=gce-asia-east1a get daemonset mydaemonset
```
The above assumes that you have a context named 'gce-asia-east1a'
configured in your client for your cluster in that zone.
-->
## 创建联邦 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’ 的上下文。
<!--
## Updating a Federated Daemonset
You can update a Federated Daemonset as you would update a Kubernetes
DaemonSet; however, for a Federated Daemonset, you must send the request to
the federation apiserver instead of sending it to a specific Kubernetes cluster.
The federation control plane ensures that whenever the Federated Daemonset is
updated, it updates the corresponding DaemonSets in all underlying clusters to
match it.
-->
## 更新联邦 Daemonset
您可以像更新 Kubernetes Daemonset 一样更新联邦 Daemonset。但是，对于联邦 Daemonset，您必须发送请求到联邦 apiserver 而不是某个特定的 Kubernetes 集群。联邦控制平面会确保每当联邦 Daemonset 更新时，它会更新所有底层集群中的 Daemonset 来和更新后的内容保持一致。
<!--
## Deleting a Federated Daemonset
You can delete a Federated Daemonset as you would delete a Kubernetes
DaemonSet; however, for a Federated Daemonset, you must send the request to
the federation apiserver instead of sending it to a specific Kubernetes cluster.
For example, you can do that using kubectl by running:
```shell
kubectl --context=federation-cluster delete daemonset mydaemonset
```
-->
## 删除联邦 Daemonset
您可以像删除 Kubernetes Daemonset 一样删除联邦 Daemonset。但是，对于联邦 Daemonset，您必须发送请求到联邦 apiserver 而不是某个特定的 Kubernetes 集群。
例如，您可以使用 kubectl 运行下面的命令来删除联邦 Daemonset：
```shell
kubectl --context=federation-cluster delete daemonset mydaemonset
```
content/zh/docs/tasks/federation/administer-federation/deployment.md
-177
View File
@@ -1,177 +0,0 @@
---
title: 联邦 Deployment
content_type: task
---
<!--
---
title: Federated Deployment
content_type: task
---
-->
<!-- overview -->
{{< deprecationfilewarning >}}
{{< include "federation-deprecation-warning-note.md" >}}
{{< /deprecationfilewarning >}}
<!--
This guide explains how to use Deployments in the Federation control plane.
Deployments in the federation control plane (referred to as "Federated Deployments" in
this guide) are very similar to the traditional [Kubernetes
Deployment](/docs/concepts/workloads/controllers/deployment/) and provide the same functionality.
Creating them in the federation control plane ensures that the desired number of
replicas exist across the registered clusters.
-->
本指南说明了如何在联邦控制平面中使用 Deployment。
联邦控制平面中的 Deployment（在本指南中称为 “联邦 Deployment”）与传统的 [Kubernetes
Deployment](/docs/concepts/workloads/controllers/deployment/) 非常类似，并提供相同的功能。在联邦控制平面中创建联邦 Deployment 确保所需的副本数存在于注册的群集中。
{{< feature-state for_k8s_version="1.5" state="alpha" >}}
<!--
Some features
(such as full rollout compatibility) are still in development.
-->
一些特性（例如完整的 rollout 兼容性）仍在开发中。
## {{% heading "prerequisites" %}}
* {{< include "federated-task-tutorial-prereqs.md" >}}
<!--
* You should also have a basic
[working knowledge of Kubernetes](/docs/tutorials/kubernetes-basics/) in
general and [Deployments](/docs/concepts/workloads/controllers/deployment/) in particular.
-->
* 您还应当拥有基本的 [Kubernetes 应用知识](/docs/tutorials/kubernetes-basics/)，特别是在 [Deployments](/docs/concepts/workloads/controllers/deployment/) 方面。
<!-- steps -->
<!--
## Creating a Federated Deployment
The API for Federated Deployment is compatible with the
API for traditional Kubernetes Deployment. You can create a Deployment by sending
a request to the federation apiserver.
You can do that using [kubectl](/docs/user-guide/kubectl/) by running:
``` shell
kubectl --context=federation-cluster create -f mydeployment.yaml
```
The `--context=federation-cluster` flag tells kubectl to submit the
request to the Federation apiserver instead of sending it to a Kubernetes
cluster.
Once a Federated Deployment is created, the federation control plane will create
a Deployment in all underlying Kubernetes clusters.
You can verify this by checking each of the underlying clusters, for example:
``` shell
kubectl --context=gce-asia-east1a get deployment mydep
```
The above assumes that you have a context named 'gce-asia-east1a'
configured in your client for your cluster in that zone.
These Deployments in underlying clusters will match the federation Deployment
_except_ in the number of replicas and revision-related annotations.
Federation control plane ensures that the
sum of replicas in each cluster combined matches the desired number of replicas in the
Federated 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 中请求的副本数量匹配。
<!--
### Spreading Replicas in Underlying Clusters
By default, replicas are spread equally in all the underlying clusters. For example:
if you have 3 registered clusters and you create a Federated Deployment with
`spec.replicas = 9`, then each Deployment in the 3 clusters will have
`spec.replicas=3`.
To modify the number of replicas in each cluster, you can specify
[FederatedReplicaSetPreference](https://github.com/kubernetes/federation/blob/{{< param "githubbranch" >}}/apis/federation/types.go)
as an annotation with key `federation.kubernetes.io/deployment-preferences`
on Federated 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`。
<!--
## Updating a Federated Deployment
You can update a Federated Deployment as you would update a Kubernetes
Deployment; however, for a Federated Deployment, you must send the request to
the federation apiserver instead of sending it to a specific Kubernetes cluster.
The federation control plane ensures that whenever the Federated Deployment is
updated, it updates the corresponding Deployments in all underlying clusters to
match it. So if the rolling update strategy was chosen then the underlying
cluster will do the rolling update independently and `maxSurge` and `maxUnavailable`
will apply only to individual clusters. This behavior may change in the future.
If your update includes a change in number of replicas, the federation
control plane will change the number of replicas in underlying clusters to
ensure that their sum remains equal to the number of desired replicas in
Federated Deployment.
-->
## 更新联邦 Deployment
您可以像更新 Kubernetes Deployment 一样更新联邦 Deployment。但是，对于联邦 Deployment，您必须发送请求到联邦 apiserver 而不是某个特定的 Kubernetes 集群。联邦控制平面会确保每当联邦 Deployment 更新时，它会更新所有底层集群中相应的 Deployment 来和更新后的内容保持一致。 所以如果（在联邦 Deployment 中）选择了滚动更新，那么底层集群会独立地进行滚动更新，并且联邦 Deployment 中的 `maxSurge` 和 `maxUnavailable` 只会应用于独立的集群中。将来这种行为可能会改变。
如果您的更新包括副本数量的变化，联邦控制平面会改变底层集群中的副本数量，以确保它们的总数等于联邦 Deployment 中请求的数量。
<!--
## Deleting a Federated Deployment
You can delete a Federated Deployment as you would delete a Kubernetes
Deployment; however, for a Federated Deployment, you must send the request to
the federation apiserver instead of sending it to a specific Kubernetes cluster.
For example, you can do that using kubectl by running:
```shell
kubectl --context=federation-cluster delete deployment mydep
```
-->
## 删除联邦 Deployment
您可以像删除 Kubernetes Deployment 一样删除联邦 Deployment。但是，对于联邦 Deployment，您必须发送请求到联邦 apiserver 而不是某个特定的 Kubernetes 集群。
例如，您可以使用 kubectl 运行下面的命令来删除联邦 Deployment：
```shell
kubectl --context=federation-cluster delete deployment mydep
```
content/zh/docs/tasks/federation/administer-federation/events.md
-87
View File
@@ -1,87 +0,0 @@
---
title: 联邦事件
content_type: concept
---
<!--
---
title: Federated Events
content_type: concept
---
-->
<!-- overview -->
{{< deprecationfilewarning >}}
{{< include "federation-deprecation-warning-note.md" >}}
{{< /deprecationfilewarning >}}
<!--
This guide explains how to use events in federation control plane to help in debugging.
-->
本指南介绍如何在联邦控制平面中使用事件来帮助调试。
<!-- body -->
<!--
## Prerequisites
-->
## 先决条件
<!--
This guide assumes that you have a running Kubernetes Cluster
Federation installation. If not, then head over to the
[federation admin guide](/docs/concepts/cluster-administration/federation/) to learn how to
bring up a cluster federation (or have your cluster administrator do
this for you). Other tutorials, for example
[this one](https://github.com/kelseyhightower/kubernetes-cluster-federation)
by Kelsey Hightower, are also available to help you.
-->
本指南假定您正在运行 Kubernetes 集群联邦安装。
如果没有，请转到[联邦管理员指南](/docs/concepts/cluster-administration/federation/)，了解如何启动集群联邦（或让集群管理员为您执行此操作）。
其他教程，例如[这个](https://github.com/kelseyhightower/kubernetes-cluster-federation)由 Kelsey Hightower，也可为您提供帮助。
<!--
You should also have a basic
[working knowledge of Kubernetes](/docs/tutorials/kubernetes-basics/) in
general.
-->
你还应该具备 [kubernetes 基本工作知识](/docs/tutorials/kubernetes-basics/)。
<!--
## View federation events
-->
## 查看联邦事件
<!--
Events in federation control plane (referred to as "federation events" in
this guide) are very similar to the traditional Kubernetes
Events providing the same functionality.
Federation Events are stored only in federation control plane and are not passed on to the underlying Kubernetes clusters.
-->
联邦控制平面中的事件（本指南中称为“联邦事件”）与提供相同功能的传统 Kubernetes 事件非常相似。
联邦事件仅存储在联邦控制平面中，不会传递给基础 Kubernetes 集群。
<!--
Federation controllers create events as they process API resources to surface to the
user, the state that they are in.
You can get all events from federation apiserver by running:
-->
联邦控制器在处理 API 资源时创建事件，以便向用户显示它们所处的状态。您可以通过运行以下命令从联邦 apiserver 获取所有事件：
```shell
kubectl --context=federation-cluster get events
```
<!--
The standard kubectl get, update, delete commands will all work.
-->
标准的 kubectl get，update，delete 命令都可以正常工作。
content/zh/docs/tasks/federation/administer-federation/job.md
-191
View File
@@ -1,191 +0,0 @@
---
title: 联邦 Job
content_type: task
---
<!--
---
title: Federated Jobs
content_type: task
---
-->
<!-- overview -->
{{< deprecationfilewarning >}}
{{< include "federation-deprecation-warning-note.md" >}}
{{< /deprecationfilewarning >}}
<!--
This guide explains how to use jobs in the federation control plane.
Jobs in the federation control plane (referred to as "federated jobs" in
this guide) are similar to the traditional [Kubernetes
jobs](/docs/concepts/workloads/controllers/job/), and provide the same functionality.
Creating jobs in the federation control plane ensures that the desired number of
parallelism and completions exist across the registered clusters.
-->
本指南解释了如何在联邦控制平面中使用 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/)。
<!--
* You should also have a basic
[working knowledge of Kubernetes](/docs/tutorials/kubernetes-basics/) in
general and [jobs](/docs/concepts/workloads/controllers/jobs-run-to-completion/) in particular.
-->
<!-- steps -->
<!--
## Creating a federated job
-->
## 创建一个联邦 job
<!--
The API for federated jobs is fully compatible with the
API for traditional Kubernetes jobs. You can create a job by sending
a request to the federation apiserver.
You can do that using [kubectl](/docs/user-guide/kubectl/) by running:
-->
用于联邦 job 的 API 与用于传统 Kubernetes job 的 API 完全兼容。您可以通过向联邦 apiserver 发送请求来创建 job。
你可以使用 [kubectl](/docs/user-guide/kubectl/) 来运行：
``` shell
kubectl --context=federation-cluster create -f myjob.yaml
```
<!--
The `--context=federation-cluster` flag tells kubectl to submit the
request to the federation API server instead of sending it to a Kubernetes
cluster.
-->
`--context=federation-cluster` 参数告诉 kubectl 将请求提交到联邦 API 服务器，而不是发送到 Kubernetes 集群。
<!--
Once a federated job is created, the federation control plane creates
a job in all underlying Kubernetes clusters.
You can verify this by checking each of the underlying clusters, for example:
-->
一旦创建了联邦 job，联邦控制平面将在所有底层 Kubernetes 集群中创建一个 job。
你可以通过检查每个集群底层来验证这一点，例如：
``` shell
kubectl --context=gce-asia-east1a get job myjob
```
<!--
The previous example assumes that you have a context named `gce-asia-east1a`
configured in your client for your cluster in that zone.
-->
前面的示例假设你的客户端中为该区域中的集群配置了一个名为 `gce-asia-east1a` 的上下文。
<!--
The jobs in the underlying clusters match the federated job
except in the number of parallelism and completions. The federation control plane ensures that the
sum of the parallelism and completions in each cluster matches the desired number of parallelism and completions in the
federated job.
-->
集群底层中的 job 与联邦 job 匹配，但并行性和完成数不匹配。
联邦控制平面确保每个集群中的并行性和完成数之和与联合作业中所需的并行度和完成数匹配。
<!--
### Spreading job tasks in underlying clusters
-->
### 将 job 任务分散到集群底层中
<!--
By default, parallelism and completions are spread equally in all underlying clusters. For example:
if you have 3 registered clusters and you create a federated job with
`spec.parallelism = 9` and `spec.completions = 18`, then each job in the 3 clusters has
`spec.parallelism = 3` and `spec.completions = 6`.
To modify the number of parallelism and completions in each cluster, you can specify
[ReplicaAllocationPreferences](https://github.com/kubernetes/federation/blob/{{< param "githubbranch" >}}/apis/federation/types.go)
as an annotation with key `federation.kubernetes.io/job-preferences`
on the federated 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 的注释。
<!--
## Updating a federated job
-->
## 更新联邦 job
<!--
You can update a federated job as you would update a Kubernetes
job; however, for a federated job, you must send the request to
the federation API server instead of sending it to a specific Kubernetes cluster.
The federation control plane ensures that whenever the federated job is
updated, it updates the corresponding job in all underlying clusters to
match it.
-->
可以像更新 Kubernetes job 一样更新联邦 job；但是，对于联邦 job，必须将请求发送到联邦 API 服务器，不是发送到指定的 Kubernetes 集群。
联邦控制平面确保无论何时更新联邦 job，它都会更新所有集群底层中的相应 job 以匹配它。
<!--
If your update includes a change in number of parallelism and completions, the federation
control plane changes the number of parallelism and completions in underlying clusters to
ensure that their sum remains equal to the number of desired parallelism and completions in
federated job.
-->
如果您的更新包含并行性和完成数的更改，则联邦控制平面将更改集群底层中的并行性和完成数，
确保它们的总和仍然等于联邦 job 中所需的并行性和完成数。
<!--
## Deleting a federated job
-->
## 删除联邦 job
<!--
You can delete a federated job as you would delete a Kubernetes
job; however, for a federated job, you must send the request to
the federation API server instead of sending it to a specific Kubernetes cluster.
-->
可以删除联邦 job，就像删除 Kubernetes job 一样;但是，对于联邦 job，必须将请求发送到联邦 API 服务器，不是发送到指定的 Kubernetes 集群。
<!--
For example, with kubectl:
-->
例如，使用 kubectl：
```shell
kubectl --context=federation-cluster delete job myjob
```
{{< note >}}
<!--
Deleting a federated job will not delete the
corresponding jobs from underlying clusters.
You must delete the underlying jobs manually.
-->
删除联邦作业不会从基础集群中删除相应的 job。
您必须手动删除基础 job。
{{< /note >}}
content/zh/docs/tasks/federation/administer-federation/namespaces.md
-158
View File
@@ -1,158 +0,0 @@
---
title: 联邦命名空间
content_type: task
---
<!--
---
title: Federated Namespaces
content_type: task
---
-->
<!-- overview -->
{{< deprecationfilewarning >}}
{{< include "federation-deprecation-warning-note.md" >}}
{{< /deprecationfilewarning >}}
<!--
This guide explains how to use Namespaces in Federation control plane.
-->
本指南介绍如何在联邦控制平面中使用命名空间。
<!--
Namespaces in federation control plane (referred to as "federated Namespaces" in
this guide) are very similar to the traditional [Kubernetes
Namespaces](/docs/concepts/overview/working-with-objects/namespaces/) providing the same functionality.
Creating them in the federation control plane ensures that they are synchronized
across all the clusters in federation.
-->
联邦控制平面中的命名空间（本指南中称为“联邦命名空间”）与提供相同功能的传统 Kubernetes 命名空间非常相似。
在联邦控制平面中创建它们可确保它们在联邦中的所有集群之间同步
## {{% heading "prerequisites" %}}
* {{< include "federated-task-tutorial-prereqs.md" >}}
* 您还需要具备基本的 [Kubernetes 工作知识](/docs/tutorials/Kubernetes-basics/)，
特别是[命名空间](/docs/concepts/overview/working-objects/Namespaces/)。
<!--
You are also expected to have a basic
[working knowledge of Kubernetes](/docs/tutorials/kubernetes-basics/) in
general and [Namespaces](/docs/concepts/overview/working-with-objects/namespaces/) in particular.
-->
<!-- steps -->
<!--
## Creating a Federated Namespace
-->
## 创建联邦命名空间
<!--
The API for Federated Namespaces is 100% compatible with the
API for traditional Kubernetes Namespaces. You can create a Namespace by sending
a request to the federation apiserver.
-->
联邦命名空间的 API 与传统 Kubernetes 命名空间的 API 100％ 兼容。您可以通过向联邦身份验证程序发送请求来创建命名空间。
<!--
You can do that using kubectl by running:
-->
您可以通过运行以下命令使用 kubectl 执行此操作：
``` shell
kubectl --context=federation-cluster create -f myns.yaml
```
<!--
The `--context=federation-cluster` flag tells kubectl to submit the
request to the Federation apiserver instead of sending it to a Kubernetes
cluster.
-->
`--context=federation-cluster` 参数通知 kubectl 将请求提交给联邦 apiserver，而不是将其发送到 Kubernetes 集群。
<!--
Once a federated Namespace is created, the federation control plane will create
a matching Namespace in all underlying Kubernetes clusters.
You can verify this by checking each of the underlying clusters, for example:
-->
创建联邦命名空间后，联邦控制平面将在所有基础 Kubernetes 集群中创建匹配的命名空间。您可以通过检查每个基础集群来验证这一点，例如：
``` shell
kubectl --context=gce-asia-east1a get namespaces myns
```
<!--
The above assumes that you have a context named 'gce-asia-east1a'
configured in your client for your cluster in that zone. The name and
spec of the underlying Namespace will match those of
the Federated Namespace that you created above.
-->
以上假设您在客户端中为该区域中的集群配置了名为 “gce-asia-east1a” 的上下文。
基础命名空间的名称和规范将与您在上面创建的联邦命名空间的名称和规范相匹配。
<!--
## Updating a Federated Namespace
-->
## 更新联邦命名空间
<!--
You can update a federated Namespace as you would update a Kubernetes
Namespace, just send the request to federation apiserver instead of sending it
to a specific Kubernetes cluster.
Federation control plane will ensure that whenever the federated Namespace is
updated, it updates the corresponding Namespaces in all underlying clusters to
match it.
-->
您可以像更新 Kubernetes 命名空间一样更新联邦命名空间，只需将请求发送到联邦身份验证程序，而不是将其发送到指定的 Kubernetes 集群。
联邦控制平面将确保每当更新联邦命名空间时，它都会更新所有基础集群中的相应命名空间以与其匹配。
<!--
## Deleting a Federated Namespace
-->
## 删除联邦命名空间
<!--
You can delete a federated Namespace as you would delete a Kubernetes
Namespace, just send the request to federation apiserver instead of sending it
to a specific Kubernetes cluster.
-->
你可以删除联邦命名空间，就像删除 Kubernetes 命名空间一样，只需将请求发送到联邦身份验证器，而不是发送到指定的 Kubernetes 群集。
<!--
For example, you can do that using kubectl by running:
-->
例如，您可以通过运行以下命令使用 kubectl 执行此操作：
```shell
kubectl --context=federation-cluster delete ns myns
```
<!--
As in Kubernetes, deleting a federated Namespace will delete all resources in that
Namespace from the federation control plane.
-->
与在 Kubernetes 中一样，删除联邦命名空间将从联邦控制平面中删除该命名空间中的所有资源。
{{< note >}}
<!--
At this point, deleting a federated Namespace will not delete the corresponding Namespace, or resources in those Namespaces, from underlying clusters. Users must delete them manually. We intend to fix this in the future.
-->
此时，删除联邦命名空间，不会从底层集群中删除相应的命名空间或这些命名空间中的资源。用户必须手动删除它们。我们打算将来解决这个问题。
{{< /note >}}
content/zh/docs/tasks/federation/administer-federation/replicaset.md
-220
View File
@@ -1,220 +0,0 @@
---
title: 联邦 ReplicaSet
content_type: task
---
<!--
---
title: Federated ReplicaSets
content_type: task
---
-->
<!-- overview -->
{{< deprecationfilewarning >}}
{{< include "federation-deprecation-warning-note.md" >}}
{{< /deprecationfilewarning >}}
<!--
This guide explains how to use ReplicaSets in the Federation control plane.
ReplicaSets in the federation control plane (referred to as "federated ReplicaSets" in
this guide) are very similar to the traditional [Kubernetes
ReplicaSets](/docs/concepts/workloads/controllers/replicaset/), and provide the same functionality.
Creating them in the federation control plane ensures that the desired number of
replicas exist across the registered clusters.
-->
本指南阐述了如何在联邦控制平面中使用 ReplicaSet。
在联邦控制平面中的 ReplicaSet (在本指南中称为”联邦 ReplicaSet”) 和传统的 [Kubernetes
ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) 很相似，提供了一样的功能。在联邦控制平面中创建联邦 ReplicaSet 可以确保在联邦的所有集群中都有预期数量的副本。
## {{% heading "prerequisites" %}}
* {{< include "federated-task-tutorial-prereqs.md" >}}
<!--
* You should also have a basic
[working knowledge of Kubernetes](/docs/tutorials/kubernetes-basics/) in
general and [ReplicaSets](/docs/concepts/workloads/controllers/replicaset/) in particular.
-->
* 你还应该具备基本的 [Kubernetes 应用知识](/docs/tutorials/kubernetes-basics/)，特别是 [ReplicaSets](/docs/concepts/workloads/controllers/replicaset/) 相关的应用知识。
<!-- steps -->
<!--
## Creating a Federated ReplicaSet
The API for Federated ReplicaSet is 100% compatible with the
API for traditional Kubernetes ReplicaSet. You can create a ReplicaSet by sending
a request to the federation apiserver.
You can do that using [kubectl](/docs/user-guide/kubectl/) by running:
``` shell
kubectl --context=federation-cluster create -f myrs.yaml
```
The `--context=federation-cluster` flag tells kubectl to submit the
request to the Federation apiserver instead of sending it to a Kubernetes
cluster.
Once a federated ReplicaSet is created, the federation control plane will create
a ReplicaSet in all underlying Kubernetes clusters.
You can verify this by checking each of the underlying clusters, for example:
``` shell
kubectl --context=gce-asia-east1a get rs myrs
```
The above assumes that you have a context named 'gce-asia-east1a'
configured in your client for your cluster in that zone.
The ReplicaSets in the underlying clusters will match the federation ReplicaSet
except in the number of replicas. The federation control plane will ensure that the
sum of the replicas in each cluster match the desired number of replicas in the
federation 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 有同样的副本数。
<!--
### Spreading Replicas in Underlying Clusters
By default, replicas are spread equally in all the underlying clusters. For example:
if you have 3 registered clusters and you create a federated ReplicaSet with
`spec.replicas = 9`, then each ReplicaSet in the 3 clusters will have
`spec.replicas=3`.
To modify the number of replicas in each cluster, you can add an annotation with
key `federation.kubernetes.io/replica-set-preferences` to the federated ReplicaSet.
The value of the annoation is a serialized JSON that contains fields shown in
the following example:
```
{
"rebalance": true,
"clusters": {
"foo": {
"minReplicas": 10,
"maxReplicas": 50,
"weight": 100
},
"bar": {
"minReplicas": 10,
"maxReplicas": 100,
"weight": 200
}
}
}
```
The `rebalance` boolean field specifies whether replicas already scheduled and running
may be moved in order to match current state to the specified preferences.
The `clusters` object field contains a map where users can specify the constraints
for replica placement across the clusters (`foo` and `bar` in the example).
For each cluster, you can specify the minimum number of replicas that should be
assigned to it (default is zero), the maximum number of replicas the cluster can
accept (default is unbounded) and a number expressing the relative weight of
preferences to place additional replicas to that cluster.
-->
### 底层集群中副本的分布
默认情况下，副本在所有底层集群中是均匀分布的。例如：如果您有 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`）。
对于每个集群，您可以指定应分配给它的最小副本数（默认值为零），集群可以接受的最大副本数（默认为无限制）以及表示要添加该群集的副本的首选项的相对权重的数字。
<!--
## Updating a Federated ReplicaSet
You can update a federated ReplicaSet as you would update a Kubernetes
ReplicaSet; however, for a federated ReplicaSet, you must send the request to
the federation apiserver instead of sending it to a specific Kubernetes cluster.
The Federation control plane ensures that whenever the federated ReplicaSet is
updated, it updates the corresponding ReplicaSet in all underlying clusters to
match it.
If your update includes a change in number of replicas, the federation
control plane will change the number of replicas in underlying clusters to
ensure that their sum remains equal to the number of desired replicas in
federated ReplicaSet.
-->
## 更新联邦 ReplicaSet
您可以像更新 Kubernetes ReplicaSet 一样更新联邦 ReplicaSet。但是对于联邦 ReplicaSet，您必须发送请求到联邦 apiserver 而不是某个特定的 Kubernetes 集群。联邦控制平面会确保任何时候联邦 ReplicaSet 更新后，它会将对应的 ReplicaSet 更新到所有的底层集群中来和它保持一致。
如果您做了包含副本数量的更改，联邦控制平面将会更改底层集群中的副本数以确保它们的总数和联邦 ReplicaSet 期望的副本数保持一致。
<!--
## Deleting a Federated ReplicaSet
You can delete a federated ReplicaSet as you would delete a Kubernetes
ReplicaSet; however, for a federated ReplicaSet, you must send the request to
the federation apiserver instead of sending it to a specific Kubernetes cluster.
For example, you can do that using kubectl by running:
```shell
kubectl --context=federation-cluster delete rs myrs
```
-->
## 删除联邦 ReplicaSet
您可以像删除 Kubernetes ReplicaSet 一样删除联邦 ReplicaSet。但是对于联邦 ReplicaSet ，您必须发送请求到联邦 apiserver 而不是某个特定的 Kubernetes 集群。
例如，您可以使用 kubectl 运行下面的命令来删除联邦 ReplicaSet：
```shell
kubectl --context=federation-cluster delete rs myrs
```
{{< note >}}
<!--
At this point, deleting a federated ReplicaSet will not delete the corresponding ReplicaSets from underlying clusters. You must delete the underlying ReplicaSets manually. We intend to fix this in the future.
-->
要注意的是这时删除联邦 ReplicaSet 并不会删除底层集群中对应的 ReplicaSet。您必须自己手动删除底层集群中的 ReplicaSet。我们打算在将来修复这个问题。
{{< /note >}}
content/zh/docs/tasks/federation/administer-federation/secret.md
-164
View File
@@ -1,164 +0,0 @@
---
title: 联邦 Secret
content_type: concept
---
<!--
---
title: Federated Secrets
content_type: concept
---
-->
<!-- overview -->
{{< deprecationfilewarning >}}
{{< include "federation-deprecation-warning-note.md" >}}
{{< /deprecationfilewarning >}}
<!--
This guide explains how to use secrets in Federation control plane.
Secrets in federation control plane (referred to as "federated secrets" in
this guide) are very similar to the traditional [Kubernetes
Secrets](/docs/concepts/configuration/secret/) providing the same functionality.
Creating them in the federation control plane ensures that they are synchronized
across all the clusters in federation.
-->
本指南解释了如何在联邦控制平面中使用 secret。
联邦控制平面中的 Secret（在本指南中称为“联邦 secret”）与提供相同功能的传统 [Kubernetes Secret](/docs/concepts/configuration/secret/) 非常相似。
在联邦控制平面中创建它们可以确保它们跨联邦中的所有集群同步。
<!-- body -->
<!--
## Prerequisites
-->
## 先决条件
<!--
This guide assumes that you have a running Kubernetes Cluster
Federation installation. If not, then head over to the
[federation admin guide](/docs/admin/federation/) to learn how to
bring up a cluster federation (or have your cluster administrator do
this for you). Other tutorials, for example
[this one](https://github.com/kelseyhightower/kubernetes-cluster-federation)
by Kelsey Hightower, are also available to help you.
-->
本指南假设你有一个正在运行的 Kubernetes 集群联邦安装。
如果没有，请访问[联邦管理指南](/docs/admin/federation/)，了解如何启动联邦集群（或者让集群管理员为你做这件事）。
其他教程，例如[这里](https://github.com/kelseyhightower/kubernetes-cluster-federation) Kelsey Hightower，也可以帮助您。
<!--
You should also have a basic
[working knowledge of Kubernetes](/docs/tutorials/kubernetes-basics/) in
general and [Secrets](/docs/concepts/configuration/secret/) in particular.
-->
你还应该具有一个基本的 [Kubernetes 工作知识](/docs/tutorials/kubernetes-basics/)，
特别是 [Secret](/docs/concepts/configuration/secret/)。
<!--
## Creating a Federated Secret
-->
## 创建联邦 Secret
<!--
The API for Federated Secret is 100% compatible with the
API for traditional Kubernetes Secret. You can create a secret by sending
a request to the federation apiserver.
-->
用于联邦 Secret 的 API 与用于传统的 Kubernetes Secret 的 API 100% 兼容。
您可以通过向联邦 apiserver 发送请求来创建一个 Secret。
<!--
You can do that using [kubectl](/docs/user-guide/kubectl/) by running:
-->
你可以使用 [kubectl](/docs/user-guide/kubectl/) 来运行：
``` shell
kubectl --context=federation-cluster create -f mysecret.yaml
```
<!--
The `--context=federation-cluster` flag tells kubectl to submit the
request to the Federation apiserver instead of sending it to a Kubernetes
cluster.
-->
`--context=federation-cluster` 参数通知 kubectl 将请求提交给联邦 apiserver，而不是将其发送到 Kubernetes 集群。
<!--
Once a federated secret is created, the federation control plane will create
a matching secret in all underlying Kubernetes clusters.
You can verify this by checking each of the underlying clusters, for example:
-->
创建联邦命名空间后，联邦控制平面将在所有基础 Kubernetes 集群中创建匹配的命名空间。您可以通过检查每个基础集群来验证这一点，例如：
``` shell
kubectl --context=gce-asia-east1a get secret mysecret
```
<!--
The above assumes that you have a context named 'gce-asia-east1a'
configured in your client for your cluster in that zone.
These secrets in underlying clusters will match the federated secret.
-->
以上假设您在客户端中为该区域中的集群配置了名为 “gce-asia-east1a” 的上下文。
集群底层中的这些 secret 将与联邦 secret 匹配。
<!--
## Updating a Federated Secret
-->
## 更新联邦 Secret
<!--
You can update a federated secret as you would update a Kubernetes
secret; however, for a federated secret, you must send the request to
the federation apiserver instead of sending it to a specific Kubernetes cluster.
The Federation control plane ensures that whenever the federated secret is
updated, it updates the corresponding secrets in all underlying clusters to
match it.
-->
您可以像更新 Kubernetes secret 一样更新联邦 secret，但是，对于联邦 secret 必须将请求发送到联邦 apiserver，
而不是将其发送到指定的 Kubernetes 集群。联邦控制平面将确保每当更新联邦 secret 时，它都会更新所有基础集群中的相应 secret 以与其匹配。
<!--
## Deleting a Federated Secret
-->
## 删除联邦 Secret
<!--
You can delete a federated secret as you would delete a Kubernetes
secret; however, for a federated secret, you must send the request to
the federation apiserver instead of sending it to a specific Kubernetes cluster.
-->
你可以删除一个联邦 secret，就像删除一个 Kubernetes secret 一样；但是，
对于联邦 secret，必须将请求发送到联邦 apiserver，而不是发送到指定的 Kubernetes 集群。
<!--
For example, you can do that using kubectl by running:
-->
例如，您可以通过运行以下命令使用 kubectl 执行此操作：
```shell
kubectl --context=federation-cluster delete secret mysecret
```
{{< note >}}
<!--
At this point, deleting a federated secret will not delete the corresponding secrets from underlying clusters. You must delete the underlying secrets manually. We intend to fix this in the future.
-->
此时，删除联邦 secret 不会从集群底层中删除相应的 secret。你必须手动删除底层 secret。我们打算将来解决这个问题。
{{< /note >}}
content/zh/docs/tasks/federation/federation-service-discovery.md
-509
View File
@@ -1,509 +0,0 @@
---
title: 使用联合服务来实现跨集群的服务发现
content_type: task
weight: 140
---
<!-- ---
title: Cross-cluster Service Discovery using Federated Services
reviewers:
- bprashanth
- quinton-hoole
content_type: task
weight: 140
--- -->
<!-- overview -->
{{< deprecationfilewarning >}}
{{< include "federation-deprecation-warning-note.md" >}}
{{< /deprecationfilewarning >}}
<!-- This guide explains how to use Kubernetes Federated Services to deploy
a common Service across multiple Kubernetes clusters. This makes it
easy to achieve cross-cluster service discovery and availability zone
fault tolerance for your Kubernetes applications. -->
本指南说明了如何使用 Kubernetes 联合服务跨多个 Kubernetes 集群部署通用服务。这样可以轻松实现 Kubernetes 应用程序的跨集群服务发现和可用区容错。
<!-- Federated Services are created in much that same way as traditional
[Kubernetes Services](/docs/concepts/services-networking/service/) by making an API
call which specifies the desired properties of your service. In the
case of Federated Services, this API call is directed to the
Federation API endpoint, rather than a Kubernetes cluster API
endpoint. The API for Federated Services is 100% compatible with the
API for traditional Kubernetes Services. -->
联合服务的创建与传统服务几乎相同 [Kubernetes Services](/docs/concepts/services-networking/service/) 即通过 API 调用来指定所需的服务属性。对于联合服务，此 API 调用定向到联合身份验证 API 接入点，而不是 Kubernetes 集群 API 接入点。联合服务的 API 与传统 Kubernetes 服务的 API 是 100% 兼容的。
<!-- Once created, the Federated Service automatically: -->
创建后，联合服务会自动:
<!-- 1. Creates matching Kubernetes Services in every cluster underlying your Cluster Federation,
2. Monitors the health of those service "shards" (and the clusters in which they reside), and
3. Manages a set of DNS records in a public DNS provider (like Google Cloud DNS, or AWS Route 53), thus ensuring that clients
of your federated service can seamlessly locate an appropriate healthy service endpoint at all times, even in the event of cluster,
availability zone or regional outages. -->
1. 在基础集群联合的每个集群中创建匹配的 Kubernetes 服务,
2. 监视那些服务 "分片"(及其驻留的集群)的运行状况,以及
3. 在公共 DNS 提供商(例如 Google Cloud DNS 或 AWS Route 53)中管理一组 DNS 记录,即使在集群可用区域中断的情况下，也能确保您联合服务的客户端始终可以无缝地定位合适的健康服务接入点。
<!-- Clients inside your federated Kubernetes clusters (that is Pods) will
automatically find the local shard of the Federated Service in their
cluster if it exists and is healthy, or the closest healthy shard in a
different cluster if it does not. -->
如果存在健康的分片，联合 Kubernetes 集群(即 Pods )中的客户端将自动在其中找到联合服务的本地分片集群或者集群中最接近的健康分片;如果不存在，则使用最接近的其他集群的健康分片。
{{< toc >}}
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
<!-- steps -->
<!-- ## Prerequisites -->
## 前提
<!-- This guide assumes that you have a running Kubernetes Cluster
Federation installation. If not, then head over to the
[federation admin guide](/docs/admin/federation/) to learn how to
bring up a cluster federation (or have your cluster administrator do
this for you). Other tutorials, for example
[this one](https://github.com/kelseyhightower/kubernetes-cluster-federation)
by Kelsey Hightower, are also available to help you. -->
本指南假设您已经安装 Kubernetes 联合集群。如果没有，则访问 [联合集群管理指南](/docs/admin/federation/)了解如何建立联合集群(或让您的集群管理员为您执行此操作)。其他教程，例如 Kelsey Hightower 编写的 [案例](https://github.com/kelseyhightower/kubernetes-cluster-federation)或许有用。
<!-- You should also have a basic
[working knowledge of Kubernetes](/docs/tutorials/kubernetes-basics/) in
general, and [Services](/docs/concepts/services-networking/service/) in particular. -->
一般而言，您应该还有基本的 [Kubernetes 工作常识](/docs/tutorials/kubernetes-basics/)，特别是 [Services](/docs/concepts/services-networking/service/)。
<!-- ## Hybrid cloud capabilities -->
## 混合云功能
<!-- Federations of Kubernetes Clusters can include clusters running in
different cloud providers (such as Google Cloud or AWS), and on-premises
(such as on OpenStack). Simply create all of the clusters that you
require, in the appropriate cloud providers and/or locations, and
register each cluster's API endpoint and credentials with your
Federation API Server (See the
[federation admin guide](/docs/admin/federation/) for details). -->
Kubernetes 联合集群需要可以在不同的云提供商(例如 Google Cloud 或 AWS)和本地(例如 OpenStack)环境中运行。只需在合适的云提供商创建所需的所有集群，向您的联合身份验证 API 服务器注册每个集群的 API 接入点和凭据(有关详细信息，请参见 [联合管理指南](/docs/admin/federation/))。
<!-- Thereafter, your applications and services can span different clusters
and cloud providers as described in more detail below. -->
此后，您的应用程序和服务可以跨越不同的集群和云提供商，如下所述。
<!-- ## Creating a federated service -->
## 创建联合服务
<!-- This is done in the usual way, for example: -->
常见方式创建，例如:
``` shell
kubectl --context=federation-cluster create -f services/nginx.yaml
```
<!-- The '--context=federation-cluster' flag tells kubectl to submit the
request to the Federation API endpoint, with the appropriate
credentials. If you have not yet configured such a context, visit the
[federation admin guide](/docs/admin/federation/) or one of the
[administration tutorials](https://github.com/kelseyhightower/kubernetes-cluster-federation)
to find out how to do so. -->
'--context=federation-cluster' 标志通知 kubectl 使用合适的凭据将请求提交到联合 API 接入点。如果您尚未配置此类上下文，请访问 [联合管理指南](/docs/admin/federation/)或者 [管理教程](https://github.com/kelseyhightower/kubernetes-cluster-federation)找出解决方案。
<!-- As described above, the Federated Service will automatically create
and maintain matching Kubernetes services in all of the clusters
underlying your federation. -->
如上所述，联合服务将自动创建并在所有集群中维护匹配的 Kubernetes 服务以支持联合。
<!-- You can verify this by checking in each of the underlying clusters, for example: -->
您可以通过核对每个基础集群的信息来验证这一点, 例如:
``` 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
```
<!-- The above assumes that you have a context named 'gce-asia-east1a'
configured in your client for your cluster in that zone. The name and
namespace of the underlying services will automatically match those of
the Federated Service that you created above (and if you happen to
have had services of the same name and namespace already existing in
any of those clusters, they will be automatically adopted by the
Federation and updated to conform with the specification of your
Federated Service - either way, the end result will be the same). -->
以上假设您有一个名为 'gce-asia-east1a' 上下文在客户端中为该区域中的集群配置。基础服务的名称和命名空间将自动与您在上面创建的联合服务匹配(如果服务的名称和命名空间与集群中任意一个服务器的名称和命名空间相同，它们将被联合并更新为符合您的规范联合服务 - 无论哪种方式，最终结果都是相同的)。
<!-- The status of your Federated Service will automatically reflect the
real-time status of the underlying Kubernetes services, for example: -->
联合服务的状态将自动反映基础 Kubernetes 服务的实时状态，例如:
``` shell
kubectl --context=federation-cluster describe services nginx
```
```
Name: nginx
Namespace: default
Labels: run=nginx
Annotations: <none>
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: <none>
Session Affinity: None
Events: <none>
```
<!-- {{< note >}}
The 'LoadBalancer Ingress' addresses of your Federated Service
correspond with the 'LoadBalancer Ingress' addresses of all of the
underlying Kubernetes services (once these have been allocated - this
may take a few seconds). For inter-cluster and inter-cloud-provider
networking between service shards to work correctly, your services
need to have an externally visible IP address. [Service Type:
Loadbalancer](/docs/concepts/services-networking/service/#loadbalancer)
is typically used for this, although other options
(for example [External IPs](/docs/concepts/services-networking/service/#external-ips)) exist.
{{< /note >}} -->
{{< 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 >}}
<!-- Note also that we have not yet provisioned any backend Pods to receive
the network traffic directed to these addresses (that is 'Service
Endpoints'), so the Federated Service does not yet consider these to
be healthy service shards, and has accordingly not yet added their
addresses to the DNS records for this Federated Service (more on this
aspect later). -->
还要注意，我们尚未设置任何后端 Pod 来接收定向到这些地址的网络流量(即 'Service Endpoints')，因此联合服务尚未将它们视为健康的服务分片，并且尚未将其地址添加到联合服务的 DNS 记录中(稍后在此方面进行介绍)。
<!-- ## Adding backend pods -->
## 添加后端 pods
<!-- To render the underlying service shards healthy, we need to add
backend Pods behind them. This is currently done directly against the
API endpoints of the underlying clusters (although in future the
Federation server will be able to do all this for you with a single
command, to save you the trouble). For example, to create backend Pods
in 13 underlying clusters: -->
为了使基础服务分片健康，我们需要在它们后面添加后端 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
```
<!-- Note that `kubectl run` automatically adds the `run=nginx` labels required to associate the backend pods with their services. -->
注意，`kubectl run` 会自动添加 `run=nginx` 标签，这是将后端 pod 与其服务关联起来所必需的。
<!-- ## Verifying public DNS records -->
## 验证公共 DNS 记录
<!-- Once the above Pods have successfully started and have begun listening
for connections, Kubernetes will report them as healthy endpoints of
the service in that cluster (through automatic health checks). The Cluster
Federation will in turn consider each of these
service 'shards' to be healthy, and place them in serving by
automatically configuring corresponding public DNS records. You can
use your preferred interface to your configured DNS provider to verify
this. For example, if your Federation is configured to use Google
Cloud DNS, and a managed DNS domain 'example.com': -->
一旦上述 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 >}}
If your Federation is configured to use AWS Route53, you can use one of the equivalent AWS tools, for example:
``` shell
aws route53 list-hosted-zones
```
and
``` shell
aws route53 list-resource-record-sets --hosted-zone-id Z3ECL0L9QLOVBX
```
{{< /note >}} -->
{{< note >}}
如果您的联邦配置为使用 AWS Route53，则可以使用类似的 AWS 工具，例如:
``` shell
aws route53 list-hosted-zones
```
和
``` shell
aws route53 list-resource-record-sets --hosted-zone-id Z3ECL0L9QLOVBX
```
{{< /note >}}
<!-- Whatever DNS provider you use, any DNS query tool (for example 'dig'
or 'nslookup') will of course also allow you to see the records
created by the Federation for you. Note that you should either point
these tools directly at your DNS provider (such as `dig
@ns-cloud-e1.googledomains.com...`) or expect delays in the order of
your configured TTL (180 seconds, by default) before seeing updates,
due to caching by intermediate DNS servers. -->
无论使用哪种 DNS 提供商，任何 DNS 查询工具(例如 'dig' 或者 'nslookup')都将允许您查看联邦会为您创建的记录。请注意，您应该将这些工具直接指向您的 DNS 提供商(例如 `dig @ ns-cloud-e1.googledomains.com ...`),或者由于中间 DNS 服务器进行了缓存，因此在看到更新之前，预计延迟会按照配置的 TTL 顺序(默认为 180 秒)进行。
<!-- ### Some notes about the above example -->
### 有关上述示例的一些注意事项
<!-- 1. Notice that there is a normal ('A') record for each service shard that has at least one healthy backend endpoint. For example, in us-central1-a, 104.197.247.191 is the external IP address of the service shard in that zone, and in asia-east1-a the address is 130.211.56.221.
2. Similarly, there are regional 'A' records which include all healthy shards in that region. For example, 'us-central1'. These regional records are useful for clients which do not have a particular zone preference, and as a building block for the automated locality and failover mechanism described below.
3. For zones where there are currently no healthy backend endpoints, a CNAME ('Canonical Name') record is used to alias (automatically redirect) those queries to the next closest healthy zone. In the example, the service shard in us-central1-f currently has no healthy backend endpoints (that is Pods), so a CNAME record has been created to automatically redirect queries to other shards in that region (us-central1 in this case).
4. Similarly, if no healthy shards exist in the enclosing region, the search progresses further afield. In the europe-west1-d availability zone, there are no healthy backends, so queries are redirected to the broader europe-west1 region (which also has no healthy backends), and onward to the global set of healthy addresses (' nginx.mynamespace.myfederation.svc.example.com.'). -->
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.')。
<!-- The above set of DNS records is automatically kept in sync with the
current state of health of all service shards globally by the
Federated Service system. DNS resolver libraries (which are invoked by
all clients) automatically traverse the hierarchy of 'CNAME' and 'A'
records to return the correct set of healthy IP addresses. Clients can
then select any one of the returned addresses to initiate a network
connection (and fail over automatically to one of the other equivalent
addresses if required). -->
上面的 DNS 记录集由联邦服务系统自动与全球所有服务分片的当前健康状况保持同步。DNS 解析库(由所有客户端调用)自动遍历 'CNAME' 与 'A' 记录的层次结构，以返回正确健康的 IP 地址集。然后，客户端可以选择任何返回的地址来启动网络连接(并根据需要自动故障转移到其他等效地址之一)。
<!-- ## Discovering a federated service -->
## 发现联合服务
<!-- ### From pods inside your federated clusters -->
### 从联合集群内的 Pods 来发现
<!-- By default, Kubernetes clusters come pre-configured with a
cluster-local DNS server ('KubeDNS'), as well as an intelligently
constructed DNS search path which together ensure that DNS queries
like "myservice", "myservice.mynamespace",
"bobsservice.othernamespace" etc issued by your software running
inside Pods are automatically expanded and resolved correctly to the
appropriate service IP of services running in the local cluster. -->
默认情况下，Kubernetes 集群预先配置了本地集群 DNS 服务器('KubeDNS')以及智能构建的 DNS 搜索路径，这些路径共同确保由 Pods 内部运行软件发出的 DNS 查询如 "myservice", "myservice.mynamespace","bobsservice.othernamespace" 等，会自动扩展并正确解析为本地集群运行服务的相应服务 IP。
<!-- With the introduction of Federated Services and Cross-Cluster Service
Discovery, this concept is extended to cover Kubernetes services
running in any other cluster across your Cluster Federation, globally.
To take advantage of this extended range, you use a slightly different
DNS name of the form ```"<servicename>.<namespace>.<federationname>"```
to resolve Federated Services. For example, you might use
`myservice.mynamespace.myfederation`. Using a different DNS name also
avoids having your existing applications accidentally traversing
cross-zone or cross-region networks and you incurring perhaps unwanted
network charges or latency, without you explicitly opting in to this
behavior. -->
随着联合服务和跨集群服务发现的引入，该概念已扩展到涵盖在全球集群联盟中任何其他集群中运行的 Kubernetes 服务。要利用此扩展范围，您可以使用形式稍有不同的 DNS 名称，形式为 ```"<servicename>.<namespace>.<federationname>"``` 来解析联合服务。例如，您可以使用 `myservice.mynamespace.myfederation`。使用不同的 DNS 名称还可以避免现有应用程序意外穿越跨区域或跨区域网络，并且可能招致不必要的网络费用或延迟，而无需您明确选择采取这种行为。
<!-- So, using our NGINX example service above, and the Federated Service
DNS name form just described, let's consider an example: A Pod in a
cluster in the `us-central1-f` availability zone needs to contact our
NGINX service. Rather than use the service's traditional cluster-local
DNS name (`"nginx.mynamespace"`, which is automatically expanded
to `"nginx.mynamespace.svc.cluster.local"`) it can now use the
service's Federated DNS name, which is
`"nginx.mynamespace.myfederation"`. This will be automatically
expanded and resolved to the closest healthy shard of my NGINX
service, wherever in the world that may be. If a healthy shard exists
in the local cluster, that service's cluster-local (typically
10.x.y.z) IP address will be returned (by the cluster-local KubeDNS).
This is almost exactly equivalent to non-federated service resolution
(almost because KubeDNS actually returns both a CNAME and an A record
for local federated services, but applications will be oblivious
to this minor technical difference). -->
因此，使用上面的 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 记录，但是应用程序将忽略这种微小的技术差异)。
<!-- But if the service does not exist in the local cluster (or it exists
but has no healthy backend pods), the DNS query is automatically
expanded to ```"nginx.mynamespace.myfederation.svc.us-central1-f.example.com"```
(that is, logically "find the external IP of one of the shards closest to
my availability zone"). This expansion is performed automatically by
KubeDNS, which returns the associated CNAME record. This results in
automatic traversal of the hierarchy of DNS records in the above
example, and ends up at one of the external IPs of the Federated
Service in the local us-central1 region (that is 104.197.247.191,
104.197.244.180 or 104.197.245.170). -->
但是，如果服务在本地集群中不存在(或者存在但没有正常的后端 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 )。
<!-- It is of course possible to explicitly target service shards in
availability zones and regions other than the ones local to a Pod by
specifying the appropriate DNS names explicitly, and not relying on
automatic DNS expansion. For example,
"nginx.mynamespace.myfederation.svc.europe-west1.example.com" will
resolve to all of the currently healthy service shards in Europe, even
if the Pod issuing the lookup is located in the U.S., and irrespective
of whether or not there are healthy shards of the service in the U.S.
This is useful for remote monitoring and other similar applications. -->
当然，可以通过明确地指定合适的 DNS 名称而不依赖于自动 DNS 扩展，在 Pod 本地的可用区域和可用区域之外的区域中明确地定位服务分片。例如，即使发出查询的 Pod 位于美国，"nginx.mynamespace.myfederation.svc.europe-west1.example.com" 也将解析欧洲目前所有健康的服务分片,并且无论美国是否有健康的服务分片。这对于远程监视和其他类似应用程序很有用。
<!-- ### From other clients outside your federated clusters -->
### 来自联合集群之外的其他客户端
<!-- Much of the above discussion applies equally to external clients,
except that the automatic DNS expansion described is no longer
possible. So external clients need to specify one of the fully
qualified DNS names of the Federated Service, be that a zonal,
regional or global name. For convenience reasons, it is often a good
idea to manually configure additional static CNAME records in your
service, for example: -->
上面大部分讨论都同样适用于外部客户端，除了不再描述所描述的自动 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.
```
<!-- That way your clients can always use the short form on the left, and
always be automatically routed to the closest healthy shard on their
home continent. All of the required failover is handled for you
automatically by Kubernetes Cluster Federation. Future releases will
improve upon this even further. -->
这样，您的客户就可以始终使用左侧的缩写形式，并始终被自动路由到其本国大陆上最接近的健康分片。Kubernetes 联邦集群自动为您处理所有必需的故障转移。将来的发行版将对此进行进一步改进。
<!-- ## Handling failures of backend pods and whole clusters -->
## 处理后端 Pod 和整个集群的故障
<!-- Standard Kubernetes service cluster-IP's already ensure that
non-responsive individual Pod endpoints are automatically taken out of
service with low latency (a few seconds). In addition, as alluded
above, the Kubernetes Cluster Federation system automatically monitors
the health of clusters and the endpoints behind all of the shards of
your Federated Service, taking shards in and out of service as
required (for example, when all of the endpoints behind a service, or perhaps
the entire cluster or availability zone go down, or conversely recover
from an outage). Due to the latency inherent in DNS caching (the cache
timeout, or TTL for Federated Service DNS records is configured to 3
minutes, by default, but can be adjusted), it may take up to that long
for all clients to completely fail over to an alternative cluster in
the case of catastrophic failure. However, given the number of
discrete IP addresses which can be returned for each regional service
endpoint (such as us-central1 above, which has three alternatives)
many clients will fail over automatically to one of the alternative
IP's in less time than that given appropriate configuration. -->
标准的 Kubernetes 服务集群 IP 已确保无响应的单个 Pod 端点以低延迟(几秒钟)自动退出服务。此外，如上所述，Kubernetes 联邦集群系统会自动监视集群的状态以及联合服务的所有分片后面的端点，并根据需要使分片进入和退出服务(例如，当服务后面的所有端点或者整个集群或可用性区域出现故障时，或者相反地从中断中恢复时)。由于 DNS 缓存固有的延迟(默认情况下,缓存超时或联合服务 DNS 记录的 TTL 配置为3分钟，可以调整),在灾难性故障的情况下，所有客户端可能要花费很长时间才能完全故障转移到备用集群。但是，鉴于每个区域服务端点可以返回的离散 IP 地址数量(例如上面的 us-central1，它有三个替代方案),与给定的合适配置相比，许多客户端将在更少的时间内自动故障转移到其他 IP。
<!-- discussion -->
<!-- ## Troubleshooting -->
## 故障排除
<!-- ### I cannot connect to my cluster federation API -->
### 我无法连接到联合集群 API
<!-- Check that your -->
检查您的
<!-- 1. Client (typically kubectl) is correctly configured (including API endpoints and login credentials).
2. Cluster Federation API server is running and network-reachable. -->
1. 客户端(通常是 kubectl)已正确配置(包括 API 端点和登录凭据)。
2. 联合集群 API 服务器正在运行并且可以访问网络。
<!-- See the [federation admin guide](/docs/admin/federation/) to learn
how to bring up a cluster federation correctly (or have your cluster administrator do this for you), and how to correctly configure your client. -->
请参阅 [联合集群管理员指南](/docs/admin/federation/)了解如何正确启动联邦集群(或让您的集群管理员为您执行此操作),以及如何正确配置客户端。
<!-- ### I can create a federated service successfully against the cluster federation API, but no matching services are created in my underlying clusters -->
### 我可以针对联合集群 API 成功创建联合服务,但是在我的基础集群中没有创建匹配的服务。
<!-- Check that: -->
检查:
<!-- 1. Your clusters are correctly registered in the Cluster Federation API (`kubectl describe clusters`).
2. Your clusters are all 'Active'. This means that the cluster Federation system was able to connect and authenticate against the clusters' endpoints. If not, consult the logs of the federation-controller-manager pod to ascertain what the failure might be.
```
kubectl --namespace=federation logs $(kubectl get pods --namespace=federation -l module=federation-controller-manager -o name)
```
3. That the login credentials provided to the Cluster Federation API for the clusters have the correct authorization and quota to create services in the relevant namespace in the clusters. Again you should see associated error messages providing more detail in the above log file if this is not the case.
4. Whether any other error is preventing the service creation operation from succeeding (look for `service-controller` errors in the output of `kubectl logs federation-controller-manager --namespace federation`). -->
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` 错误)。
<!-- ### I can create a federated service successfully, but no matching DNS records are created in my DNS provider.
Check that: -->
### 我可以成功创建联合服务，但是在我的 DNS 提供程序中没有创建匹配的 DNS 记录。
检查:
<!-- 1. Your federation name, DNS provider, DNS domain name are configured correctly. Consult the [federation admin guide](/docs/admin/federation/) or [tutorial](https://github.com/kelseyhightower/kubernetes-cluster-federation) to learn
how to configure your Cluster Federation system's DNS provider (or have your cluster administrator do this for you).
2. Confirm that the Cluster Federation's service-controller is successfully connecting to and authenticating against your selected DNS provider (look for `service-controller` errors or successes in the output of `kubectl logs federation-controller-manager --namespace federation`).
3. Confirm that the Cluster Federation's service-controller is successfully creating DNS records in your DNS provider (or outputting errors in its logs explaining in more detail what's failing). -->
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 记录(或在其日志中输出错误，以更详细地解释失败原因)。
<!-- ### Matching DNS records are created in my DNS provider, but clients are unable to resolve against those names
Check that: -->
### 在我的 DNS 提供程序中创建了匹配的 DNS 记录，但是客户端无法根据这些名称进行解析
检查:
<!-- 1. The DNS registrar that manages your federation DNS domain has been correctly configured to point to your configured DNS provider's nameservers. See for example [Google Domains Documentation](https://support.google.com/domains/answer/3290309?hl=en&ref_topic=3251230) and [Google Cloud DNS Documentation](https://cloud.google.com/dns/update-name-servers), or equivalent guidance from your domain registrar and DNS provider. -->
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 提供商的等效指南。
<!-- ### This troubleshooting guide did not help me solve my problem -->
### 此疑难解答指南没有帮助我解决问题
<!-- 1. Please use one of our [support channels](/docs/tasks/debug-application-cluster/troubleshooting/) to seek assistance. -->
1. 请使用我们的 [支持渠道](/docs/tasks/debug-application-cluster/troubleshooting/)寻求帮助。
<!-- ## For more information -->
## 更多信息
<!-- * [Federation proposal](https://git.k8s.io/community/contributors/design-proposals/multicluster/federation.md) details use cases that motivated this work. -->
* [联合提议](https://git.k8s.io/community/contributors/design-proposals/multicluster/federation.md) 详细介绍了促进这项工作的用例。
content/zh/docs/tasks/federation/set-up-coredns-provider-federation.md
-254
View File
@@ -1,254 +0,0 @@
---
title: 将 CoreDNS 设置为联邦集群的 DNS 提供者
content_type: tutorial
weight: 130
---
<!--
---
title: Set up CoreDNS as DNS provider for Cluster Federation
content_type: tutorial
weight: 130
---
-->
<!-- overview -->
{{< deprecationfilewarning >}}
{{< include "federation-deprecation-warning-note.md" >}}
{{< /deprecationfilewarning >}}
<!--
This page shows how to configure and deploy CoreDNS to be used as the
DNS provider for Cluster Federation.
-->
此页面显示如何配置和部署 CoreDNS，将其用作联邦集群的 DNS 提供者
## {{% heading "objectives" %}}
<!--
* Configure and deploy CoreDNS server
* Bring up federation with CoreDNS as dns provider
* Setup CoreDNS server in nameserver lookup chain
-->
* 配置和部署 CoreDNS 服务器
* 使用 CoreDNS 作为 dns 提供者设置联邦
* 在 nameserver 查找链中设置 CoreDNS 服务器
## {{% heading "prerequisites" %}}
<!--
* You need to have a running Kubernetes cluster (which is
referenced as host cluster). Please see one of the
[getting started](/docs/setup/) guides for
installation instructions for your platform.
* Support for `LoadBalancer` services in member clusters of federation is
mandatory to enable `CoreDNS` for service discovery across federated clusters.
-->
* 你需要有一个正在运行的 Kubernetes 集群（作为主机集群引用）。请参阅[入门指南](/docs/setup/)，了解平台的安装说明。
* 必须在联邦的集群成员中支持 `LoadBalancer` 服务，用来支持跨联邦集群的 `CoreDNS` 服务发现。
<!-- lessoncontent -->
<!--
## Deploying CoreDNS and etcd charts
-->
## 部署 CoreDNS 和 etcd 图表
<!--
CoreDNS can be deployed in various configurations. Explained below is a
reference and can be tweaked to suit the needs of the platform and the
cluster federation.
-->
CoreDNS 可以部署在各种配置中。下面解释的是一个参考，可以根据平台和联邦集群的需要进行调整。
<!--
To deploy CoreDNS, we shall make use of helm charts. CoreDNS will be
deployed with [etcd](https://coreos.com/etcd) as the backend and should
be pre-installed. etcd can also be deployed using helm charts. Shown
below are the instructions to deploy etcd.
--->
为了部署 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
<!--
*Note: etcd default deployment configurations can be overridden, suiting the
host cluster.*
-->
*注意：etcd 默认部署配置可以被覆盖，适合主机集群。*
<!--
After deployment succeeds, etcd can be accessed with the
[http://etcd-cluster.my-namespace:2379](http://etcd-cluster.my-namespace:2379) endpoint within the host cluster.
-->
部署成功后，可以使用主机集群中的 [http://etcd-cluster.my-namespace:2379](http://etcd-cluster.my-namespace:2379) 端点访问 etcd。
<!--
The CoreDNS default configuration should be customized to suit the federation.
Shown below is the Values.yaml, which overrides the default
configuration parameters on the CoreDNS chart.
-->
应该定制 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"
```
<!--
The above configuration file needs some explanation:
-->
以上配置文件需要说明：
<!--
- `isClusterService` specifies whether CoreDNS should be deployed as a
cluster-service, which is the default. You need to set it to false, so
that CoreDNS is deployed as a Kubernetes application service.
- `serviceType` specifies the type of Kubernetes service to be created
for CoreDNS. You need to choose either "LoadBalancer" or "NodePort" to
make the CoreDNS service accessible outside the Kubernetes cluster.
- Disable `plugins.kubernetes`, which is enabled by default by
setting `plugins.kubernetes.enabled` to false.
- Enable `plugins.etcd` by setting `plugins.etcd.enabled` to
true.
- Configure the DNS zone (federation domain) for which CoreDNS is
authoritative by setting `plugins.etcd.zones` as shown above.
- Configure the etcd endpoint which was deployed earlier by setting
`plugins.etcd.endpoint`
-->
- `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 端点
<!--
Now deploy CoreDNS by running
helm install --namespace my-namespace --name coredns -f Values.yaml stable/coredns
Verify that both etcd and CoreDNS pods are running as expected.
-->
现在部署 CoreDNS 来运行
helm install --namespace my-namespace --name coredns -f Values.yaml stable/coredns
验证 etcd 和 CoreDNS，pod 都按预期运行。
<!--
## Deploying Federation with CoreDNS as DNS provider
-->
## 使用 CoreDNS 作为 DNS 提供者部署联邦
<!--
The Federation control plane can be deployed using `kubefed init`. CoreDNS
can be chosen as the DNS provider by specifying two additional parameters.
-->
可以使用 `kubefed init` 部署联邦控制平面。通过指定两个附加参数，可以选择 CoreDNS 作为 DNS 提供者。
--dns-provider=coredns
--dns-provider-config=coredns-provider.conf
<!--
coredns-provider.conf has below format:
-->
coredns-provider.conf 的格式如下：
[Global]
etcd-endpoints = http://etcd-cluster.my-namespace:2379
zones = example.com.
coredns-endpoints = <coredns-server-ip>:<port>
<!--
- `etcd-endpoints` is the endpoint to access etcd.
- `zones` is the federation domain for which CoreDNS is authoritative and is same as --dns-zone-name flag of `kubefed init`.
- `coredns-endpoints` is the endpoint to access CoreDNS server. This is an optional parameter introduced from v1.7 onwards.
-->
- `etcd-endpoints` 是访问 etcd 的端点。
- `zones` 是 CoreDNS 具有权威性的联邦域，它与 `kubefed init` 的 --dns-zone-name 参数相同。
- `coredns-endpoints` 是访问 CoreDNS 服务器的端点。这是从 v1.7 开始引入的一个可选参数。
{{< note >}}
<!--
`plugins.etcd.zones` in the CoreDNS configuration and the `--dns-zone-name` flag to `kubefed init` should match.
-->
CoreDNS 配置中的 `plugins.etcd.zones` 和 `kubefed init` 的 `--dns-zone-name` 参数应该匹配。
{{< /note >}}
<!--
## Setup CoreDNS server in nameserver resolv.conf chain
-->
## 在 nameserver resolv.conf 链中设置 CoreDNS 服务器
{{< note >}}
<!--
The following section applies only to versions prior to v1.7
and will be automatically taken care of if the `coredns-endpoints`
parameter is configured in `coredns-provider.conf` as described in
section above.
-->
下面的部分只适用于 v1.7 之前的版本，如果 `coredns-endpoint` 参数是
在 `coredns-provider.conf` 中配置的，就会自动处理。
{{< /note >}}
<!--
Once the federation control plane is deployed and federated clusters
are joined to the federation, you need to add the CoreDNS server to the
pod's nameserver resolv.conf chain in all the federated clusters as this
self hosted CoreDNS server is not discoverable publicly. This can be
achieved by adding the below line to `dnsmasq` container's arg in
`kube-dns` deployment.
-->
一旦部署了联邦控制平面并将联邦集群连接到联邦，
你需要将 CoreDNS 服务器添加到所有联邦集群中 pod 的 nameserver resolv.conf 链，因为这个自托管的 CoreDNS 服务器是不可公开发现的。
这可以通过在 `kube-dns` 部署中将下面的行添加到 `dnsmasq` 容器的参数中来实现。
--server=/example.com./<CoreDNS endpoint>
<!--
Replace `example.com` above with federation domain.
-->
将上面的 `example.com` 替换为联邦域。
<!--
Now the federated cluster is ready for cross-cluster service discovery!
-->
现在联邦集群已经为跨集群服务发现做好了准备！
content/zh/docs/tasks/federation/set-up-placement-policies-federation.md
-331
View File
@@ -1,331 +0,0 @@
---
title: 在联邦中设置放置策略
content_type: task
---
<!--
title: Set up placement policies in Federation
content_type: task
-->
<!-- overview -->
{{< deprecationfilewarning >}}
{{< include "federation-deprecation-warning-note.md" >}}
{{< /deprecationfilewarning >}}
<!--
This page shows how to enforce policy-based placement decisions over Federated
resources using an external policy engine.
-->
此页面显示如何使用外部策略引擎对联邦资源强制执行基于策略的放置决策。
## {{% heading "prerequisites" %}}
<!--
You need to have a running Kubernetes cluster (which is referenced as host
cluster). Please see one of the [getting started](/docs/setup/)
guides for installation instructions for your platform.
-->
您需要一个正在运行的 Kubernetes 集群(它被引用为主机集群)。有关您的平台的安装说明，请参阅[入门](/docs/setup/)指南。
<!-- steps -->
<!--
## Deploying Federation and configuring an external policy engine
-->
## Deploying 联邦并配置外部策略引擎
<!--
The Federation control plane can be deployed using `kubefed init`.
-->
可以使用 `kubefed init` 部署联邦控制平面。
<!--
After deploying the Federation control plane, you must configure an Admission
Controller in the Federation API server that enforces placement decisions
received from the external policy engine.
-->
Deploying 联邦控制平面之后，必须在联邦 API 服务器中配置一个准入控制器，该控制器强制执行从外部策略引擎接收到的放置决策。
kubectl create -f scheduling-policy-admission.yaml
<!--
Shown below is an example ConfigMap for the Admission Controller:
-->
下图是准入控制器的 ConfigMap 示例：
{{< codenew file="federation/scheduling-policy-admission.yaml" >}}
<!--
The ConfigMap contains three files:
-->
ConfigMap 包含三个文件：
<!--
* `config.yml` specifies the location of the `SchedulingPolicy` Admission
Controller config file.
* `scheduling-policy-config.yml` specifies the location of the kubeconfig file
required to contact the external policy engine. This file can also include a
`retryBackoff` value that controls the initial retry backoff delay in
milliseconds.
* `opa-kubeconfig` is a standard kubeconfig containing the URL and credentials
needed to contact the external policy engine.
-->
* `config.yml` 指定 `调度策略` 准入控制器配置文件的位置。
* `scheduling-policy-config.yml` 指定与外部策略引擎联系所需的 kubeconfig 文件的位置。
该文件还可以包含一个 `retryBackoff` 值，该值以毫秒为单位控制初始重试 backoff 延迟。
* `opa-kubeconfig` 是一个标准的 kubeconfig，包含联系外部策略引擎所需的 URL 和凭证。
<!--
Edit the Federation API server deployment to enable the `SchedulingPolicy`
Admission Controller.
-->
编辑联邦 API 服务器部署以启用 `SchedulingPolicy` 准入控制器。
kubectl -n federation-system edit deployment federation-apiserver
<!--
Update the Federation API server command line arguments to enable the Admission
Controller and mount the ConfigMap into the container. If there's an existing
`--enable-admission-plugins` flag, append `,SchedulingPolicy` instead of adding
another line.
-->
更新 Federation API 服务器命令行参数以启用准入控制器，
并将 ConfigMap 挂载到容器中。如果存在现有的 `-enable-admissionplugins` 参数，则追加 `SchedulingPolicy` 而不是添加另一行。
--enable-admission-plugins=SchedulingPolicy
--admission-control-config-file=/etc/kubernetes/admission/config.yml
<!--
Add the following volume to the Federation API server pod:
-->
将以下卷添加到联邦 API 服务器 pod：
- name: admission-config
configMap:
name: admission
<!--
Add the following volume mount the Federation API server `apiserver` container:
-->
添加以下卷挂载联邦 API 服务器的 `apiserver` 容器：
volumeMounts:
- name: admission-config
mountPath: /etc/kubernetes/admission
<!--
## Deploying an external policy engine
-->
## Deploying 外部策略引擎
<!--
The [Open Policy Agent (OPA)](http://openpolicyagent.org) is an open source,
general-purpose policy engine that you can use to enforce policy-based placement
decisions in the Federation control plane.
-->
[Open Policy Agent (OPA)](http://openpolicyagent.org) 是一个开源的通用策略引擎，
您可以使用它在联邦控制平面中执行基于策略的放置决策。
<!--
Create a Service in the host cluster to contact the external policy engine:
-->
在主机群集中创建服务以联系外部策略引擎：
kubectl create -f policy-engine-service.yaml
<!--
Shown below is an example Service for OPA.
-->
下面显示的是 OPA 的示例服务。
{{< codenew file="federation/policy-engine-service.yaml" >}}
<!--
Create a Deployment in the host cluster with the Federation control plane:
-->
使用联邦控制平面在主机群集中创建部署：
kubectl create -f policy-engine-deployment.yaml
<!--
Shown below is an example Deployment for OPA.
-->
下面显示的是 OPA 的部署示例。
{{< codenew file="federation/policy-engine-deployment.yaml" >}}
<!--
## Configuring placement policies via ConfigMaps
-->
## 通过 ConfigMaps 配置放置策略
<!--
The external policy engine will discover placement policies created in the
`kube-federation-scheduling-policy` namespace in the Federation API server.
-->
外部策略引擎将发现在 Federation API 服务器的 `kube-federation-scheduling-policy`
命名空间中创建的放置策略。
<!--
Create the namespace if it does not already exist:
-->
如果命名空间尚不存在，请创建它：
kubectl --context=federation create namespace kube-federation-scheduling-policy
<!--
Configure a sample policy to test the external policy engine:
-->
配置一个示例策略来测试外部策略引擎:
```
# 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 <preferences>.
# 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
# <head> if <body> where <body> is true if <expr-1> AND <expr-2> AND ...
# <expr-N> 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]
}
```
<!--
Shown below is the command to create the sample policy:
-->
下面显示的是创建示例策略的命令：
kubectl --context=federation -n kube-federation-scheduling-policy create configmap scheduling-policy --from-file=policy.rego
<!--
This sample policy illustrates a few key ideas:
-->
这个示例策略说明了一些关键思想：
<!--
* Placement policies can refer to any field in Federated resources.
* Placement policies can leverage external context (for example, Cluster
metadata) to make decisions.
* Administrative policy can be managed centrally.
* Policies can define simple interfaces (such as the `requires-pci` annotation) to
avoid duplicating logic in manifests.
-->
* 位置策略可以引用联邦资源中的任何字段。
* 放置策略可以利用外部上下文(例如，集群元数据)来做出决策。
* 管理策略可以集中管理。
* 策略可以定义简单的接口(例如 `requirements -pci` 注解)，以避免在清单中重复逻辑。
<!--
## Testing placement policies
-->
## 测试放置政策
<!--
Annotate one of the clusters to indicate that it is PCI certified.
-->
注释其中一个集群以表明它是经过 PCI 认证的。
kubectl --context=federation annotate clusters cluster-name-1 pci-certified=true
<!--
Deploy a Federated ReplicaSet to test the placement policy.
-->
部署联邦副本来测试放置策略。
{{< codenew file="federation/replicaset-example-policy.yaml" >}}
<!--
Shown below is the command to deploy a ReplicaSet that *does* match the policy.
-->
下面显示的命令用于部署与策略匹配的副本集。
kubectl --context=federation create -f replicaset-example-policy.yaml
<!--
Inspect the ReplicaSet to confirm the appropriate annotations have been applied:
-->
检查副本集以确认已应用适当的注解：
kubectl --context=federation get rs nginx-pci -o jsonpath='{.metadata.annotations}'
content/zh/docs/tutorials/kubernetes-basics/scale/scale-intro.html
+2 -2
View File
@@ -126,8 +126,8 @@ weight: 10
<div class="row">
<div class="col-md-12">
<!-- <a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/scale-interactive/" role="button">Start Interactive Tutorial <span class="btn__next">›</span></a> -->
<a class="btn btn-lg btn-success" href="/zh/docs/tutorials/kubernetes-basics/scale-interactive/" role="button">开始互动教程 <span class="btn__next">›</span></a>
<!-- <a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/scale/scale-interactive/" role="button">Start Interactive Tutorial <span class="btn__next">›</span></a> -->
<a class="btn btn-lg btn-success" href="/zh/docs/tutorials/kubernetes-basics/scale/scale-interactive/" role="button">开始互动教程 <span class="btn__next">›</span></a>
</div>
</div>
content/zh/docs/tutorials/services/source-ip.md
+1 -1
View File
@@ -150,7 +150,7 @@ service/nodeport exposed
```console
NODEPORT=$(kubectl get -o jsonpath="{.spec.ports[0].nodePort}" services nodeport)
NODES=$(kubectl get nodes -o jsonpath='{ $.items[*].status.addresses[?(@.type=="ExternalIP")].address }')
NODES=$(kubectl get nodes -o jsonpath='{ $.items[*].status.addresses[?(@.type=="InternalIP")].address }')
```
如果你的集群运行在一个云服务上，你可能需要为上面报告的 `nodes:nodeport` 开启一条防火墙规则。