偶遇 kubernetes

大家好，一直以来我都想着是否应该去针对 kubernetes 写一个系列课程，这个课程不一定要成为专门的教程，也不一定成为大家学习 k8s 的手册，只是想能够写出这几年对 k8s 的一些学习、实践的思考、沉淀。希望能够帮助到爱好云原生技术、或者准备往云原生发展、甚至已经在使用云原生技术的同学。

我接触云原生相关技术，其实并不算太早，我也不是一开始就做运维的，刚毕业的时候职业规划不够清晰、明确，也走了不少弯路。最先知道容器技术，大概在 2016，依稀记得当时我第一次使用 docker 启动一个 nginx 和 elk 服务的时候，那种激动的心情。只需要大概一分钟的时间，就能部署一个服务，这在之前是完全不可能的事情。

偶遇 kubernetes，记得那还是 2017 年初，一篇京东大佬写的文章让我震撼：京东如何从 OpenStack 迁移至 Kubernetes，虽然现在我已经忘记当时在哪个网站上读到的，但是依稀记得那是我第一次比较清晰的认识 kubernetes，现在网上还能搜索到。虽然之前听说过，但是一直也没当回事。因为那时的我还沉浸在 OpenStack 这种技术里面，一直觉得 OpenStack 颠覆了运维模式，让运维管理虚拟机如此方便，是 IaaS 在开源界的最佳实践。甚至一度认为未来 5 年、甚至 10 年像 OpenStack 这种技术都会还是主流，起码还是会有很大的市场。

我一直比较关注大公司关于技术的行业动态，比较认同大公司对待技术趋势的把握。从 2017 年看到各大公司都在往 kubernetes 迁移，就已经感觉到学习 kubernetes 可能是运维的必修课了。当然当时业内也有其它比较流行的调度平台，比如 docker 的 swarm，Mesos 等，还不是 k8s 一家独大。至于 k8s 如何成为调度领域的事实标准，后续再讲。

谈谈容器的发展史

关于这个话题，我其实还是蛮纠结的，要从哪里开始说起呢。这里先简单将云计算发展划成三个阶段：物理机时代、虚拟机时代、容器化时代。在 2000 年之前，互联网才刚刚兴起，云计算还只是理论阶段，我们可以称为是物理机时代。在这个时代，上线一个网站大概流程就是：

• 购买一台物理机、部署在机房、通电、通网

• 在服务器上部署操作系统，部署服务要依赖的环境

• 安装数据库和网站服务

• 测试、保证其稳定运行

这个时期的服务可用性很低，服务器停掉、断网、甚至宕机，都有可能导致服务不可用时间很长，迁移的动作，故障处理周期长，并且自动化的程度都很低。

2001 年 vmware 发布了 EXS 1.0 开启了虚拟机时代，倒不是说这个时候才有了虚拟机这个概念，理论很早就有，只是一直没有比较好的落地产品。相信搞技术的，尤其是运维人员应该都用过 vmware 的产品。这一年 VMWare 带来的针对 x86 服务器的虚拟化产品，使虚拟化技术逐渐普及。通过虚拟化技术，它可以把一台物理机分割成多台虚拟机提供给多用户使用，充分利用硬件资源，而且创建速度和弹性也远超物理机。

虚拟化技术日渐成熟， 因此也出现了很多基于虚拟化的云厂商和产品，比如 AWS 的 EC2、阿里云 ECS、Azure Virtual Machines，这种云计算形态也被叫作 IaaS（基础设施即服务）。那有了 IaaS 之后，你就可以把电商网站迁移到虚拟机上了， 再也不用担心断电断网和硬件故障。这个时候很多企业也开始用类似 OpenStack 的开源技术开始搞私有云，就算是现在以 kubernetes 为首的云原生技术，OpenStack 在有些企业应该还是存在的。

那容器时代是如何来临的呢，可能很多小伙伴所了解到的，其实到现在为止虚拟化技术仍然占据着基础设施举足轻重的地位。就好比我们用的阿里云 ECS 算不算虚拟化技术，当然算。其实在我看来虚拟化和容器其实并不冲突，可以说是相辅相成的，甚至我们现在很多 kubernetes 就是部署在这些虚拟机上。早期的时候，经常会有同学把虚拟机和容器放在一起比较，比如下面的架构图，大家觉得是不是跟你想的差不多，容器是替换虚拟机那一层的。给大家留个问题思考，这样的架构图是否合理、是否够严谨，这个等我后面讲 docker 篇会有所解答。

