2021-03-30 16:26:01 +08:00
# 集群联邦（ ）
2020-03-06 13:49:15 +08:00
2020-12-11 21:15:53 +08:00
Kubernetes 从 1.8 版本起就声称单集群最多可支持 5000 个节点和 15 万个 Pod， ， ， ， （ ）
2018-02-24 11:47:55 +08:00
2021-03-30 16:26:01 +08:00
## 为什么要使用集群联邦
2018-02-24 11:47:55 +08:00
Federation 使管理多个集群变得简单。它通过提供两个主要构建模块来实现：
- 跨集群同步资源：
- 跨集群服务发现：
Federation 还可以提供一些其它用例：
- 高可用：通过在集群间分布负载并自动配置 DNS 服务和负载均衡，
- 避免厂商锁定： ，
2020-12-11 21:15:53 +08:00
Federation 对于单个集群没有用处。基于下面这些原因你可能会需要多个集群：
2018-02-24 11:47:55 +08:00
- 低延迟：通过在多个区域部署集群可以最大限度减少区域近端用户的延迟。
2020-12-11 21:15:53 +08:00
- 故障隔离：拥有多个小集群可能比单个大集群更利于故障隔离（例如：在云服务提供商的不同可用区中的多个集群）。
- 可伸缩性：单个集群有可伸缩性限制（对于大多数用户这不是典型场景。更多细节请参考 [Kubernetes 弹性伸缩与性能目标 ](https://github.com/kubernetes/community/blob/master/sig-scalability/goals.md )）。
- 混合云：你可以在不同的云服务提供商或本地数据中心中拥有多个集群。
2018-02-24 11:47:55 +08:00
### 警告
虽然 federation 有很多吸引人的使用案例，但也有一些注意事项：
- 增加网络带宽和成本：
- 减少跨集群隔离：
- 成熟度： Issue 88 ](https://github.com/kubernetes/kubernetes/issues/88 ) 列举了团队目前正忙于解决的与系统相关的已知问题。
### 混合云能力
2020-12-11 21:15:53 +08:00
Kubernetes 集群 federation 可以包含运行在不同云服务提供商（例如 Google Cloud、AWS） （
2018-02-24 11:47:55 +08:00
2020-12-11 21:15:53 +08:00
此后，你的 API 资源就可以跨越不同的集群和云服务提供商。
2018-02-24 11:47:55 +08:00
## 单个集群范围
2020-12-11 21:15:53 +08:00
在诸如 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 集群中的所有虚拟机应该位于相同的可用区，因为：
2018-02-24 11:47:55 +08:00
- 与拥有单个全局 Kubernetes 集群相比，单点故障更少。
- 与跨可用区集群相比，推测单区域集群的可用性属性更容易。
- 当 Kubernetes 开发人员设计系统时（例如对延迟，带宽或相关故障进行假设），它们假设所有的机器都在一个单一的数据中心，或以其它方式紧密连接。
在每个可用区域同时拥有多个集群也是可以的，但总体而言，我们认为少一点更好。 选择较少集群的理由是：
- 某些情况下，在一个集群中拥有更多的节点可以改进 Pod 的装箱打包（较少资源碎片）。
- 减少运维开销（尽管随着运维工具和流程的成熟，优势已经减少）。
- 减少每个集群固定资源成本的开销，例如 apiserver 虚拟机（但对于大中型集群的整体集群成本来说百分比很小）。
拥有多个集群的原因包括：
- 严格的安全策略要求将一类工作与另一类工作隔离开来（ ， （ ） ）
- 对新的 Kubernetes 发行版或其它集群软件进行灰度测试。
## 选择正确的集群数量
Kubernetes 集群数量的选择可能是一个相对静态的选择，只是偶尔重新设置。相比之下，依据负载情况和增长，集群的节点数量和 service 的 pod 数量可能会经常变化。
2020-12-11 21:15:53 +08:00
要选择集群的数量，首先要确定使用哪些区域，以便为所有终端用户提供足够低的延迟，以在 Kubernetes 上运行服务， （ ， ） ， `R` 。
2018-02-24 11:47:55 +08:00
2020-12-11 21:15:53 +08:00
其次，决定在整体仍然可用的前提下，可以同时有多少集群不可用。将不可用集群的数量称为 `U` 。如果你不能确定，那么 1 是一个不错的选择。
2018-02-24 11:47:55 +08:00
2020-12-11 21:15:53 +08:00
如果在集群故障的情形下允许负载均衡将流量引导到任何区域，则至少需要有比 `R` 或 `U + 1` 数量更大的集群。如果不行的话（例如希望在集群发生故障时对所有用户确保低延迟），那么你需要有数量为 `R * (U + 1)` 的集群（`R` 个区域，每个中有 `U + 1` 个集群）。无论如何，请尝试将每个集群放在不同的区域中。
2018-02-24 11:47:55 +08:00
2020-12-11 21:15:53 +08:00
最后，如果你的任何集群需要比 Kubernetes 集群最大建议节点数更多的节点，那么你可能需要更多的集群。 Kubernetes v1.3 支持最多 1000 个节点的集群。 Kubernetes v1.8 支持最多 5000 个节点的集群。
2018-02-24 11:47:55 +08:00
2021-03-30 16:26:01 +08:00
## Kubernetes 集群联邦的演进
[Kubernetes 官方博客的文章 ](https://kubernetes.io/blog/2018/12/12/kubernetes-federation-evolution/ )中介绍了 Kubernetes 集群联邦的演进，该项目是在 SIG Multicluster 中进行的， ，
- 在集群层面重新实施 Kubernetes API 的困难，因为 Federation 的特定扩展存储在注释中。
- 由于 Kubernetes API 的1:1仿真， （ ） （ ）
- 没有固定的 GA 路径， ； ， ，
随着 Federation 特定的 API 架构和社区的努力，这些想法有了进一步的发展，改进为 Federation v2。请注意，
下面将带你了解 Federation v2 背后的考量。
### 将任意资源联合起来
联邦的主要目标之一是能够定义 API 和 API 组，其中包含联邦任何给定 Kubernetes 资源所需的基本原则。这是至关重要的，因为 CRD 已经成为扩展 Kubernetes API 的一种主流方式。
Multicluster SIG 得出了 Federation API 和 API 组的共同定义，即 "一种将`规范的` Kubernetes API 资源分配到不同集群的机制"。最简单的分布形式可以想象为这种'规范的 Kubernetes API 资源'在联邦集群中的简单传播。除了这种简单的 Kubernetes 资源传播之外，有心的读者当然可以看出更复杂的机制。
在定义 Federation API 的构建模块的历程中，最早期的目标也演化为 "能够创建一个简单的联邦，也就是任何 Kubernetes 资源或 CRD 的简单传播，几乎不需要编写代码"。随后，核心 API 组进一步定义了构件，即每个给定的 Kubernetes 资源有一个 `Template` 资源、一个 `Placement` 资源和一个 `Override` 资源，一个 `TypeConfig` 来指定给定资源的同步或不同步，以及执行同步的相关控制器。更多细节将在后文中介绍。进一步的章节还将谈到能够遵循分层行为，更高级别的 Federation API 消耗这些核心构件的行为，而用户能够消耗整个或部分 API 和相关控制器。最后， （ ） ，
能够 "轻松地联合任意 Kubernetes 资源"，以及一个解耦的 API，
2021-03-31 12:26:12 +08:00
### 联邦服务与跨集群服务发现
Kubernetes 服务在构建微服务架构时非常有用。人们明显希望跨越集群、可用区、区域和云的边界来部署服务。跨集群的服务提供了地理分布，实现了混合和多云场景，并提高了超越单一集群部署的高可用性水平。希望其服务跨越一个或多个（可能是远程）集群的客户，需要在集群内外以一致的方式提供服务。
Federated Service 的核心是包含一个 Template（ ） （ ） （ ） （ ）
注意：联邦服务必须是 LoadBalancer 类型，以便它可以跨集群发现。
### Pod 如何发现联邦服务
默认情况下， `或 ` some-other-service.other-namespace` 等 DNS 查询会自动扩展并正确解析到本地集群中运行的服务的相应 IP。
随着联邦服务和跨集群服务发现的引入，这个概念被扩展到全局覆盖在你的集群联邦中所有集群中运行的 Kubernetes 服务。为了利用这个扩展的范围，我们需要使用一个稍微不同的 DNS 名称（例如 `myservice.mynamespace.myfederation` ）来解析联邦服务。使用不同的 DNS 名还可以避免现有的应用意外地穿越区域网络而会产生不必要的网络费用或延迟。
让我们看一个例子，使用一个名为 nginx 的服务。
在 `us-central1-a` 可用区的集群中的一个 pod 需要联系我们的 nginx 服务。它现在可以使用服务的联邦 DNS 名，即 `nginx.mynamespace.myfederation` ，而不是使用服务的传统集群本地 DNS 名（即 `nginx.mynamespace` 自动扩展为 `nginx.mynamespace.svc.cluster.local` ）。这将被自动扩展并解析到离我的 nginx 服务最近的健康 shard。如果本地集群中存在一个健康的 shard， ）
如果服务在本地集群中不存在（或者存在但没有健康的后端 pod） ， `nginx.mynamespace.myfederation.svc.us-central1-a.example.com` 。在幕后，这可以找到离我们的可用区最近的一个 shard 的外部 IP。这个扩展是由集群本地 DNS 服务器自动执行的，它返回相关的 CNAME 记录。这就导致了对 DNS 记录的层次结构的遍历，并最终找到附近联邦服务的一个外部 IP。
也可以通过明确指定适当的 DNS 名称， ， ， ， ，
### 从联邦集群之外的其他客户端发现联邦服务
对于外部客户端，目前还不能实现所述自动 DNS 扩展。外部客户需要指定联邦服务的一个完全限定的 DNS 名称，无论是区域、可用区还是全局名称。为了方便起见，通常情况下，在服务中手动配置额外的静态 CNAME 记录是一个好主意，例如：
| 短名称 | CNAME |
| ----------------- | ----------------------------------------------------------- |
| eu.nginx.acme.com | nginx.mynamespace.myfederation.svc.europe-west1.example.com |
| us.nginx.acme.com | nginx.mynamespace.myfederation.svc.us-central1.example.com |
| nginx.acme.com | nginx.mynamespace.myfederation.svc.example.com |
这样一来，你的客户就可以始终使用左边的短名称，并始终自动路由到离他们位置最近的健康 shard。所有所需的故障转移都由 Kubernetes 集群联邦为你自动处理。
2021-03-30 16:26:01 +08:00
## 架构概览
Kubernetes Cluster Federation 又名 KubeFed 或 Federation v2， （ ）
由于 Federation 试图解决一系列复杂的问题，
上图中展示了集群联邦的过程：
- 配置需要联邦的集群
- 配置需要在集群中传播的 API 资源
- 配置 API 资源如何分配到不同的集群
- 对集群中 DNS 记录注册
相较于 v1， ，
目前 KubeFed 通过 CRD 方式新增了四种 API 群组来实现联邦机制的核心功能：
| API Group | 用途 |
| ------------------------------ | ----------------------------------------------------- |
| core.kubefed.k8s.io | 集群组态、联邦资源组态、KubeFed Controller 设定档等。 |
| types.kubefed.k8s.io | 被联邦的 Kubernetes API 资源。 |
| scheduling.kubefed.k8s.io | 副本编排策略。 |
| multiclusterdns.kubefed.k8s.io | 跨集群服务发现设定。 |
在这些核心功能中，我们必须先了解一些 KebeFed 提出的基础概念后，才能更清楚知道 KubeFed 是如何运作的。
### Cluster Configuration
用来定义哪些 Kubernetes 集群要被联邦。可通过 kubefedctl join/unjoin 来加入/删除集群，当成功加入时，会建立一个 KubeFedCluster 组件来储存集群相关信息，如 API Endpoint、CA Bundle 等。这些信息会被用在 KubeFed Controller 存取不同 Kubernetes 集群上，以确保能够建立 Kubernetes API 资源，示意图如下所示。
在 Federation 中，会区分 Host 与 Member 两种类型集群。
- Host : 用于提供 KubeFed API 与控制平面的集群。
- Member : 通过 KubeFed API 注册的集群，并提供相关身份凭证来让 KubeFed Controller 能够存取集群。Host 集群也可以作为 Member 被加入。
### Type Configuration
定义了哪些 Kubernetes API 资源要被用于联邦管理。比如说想将 ConfigMap 资源通过联邦机制建立在不同集群上时，就必须先在 Federation Host 集群中，通过 CRD 建立新资源 FederatedConfigMap， （ ） ，
```yaml
apiVersion: core.kubefed.k8s.io/v1beta1
kind: FederatedTypeConfig
metadata:
name: configmaps
namespace: kube-federation-system
spec:
federatedType:
group: types.kubefed.k8s.io
kind: FederatedConfigMap
pluralName: federatedconfigmaps
scope: Namespaced
version: v1beta1
propagation: Enabled
targetType:
kind: ConfigMap
pluralName: configmaps
scope: Namespaced
version: v1
```
若想新增 CRD 的 Federated API 的话，可通过 `kubefedctl enable <res>` 指令来建立，如下:
```sh
$ kubefedctl enable etcdclusters
$ kubectl api-resources | grep etcd
etcdclusters etcd etcd.database.coreos.com true EtcdCluster
federatedetcdclusters fetcd types.kubefed.k8s.io true FederatedEtcdCluster
$ kubectl -n kube-federation-system get federatedtypeconfigs | grep etcd
etcdclusters.etcd.database.coreos.com 3m16s
```
而一个 Federated 资源一般都会具备三个主要功能，这些信息能够在 spec 中由使用者自行定义，如下范例：
```yaml
apiVersion: types.kubefed.k8s.io/v1beta1
kind: FederatedDeployment
metadata:
name: test-deployment
namespace: test-namespace
spec:
template: # 定义 Deployment 的所有內容，可理解成 Deployment 与 Pod 之间的关联。
metadata:
labels:
app: nginx
spec:
...
placement:
clusters:
- name: cluster2
- name: cluster1
overrides:
- clusterName: cluster2
clusterOverrides:
- path: spec.replicas
value: 5
```
- Placement： `spec.placement` 定义了两个集群时，这些集群将被同步建立相同的 Deployment。另外也支持用 `spec.placement.clusterSelector` 的方式来选择要放置的集群。
- Override： `spec.template` 内容。如部署 FederatedDeployment 到不同公有云上的集群时，就能通过 `spec.overrides` 来调整 Volume 或副本数。
注意：目前 Override 不支持 List（ ） `spec.template.spec.containers [0].image` 。
### Scheduling
2021-03-31 12:26:12 +08:00
KubeFed 提供了一种自动化机制来将工作负载实例分散到不同的集群中，这能够基于总副本数与集群的定义策略来将 Deployment 或 ReplicaSet 资源进行编排。编排策略是通过建立 `ReplicaSchedulingPreference` （ ） ， `ReplicaSchedulingPreferences` 的用户指南 ](https://github.com/kubernetes-sigs/kubefed/blob/master/docs/userguide.md#replicaschedulingpreference )中找到。
2021-03-30 16:26:01 +08:00
以下为一个 RSP 范例。假设有三个集群被联邦，名称分别为 ap-northeast、us-east 与 us-west。
```yaml
apiVersion: scheduling.kubefed.k8s.io/v1alpha1
kind: ReplicaSchedulingPreference
metadata:
name: test-deployment
namespace: test-ns
spec:
targetKind: FederatedDeployment
totalReplicas: 15
clusters:
"*":
weight: 2
maxReplicas: 12
ap-northeast:
minReplicas: 1
maxReplicas: 3
weight: 1
```
该配置示意图如下所示。
当该范例建立后， `spec.overrides` 内容以修改每个集群的副本数，最后再由 KubeFed Sync Controller 来同步至每个集群的 Deployment。以上面为例， ，
注意：
- 若 `spec.clusters` 未定义的话，则预设为 `{“*”:{Weight: 1}}` 。
- 若有定义 `spec.replicas` 的 overrides 时，副本会以 RSP 为优先考量。
2021-03-31 12:26:12 +08:00
- 分配的计算机制可以参考 `kubefed/pkg/controller/util/planner/planner.go` 。
2021-03-30 16:26:01 +08:00
### Multi-cluster DNS
KubeFed 提供了一组 API 资源，以及 Controllers 来实现跨集群 Service/Ingress 的 DNS records 自动产生机制，并结合 ExternalDNS 来同步更新至 DNS 服务供应商。以下为简单例子：
```yaml
apiVersion: multiclusterdns.kubefed.k8s.io/v1alpha1
kind: Domain
metadata:
name: test
namespace: kube-federation-system
domain: k8s.example.com
2018-02-24 11:47:55 +08:00
---
2021-03-30 16:26:01 +08:00
apiVersion: multiclusterdns.kubefed.k8s.io/v1alpha1
kind: ServiceDNSRecord
metadata:
name: nginx
namespace: development
spec:
domainRef: test
recordTTL: 300
```
首先假设已建立一个名称为 nginx 的 FederatedDeployment， ，
若是 Ingress 的话，会由 IngressDNSRecord 文件取代，并由 Ingress DNS Controller 收集信息。
## 参考
2018-02-24 11:47:55 +08:00
2021-03-30 16:26:01 +08:00
- [Kubernetes Federation v2 - github.com ](https://github.com/kubernetes-sigs/kubefed )
2022-02-22 16:27:14 +08:00
- [Kubernetes Federation Evolution - kuberentes.io ](https://kubernetes.io/blog/2018/12/12/kubernetes-federation-evolution/ )
