同学,你听说过“云原生”吗?
我相信大部分人会回答:“Yes,I do.”
是的,作为云计算领域的一个新兴概念,云原生现在频繁出现在我们的视野中。很多互联网大咖把它奉为至宝,走到哪说到哪。
那么,我们不仅会好奇,究竟什么是“云原生”?它会给我们带来什么改变?
今天这篇文章,我们来探寻答案。
云原生的起源
介绍云原生之前,我们先介绍一下CNCF。
CNCF,全称为Cloud Native Computing Foundation,中文译为“云原生计算基金会”。
这个基金会成立于2015年12月11日,属于Linux基金会旗下。
CNCF致力于培育和维护一个厂商中立的开源生态系统,来推广云原生技术。
所以说,CNCF是云原生领域影响力最大最有话语权的组织。
说起CNCF的故事,还要从Cgroups(control groups,控制组群)开始说起。
十六年前,也就是2004年,谷歌开始使用容器技术。到了2006年,谷歌发布了Cgroups,最初叫Process Container(进程容器)。
Process Container的目的非常直白,它希望能够像虚拟化技术那样,给进程提供操作系统级别的资源限制、优先级控制、资源审计能力和进程控制能力。
带着这样的设计思路,Process Container发布后第二年就进入了Linux内核主干。
因为在Linux内核中,容器(container)这个名词有许多不同的意义,为避免混乱,就更名为Control Groups,也就是Cgroups。
2013年,Docker项目正式发布,2014年,Kubernetes项目也正式发布。
Kubernetes项目的初衷,就是提供一种方式去帮助大家方便、快速、优雅地管理容器。(Kubernetes是云原生的基石,后面会细讲。)
在Google和Redhat发布了Kubernetes之后,这个项目的发展速度非常之快。
2015年,由Google、Redhat以及微软等大型云计算厂商以及一些开源公司共同牵头成立了CNCF云原生基金会。
CNCF成立之初,就有22个创始会员,而且Kubernetes也成为了CNCF托管的第一个开源项目。
CNCF一直保持高速发展。截止2020年2月,已有433个会员。
会员名单(部分)
那么,CNCF是如何定义云原生的呢?
云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中,构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。
这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段,云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。
云原生计算基金会(CNCF)致力于培育和维护一个厂商中立的开源生态系统,来推广云原生技术。我们通过将最前沿的模式民主化,让这些创新为大众所用。
除了CNCF之外,网络上还流传着另一个版本的“云原生”定义和来源——
这种说法认为,是Pivotal公司的Matt Stine,于2013年首次提出云原生概念。
2015年,云原生刚推广时,Matt Stine在《迁移到云原生架构》一书中定义了符合云原生架构的几个特征:12因素、微服务、自敏捷架构、基于API 协作、扛脆弱性。
到了2017年,Matt Stine改了口风,将云原生架构归纳为模块化、可观察、可部署、可测试、可替换、可处理6特质。而Pivotal官网对云原生概括为4个要点:DevOps+持续交付+微服务+容器。
MattStine认为云原生它是一个思想的集合,包括DevOps、持续交付(Continuous Delivery)、微服务(MicroServices)、敏捷基础设施(Agile Infrastructure)、康威定律(Conways Law)等。
云原生既包含技术(微服务,敏捷基础设施),也包含管理(DevOps,持续交付,康威定律,重组等),可以说是一系列云技术、企业管理方法的集合。
我们还是以CNCF官方的定义为准吧。
按CNCF的定义,云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。
那么,这些技术都是什么?这些技术有什么联系?
云原生的代表技术
容器
一般我们说的“容器”(LinuxContainer,LXC),都是“Linux容器”(当然微软也在搞容器,但还没Linux那么成熟)。
开源解决方案供应商红帽官网给出的容器定义:
Linux?容器是与系统其他部分隔离开的一系列进程。
运行这些进程所需的所有文件都由另一个镜像提供,这意味着从开发到测试再到生产的整个过程中,Linux 容器都具有可移植性和一致性。
因而,相对于依赖重复传统测试环境的开发渠道,容器的运行速度要快得多。容器比较普遍也易于使用,因此也成了 IT 安全方面的重要组成部分。
容器提供进程级的隔离,可以将操作系统管理的资源划分到相互隔离的组中,在相互隔离的组之间解决资源使用存在冲突的问题。
比如应用程序(Application)APP 1 ,只能在centos 操作系统上运行;APP2只能在Ubuntu操作系统上运行。而同一个操作系统同时运行APP1和APP2就产生冲突。容器技术则恰恰可以解决这类问题。目前主流的容器技术有Docker、LXD以及RKT等。
Docker
说到容器,就不得不说Docker。
2010年,几个大胡子的年轻人在美国旧金山成立了一家名叫“dotCloud”的公司。这家公司主要提供基于PaaS的云计算技术服务。具体来说,是和LXC有关的容器技术。
LXC,就是Linux容器虚拟技术(Linux container)。
后来,dotCloud公司将自己的容器技术进行了简化和标准化,并命名为——Docker。
Docker项目发布时,无非也是LXC的一个使用者。它创建和使用应用容器的逻辑跟Warden等竞争对手没有本质不同。
不过,我们现在也知道,真正让PaaS项目无所适从的,是Docker项目最厉害的杀手锏:容器镜像。
Docker项目通过容器镜像,直接将一个应用运行所需的完整环境,即:整个操作系统的文件系统也打包了进去。
这种思路,可算是解决了困扰PaaS用户已久的一致性问题,制作一个“一次发布、随处运行”的Docker镜像的意义,一下子就比制作一个连开发和测试环境都无法统一的Buildpack高明了太多。
Docker项目大大降低了容器技术的使用门槛。轻量级,可移植,虚拟化,语言无关,写了程序扔上去做成镜像可以随处部署和运行,开发、测试和生产环境彻底统一了,还能进行资源管控和虚拟化。
Docker作为一种开源应用容器引擎,是为开发人员和系统管理员设计的用于构建、发布和运行分布式应用的平台,典型的Docker平台Kubernetes、OpenShift V3、Flynn、Deis等。
Docker允许开发人员将各种应用以及依赖包打包到一个可移植的Docker容器中,以Docker容器为资源分割和调度的基本单位,封装整个软件运行时的环境,然后发布到Linux机器上。
按照Docker的设计方案,应用软件的交付过程如同海上运输,操作系统OS如同一个货轮,每一个在OS基础上的软件都如同一个集装箱。
用户可以通过标准化手段自由组装运行环境,同时集装箱的内容可以由用户自定义,也可以由专业人员(开发人员或系统管理员)定制。
如此一来,交付一个应用软件产品,就相当于交付一系列标准化组件的集合。