让我们把时间回到 2013 年吧。在 docker 没有出现之前，以 OpenStack 为代表的开源 IaaS，和以 Cloud Foundry 为代表的开源 PaaS 的确是当时技术一股清流。吸引了国内外一大批厂商，开启了以开源 PaaS 为核心构建平台层服务能力的变革。当时云计算的从业者，十有八九都觉得”PaaS“ 时代要来了，PaaS 应该会引领技术市场，可惜这个时候一个叫 docker 的开源技术出现了，从此掀起了整个基础设施技术的变革。

容器这个概念、这门技术从来都不是什么新鲜的东西，更不是 docker 公司发明的。即使在当时最热门的 PaaS 项目 Cloud Foundry 中，容器也只是其最底层、最没人关注的那一部分。PaaS 技术在当时最重要的是提供了应用托管的能力，这之前，大家更多的是自建虚拟化或者使用公有云的虚拟机，然后以手工或者自动化脚本的方式进行应用的部署和发布。这种部署方式跟之前的物理机一样，可能会有测试环境和线上的环境不一致问题，导致故障。所以大家更多的是去模拟本地服务器环境，带来更好的上云体验，而当时的 Paas 就是解决这一问题的最佳方案。比如 Cloud Foundry 的一个命令，就能把本地环境的应用部署到云上，当然这里面用到了调度、Linux 的 namespace、cgroup 技术做资源的隔离和限制。这种我们可以称为”沙盒“，然后”沙盒”里去启动应用程序，后来我们称这种技术叫做“容器”，这是 PaaS 平台的核心能力。

聊到这里，我们还是简单追溯一下容器技术的历史吧，早在 2008 年，就已经有容器技术了，当时有一个开源的容器项目 LXC，LXC 的意思是 LinuX Containers，它是第一个最完善的 Linux 容器管理器的实现方案，是通过 cgroups 和 namespace 实现的。而 docker 用到的技术也包括 cgroups 和 namespace，那为什么 docker 后来能够迅速成为大家最喜爱的容器技术呢。这里我们还是继续说下 PaaS 平台，它在带来应用部署方便的同时，也带来了一些“诟病”。一旦用上了 PaaS，用户就必须为每种语言、每种框架，甚至每个版本的应用维护一个打好的包，并且依赖的配置环境也都不同。虽然 PaaS 针对应用管理这事做了统一化的标准、流程，但是仍然在环境配置的复杂性面前束手无策，或者说没有什么彻底解决的办法。然而这个时候 docker 出现了，而 docker 项目，实际上跟 Cloud Foundry 的容器并没有太大不同，所以在它发布后不久，很多人都觉得 docker 实际上只是一个同样使用 cgroups 和 namespace 实现的“沙盒”而已，没有什么特别的地方，也不需要特别关注。但是就短短的几个月，docker 这个项目就崛起了，以至于 Cloud Foundry 以及所有的 PaaS 社区还没来得及成为它的竞争对手，就直接被宣告出局了。现在看起来，这简直就是一场“降维打击”啊，是之前大家都看走眼了么，其实并没有，事实上 docker 跟我们之前讲的容器技术并没有什么很大的不同，可就是一个很小的改动让它成为至今还很流行的容器技术，这个改动就是 docker 镜像。我经常也会问一些学习容器技术或者过来面试的同学，谈谈 docker 技术原理上比较有创新的点，我希望他们能够说到 docker 镜像。大部分人都没想到，就是因为这个创新，确迅速的改变了整个云计算领域的发展历程。

为什么会这样呢，咱们前面也提到了 PaaS 的一些问题，docker 镜像解决的恰恰就是这个打包的问题。所谓的 docker 镜像，就是一个压缩包，大多数 docker 镜像是直接由一个完整操作系统的所有文件和目录构成的，所以这个压缩包里的内容跟你本地开发和测试环境用的操作系统是完全一样的。这样你的应用所依赖的系统、运行时环境都可以打包在一起，然后到处运行，并且能够保证环境的绝对一致性。一时之间，“容器化”取代“PaaS 化”成为了基础设施领域最炙手可热的关键词，现在大家也经常会听到某某公司容器化等等，而作为这个生态的一手缔造者，此时的 dotCloud 公司突然宣布将公司名称改为“Docker”。关于 docker 镜像的原理，后面我会在 docker 篇进行原理讲解，这里就不再赘述了。

