第1章 引言

1.1 云原生介绍

1.1.1　云原生的起源与发展

近年来，“云原生”逐渐成云计算领域非常热门的词汇。各大云计算厂商的产品宣传材料、各类云计算技术会议，以及各种技术博客、公众号、微信群中，经常会提及“云原生”。 那么究竟什么是“云原生”？它为什么这么流行？下面我们来一探究竟。实际上，云原生是云计算发展的必然阶段。到目前为止，可以把云计算的发展分为 3个阶段：云计算 1.0、云计算 2.0、云计算 3.0。

1. 云计算 1. 0 和云计算 2. 0

云计算 1.0 和云计算 2.0 阶段是以虚拟化技术为基础、以资源编排（计算、存储、网络）为主体的时代。20 世纪 90 年代，VMware 公司推出了个人桌面版的虚拟化软件 VMware Workstation（VMware 工作站），用户可以在 PC 上安装不同的虚拟机，比如 Linux 发行版 Red Hat、Ubuntu 等。2001 年，VMware 公司又推出了服务器版虚拟化软件 VMware ESX，后来又推出了一系列虚拟化及管理软件，如 vSphere、vSAN、NSX 等，逐步开启了一个私有云时代。与此同时，随着 VMware 公司在商业中取得巨大成功，越来越多的公司、学校、组织纷纷投入对计算、存储、网络虚拟化的研究，并推出了许多开源项目，其中的典型代表包括计算虚拟化领域的 Xen（2005 年）和 KVM（2006 年）、存储虚拟化领域的 Ceph（2007 年）、网络虚拟化领域的 Open vSwitch（2009 年）。在管理软件方面，2008

年出现了 OpenNebula；2010 年 OpenStack 问世，得到了全世界众多厂商和开发者的支持，它逐步成为事实上的开源云计算管理平台标准（如图 1-1 所示）。值得一提的是，以网上书店为主营业务的 Amazon 于 2006 年推出了全世界第一个公有云服务 AWS（Amazon Web Service），以云主机 EC2 和对象存储 S3 为主要产品，逐步开辟了公有云时代。随着产品的不断丰富和用户数的不断增加，Amazon 也成为万亿美元市值的大公司。

云计算 1.0 以虚拟化为主要特征，引入了计算虚拟化技术，将企业 IT 应用与底层基础设施分离解耦，可以在同一台物理服务器上运行多个 IT 应用实例，从而提高资源利用率，降低成本。云计算 2.0 以自动化为主要特征，一方面引入了软件定义存储（SDS，Software Defined Storage）、软件定义网络（SDN，Software Defined Network）技术，实现了计算、存储、网络的全面虚拟化，使得 IT 资源具备弹性、可扩展性；另一方面，引入了云管理平台，对各类基础设施资源进行统一管理，通过自服务、按需开通、按量计费的模式实现资源供应的灵活性和自动化。

图 1-1　云计算 1.0 和云计算 2.0

总的来说，云计算 2.0 时代主要解决资源分配和管理的问题，这是资源维护者的核心诉求，而众多的资源中（计算、存储和网络等）又以虚拟机为主体，所以简单来说，这个时代的云计算就是围绕虚拟机构建 IaaS 资源管理体系，所有的资源管理都是以虚拟机为核

心实现配套设计。在以私有云为主的时代，完美地匹配了用户的需求。云计算 2.0 时代，用户是比较单一的，诉求就是作为 IT 操作人员（Operator）或者维护人员（Maintainer）要把资源的管理做到极致。这个时代其实也在尝试满足更高级的用户需求，比如早期基于虚拟机的 PaaS 平台 Cloud Foundry、基于虚拟机的应用编排项目 Murano 等，但它们都没有成为云计算 3.0 时代的主流技术框架。云计算 1.0 和云计算 2.0 时代的主要用户场景如图 1-2 所示。

图 1-2　云计算 1.0 和云计算 2.0 时代的主要用户场景

2. 云计算 3. 0

IT 基础设施不能直接带来经济效益，在其基础上构建的应用更贴近于市场与业务发展的需求。 随着公有云的普及和私有云的极致发展，云计算的主要矛盾变成了日益增长的多元化用户（不仅仅是 IT 维护人员）需求与落后的以资源编排（分配）为主体的理念之间的矛盾。公有云用户更希望以应用为主体来构建 IT 软件栈和系统，希望以更加敏捷、更细粒度的控制来适应应用的快速迭代，甚至是私有云的 IT 管理员也希望资源编排更加敏捷。此时，云计算的核心理念就很自然地进入以应用编排为主体的云计算时代，我们称之为云计算 3.0。因此，满足这个理念的 Docker、Kubernetes 等技术必将会在这个时代实现空前的发展。

下面介绍 Docker 和 Kubernetes 的历史及主要问题。

