Karmada多集群管理方案

2023-11-27 约 3100 字预计阅读 7 分钟 - 次阅读

`Kubernetes` 衍变

在云原生时代，Kubernetes 作为一项核心技术已成为现代应用程序架构的基础，越来越多的企业使用 Kubernetes 作为容器编排系统，其成为容器编排事实标准得益于 Kubernetes 的主要有以下几个原因：

自动化: Kubernetes 实现了容器的部署、扩展、负载均衡、故障恢复、滚动更新等操作的自动化，极大地简化了应用程序的管理和维护工作。这种自动化也提升了应用程序的弹性和可用性。
可移植性: Kubernetes 基于容器的架构模型，使得应用无需重新编码或更新配置就可以在任何云平台、物理机或者虚拟机中运行。
生态系统: Kubernetes 作为一个成功地开源项目，拥有强大的社区支持和生态系统，使其可以获得更好的创新、优化和安全性保障。从社区中，我们可以找到各种插件和工具，为开发者提供了丰富的选择和扩展性。

单 `Kubernetes` 集群到多 `Kubernetes` 集群

随着企业发展，企业中的应用也变得越来越复杂，需要区分不同环境、多机房、混合云、异地多活、全球各地域数据合规差异等，多 Kubernetes 集群可以在不同的云平台、不同的数据中心、不同的网络环境和不同的物理基础设施中部署，以满足不同的应用程序和业务需求。但随着集群数量的增加，也面临着诸多挑战

集群管理复杂性
应用管理成本
跨集群网络和服务通信

multi-cluster

multi-cloud

多 `Kubernetes` 集群到 `Kubernetes` 多集群

为了解决上面的种种挑战，衍变出了 Kubernetes 多集群概念，Kubernetes 多集群和多 Kubernetes 集群是两个不同的概念，社区也将其称为 Kubernetes 联邦。

Kubernetes 联邦是将多个 Kubernetes 集群连接在一起，以便协同工作和实现跨集群资源和应用的统一管理、跨地域和跨云的故障切换、根据实际需求动态分配资源降低成本、提升业务的灵活性和扩展性。

解决方案

集群管理复杂性

使用集中式的多集群管理平台，在一个统一的界面中管理多云混合云中的 Kubernetes 集群，提供集群创建、配置、监控和故障排查的功能，使集群管理变得更加简单和高效，同时提高集群的可靠性和可用性。例如社区中的 Kubesphere 与 Rancher 和公有云厂商 AWS 的 EKS 、腾讯云的 TKE 、阿里云的 ACK 等。

应用管理

使用自动化的多集群应用编排和管理平台，解决多集群、多云环境下应用程序的快速部署、扩展和管理问题，保证应用程序的可靠性。

除了上面提到多集群管理平台提供了应用管理能力以外，还有如 Kubernetes Federation（发展了2个版本,于 22 年 8 月已存档）、Karmada 和字节开源不久的 KubeAdmiral 等开源多集群应用管理平台。

跨集群网络和服务通信

降低多集群环境中的网络复杂性。使用服务网格技术，管理跨多个集群的服务流量、安全性和可观测性，实现跨集群的服务发现和通信；或者采用跨集群的网络解决方案实现网络互通。

服务网格技术有 Istio、Linkerd、Flomesh 、Kuma、Mosh 等，网络解决方案有 Submariner。

`Karmada` 是什么?

开源解决方案 Karmada 是基于 Kubernetes 的多集群管理方案，支持跨多个 Kubernetes 集群的资源调度、服务发现、负载均衡、故障转移、资源管理、策略执行等功能。

`Karmada` 架构

Karmada的架构如下图所示:

karmada-arch

`Karmada` 控制平面组件

Karmada API Server

Karmada API 服务器是直接使用 Kubernetes 的 kube-apiserver 实现的，因此 Karmada 与 Kubernetes API 自然兼容。这也使得 Karmada 更容易实现与 Kubernetes 生态系统的集成，例如允许用户使用 kubectl 来操作 Karmada、与 ArgoCD 集成、与 Flux 集成等等。

Karmada Controller Manager

Karmada 控制器管理器运行了各种自定义控制器进程。

控制器负责监视Karmada对象，并与底层集群的API服务器通信，以创建原生的 Kubernetes 资源

202312071711253

Karmada Scheduler

karmada-scheduler 负责将 Kubernetes 原生API资源对象（以及CRD资源）调度到成员集群。

调度器依据策略约束和可用资源来确定哪些集群对调度队列中的资源是可用的，然后调度器对每个可用集群进行打分排序，并将资源绑定到最合适的集群。

ETCD

ETCD 存储了 karmada API 对象，API Server 是所有其他组件通讯的 REST 端点，Karmada Controller Manager 根据您通过 API 服务器创建的 API 对象执行操作

