带你读《云原生应用开发 Operator原理与实践》第一章引言1.1云原生介绍-阿里云开发者社区

开发者社区> 人民邮电出版社> 正文
登录阅读全文

带你读《云原生应用开发 Operator原理与实践》第一章引言1.1云原生介绍

简介: 《云原生应用开发 Operator原理与实践》第一章引言1.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 公司推出了个人桌面版的虚拟化软件VMwareWorkstation(VMware工作站),用户可以在PC上安装不同的虚拟机,比如Linux发行版 RedHat、Ubuntu等。2001年,VMware 公司又推出了服务器版虚拟化软件VMwareESX,后来又推出了一系列虚拟化及管理软件,如 vSphere、vSAN、NSX等,逐步开启了一个私有云时代。与此同时,随着 VMware 公司在商业中取得巨大成功,越来越多的公司、学校、组织纷纷投入对计算、存储、网络虚拟化的研究,并推出了许多开源项目,其 中的典型代表包括计算虚拟化领域的Xen(2005年)和 KVM(2006年)、存储虚拟化领域的Ceph(2007年)、网络虚拟化领域的 OpenvSwitch(2009年)。在管理软件方面,2008 年出现了 OpenNebula;2010年 OpenStack问世,得到了全世界众多厂商和开发者的支持, 它逐步成为事实上的开源云计算管理平台标准(如图 1-1所示)。值得一提的是,以网上书店为主营业务的 Amazon于 2006 年推出了全世界第一个公有云服务AWS(AmazonWebService),以云主机EC2和对象存储S3为主要产品,逐步开辟了公有云时代。随着产品的不断丰富和用户数的不断增加,Amazon也成为万亿美元市值的大公司。

云计算1.0以虚拟化为主要特征,引入了计算虚拟化技术,将企业 IT应用与底层基础设施分离解耦,可以在同一台物理服务器上运行多个IT应用实例,从而提高资源利用率,降低成本。云计算2.0以自动化为主要特征,一方面引入了软件定义存储(SDS,SoftwareDefinedStorage)、软件定义网络(SDN,SoftwareDefinedNetwork)技术,

实现了计算、存储、网络的全面虚拟化,使得IT资源具备弹性、可扩展性;另一方面,引入了云管理平台,对各类基础设施资源进行统一管理,通过自服务、按需开通、按量计费的模式实现资源供应的灵活性和自动化。

image.png

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

 

总的来说,云计算 2.0 时代主要解决资源分配和管理的问题,这是资源维护者的核心诉求,而众多的资源中(计算、存储和网络等)又以虚拟机为主体,所以简单来说,这个时代的云计算就是围绕虚拟机构建IaaS 资源管理体系,所有的资源管理都是以虚拟机为核心实现配套设计。在以私有云为主的时代,完美地匹配了用户的需求。云计算2.0时代,用户是比较单一的,诉求就是作为IT操作人员(Operator)或者维护人员(Maintainer)要把资源的管理做到极致。这个时代其实也在尝试满足更高级的用户需求,比如早期基于虚拟机的 PaaS平台CloudFoundry、基于虚拟机的应用编排项目Murano 等,但它们都没有成为云计算 3.0时代的主流技术框架。云计算 1.0和云计算 2.0时代的主要用户场景如图1-2所示。

image.png

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

2. 云计算 3.0

 

IT 基础设施不能直接带来经济效益,在其基础上构建的应用更贴近于市场与业务发展的需求。 随着公有云的普及和私有云的极致发展,云计算的主要矛盾变成了日益增长的多元化用户(不仅仅是IT 维护人员)需求与落后的以资

源编排(分配)为主体的理念之间的矛盾。公    图 1—2    云计算 1.0和云计算 2.0 时代的王要用户场景有云用户更希望以应用为主体来构建IT 软件栈和系统,希望以更加敏捷、更细粒度的控制来适应应用的快速迭代,甚至是私有云的IT 管理员也希望资源编排更加敏捷。此时,云计算的核心理念就很自然地进入以应用编排为主体的云计算时代,我们称之为云计算3.0。因此,满足这个理念的 Docker、Kubernetes 等技术必将会在这个时代实现空前的发展。

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

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

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


 


版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享: