容器的历史，可能比你想象的更为久远
作者:戴尔科技集团
人们常说,IT的脚步日新月异,每天都有新的技术被创造、应用,每天也有旧的技术被淘汰,逐渐消失在人们的视野。但事实真的是这样吗?也许,这些新技术并没有那么“新”,那些“旧技术”也只是在等待破茧成蝶的那一天。
举个“栗”子,1999年VMware推出了第一个x86虚拟化产品VMware Virtual Platform并大获成功,继而成为当今虚拟化市场的领导者。对于一款产品来说,VMware的虚拟化确实是新的,但对于虚拟化本身来说,VMware虚拟化则是一种继承和突破,有关虚拟化的概念与早期产品,可以追溯到1960年代,这中间整整相差了39年。
容器技术也是一样,今天人们普遍将Docker视为容器的代名词,但其实容器要比Docker古老的多了。1979年,在Unix V7操作系统的开发中,为隔离出可供软件进行构建和测试的环境,chroot(change root)系统调用程序横空出现,这是容器史上第一道乍现的灵光。
接着到2000年,互联网开始繁荣,纳斯达克综合指数站到了5132.52的峰值,在这一年,一家小型的共享环境托管提供商提出了FreeBSD jails,以实现服务与客户服务之间的明确区分。FreeBSD Jails允许管理员将FreeBSD计算机系统划分为几个独立的,较小的系统,称为“ jails”,并能够为每个系统和配置分配IP地址,真正意义上实现了进程的沙盒化。从而成为容器发展史上的一个重要转折点。
此后,又经过了13年的蛰伏,直到2013年,随着开源Docker项目容器镜像格式和运行时的横空出世,容器才真正广受欢迎。
Docker诞生在云计算繁荣的背景下,这种使应用程序部署更精简,更方便的方式,恰好符合云时代人们对于敏捷和灵活的要求。Docker镜像是一种标准化、轻量级、独立、可执行的软件包,其中包含运行一项功能所需的一切组件,例如代码、运行时间库、环境变量以及配置文件。从而避免了依赖运行容器的各种服务器的操作系统,实现 “build once,run anywhere”。
容器和Kubernetes
说到容器,不少人也把Kubernetes与Docker相提并论。其实两者没有直接的可比性,根基不同,解决的问题也不同。Kubernetes最初由谷歌开发而来,目前由云原生计算基金会(Cloud Native Computing Foundation, CNCF)管理。Kubernetes的目的是为了解决容器不易于批量管理的问题,实现容器集群的自动化部署、自动扩缩容、维护等功能。
今天,Kubernetes已成为构建容器化平台体系的默认抽象方案,从更大的意义上来说,Kuberntes也是容器发展的重大贡献者之一。试想一下,容器(Container)就是集装箱,本身就是个大铁盒子,其实没有太多价值,单单靠它提高不了社会协作的效能。它只有流动起来,把货物从一个车间运到另一个车间,从一个国家运送到另一个国家,才能极大提高生产力,这种连接才是其价值所在。
而Kubernetes就是这样一个容器编排工具。在既有硬件资源的基础上,启动容器不需要关注具体运行的节点,各个容器之间仍能保持通信,信息在容器之间依然可以流动。这样容器技术便可以付诸商用,整个软件的开发交付流程就会变得高效和颠覆。
在具体操作中,Kubernetes使用主节点来调度和管理容器应用的执行过程。主节点提供环境来执Kubernetes控制面板,搭建集群,以及安排容器执行日程。Kubernetes容器在工作节点中的pod下执行。
一般情况下,每个pod运行一个容器实例,或者少数选定的实例——这些少数实例共享着需要共同执行的资源。一个Kubernetes pod包含操作系统和运行时间环境,该环境使容器应用能够运行。容器网络由Kubernetes控制面板、主节点和工作节点配置和管理,旨在提供容器应用所需的IP连接。
容器离不开编排
容器也离不开IT基础架构
正如容器在Kubernetes的推动下得到了极大发展,一个位于底层的IT基础架构如果对于容器有很好的支持,也必将为开发人员带来事半功倍的效果。
去年,VMware发布的全新解决方案——VMware Tanzu和VMware Cloud Foundation 4,通过将容器与虚拟机统一为一体,用户可以在vSphere7.0下大规模地并行运行Kubernetes服务和虚拟化应用,从而为应用的开发和运维带来极大便利。
而作为市面上唯一全面集成VMware、预先配置VMware软件的超融合一体机,VxRail也已同步升级到7.0版本,通过大幅降低使用Kubernetes和基于Kubernetes的开发者工具的复杂性,为用户提供了从单一环境到Kubernetes的简单直接路径。
从此IT管理员可以在熟悉的vSphere客户端环境中使用Kubernetes,同时启动并运行所有的关键应用程序。企业在一个统一平台逐步实现应用现代化和新应用持续交付,获得了更好的云原生体验,为业务创新赋能。
此外,VxRail也支持独立的开源Kubernetes。开发人员可选择下载和配置Kubernetes 版本,将节点作为虚拟机在vSphere上运行。使用独立的Kubernetes 集群来运行容器,需要手动下载、安装、配置、检验和管理 Kubernetes软件。
不过独立的Kubernetes不具备原生的自动化生命周期管理或高可用性支持 。Kubernetes节点可能由于出错而发生故障,这些节点将无法提供服务。如果你的团队拥有在裸机环境中运Kubernetes的丰富经验,可选择独立Kubernetes。
当然,更推荐的还是戴尔科技和VMware 联合提供最佳技术解决方案来运行容器应用,用户能够更快速地采用云原生技术,并且更进一步采用数字化业务项目。VxRail和vSphere已成为在数据中心运行云原生Kubernetes容器应用的优选平台。
容器or虚拟化?
两者不是二选一
最后,不得不提的是容器与虚拟化的关系,不少人把容器当成是轻量级的虚拟化,由此难免与传统虚拟化技术进行比较。其实,两者并不等同。传统虚拟化是硬件的虚拟化,目标是建立一个完全独立的沙箱式操作系统环境。而容器技术则纯粹只是将应用系统相关的代码、运行时间库、环境变量以及配置文件打包成隔离的可执行沙箱环境,并没有做任何硬件虚拟化。
也就是说,传统虚拟化可以很容易地部署一台VM,但仍需安装各种执行环境所需要的程序并设定正确的环境参数才能运行应用,而容器可以大幅简化并自动化这些工作。所以容器和虚拟化非但不是竞争关系,而且还是互补而共生的。这也是VMware将两者合二为一的重要意义。容器和虚拟化好比是企业迈向数字化未来“左膀右臂”,VMware为开发者扫清了障碍,而VxRail就是那个坚实底座!
免责声明：市场有风险，选择需谨慎！此文仅供参考，不作买卖依据。