PaaS 就此结束了么，然而并没有，只是以 docker 这种容器化技术为基础重新被定义了而已，以对开发者更友好的形式存在。Docker 公司在 2014 年 12 月的 DockerCon 上发布 Swarm 的这一举动，意味着也在往平台化方向去发展。Swarm 是一个完整的集群管理工具，之后各个云商平台也陆陆续续开始对接 Swarm 成为管理容器的调度平台，起码在 kubernetes 成为容器调度的事实标准之前，swarm 也曾经盛极一时。我也不例外，一开始也是从 swarm 这个平台学起，使用过一段时间，起码在 18 年之前，公有云上还能看到 swarm 的影子。在 14、15 这两年，各大公司都在争相角逐自己在容器领域的市场，多种调度平台、多种容器项目应运而生。

步入 kubernetes 时代

打破这一局面就在 2014 年的 6 月，谷歌开源了 kubernetes 的项目，这个项目跟当时的 docker 项目横空出世一般，再次改变了整个云计算领域的新格局。这个时候 Docker 公司和 Mesosphere 公司，依托自身优势已经率先占据了有利位置，那为啥 kubernetes 会后来者居上呢。在 18 年左右的时候，我做技术分享，还经常会去对比 Swarm、Mesos、kubernetes 这三种调度平台的优劣势，现在已经很少去写对比的文章或者说讨论了。并且各大公有云上，也只有 kubernetes 这一种调度平台了。

kubernetes 到底有什么魅力呢，能让全世界的运维和开发者们后来这么热衷。在容器编排领域，Kubernetes 项目需要面对来自 Docker 公司和 Mesos 社区两个方向的压力。不难看出，Swarm 擅长的是跟 Docker 生态的无缝集成，而 Mesos 擅长的则是大规模集群的调度与管理。如果 kubernetes 也从这两个方向出发，那就不太明智了，这一次 kubernetes 选择了 Borg，这也是发布后，大家都觉得 kubernetes 的设计理念太超前了。kubernetes 的功能特性，并不是区区几个工程师在短时间靠拍脑袋想出来的产品，而是 Google 公司在容器化领域里多年实践出来的沉淀，这正是 Kubernetes 项目能够从一开始就避免同 Swarm 和 Mesos 社区同质化的重要手段。

大家都知道，随后 Google 牵头成立了 CNCF 基金会，CNCF 的首要任务就是如何把 kubernetes 这种先进的理念通过技术手段在社区落地，再加上 Redhat 也站 kubernetes 这一边，共同打造 kubernetes 的生态，kubernetes 开始逐渐的占领容器市场。随后，在已经囊括了容器监控事实标准的 Prometheus 项目之后，CNCF 社区迅速在成员项目中添加了 Fluentd、OpenTracing、CNI 等一系列容器生态的知名工具和项目。如果大家现在再去看 CNCF Landscape，几乎涵盖了各个技术领域的项目（https://landscape.cncf.io/），多到很多都不熟悉。

我想到这里大家一定好奇 kubernetes 的魔力在哪里，一样卖个关子，关于 kubernetes 的原理后续在技术篇分解。下面是容器时代的重要事件发展路线图，大家可以看看。

聊聊云原生

到底什么是云原生呢，关于这个问题，问的人实在是太多了，答案也很多，每个人都有不同的理解，到现在业界也没有一个统一的共识，包括最近华为提出了云原生 2.0，又迈入了另外一个时代。我这边从早期的一些定义，然后结合我个人的一些看法给大家讲讲。

CNCF 官方在 18 年的时候给出了 1.0 版本的定义：

CNCF Cloud Native Definition v1.0

云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API。

Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.

这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。

These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.

云原生计算基金会（CNCF）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。我们通过将最前沿的模式民主化，让这些创新为大众所用。

The Cloud Native Computing Foundation seeks to drive adoption of this paradigm by fostering and sustaining an ecosystem of open source, vendor-neutral projects. We democratize state-of-the-art patterns to make these innovations accessible for everyone.

以上都是官方给出的定义，后面大家对云原生的理解是使用了容器、服务网格、微服务、不可变基础设施和声明式 API 的技术，包括 Pivotal 公司提出的云原生 12 要素大家也可以网上看下，由于篇幅问题就不在这里贴出了。

我们可以从字面的意思理解下云原生，为云而生的应用，天生适合运行在云上的应用，云原生并不代表某个开源项目或者某种技术，是一种指导软件和基础设施架构架构设计的思想，这里关键之处在于，基于这套思想构建出来的应用和应用基础设施，将天然能够与“云”天然地集成在一起，将云”的最大能力和价值发挥出来，而 k8s、docker、service mesh 是让这种思想落地的一种技术手段，当然这个云可以是公有云、私有云甚至是混合云。

