容器技术的前世今生

作为一个软件工程师,DevOps工程师或DevSecOps工程师,系统集成商,甚至网络工程师,你肯定听过这样一句话,用容器、Docker或者Kubernetes的方式来描述一种新技术已经成为一种流行。“……一种系统级别的虚拟化技术,允许存在多个隔离的用户空间实例……”

当然,作为软件工程师、DevOps工程师或DevSecOps工程师、系统集成商或网络工程师,多个独立用户空间实例的存在对你有不同的意义。

但是,从广义上讲,容器提供了一种机制,允许将应用程序(软件、库和配置文件等)打包并部署到宿主机的隔离环境(用户空间)中。

每个容器都独立运行,但如果容器之间需要进行通信。必须为容器之间构建通信通道,并在操作系统层面上管理这些通道。通道的连通性有两个要素:网络拓扑用于识别各个容器和是否有权限建立连接。

随着更好的安全性、监控、自我修复和可伸缩性机制的加入,容器在微服务领域大放异彩,特别是在开发和部署方面。

但我们是如何走到这一步的呢?这种神秘而又不为人所知的技术是如何突然出现,并在短短几年内主导云计算、高并发应用和微服务部署的呢?事实证明,所有旧的技术都将变成新的技术。

故事开始于很久以前,确切地说是1979年。在第7版的Unix系统开发过程中。那时候,我还是个爱惹麻烦的六岁小孩。

在Unix的开发过程中,引入了一个称为chroot系统调用的新特性。Marshall Kirk Mckusick博士建议Bill Joy在1982年3月18日(4.2BSD发布前17个月)添加了它。

这个新系统调用的本质是允许将进程及其子进程的根目录更改为文件系统中的新位置。这是文件系统级别进程隔离的开始,即为每个进程隔离文件访问。chroot系统调用于1982年正式添加到BSD中。但再次谈到chroot就是18年后。

在2000年的最后几个月,另一特性出现:FreeBSD jails。1999年,经生产环境应用后,Poul-Henning Kamp正式将该功能引入到FreeBSD中,并首次在FreeBSD 4.0中发布,因此许多FreeBSD后代都支持该功能。

主机托管提供商创建FreeBSD jails的动机是,出于安全和易于管理的需要,对其不同客户的服务实现明确的分离。FreeBSD jails允许系统管理员将一个FreeBSD计算机系统划分为几个独立的、较小的系统(称为jails),并能够为每个系统分配单独的IP地址和系统配置。

2001年,Jacques Gélinas开始了一个新的项目,其目的是在计算机系统中实现一个监狱机制,为计算机系统提供安全的分区资源,即文件系统、CPU、网络地址和内存。没有进程可以对自己分区外的分区发起拒绝服务或其他攻击。Linux VServer就是此次项目的结果。

可以通过为Linux内核打补丁的方式实现Linux VServer操作系统虚拟化机制。最后一个稳定版补丁是在2006年发布。根据维基百科,最近的稳定发布版是2.6.22.19-vs2.2.0.7,发布于2008年3月14日。最新的预览版本是4.9.195-vs2.3.9.8,发布于2019年10月5日。

在2004年2月的早些时候,Sun Microsystems发布了Solaris容器(包括Solaris zone),作为x86和SPARC系统的操作系统虚拟化技术实现。Solaris容器的第一个公开测试版结合了系统资源控制和区域边界分离,从而能够利用快照和ZFS克隆等特性。

每个Solaris zone都有自己的节点名,可以访问虚拟或物理网络接口,并为其分配存储空间。除了部分配置所需的磁盘存储之外,对给定区域没有最低的专用硬件要求,它不需要专用的CPU、内存、物理网络接口或主机总线适配器。尽管可以为特定的区域分配特定资源。

OpenVZ是一种用于Linux的操作系统虚拟化技术,它使用一个经过修补的Linux内核来进行虚拟化、隔离、资源管理和检查。这些代码并没有作为官方Linux内核的一部分发布,但是它的后代在我们的故事中扮演了至关重要的角色。

2014年,时任Virtuozzo高级软件工程师的Kir Kolyshkin在LiveJournal上发表了一篇博文,他说:“事实上,早在1999年我们的工程师开始将容器技术添加到Linux内核2.2中。嗯,当时还不叫容器,而称之为虚拟环境。这在新技术中经常发生,只是术语有所不同而已。(术语container一词是在2004年由Sun Microsystems提出的)。

2000年,他们已经将实验代码移植到Linux内核2.4.0test1,并在2002年1月发布了Virtuozzo v2.0。随着时间的推移,更多的功能被添加进来,比如实时迁移功能。但是直到2005年,他们才意识到使用自由开源软件模式将极大地提高项目的实用性。因此,OpenVZ作为一个独立的实体诞生了,作为商业版Virtuozzo的补充(后来更名为Parallels Cloud Server, 缩写为PCS)。

