从零开始的k8s之旅(一)：云原生前夜

MagicON 发布于 5 月 12 日

前言

罗马不是一天建成的，如今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，各组件负责的功能如下：
​

借助Borg系统，Google声称每周可处理几十亿容器。 Kubernetes可以看成是Borg的继任者，这个项目的未来目标是纠正Borg、Omega的错误，最终超越这两位前辈，就目前的情况（2021）来看，k8s是相当成功的，这股云原生浪潮将由k8s引领，云计算2.0势在必行。
​

黑客与音乐家

音乐爱好者的计算机之旅

关注专栏