update federation
Jimmy Song
parent
3f0b5b549a
commit
7c794471d8
|
|
@ -1,12 +1,6 @@
|
|||
|
||||
# 集群联邦
|
||||
**Deprecated**
|
||||
>
|
||||
Federation 的V1版本已经归档不再维护和更新，且官方也不再推荐继续使用。故以下内容仅作为历史存档，如果需要了解更多的Federation资料，请参考：[Kubernetes Federation v2](https://github.com/kubernetes-sigs/federation-v2).
|
||||
|
||||
-----
|
||||
|
||||
Kubernetes v1.9声称单集群最多可支持5000个节点和15万个Pod，我相信很少有公司会部署如此庞大的一个单集群，总有很多情况下因为各种各样的原因我们可能会部署多个集群，但是有时候有想将他们统一起来管理，这时候就需要用到集群联邦（Federation）。
|
||||
Kubernetes 从 1.8 版本起就声称单集群最多可支持 5000 个节点和 15 万个 Pod，我相信很少有公司会部署如此庞大的一个单集群，总有很多情况下因为各种各样的原因我们可能会部署多个集群，但是有时候有想将他们统一起来管理，这时候就需要用到集群联邦（Federation）。
|
||||
|
||||
## 为什么要使用 federation
|
||||
|
||||
|
|
@ -20,12 +14,12 @@ Federation 还可以提供一些其它用例：
|
|||
- 高可用：通过在集群间分布负载并自动配置 DNS 服务和负载均衡，federation 最大限度地减少集群故障的影响。
|
||||
- 避免厂商锁定：通过更简单的跨集群应用迁移方式，federation 可以防止集群厂商锁定。
|
||||
|
||||
Federation 对于单个集群没有用处。基于下面这些原因您可能会需要多个集群：
|
||||
Federation 对于单个集群没有用处。基于下面这些原因你可能会需要多个集群：
|
||||
|
||||
- 低延迟：通过在多个区域部署集群可以最大限度减少区域近端用户的延迟。
|
||||
- 故障隔离：拥有多个小集群可能比单个大集群更利于故障隔离（例如：在云服务提供商的不同可用区中的多个集群）。详情请参考 [多集群指南](https://kubernetes.io/docs/concepts/cluster-administration/federation)。
|
||||
- 可伸缩性：单个集群有可伸缩性限制（对于大多数用户这不是典型场景。更多细节请参考 [Kubernetes 弹性伸缩与性能目标](https://git.k8s.io/community/sig-scalability/goals.md)）。
|
||||
- [混合云](https://kubernetes.io/docs/concepts/cluster-administration/federation/)：您可以在不同的云服务提供商或本地数据中心中拥有多个集群。
|
||||
- 故障隔离：拥有多个小集群可能比单个大集群更利于故障隔离（例如：在云服务提供商的不同可用区中的多个集群）。
|
||||
- 可伸缩性：单个集群有可伸缩性限制（对于大多数用户这不是典型场景。更多细节请参考 [Kubernetes 弹性伸缩与性能目标](https://github.com/kubernetes/community/blob/master/sig-scalability/goals.md)）。
|
||||
- 混合云：你可以在不同的云服务提供商或本地数据中心中拥有多个集群。
|
||||
|
||||
### 警告
|
||||
|
||||
|
|
@ -37,25 +31,13 @@ Federation 对于单个集群没有用处。基于下面这些原因您可能会
|
|||
|
||||
### 混合云能力
|
||||
|
||||
Kubernetes 集群 federation 可以包含运行在不同云服务提供商（例如 Google Cloud、AWS）及本地（例如在 OpenStack 上）的集群。您只需要按需在适合的云服务提供商和/或地点上简单的创建集群，然后向 Federation API Server 注册每个集群的 API endpoint 和凭据即可。
|
||||
Kubernetes 集群 federation 可以包含运行在不同云服务提供商（例如 Google Cloud、AWS）及本地（例如在 OpenStack 上）的集群。你只需要按需在适合的云服务提供商和 / 或地点上简单的创建集群，然后向 Federation API Server 注册每个集群的 API endpoint 和凭据即可。
|
||||
|
||||
此后，您的 [API 资源](https://kubernetes.io/docs/concepts/cluster-administration/federation/) 就可以跨越不同的集群和云服务提供商。
|
||||
|
||||
## 设置 federation
|
||||
|
||||
为了能够联合（federate）多个集群，首先需要建立一个 federation 控制平面。请按照 [设置指南](https://kubernetes.io/docs/tutorials/federation/set-up-cluster-federation-kubefed) 设置 federation 控制平面。
|
||||
|
||||
## 级联删除
|
||||
|
||||
Kubernetes 1.6 版本包括了对联邦资源（federated resources）级联删除的支持。通过级联删除，当您从 federation 控制平面删除一个资源时，会同时删除所有底层集群中对应的资源。
|
||||
|
||||
当使用 REST API 时，级联删除没有默认开启。要想在使用 REST API 从 federation 控制平面删除资源时启用级联删除，请设置 `DeleteOptions.orphanDependents=false` 选项。使用 `kubectl delete` 时默认使用级联删除。您可以通过运行 `kubectl delete --cascade=false` 来禁用该功能。
|
||||
|
||||
注意：Kubernetes 1.5 版本支持的级联删除仅支持部分 federation 资源。
|
||||
此后，你的 API 资源就可以跨越不同的集群和云服务提供商。
|
||||
|
||||
## 单个集群范围
|
||||
|
||||
在诸如 Google Compute Engine 或者 Amazon Web Services 等 IaaS 服务提供商中，虚拟机存在于 [区域](https://cloud.google.com/compute/docs/zones) 或 [可用区](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html) 上。我们建议 Kubernetes 集群中的所有虚拟机应该位于相同的可用区，因为：
|
||||
在诸如 Google Compute Engine 或者 Amazon Web Services 等 IaaS 服务提供商中，虚拟机存在于 [区域（Zone）](https://cloud.google.com/compute/docs/zones) 或 [可用区（Availability Zone）](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html) 上。我们建议 Kubernetes 集群中的所有虚拟机应该位于相同的可用区，因为：
|
||||
|
||||
- 与拥有单个全局 Kubernetes 集群相比，单点故障更少。
|
||||
- 与跨可用区集群相比，推测单区域集群的可用性属性更容易。
|
||||
|
|
@ -76,16 +58,14 @@ Kubernetes 1.6 版本包括了对联邦资源（federated resources）级联删
|
|||
|
||||
Kubernetes 集群数量的选择可能是一个相对静态的选择，只是偶尔重新设置。相比之下，依据负载情况和增长，集群的节点数量和 service 的 pod 数量可能会经常变化。
|
||||
|
||||
要选择集群的数量，首先要确定使用哪些区域，以便为所有终端用户提供足够低的延迟，以在 Kubernetes 上运行服务（如果您使用内容分发网络（Content Distribution Network，CDN），则 CDN 托管内容的时延要求不需要考虑）。法律问题也可能影响到这一点。例如，拥有全球客户群的公司可能会决定在美国、欧盟、亚太和南亚地区拥有集群。我们将选择的区域数量称为 `R`。
|
||||
要选择集群的数量，首先要确定使用哪些区域，以便为所有终端用户提供足够低的延迟，以在 Kubernetes 上运行服务，如果你使用内容分发网络（Content Distribution Network，CDN），则 CDN 托管内容的时延要求不需要考虑。法律问题也可能影响到这一点。例如，拥有全球客户群的公司可能会决定在美国、欧盟、亚太和南亚地区拥有集群。我们将选择的区域数量称为 `R`。
|
||||
|
||||
其次，决定在整体仍然可用的前提下，可以同时有多少集群不可用。将不可用集群的数量称为 `U`。如果您不能确定，那么 1 是一个不错的选择。
|
||||
其次，决定在整体仍然可用的前提下，可以同时有多少集群不可用。将不可用集群的数量称为 `U`。如果你不能确定，那么 1 是一个不错的选择。
|
||||
|
||||
如果在集群故障的情形下允许负载均衡将流量引导到任何区域，则至少需要有比 `R` 或 `U + 1` 数量更大的集群。如果不行的话（例如希望在集群发生故障时对所有用户确保低延迟），那么您需要有数量为 `R * (U + 1)` 的集群（`R` 个区域，每个中有 `U + 1` 个集群）。无论如何，请尝试将每个集群放在不同的区域中。
|
||||
如果在集群故障的情形下允许负载均衡将流量引导到任何区域，则至少需要有比 `R` 或 `U + 1` 数量更大的集群。如果不行的话（例如希望在集群发生故障时对所有用户确保低延迟），那么你需要有数量为 `R * (U + 1)` 的集群（`R` 个区域，每个中有 `U + 1` 个集群）。无论如何，请尝试将每个集群放在不同的区域中。
|
||||
|
||||
最后，如果您的任何集群需要比 Kubernetes 集群最大建议节点数更多的节点，那么您可能需要更多的集群。 Kubernetes v1.3 支持最多 1000 个节点的集群。 Kubernetes v1.8 支持最多 5000 个节点的集群。
|
||||
最后，如果你的任何集群需要比 Kubernetes 集群最大建议节点数更多的节点，那么你可能需要更多的集群。 Kubernetes v1.3 支持最多 1000 个节点的集群。 Kubernetes v1.8 支持最多 5000 个节点的集群。
|
||||
|
||||
---
|
||||
|
||||
原文地址：https://kubernetes.io/docs/concepts/cluster-administration/federation/
|
||||
|
||||
译文地址：https://k8smeetup.github.io/docs/concepts/cluster-administration/federation/
|
||||
注意：Federation V1 版本已经归档不再维护和更新，且官方也不再推荐继续使用。如果需要了解更多的 Federation 资料，请参考：[Kubernetes Federation v2](https://github.com/kubernetes-sigs/kubefed)。
|
||||
Loading…
Reference in New Issue