2006年,谷歌启动了Process Containers项目。该技术主要由Paul Menage和Rohit Seth领导,旨在限制、计算和隔离进程的资源使用,例如CPU、内存、磁盘I/O和网络。

2007年,Process Containers被重新命名为Control Groups或cgroups,并最终合并到Linux内核v2.6.24中。

2008年,LXC(LinuX Containers)是第一个完整的Linux容器管理器实现。通过使用cgroups和Linux命名空间实现。它在一个Linux内核工作,不需要任何额外的补丁。LXC结合了cgroups和Linux命名空间,为应用程序提供了一个独立的运行环境。

LXC通过创建自己的进程和网络空间提供虚拟环境,而不是创建一个完全的虚拟机。早期版本的Docker使用LXC作为容器执行驱动程序(Docker引擎),尽管LXC在v0.9中是可选的,官方支持最终在Docker v1.10的发布中被删除了。Virtuozzo、IBM和谷歌负责LXC的内核级工作,由Eric Biederman等人领导。而命名空间团队则由Daniel Lezcano, Serge Hallyn,Stephane Graber等人领导。

2011年,Cloud Foundry启动了Warden项目。在早期阶段使用LXC,但后来用它自己的实现替换了LXC。Warden可以作为守护进程运行,并为容器管理提供高级API,从而在任何操作系统上隔离环境。作为客户机-服务器模型开发,用于跨多个主机管理容器集合。Warden还包括一个管理cgroups、命名空间和进程生命周期的服务。

Garden以Go语言对Warden进行重新编码的形式发布,并为Diego提供了容器技术。反过来,这也是Cloud Foundry的未来架构。Garden是一个平台无关的高级API,用Go编写,用于容器创建和管理,具有可插入的后端,可用于许多不同的平台和运行时。

2013年,Let Me Contain That For You(LMCTFY)作为谷歌的开源项目,提供Linux应用程序容器。应用程序可以被容器感知,创建和管理自己的子容器。

2015年,谷歌开始将LMCTFY的核心概念贡献给Libcontainer,就停止了对LMCTFY项目的开发维护工作。现在Libcontainer是Open Container Foundation的一部分。Libcontainer是一段与Linux内核(如cgroups和命名空间)交互的代码。

Docker是一种Linux容器(LXC)技术,增加了高级API,提供了一种轻量级的虚拟化解决方案,可以独立运行Unix进程。它于2013年3月发布,提供了可预测、安全、可重复、自动化的部署软件(工作负载)。

它是一种可重复的、轻量级的虚拟化解决方案,因为“它在进程级别上是隔离的,而且它有自己的文件系统”。高级API允许系统管理员在容器上执行许多操作:如启动、停止、复制、等待、提交、附加标准流、列出文件系统更改等。

Docker最初是作为一个开源平台发布的,名称是dotCloud。在仅仅几个月的最初版本,大量的开发人员对Docker产生了极大的兴趣和测试教程。2013年9月和Red Hat达成战略合作伙伴,并在2014年4月15号正式对外公布。

Docker因为和Red Hat的良好关系,甚至得到了谷歌、亚马逊、微软等商业公司的更多支持,进一步增强了其在容器化领域的影响力。

Docker使用了标准容器概念,它包含一个软件组件及其所有依赖项,二进制文件、库、配置文件、脚本、虚拟环境、jar、gem、tar包等等。并且可以在任何支持cgroups的x64位Linux内核上运行。此类容器可以部署在笔记本电脑、分布式基础设施、云上,保护其环境并使其适用于广泛的用途,持续部署、Web部署、数据库集群、SOA等等。

当Docker在2013年出现时,容器的受欢迎程度激增。即使在今天,Docker和容器的使用率一直是齐头并进的,甚至有时它们就表示同一个意思。2014年6月Docker宣布发布1.0版本时,该软件的下载量已达到惊人的275万次。

但这一势头并不意味着Docker是所有容器管理平台的王者。许多用户很快指出Docker缺乏安全性,因为它使用了一个中央Docker守护进程。CoreOS等公司以此为线索,提供了自己的具有竞争力的容器管理软件,以确保用户获得更可靠、更安全的平台。用户还发现Docker缺少编排工具,这促使了Kubernetes的崛起。

尽管存在缺陷,Docker还是在亚马逊的帮助下稳步前进,亚马逊发布了弹性计算云(EC2)容器服务。这使用户能够更好地在亚马逊托管的EC2实例集群中运行Docker容器。

正如Warden之前所做的那样,Docker在最初的阶段也使用了LXC,在Docker以后的版本中用自己的库Libcontainer替换了原有的容器管理器。但毫无疑问,Docker为容器管理提供了一个完整的生态系统。