从技术的角度来讲，云原生架构是基于云原生技术的一组架构原则和设计模式的集合，旨在将云应用中的非业务代码部分进行最大化的剥离，从而让云设施接管应用中原有的大量非功能特性（如弹性、韧性、安全、 可观测性、灰度等），使业务不再受非功能性业务中断困扰的同时，具备轻量、敏捷、高度自动化的特点。简单的说，就是帮助企业的业务功能迭代更快、系统能承受住各种量级的流量冲击的同时，构建系统的成本更低。

说到这里不知道大家对于云原生是否有一些简单的了解了，所以很多人说 kubernetes 是云原生、docker 是云原生、serverless 是云原生等，这些说法都是不对的。这些都是云原生领域的一种落地实践，哪怕你用虚拟机技术能够发挥云的优势，做到应用弹性、按需使用也可以是云原生的落地。

最后

无论用什么技术，都是要回归到业务价值，兑现业务价值才是发展之本。从业务的角度，采纳新技术的关键是能解决当下的什么痛点、是否带来机器成本的显著降低、能否让稳定性有明显的提升、运维和研发效率有否变得更高，这些收益被总称为业务价值。我们从 19 年开始做云原生，经历了两年多的发展，除了个别有状态的应用，我们已经 99%容器化。在这个过程中，我们也踩了不少的坑，也总结了很多云原生相关技术落地的经验。

从运维的角度来看，kubernetes 带来的价值是

• 屏蔽底层基础设施、屏蔽底层异构环境：这个事情我一直觉得很重要，尤其是对于运维，有了 k8s 之后，全世界的基础设施层就有一个统一的技术栈，让基础设施有了统一的标准化。我们不在关心底层用的是什么服务器或者是哪个云商，不在关心 OS 是 ubuntu 还是 centos，一个 k8s 集群，可以有这些服务器和 OS 不同的组合。我曾经也一度一套 k8s 集群同时使用过 ubuntu 和 centos，对于上层的应用是无感知的，无论调度到哪台服务器，都能够稳定、正常的运行。这样的标准，让服务、甚至平台之间迁移更简单

• 管理方便、高效：如果你问一位运维人员是管理 10000 台服务器简单，还是管理 10000 个 docker 简单，我相信用过 k8s 的同学都会选择后者。之前我们的 ecs 服务器数量虽然没有上万，但是也直逼 2000 台，如果不是随着容器化的落地，早已远远超过这个数字了。针对这么庞大的公有云资源，现在仅仅一位运维花费少量的时间就行。

从业务角度来看，kubernetes 带来的价值是

• 弹性：很多企业上 k8s 更多应该就是冲着容器技术弹性来的，以前的分钟级、十分钟级的扩缩容，现在变成了秒级。这样我们就基于这种弹性做一些动态扩缩容，比如这边我们在原生的内存、CPU 指标的情况下，又开发支持了一些自定义的指标，比如流控、定时、对接 prometheus 指标等，后续我们会基于业务的一些指标的开发。

• 降本：我们大概在去年下半年完成了生产环境的容器化，然后在今年年初做了整体的降本项目，我们用容器化的混部技术让资源得到更充分的利用，整体成本下降了很多，接下来我们仍然会在更多的产品领域去覆盖，真正的发挥云原生技术带来的红利，实实在在的的提效降本。

从技术趋势角度来看，kubernetes 带来的价值是

• 这个更多的是指云原生技术带来的价值，以 kubernetes 为基础设施坚实的底座带来的一系列技术价值，包括最近比较火的 service mesh、serverless、边缘计算领域、flink on k8s，更多的部署应用在 kubernetes 上的。它让服务更弹性、使用成本更低、稳定性更高。

• 有时候我们做技术、做架构需要往前看，不然随着时间的推移、业务的增长，可能会带来很多技术债，那个时候想要重构、改变就能很难，成本会很高。以 kubernetes 为首的容器技术是基础设施标准。围绕着 kubernetes 的生态也慢慢健全起来，各大云厂商也在基于 kubernetes 的赛道在云计算领域做赛跑。有了 kubernetes，我们做上层应用平台的建设就更容易了，包括服务治理的 service mesh 技术，无服务器 serverless。

• 技术文化沉淀，我相信每一位做技术的人员都希望能够接触到前沿技术领域，尤其是热门技术。一个有技术氛围的团队，更容易吸引人才，因为大家都渴望能够和企业共同成长，这也是为什么一些大厂会去做一些前沿技术的交流峰会、沙龙等。

最后，云原生更多的是一种技术文化、思想的传播，它不仅仅是一种技术的落地，更能够给企业带来长期的业务价值。