近日，Kubernetes的拥护者又多了一位，Twitter 公司正式宣布Twitter 的基础设施将从 Mesos 全面转向 Kubernetes。Mesos 项目发布于 2009 年，而 Twitter 公司则是 Mesos 项目的早期支持者和使用者之一。在持续投入 Mesos 项目近 10 年之后，Twitter公司全面转向 Kubernetes 体系的背后原因是什么呢？
云时代，Twitter 基础设施面临新挑战
随着云计算的普及，以及 Kubernetes 以“云”为核心的容器化项目的崛起，Mesos 的调度框架和 Aurora 配置管理的编排引擎等传统互联网基础技术架构选型方法，逐步暴露出很多前所未有的问题。
1）存储系统的多样化与专业化，使传统基础设施复杂度急剧上升
相比于传统技术架构对存储系统的单一假设（比如一套 Ceph 打天下），云时代的软件架构为用户存储选择带来了爆发性增长。随着互联网公司的基础架构和软件规模的不断扩张和发展，互联网软件本身对存储的需求也更加细化和专业。
比如，在 Twitter，Local Persistent Volume 这种“非典型”存储诉求，逐渐在平衡性能与成本的过程中成为一种主流方案。作为 CSI（Container Storage Inerface）的提出者，Kubernetes 社区不仅拥有最完善的 Local PV 机制，还能够凭借标准接口和 PV、PVC 体系，完全为用户抹平其它数十种不同存储服务的对接问题。
2）Mesos 和 Aurora 体系与“云原生”始终渐行渐远
云时代一个重要的技术发展趋势就是软件的生命周期会逐步向“生在云上、长在云上”的形态靠拢。这也就意味着作为支撑软件的核心基础设施项目，必然要向“发挥云的最大价值”的方向不断演进。
遗憾的是，Mesos 以及 Aurora 项目或许是由于发布较早，始终没能够将“云”变成整个基础设施体系中的“一等公民”。相比之下，Kubernetes 体系从发布伊始就不断倡导“声明式 API”、“容器设计模式”、“控制器模型”等各项理念，其实都是为了帮助用户能够在云上以“可扩展、可复制、高度自动化”的方式开发、交付和运维软件。这也成为 Kubernetes 项目与其它竞争对手相比最大的不同。
3）传统的多云、多集群管理成本居高不下
在传统的互联网架构中，自建数据中心和基础设施体系是整个软件系统的第一假设。而“云”所扮演的角色，更像是在流量突发时应付峰值的资源“备胎”。
在这种以“云”为辅助角色的指导思想下，多云和多集群很难成为整个架构的重中之重。这就使得多云和多集群能力，成为底层资源对接层的职责，而与更重要的应用开发、交付和运维体系失去直接关联。这种方案短期内固然可以奏效，但长期的维护和迭代成本却很容易因为上层应用本身千变万化的形态与高速迭代而超出把控。
此外，这种设计的另一个极端是让整体基础设施走向“多活”技术深渊：这实际上已经远远超出 90% 以上互联网公司的技术能力。在云原生体系普及之后，“每朵云上都有无数个 Kubernetes 集群”逐渐成为应用基础设施能够依赖的新常态。
这就为多云和多集群管理提供了一种全新的突破性思路：只要软件选择面向 Kubernetes 来进行架构、设计和实现，那么“多云、多集群”就自然而然成为应用基础设施的默认能力。在 Twitter 的业务越来越多的需要多云、多集群环境交付的趋势下， Kubernetes 这种从根本上帮助应用迅速向多云交付的“捷径”，成为 Twitter 选择变更自身技术体系的另一个重要原因。
大规模生产环境的" Kubernetes Native "技术路径
作为不断在快速发展和迭代的互联网公司，高压力和快节奏背景下的企业往往无暇顾及基础设施架构的标准化与兼容性问题，这同样也是 Twitter 公司面临的主要问题之一。所以，在这次转型过程当中，“Kubernetes Native”成为一个被反复强调的关键词。在发布会上，Twitter 公司公布了选择 Kubernetes Native 方向的诸多评估依据。
良好的开源技术与开源生态；
全世界所有的公有云都提供 Kubernetes 服务，不必担心厂商锁定；
原生具备有状态业务（Stateful Application）的管理语义；
项目本身快速迭代，具有很强创新能力和先进性；
具备标准的存储对接接口，帮助 Twitter 无缝迁移各种现有存储服务；
最终，Twitter 公司用一句话总结了这次评估的结果：“我们认为，使用 Kubernetes 项目作为 Twitter 公司基础设施向前演进的核心依赖，将会是一个正确的选择”。
网友评论