用virtual kubelet 的思路接管一个标准Kubernetes 集群的方案

1. 背景介绍

把自有集群接入情况下，由于不同云环境的基础设施能力、安全架构的差异会，加大多云实施的复杂性。

在云原生时代，以Kubernetes为代表的技术屏蔽了基础设施的差异性，推动了以应用为中心的多云混合云新架构的到来，我们目前只针对，拥有自建kuberntes 集群的用户，提供接入能力。

2. 目标

• 统一的集群管理能力
  自有的Kubernetes集群被注册到平台里，需要实现统一的安全治理、应用管理和监控、日志等能力。

• 统一的动态弹性能力
  纳入的资源，必须拥有统一的资源调度视角，在此基础上提供动态弹性能力。

• 统一的服务治理能力
  基于服务网格产品，实现跨地域的多集群上的应用服务就近访问、故障转移等功能，原生支持云容灾、异地多活。

3. 方案

在最底层，所有的资源最终落在了pod 上。有两种方案可以完成这种设计。

1. admiralty

   admiralty充分利用了两级调度的优势，仅由四个组件组成，就可以管理数量可观的集群，它和virtual kubelet 的关系是，仅仅利用了这个组件的node 管理能力。

   它的特点：

   • 两级调度

   • 需要在目标集群上装certmanager和admiralty 组件

   • 调度时无法从全集群的统一视角出发，需要人为指定目标集群调度。

   • 可以支持istio

   • 只需在主集群中部署的组件与集群数量无关。

2. tensible-kube

   这是一种利用了virtual kubelet 的提供了kubernetes provider的方案，

   • istio 的支持不够完善

   • 组件多，至少4个组件，且每一个集群一组组件去接管该集群

   • 无需在目标集群中部署相关组件

   两者在自动化部署上的差异会更多，admiralty 的社区相对更加完善，后者就是腾讯游戏团队的一个小范围内的项目。

3. 讨论