随着以容器为基础的应用程序的迅速和广泛应用,系统变得更加复杂,面临的风险也增加了。这为容器安全奠定了基础,在2016年,像dirty COW这样的安全漏洞进一步推动了这种想法。

这导致了一种转变,在容器应用程序和微服务开发的每个阶段中,安全性变得异常重要。

2017年初,有大量的工具涌现,使容器管理变得容易。

Kubernetes就是一个明显的例子。自2016年云原生计算基金会(CNCF)采用该技术以来,VMWare、Azure、AWS和Docker公司就宣布了它们对Kubernetes的支持和兼容性,Kubernetes可以运行在它们自己的基础设施上并与之集成。

随着环境和市场的持续成长,一些工具已经开始定义容器生态标准。Ceph和REX-Ray定义了容器存储标准,Flannel成为了容器网络的默认实现。在CI/CD持续集成/持续交付方面,Jenkins完全改变了DevOps和DevSecOps大规模构建和部署应用程序的方式。

2017年末,容器生态系统变得独一无二,因为它是由整个社区共同努力以及对开源项目的支持所推动的。Docker公司在2017年将Containerd项目捐赠给CNCF就是一个很好的例子。同时,CNCF也接纳了CoreOS的rkt容器运行时。

回到2014年12月,CoreOS发布了rkt容器,作为Docker的替代品,提供了应用程序容器镜像的另一种标准格式、容器运行时,以及容器发现和检索协议。

CoreOS的rkt容器的出现,使用户有了更多的选择,并促成了容器社区的良性循环。

谷歌在2003-2004年左右引进了Borg系统。一开始只是一个小规模的项目,只有3-4个人。

Borg是一个大型内部集群管理系统,用于运行数十万个作业,来自数千个不同的应用程序,并且跨许多集群,每个集群最多有数万台机器。

随着Borg的引入,谷歌也随之推出了Omega集群管理系统。Omega是一款灵活、可伸缩的调度器,可用于大型集群。谷歌在2017年推出了Kubernetes作为Borg的开源版本。在短时间内,Kubernetes变得越来越成熟。

2015年7月21日Kubernetes v1.0发布。在发布的同时,谷歌与Linux基金会合作,成立了云原生计算基金会(CNCF)。CNFC表示,其目标是建立可持续的生态系统,并围绕一系列高质量的项目建立一个社区,这些项目将成为微服务架构的一部分。

Kubernetes发展迅速,支持越来越复杂的应用程序类别,允许大量企业过渡到混合云和微服务。在2017年哥本哈根的DockerCon上,Docker公司宣布他们也将支持Kubernetes。

微软的Azure和亚马逊的AWS也很快推出了自己的Kubernetes服务,分别为AKS和EKS,旨在与ECS竞争。Kubernetes也是CNCF的第一个项目,并拥有越来越多的第三方系统集成服务提供商。

2018年,容器化最终成为现代软件基础设施的基础。Kubernetes有史以来第一次被大量企业使用。截至2018年初,GitHub上的Kubernetes项目拥有超过1500名贡献者,是最重要的开源社区之一,拥有超过27000颗星星。到2020年7月初,这个数字已经增长到超过62000颗。

Kubernetes令人难以置信的受欢迎程度,让更多的企业,如AWS、Oracle、谷歌、Azure、VMWare、RedHat和Rancher都开始提供基于Kubernetes的管理平台。

基础设施提供商,如VMware也开始采用Kubernetes。2018年底,VMware宣布收购咨询公司Heptio,后者帮助企业部署和管理Kubernetes。容器化领域还出现了新的混合技术,将虚拟机级别的隔离性和容器的快速相结合的技术。

开源项目,如Kata容器、gVisor和Nabla尝试提供更安全的容器运行时,以及轻量级的虚拟机,这些虚拟机的执行方式与容器相同,但提供了更强的工作负载隔离。

2019年,容器生态系统发生了重大变化。新的运行时引擎试图取代了原来的Docker运行时引擎containerd。最著名的开源容器运行时引擎是CRI-O,一种针对Kubernetes的轻量级运行时引擎。

此外,2019年还发生了一件大事。当年Docker Enterprise被收购并拆分,导致Docker Swarm的寿命被延长2年。与此同时,我们也看到了rkt容器引擎的受欢迎程度持续下降,尽管它仍然是CNCF稳定版的一部分。

与此同时,VMware加注对Kubernetes的投入,先是收购了Heptio,然后收购了Pivotal Software(包括PAS和PKS)。这一举措旨在为企业提供私有云服务。

这一年,无服务器技术平台也取得了进步,比如Knative(基于Kubernetes的无服务器工作负载管理平台)得到了组织的青睐。

