K8s 多集群实践思考和探索( 二 )


以上多集群项目主要功能为资源分发和调度 , 还有如多云基础设施管理cluster-api , 多集群检索Clusterpedia , 多集群pod互通submariner , multicluster-ingress解决多集群的ingress , 服务治理和流量调度 Service Mesh , 如istio、cilium等网络组件实现的multi cluster mesh解决跨集群的mesh网络管理 , 以及结合存储相关项目实现跨集群存储管理和迁移等 。
2.2 vivo 在多集群上的探索2.2.1 非联邦集群管理
 

K8s 多集群实践思考和探索

文章插图
 
非联邦多集群管理系统主要是进行资源管理、运维管理和用户管理 , 提供导入K8s集群权限功能 , 并通过统一 Web 界面进行查看和管理 。这类工具不引入额外集群联邦的复杂 , 保持每个集群的独立性 , 同时通过统一的 Web 界面来查看多个集群的资源使用情况 , 支持通过 Web 界面创建 Deployment、Service 和负载均衡等 , 并且会集成持续集成、持续交付和监控告警等功能 。由于集群联邦技术还在发展 , 大多数企业倾向于使用这种方式来运维和管理多集群 Kubernetes 环境 。当前vivo主要是通过这种方式管理多集群 。
2.2.2 联邦集群管理
K8s 多集群实践思考和探索

文章插图
联邦集群主要将资源联邦化 , 实现资源的统一管理和调度 。随着K8s在数据中心大量使用 , K8s已成为基础设施管理的标准 , 不同区域部署已非常普遍 。如K8s运行在云上来托管集群、企业自建数据中心的私有云、边缘计算等 。越来越多的企业投入到多集群管理项目 , 当然联邦集群肯定会增加整体架构的复杂度 , 集群之间的状态同步也会增加控制面的额外开销 。尽管增加了所有的复杂性 , 但普遍存在的多集群拓扑引入了新的令人兴奋的潜力 。这种潜力超越了目前所探索的通过多个集群进行的简单静态应用程序编排 。事实上 , 多集群拓扑对于跨不同位置编排应用程序和统一对基础设施的访问非常有用 。其中 , 这引入了一种令人兴奋的可能性 , 可以透明而快速地将应用程序从一个集群迁移到另一个集群 。在处理集群灾难或关键基础设施干预、扩展或布局优化时 , 移动工作负载是可行的 。
vivo在联邦集群的探索方向主要有以下四个方面:
  1. 资源分发和编排
  2.  弹性突发
  3. 多集群调度
  4. 服务治理和流量调度
本次主要分享资源分发和编排、弹性突发和多集群调度以K8s为核心的联邦多集群探索 。网络为核心的能力建设 , 主要为不同集群的网络可以通过如 Service Mesh或者 Mesh Federation打通 , 就可以实现网络流量的灵活调度和故障转移 。实际上 , 也有很多应用通过隧道或者专线打通多个集群 , 进一步保证了多集群之间网络通信的可靠性 。vivo网络和服务发现主要是开源的基础上自研 , 可以持续关注后面分享 。
三、面向应用的多集群实践云原生技术的发展是持续输出“事实标准的软件” , 而这些事实标准中 , 应用的弹性、易用性和可移植性是其所解决的三大本质问题 。
  • 应用的弹性:对于云产品的客户来说等价于业务可靠性和业务探索与创新的敏捷性 , 体现的是云计算所创造的客户价值 , 应用弹性的另一个关注点在于快速部署、交付、以及在云上的扩缩容能力 。这就需要完善的应用交付链路以及应用的云原生开发框架支撑;
  • 易用性:能更好地发挥应用的弹性 , 在微服务软件架构成为主流的情形下 , 易用性需要考虑通过技术手段实现对应用整体做全局性的治理 , 实现全局最优 。这凸显了 Service Mesh 的服务能力;
  • 可移植性:实现多集群和混合云无障碍迁移等 。
那么一个以应用为中心 , 围绕应用交付的多集群多集群管理具备统一的云原生应用标准定义和规范 , 通用的应用托管和分发中心 , 基于 Service Mesh 的跨云的应用治理能力 , 以及 K8s 原生的、面向多集群的应用交付和管理体系 , 将会持续不断的产生巨大的价值 。vivo当前主要结合Karmada和CNCF周边项目来探索以上挑战 。


推荐阅读