Kubernetes

谢邀，一种现象的出现往往都是多种因素的叠加造成的。

一、天时：当Docker等容器运行时成熟时，越来越多的企业在私有云和公有云中运行著成百上千的容器实例，关注点逐渐转移到如何管理和调度容器了，自然需要在上层架设一套管理系统。

二、地利：K8S由Google背书，是由Google内部稳定运行了十几年的第一代容器管理系统Borg、第二代容器管理系统Omega演进而来，目前的K8S是第三代容器管理系统，针对大规模应用集群的自动管理提出了很多先进的理念并且实现了：Pod、ReplicaSet、Service、Kube-proxy等。而且，由于Google的背书，越来越多的第三方加入到K8S生态中来，可以说整个CNCF社区就是围绕K8S生态构建的。这是其他几个竞争对手（如Mesos、Swarm等）没法比的。

CNCF社区的项目清单

三、人累：没错，是人累了。2010-2017年可以算是云计算基础软体创新的黄金几年，这几年大家一直在围绕虚拟化和云计算花式创新，从XEN、KVM一路玩到Eucalyptus、CloudStack、OpenStack，从LXC、Docker玩到Yarn、Mesos、Swarm和Kubernetes。但天下苦秦久矣，创业厂家、科技媒体、IT自媒体隔三差五就跳出来要颠覆已有的IT基础设施。

1、刚部署完Xen，就说Xen性能不好，要用KVM；

2、换了KVM后，说光有虚拟化不成，需要加一层云管理平台OpenStack；

3、刚部署完OpenStack，又说OpenStack太笨重庞大，不好运维，需要考虑容器；

4、刚部署完容器，准备用Mesos+Marathon来管理容器，又说Mesos不好，不适合长任务，要用Kubernetes。

花了这么多时间在底层折腾，底层迭代比业务系统迭代还快，业务层面没见更多好转，人却疲惫了，所以大家急切需要有一套稳定可靠的软体来统管云平台基础设施，用稳态的云平台基础设施支撑上层敏态应用的快速迭代更新。

选择开源的原因一般都是技术先进、生态好、无厂商锁定之类的，然而并不是所有的开源项目都能成为业界标准，Kubernetes 之所以成为标准，被 Docker、OpenStack 和各大公有云服务商接受，还是因为其本身的云原生（Cloud Native）属性。

就在这个五一假期（美国西部时间 5 月 2 日），作为 Mesos 项目的早期支持者和重度使用者之一的 Twitter，宣布从 Mesos 迁移到 Kubernetes（内部 Kubernetes 集群 + 公有云 Kubernetes 集群），迁移工作将于 2020 年底之前完成。

2017 年，Kubernetes 被 Docker 接纳，已经成为容器编排的标准，此番 Twitter 从 Mesos 全面转向 Kubernetes，再次证明了 Kubernetes 的江湖地位不可动摇。毕竟，Mesos 也是编排工具的三大竞争者之一，而 Twitter 运行著万级别节点的 Mesos 集群作为生产环境。

Twitter 对这一改变的解释，主要是 Mesos 跟不上云计算的节奏，表现为基础设施复杂性上升、非云原生设计、多云/多集群管理成本高等，但这些挑战，在 Kubernetes 以应用为核心的云原生设计中就不再是问题了。

我云首席架构师刘超曾经撰文指出：Kubernetes 确实引入了很多概念，但它的这些设计，更适合微服务和 DevOps 的思想与实践。比如，微服务设计区分无状态和有状态，在 Kubernetes 中，无状态对应 deployment，有状态对应 StatefulSet。详见：为什么 kubernetes 天然适合微服务

Twitter 倾心于 Kubernetes 的原因之一，正是后者原生具备有状态业务（Stateful Application）的管理语义。

kubernetes成为一个趋势是必然

过去的xen也好，kvm也罢，还是什么openstack，都离应用太远了

他们都在关注如何管理虚拟机，好像管理好虚拟机了，一切就万事大吉了，应用谁来管理，应用和底层基础设施的耦合无法处理

举个例子吧，通常云厂商有autoscaling对吧，这一套autoscaling是基于什么的呢，是基于操作系统的快照，和对特定的监控指标，看起来似乎是解决了扩缩容问题，其实还差很远。操作系统的镜像制作复杂且麻烦，繁重不堪，迭代相对复杂

kubernetes出来之后，你只需要告诉他，你需要的副本数，就可以实现了，多么的简单

另外就是现在随著kubernetes的能力越来越强，云基础设施对kubernetes的支持越来越好，我们以后只需要面向kubernetes进行应用的部署维护，只需要一个yaml声明（也可能是使用helm工具），告诉我们kubernetes集群，我需要一个5Gi的磁碟，我需要在负载均衡上面配置一个路由，我需要的一切都可以通过kubernetes的声明文件来声明，并且呢，由于对于很多介面，kubernetes都做了很大的抽象，所以在不同的云厂商间切换，所需要做的修改，也非常小

kubernetes所具备的能力是之前的云基础设施没有解决的，所以当然火了啊

对比下kubernetes和mesos，以本人的浅见，mesos并非是专门调度容器的框架，以其文档所述，mesos在使用容器的时候会强依赖docker cli，而kubernetes实现了CRI介面，不仅可以支持docker，还可以支持诸如podman, rkt这样的runtime。

先写这么多

因为之前 Docker 实在太热门了，不管用不用大家都要来凑热闹。但是 Kubernetes 诞生不久后直接边缘化了 Docker。同时让容器规范的定制权不再专治（减弱了 Docker 公司对 Docker 的控制权），Openstack 底层也接受 K8S，不得不说它实在太流弊了…

