本文分享virtual kubelet项目，以及基于vk实现的多集群调度的idea

virtual kubelet是什么

virtual kubelet是微软开源的一个kubelet实现。顾名思义，virtual kubelet不像原生的kubelet，是一个运行在真实节点上的进程，而是一个“虚拟”的kubelet，它将自己向k8s apiserver上报为一个节点。在k8s master层面看来，这个节点与其他节点没有区别。

• 没有真实节点，工作负载如何运行？

  如图所示，virtual kubelet在集群中相当于一个代理，将调度到vk节点的pod，转发到底层真实对接的资源生产平台，vk将底层平台称为provider。provider可以是公有云容器平台，私有容器平台，或者是k8s集群（AWS/Aliyun/Azure/HashiCorp/Openstack...)。 为了对接provider，vk定义了一系列接口，需要实现这些接口，才能保证vk正常运行。当一个pod调度到vk节点时，vk会调用CreatePod接口创建该pod。

  

• 如何更新pod状态？

  vk定义了UpdatePod接口，会定时调用该接口从底层更新pod的状态并同步到apiserver. 另外也可以实现NotifyPod接口，主动推送pod状态更新给vk.

• 怎么确定provider有多少资源可用？

  vk定义了ConfigureNode接口，可以在这个接口里面实现上报节点资源的逻辑。如果provider提供了查询资源的接口，可以在这里调用该接口，实现定时更新可用资源。

• 数据（secret/configmap/pv/pvc）怎么处理

  这部分数据需要从vk按照一定的映射关系同步到底层provider中，如果provider不支持这种类型的资源则无法支持对应资源的使用

基于virtual kubelet实现两层k8s架构

• VK将上层pod的创建转发到下层的集群中
• 底层k8s提供接口查询可用资源（比如通过CRD），上报到上层
• 可以将多个底层k8s连接到同一个vk，在vk中实现调度逻辑选择集群
• 也可以一个vk对应一个底层集群，通过上层的scheduler来选择调度到哪个vk节点（对应底层哪个集群）
• 实际生产中使用了第二种方式
• 一个vk可以配置对应一个上层的用户，不同vk对应不同的用户实现隔离

小结

优点：

• 隔离业务层和资源层，业务无需关心机器运维
• 统一资源池进行调度

问题：

• 多集群级联方式不够云原生，不够优雅
• 需要进行大量状态同步，增加系统复杂性，容易出现严重故障

vk的设计初衷是为了将外部资源纳管到k8s集群中；通过vk实现两层k8s是一个可用的多集群架构，但系统架构比较复杂，维护成本也比较大；多集群可以用CRD或者扩展apiserver的方式来实现，或者使用业界的karmada/kubefed等方案。vk比较适合私有化定制需求比较多的场景。