k8s多集群管理的思考

k8s多集群的思考

1. 为什么需要多集群

1、k8s单集群的承载能力有限。

Kubernetes v1.21 支持的最大节点数为 5000。 更具体地说,Kubernetes旨在适应满足以下所有标准的配置:

  • 每个节点的 Pod 数量不超过 100

  • 节点数不超过 5000

  • Pod 总数不超过 150000

  • 容器总数不超过 300000

参考:https://kubernetes.io/zh/docs/setup/best-practices/cluster-large/

且当节点数量较大时,会出现调度延迟,etcd读写延迟,apiserver负载高等问题,影响服务的正常创建。

2、分散集群服务风险。

全部服务都放在一个k8s集群中,当该集群出现异常,短期无法恢复的情况下,则影响全部服务和影响部署。为了避免机房等故障导致单集群异常,建议将k8s的master在分散在延迟较低的不同可用区部署,且在不同region部署多个k8s集群来进行集群级别的容灾。

3、当前混合云的使用方式和架构

当前部分公司会存在自建机房+不同云厂商的公有云从而来实现混部云的运营模式,那么自然会引入多集群管理的问题。

2. 多集群部署需要解决哪些问题

目标:让用户像使用单集群一样来使用多集群

扩展集群的边界,服务的边界从单台物理机多个进程,发展到通过k8s集群来管理多台的物理机,再发展到管理多个的k8s集群。服务的边界从物理机发展到集群

而多集群管理需要解决以下问题:

  • 多集群服务的分发部署(deployment、daemonset等)

  • 跨集群自动迁移与调度(当某个集群异常,服务可以在其他集群自动部署)

  • 多集群服务发现,网络通信及负载均衡(service,ingress等)

而多集群服务的网络通信可以由Service mesh等来解决,本文不做重点讨论。

以上几个问题,可以先从k8s管理节点的思维进行分析

2.1. 多集群工作负载的分发

单集群中k8s的调度单元是pod,即一个pod只能跑在一个节点上,一个节点可以运行多个pod,而不同节点上的一组pod是通过一个workload来控制和分发。类似这个逻辑,那么在多集群的视角下,多集群的调度单元是一个集群的workload,一个workload只能跑在一个集群中,一个集群可以运行多个workload。

那么就需要有一个控制器来管理不同k8s集群的相同workload。例如 workloadGroup。而该workloadGroup在不侵入k8s原生API的情况下,主要包含两个部分。

workloadGroup:

  • 资源模板(Resource Template):服务的描述(workload)

  • 分发策略(Propagaion Policy):服务分发的集群(即多个workload应该被分发到哪些集群运行)

workload描述的是什么服务运行在什么节点,workloadGroup描述的是什么服务运行在什么集群。

实现workloadGroup有两种方式

  1. 一种是自定义API将workloadGroup中的Resource Template和Propagaion Policy合成在一个自定义的对象中,由用户直接指定该workloadGroup信息,从而将不同的workload分发到不同的集群中。

  2. 另一种方式是通过一个k8s载体来记录一个具体的workload对象,再由用户指定Propagaion Policy关联该workload对象,从而让控制器自动根据用户指定的Propagaion Policy将workload分发到不同的集群中。

2.2. 跨集群自动迁移与调度

单集群中k8s中通过workload中的nodeselector或者nodename以及亲和性来控制pod运行在哪个节点上。而多集群的视角下,则需要有一个控制器来实现集群级别的调度逻辑,例如clustername,cluster selector,cluster AntiAffinity,从而来自动控制workloadGroup下的workload分散在什么集群上。

3. 目前的多集群方案

3.1. Kubefed[Federation v2]

简介

基本思想

3.2. virtual kubelet

简介

基本思想

3.3. Karmada

简介

基本思想

参考:

最后更新于

www.huweihuang.com