2013 年以前，人们遇到的最棘手的问题之一是如何交付应用。在应用的开发、测试、交付、运维的生命周期中，通常以代码包、二进制文件等方式交付应用。虽然云计算的发展使得计算、存储、网络资源随手可得，但是由于操作系统、应用依赖包的不同，在测试

环境、集成环境、生产环境中部署和调试应用消耗了太多精力。例如，测试环境中主机操作系统是 CentOS 6.5，通过测试后将 RPM（Red Hat Package Manager）同步到生产环境中，但生产环境主机操作系统是 CentOS 7.5，且未安装应用所需的依赖包，所以应用无法正常运行，需要安装依赖包并进行全量测试。一种解决该问题的思路是以虚拟机镜像为单位交付应用，但是由于虚拟机往往是多个应用共享的，应用之间会产生依赖包冲突等问题，而且虚拟机文件太大（2 ～ 3GB）不便于传输。2013 年，Docker（当时称 dotCloud）公司开源了其应用打包的项目，命名为“Docker”，通过 Docker 镜像方式，解决了单体应用打包、交付的问题。简单来说，Docker 镜像是一个压缩包，由一个完整操作系统的所有文件和目录构成，所以这个压缩包里的内容与本地开发和测试环境用的操作系统是完全一样的。需要注意的是，这些文件和目录不包含操作系统内核，在 Linux 中，这两部分是分开存放的，操作系统只有在开机启动时才会加载指定版本的内核镜像。除了解决单个应用交付问题，Docker 还利用 Linux 的 Namespace（命名空间）、Cgroup（控制族群）等技术实现了资源隔离、资源限制。由于减少了 Hypervisor，相比于虚拟机，在一台 Linux 主机上可以运行许多 Docker 容器，每个容器可以包含独立的应用，相互之间彼此隔离。同时，Docker 提供了简单的命令，帮助开发者制作、分发镜像。因此，一经推出，Docker 很快成了单体应用交付的热门方式。

但是人们很快发现，Docker 仅仅解决了单体应用的交付问题，无法解决复杂应用的编排管理问题。随着互联网技术的发展和影响，各个行业的应用逐步向微服务化、复杂化发展，每个微服务通常具备独立功能，由独立的团队负责开发和维护。服务与服务之间存在服务注册、服务发现、路由选择、流量控制、灰度发布等需求。这些都是 Docker 不具备的。因此容器编排、应用编排成为新的热点领域。经过数年的发展，Google、Red Hat 主推的Kubernetes 最终胜出，成为事实上的容器编排、应用编排标准。

3. 云原生概念的发展

在 Docker 和 k8s 不断发展时，“云原生应用”的理念被逐步提出。2014 年，Pivotal公司提出了“Cloud Native”一词，并且提出了一系列概念，凡是符合这些概念的应用都叫云原生应用。Pivotal 公司也在不断修改云原生应用的特征定义，2014 年，该公司Twelve-Factor 应用、Microservices 等；2017 年，提出模块化、可观测性、可部署性、可测试性、可处理性、可替换性，2019 年，将云原生应用的特征定义修改为 DevOps、持续交付、容器化、微服务化。同时，CNCF 基金会是云原生理念的重要推手，它不断改变云原生应用的定义：2015 年，将云原生应用定义为容器化、微服务化、动态编排，2018 年，将云原生应用定义为容器、服务网格、微服务、不可变基础设施、声明式 API（应用程序编程接口）。云原生服务的发展如图 1-3 所示。

图 1-3　云原生服务的发展

总之，“云原生”虽然像“中台”概念一样也在不断被炒作，但云上的应用的确在向“云原生应用化”发展。云原生只是一种理念，指的是软件“生于云上、长于云上”，能够最大化地利用云的能力实现商业价值。很多人认为云原生就是容器、k8s，其实不太准确。没有容器、k8s，一样可以实现云原生，但有了容器和 k8s，再配合其他技术、产品，能够更好地组织团队，利用云提供的各种能力，如 DevOps，以敏捷的方式开发、交付、管理复杂应用，更快地响应市场，实现商业价值。云原生也是“云的本源需求”。云计算的初衷就是要像水、电一样为人们提供按需、随处可得、易用、弹性的服务和能力。用户不需要考虑水和电是如何产生的，只需要考虑如何利用水和电。云原生也一样：用户只需要专注业务、考虑如何实现业务，而不需要考虑业务必需的硬件、操作系统、数据库、MQ（消息队列）、缓存、开发框架、微服务框架等。这些都交给云服务商来考虑。

所以，云原生对开发者来说，就是要利用好云的能力，构建满足容器化、微服务化、可以敏捷迭代、更具备弹性化等特征的云原生应用；对云服务商来说，就是要在设计云产品和服务时，考虑如何更好地支撑和承载云原生应用。