karmada-arch

Karmada的关键特性

跨云多集群多模式管理

安全隔离

为每个集群创建一个 namespace，以karmada-es-为前缀

多模式

Push模式
Pull模式

多云支持(Kubernetes规范)

20231128103546

多策略的多集群调度

自定义集群调度策略

不同调度策略下的集群分发能力

ClusterAffinity：基于 ClusterName、Label、Field 的定向调度。
Toleration：基于 Taint 和 Toleration 的调度。
SpreadConstraint：基于集群拓扑的调度。
ReplicasScheduling：针对有实例的工作负载的复制模式与拆分模式。

差异化配置（ OverridePolicy ）

ImageOverrider：镜像的差异化配置。
ArgsOverrider：运行参数的差异化配置。
CommandOverrider：运行命令的差异化配置。
PlainText：自定义的差异化配置。

支持重调度

Descheduler（karmada-descheduler）：根据成员集群内实例状态变化触发重调度。
Scheduler-estimator(karmada-scheduler-estimator)：为调度器提供更精确的成员集群运行实例的期望状态。

overall-scheduling

Scheduler Code Analysis

跨集群资源重调度

如果一个成员集群没有足够的资源容纳其中的 Pod，Karmada 会重新调度 Pod。整体的重调度流程如下图所示 overall-rescheduling

跨集群服务治理

跨集群服务调用

跨集群服务调用需要创建 ServiceExporter 、ServiceImporter 和 PropagationPolicy 等多个资源，使用相对复杂；

目前 Karmada 社区提案引入 MultiClusterService 一种新的 API 资源，它允许用户在多个集群中运行服务，并通过一个统一的入口进行访问，提案详细可以查看[7],具体实现[8]

MultiClusterService

跨集群Failover

为了提高业务的高可用性，应用服务可能部署在多个不同的集群中，当集群发生故障或者用户不希望在某个集群运行负载，将集群标记不可用，并添加污点。Karmada 检测到成员集群故障后，会将故障集群中的工作负载驱逐并迁移到合适的其他成员集群中。

Failover

全局统一资源视图

20231128103450

Karmada 部署方案

复用 `Kube ApiServer`

Deploy1

优点:

复用 Kube ApiServer 的能力，可以减少 ApiServer 和 ETCD 资源成本;

不足:

尚未经过 Karmada 社区的全面测试，社区也没有相关测试计划;
会增加 Karmada 系统的计算成本,以 Deployment 为例采用 resource template 后，kube-controller 会为 Deployment 创建 Pods 并持续更新状态，Karmada 系统也会协调这些变化，所以可能会发生冲突,详细查看[6];
架构复杂度高，增加维护难度;

控制面独立集群

Deploy2

优点:

控制面独立于集群,控制面和数据面分离，整体架构清晰，可以方便地进行升级和维护;
控制面异常不影响业务应用正常运行；
社区主流方式,社区支持;

不足:

资源成本增加;

Karmada && Submariner

202312131346058

Karmada 负责资源分发，Submariner 负责服务发现和网络互通,如果整个数据面网络已经互通可以不开启网络互通功能

优点:

MCS-Controller控制器无需重复造轮子，Submariner实现了服务发现和注册，实现本集群就近调度，本集群节点异常后自动分发到其他集群；
无需对Coredns编译插件，调整Coredns配置，将ClusterSet集群集的DNS解析转发给 Submariner组件lighthouse；

不足:

额外增加Submariner 组件，复杂度提高，资源成本提高;
Submariner 仅支持 iptables 模式下的 kube-proxy ,目前不支持 IPVS ,经测试修改为IPVS 模式后可以正常使用服务自动发现, 主要影响的是 globalnet,详细issue 可以查看[10],具体提案可以查看[11],从提案中工作事项全部已经完成.关于kube-proxy 不支持 IPVS的事项也已经完成，并合并了PR[12]

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
root@localhost:/data/services/karmada# kubectl  get pod --context member1
NAME                     READY   STATUS    RESTARTS   AGE
nginx-77b4fdf86c-zvxpv   1/1     Running   0          106s
tmp-shell                1/1     Running   0          4m30s
root@localhost:/data/services/karmada# kubectl  scale deploy --context member1  nginx --replicas=0
deployment.apps/nginx scaled
root@localhost:/data/services/karmada# kubectl  get pod --context member1
NAME        READY   STATUS    RESTARTS   AGE
tmp-shell   1/1     Running   0          4m34s
root@localhost:/data/services/karmada#

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
bash-5.0# while true
> do
> curl nginx.default.svc.clusterset.local
> sleep 5
> done
member1
member1
member1
member1
member1
member1
member1
member1
member1
member2
member2
member2
member2
member2
member2
member2
member2
member2
member2
member2
member2
member2
member2
member2
member2
member2