前言

罗马不是一天建成的，现在k8s被称为云原生时代的操作系统，霸主位置理论已不可动摇，在此之前，我简要梳理下容器技术衰亡的背景与发展史，而后看下近年来应用程序的开发部署是如何变动的，了解这些变动，可能清晰地感知应用k8s带来的微小劣势。

容器技术的历史

容器最早的原型是对目录的形象，通过chroot技术把用户的文件系统根目录切换到某个指定的目录下，实现了简略的文件系统视图上的形象或虚拟化；然而这种技术只是提供了无限的文件系统隔离，并没有任何其余隔离伎俩，而且人们起初发现这种技术并不平安，用户能够逃离设定的根目录从而拜访host上的文件。

在内核版本2.3.41引入了pivot_root技术，它能够无效地防止chroot带来的安全性问题。今日的容器技术，比方LXC、Docker等，也都是应用了pivot_root来做根文件系统的切换。然而pivot_root也仅仅是在文件系统的隔离上做了一些加强，并没有在其余隔离性上有所提高。

起初呈现了基于Linux-VServer和SWsoft（当初的Odin）开发的Virtuozzo，尽管这些技术绝对过后的XEN和KVM，有显著的性能晋升，然而因为各种起因，并未在过后引起市场太多的关注。之后在Virtuozzo的根底上公布了OpenVZ技术，同时开始推动OpenVZ中的外围容器技术进入Linux内核主线，而此时IBM等公司也在推动相似的技术，最初在社区的单干下，造成了目前大家看到的Cgroup和Namespace，这时，容器技术才开始逐步进入公众的视线。

整个容器技术发展史如下图所示：

更多对于容器的介绍参考这篇文章: 什么是容器：namespace和cgroup

从单体利用到微服务

一图胜千言，这里间接上图：

服务器是一个筐，什么都能够往里装。在晚期，服务大多都是单体利用，由多个组件严密地耦合在一起，其复杂性可想而知，即便是一个小的批改都必须大动干戈，保护这样的零碎能够说很多时候就是黑箱操作，零碎随时处于解体的边缘；这些问题迫使业界从新思考服务的架构模式，微服务架构应运而生，将大型单体利用拆分成小的可独立部署的微服务组件，每个微服务以独立的过程运行，并通过简略且定义良好的接口（API）与其余的微服务通信。这样带来的益处是显而易见的，通过解耦，零碎变得灵便且强壮。

解决了一个问题，但带来了新的问题，组件部署的组合数在减少的同时，组件间依赖的组合数也在急剧减少。还有其余的诸如跨多过程和机器导致调试代码和定位异样调用变得越来越艰难等问题，
操作系统、库、系统配置、网络环境以及其余所有的条件是如此芜杂，迫切需要一个统一的环境，或者叫做沙箱，也可称之为容器。

从Borg到k8s

既如此容器横空出世，Docker大行其道，本着“解决一个问题会带来另一个新问题的准则”，果不其然，如何治理这些容器成了让业界头疼的新问题。一时间Docker Swarm、Apache Mesos、CoreOS Fleet等编排工具纷纷涌现。

谷歌在很早的时候就开发了一个Borg的外部零碎（起初还有一个新零碎叫Omega）， 曾始终是Google激进得最好的机密之一。它是谷歌外部的大规模集群管理系统，负责对谷歌外部很多外围服务的调度和治理。Borg 的目标是让用户可能不用操心资源管理的问题，让他们专一于本人的外围业务，并且做到跨多个数据中心的资源利用率最大化。次要架构见下图：

Borg有四个组件：BorgMaster、Borglet、borgcfg 和 Scheduler，各组件负责的性能如下：

  • BorgMaster 是整个集群的大脑，负责保护整个集群的状态，并将数据长久化到 Paxos 存储中；
  • Scheduer 负责工作的调度，依据利用的特点将其调度到具体的机器下来；
  • Borglet 负责真正运行工作（在容器中）；
  • borgcfg 是 Borg 的命令行工具，用于跟 Borg 零碎交互，个别通过一个配置文件来提交工作。

借助Borg零碎，Google宣称每周可解决几十亿容器。 Kubernetes能够看成是Borg的继任者，这个我的项目的将来指标是纠正Borg、Omega的谬误，最终超过这两位前辈，就目前的状况（2021）来看，k8s是相当胜利的，这股云原生浪潮将由k8s引领，云计算2.0势在必行。