出自谷歌，又确实很好，要一统天下的架势，怎么能不火呢。

因为微服务架构解决单体应用问题。

但是又引入了新的复杂性需要解决

目前看来只有k8s比较好的解决了这个复杂的问题

k8s本身也是一个微服务分散式架构

因为云计算发展越来越快了，Kubernetes现在成为docker编排工具的领头羊了，微服务框架越来越成熟，标准化，通过Kubernetes快速部署服务效率大大提高，容器化部署服务，快速交互，自动化运维。

2019年5月2日下午，Twitter 公司正式宣布从 Mesos 全面转向 Kuberbetes，消息一出，引起了一场互联网业内的小「地震」。那么， Kubernetes 现在为什么如此火热？为什么 Twitter 公司会选择 Kubernetes？

Kubernetes，是一个开源的 Linux 容器自动化运维平台，它消除了容器化应用程序在部署、伸缩时涉及到的许多手动操作。

它最开始是由谷歌的工程师设计开发的，谷歌作为 Linux 容器技术的早期贡献者之一，曾公开演讲介绍他们是如何将一切都运行于容器之中。Borg 就是 Kubernetes 的前身，谷歌几年来开发 Borg 的经验教训也成了影响 Kubernetes 中许多技术的主要因素。

那么，为什么需要 Kubernetes 呢？

其实真实的生产环境应用会包含多个容器，而这些容器还很可能会跨越多个伺服器主机部署。Kubernetes 提供了为那些工作负载大规模部署容器的编排与管理能力。Kubernetes 编排让人们能够构建多容器的应用服务，在集群上调度或伸缩这些容器，以及管理它们随时间变化的健康状态。

当然，Kubernetes 也需要与网路、存储、安全、监控等其它服务集成才能提供综合性的容器基础设施。

而企业在生产环境中使用 Kubernetes 的主要优势在于它提供了在物理机或虚拟机集群上调度和运行容器的平台。更宽泛地说，它能帮人们在生产环境中实现可以依赖的基于容器的基础设施。

以 Twitter 为首的互联网公司，决定转向 Kubernetes，主要是基于以下几个原因：

1/ 云时代，企业基础设施面临新挑战

在互联网级别的技术场景下，依托顶级工程师和成熟技术自建基础设施，一直以来都是一线非云互联网厂商的架构首选。正是在这个过程中，相对成熟并且工作层次较低的 Mesos 项目收获到了大量规模级生产环境部署案例。不过，随著云计算的普及和 Kubernetes 这样以「云」为核心的容器化基础设施项目的迅速崛起，这种传统互联网基础技术架构选型方法逐步暴露出很多前所未有的问题。

2/ Mesos 和 Aurora 体系与「云原生」始终渐行渐远

云时代一个重要的技术发展趋势就是软体的生命周期会逐步向「生在云上、长在云上」的形态靠拢。这也就意味著作为支撑软体的核心基础设施项目，必然要向「发挥云的最大价值」的方向不断演进。

遗憾的是，Mesos 以及 Aurora 项目或许是由于发布较早，始终没能够将「云」变成整个基础设施体系中的「一等公民」。相比之下，Kubernetes 体系从发布伊始就不断倡导「声明式 API」、「容器设计模式」、「控制器模型」等各项理念。

如今，这些顶层架构设计与各种最佳实践，被广大开发者们冠名为「云原生」。这也成为 Kubernetes 项目与其它竞争对手相比最大的不同。

3/ 大规模生产环境的「Kubernetes Native「技术路径

作为不断在快速发展和迭代的互联网公司，高压力和快节奏背景下的企业往往无暇顾及基础设施架构的标准化与兼容性问题，这同样也是 Twitter 公司面临的主要问题之一，所以，在这次转型过程当中，「Kubernetes Native」成为一个被反复强调的关键词。

在发布会上，Twitter 公司公布了选择 Kubernetes Native 方向的诸多评估依据：
  • 良好的开源技术与开源生态；
  • 全世界所有的公有云都提供 Kubernetes 服务，不必担心厂商锁定；
  • 原生具备有状态业务（Stateful Application）的管理语义；
  • 项目本身快速迭代，具有很强创新能力和先进性；
  • 具备标准的存储对接介面，帮助 Twitter 无缝迁移各种现有存储服务。

4/ 传统的多云、多集群管理成本居高不下，并在可预见的未来内迅速攀升

在传统的互联网架构中，自建数据中心和基础设施体系是整个软体系统的第一假设。而「云」所扮演的角色，更像是在流量突发时应付峰值的资源「备胎」，与应用开发、交付和运维体系也失去了直接关联。

而在云原生体系普及之后，「每朵云上都有无数个 Kubernetes 集群」逐渐成为应用基础设施能够依赖的常态。在 Twitter 的业务越来越多的需要多云、多集群环境交付的趋势下， Kubernetes 这种从根本上帮助应用迅速向多云交付的「捷径」，这也成为 Twitter 选择变更自身技术体系的另一个重要原因。

从最早 Mesos 「代言人」到如今的全面转向 「Kubernetes Native」，Twitter 公司的选择无疑为「Kubernetes 项目成为互联网级基础设施标准」又增加了一个重量级佐证。

伴随著云计算的进一步普及和像 Kubernetes 这样以「云」为核心的容器化基础设施项目的迅速崛起，越来越多的世界级企业开始思考如何借助「云」以及云原生技术来拥抱开源生态和开放的技术标准，准备迎接一个具备强劲的迭代能力的、面向「云原生」的未来。

文章转载自微信公众号「 云上马可君 」（ID: webeye_global）

推荐阅读：
相关文章