共计 1754 个字符，预计需要花费 5 分钟才能阅读完成。
前言
罗马不是一天建成的，现在 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 势在必行。