2019年推出的基于Kubernetes的混合云解决方案,如IBM Cloud Paks,Google Anthos,Aws Outposts和Azure Arc。这些云平台模糊了传统云和on-prem环境之间的界限,使客户可以管理on-prem和云上的集群。

2020年,企业对容器和相关技术的采用大多围绕着新的实现。虽然系统集成商确实对现有的工作负载表现出了相当大的兴趣,但这很难证明是合理的。

考虑到在遗留应用系统中应用容器或者微服务,需要进行大量的重构,这可能会在短期内阻碍这些技术的持续发展。也就是说,新应用系统会更倾向于使用容器技术,因为容器编排工具(如Kubernetes)正在不断出现并持续改进。

Kubernetes已经成为每个人都想使用的容器编排工具,但这并不是说,其他的容器编排工具,如Docker Swarm和Apache的Mesos会消失。

甚至连容器编排工具本身也在不断进化,从集中的容器编排到与云内或云间其他集群无缝协作的分布式集群。

根据最新的State of Kubernetes (2020) 报告,Kubernetes的使用率从2018年的27%上升到2019年的48%。57%的受访者表示运行的Kubernetes集群少于10个,多达60%的受访者表示有一半的容器化工作负载运行在Kubernetes上。

尽管Kubernetes给企业带来了明显的好处,特别是那些需要大规模部署应用程序和微服务的企业,但Kubernetes并不经常部署在云中。相反,报告显示60%的企业将Kubernetes部署在on-premises环境中,云部署的比例紧随其后,大约42%,而其他部署模式则更低。

对容器尤其是Kubernetes持乐观态度的一个原因是,这些早期采用者获得了显著的好处。95%的受访者表示,采用Kubernetes系统可以带来明显的好处,56%的受访者将资源利用列为Kubernetes系统最大的好处,53%的受访者表示缩短软件开发周期是最大的好处。

其他明显的好处包括独立的应用程序、支持迁移到云以及降低公共云成本。总体而言,报告显示了开发和运维方面的积极成果。这个故事始于41年前,在Unix 7(简称V7)的开发过程中,从chroot到容器的道路是漫长而曲折的,它对大规模应用程序和微服务的真正影响现在才开始显现。

原文链接:https://medium.com/dev-genius/j-a-cirez-goes-into-the-container-business-4700dcf66059

DDD实战演练工作坊

DDD实战演练工作坊将于2020年10月17日在北京开课。DDD全过程工作坊将以事件风暴为纵贯线,以领域场景为横切面,驱动从战略设计到战术设计的全生命周期的完整开发过程。内容涵盖事件风暴、限界上下文、上下文映射、角色构造型、场景驱动设计和测试驱动开发。整个工作坊围绕一个全真案例进行演练,实践具有实操价值的领域驱动设计方法。点击下方图片或者阅读原文链接查看详情。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
《基于docker容器的高并发web系统架构设计与实现》随着互联网迅速发展,社交、媒体以及电商等web网站用户数量 越来越大,并发流量也越来越高,这对于传统web系统架构设计提出 新的挑战。本文基于docker容器虚拟化技术来设计实现高并发web系 统架构,实现web系统的高并发、易扩展以及提升系统资源利用均衡 率等功能。 本文基于docker容器以及Kubemetes容器集群技术,从负载均 衡、弹性伸缩以及资源调度等方面设计实现容器化高并发web系统架 构。设计实现基于工作负载特性的动态负载均衡策略,能够实现根据 不同负载类型以及容器集群资源利用率而实时调整容器集群服务的 权重;设计实现基于灰度模型短时间负载预测弹性伸缩策略,能够实 现高效容器集群弹性伸缩以及提升系统并发性能;设计实现基于蚁群 算法并行调度策略,能够有效提升容器集群整体调度效果,提高容器 服务集群的可用性以及改善系统的资源利用均衡率等。 基于docker容器的高并发web系统架构能够实现系统的高并发、 易扩展以及提升系统集群的资源利用率等功能。经过系统测试分析, 基于工作负载特性的动态负载均衡策略比传统轮询、加权轮询策略在 高并发流量下有更好的吞吐量以及响应时间等性能表现,基于灰度模 型预测的弹性伸缩机制比传统KubemetesHPA机制在短时间内具有 更好的集群伸缩特性以及基于蚁群算法的并行容器调度策略比传统 Kubemetesdefaults策略有更高的调度优势,能够有效提升容器的均 匀分发,实现系统高可用性以及提升系统的资源利用均衡率等。 基于docker容器技术高并发web系统架构设计,能够有效解决 当前高并发流量下web系统流量转发、集群伸缩以及资源调度等问 题,对于容器技术的具体应用研究以及高并发系统架构的设计具有一 定的实用价值。 关键词:高并发web系统,容器虚拟化,动态负载均衡,弹性伸 缩,并行资源调度
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值