1. 背景介绍

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

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

2. 目标

  • 统一的集群管理能力
    自有的Kubernetes集群被注册到平台里，需要实现统一的安全治理、应用管理和监控、日志等能力。
  • 统一的动态弹性能力
    纳入的资源，必须拥有统一的资源调度视角，在此基础上提供动态弹性能力。
  • 统一的服务治理能力
    基于服务网格产品，实现跨地域的多集群上的应用服务就近访问、故障转移等功能，原生支持云容灾、异地多活。

3. 方案

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

  1. admiralty
    admiralty充分利用了两级调度的优势，仅由四个组件组成，就可以管理数量可观的集群，它和virtual kubelet 的关系是，仅仅利用了这个组件的node 管理能力。
    它的特点：
  • 两级调度
  • 需要在目标集群上装certmanager和admiralty 组件
  • 调度时无法从全集群的统一视角出发，需要人为指定目标集群调度。
  • 可以支持istio
  • 只需在主集群中部署的组件与集群数量无关。
  1. tensible-kube
    这是一种利用了virtual kubelet 的提供了kubernetes provider的方案，
  • istio 的支持不够完善
  • 组件多，至少4个组件，且每一个集群一组组件去接管该集群
  • 无需在目标集群中部署相关组件

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

  1. 讨论