容器化学习——从容器的发展历史理解容器的本质-4008云顶国际网站
近期工作上开始接触了相关容器化的内容,因此整理学习了一堆有关容器化的知识,特此进行分享。
首先,理解k8s和容器,首先需要学习以下它的发展历史,才能逐步理解容器的意义和作用。
在1979年,unix系统引入了一个革命性的命令,它允许系统管理员将进程的根目录锁定在指定的位置,从而有效地限制了该进程访问的文件系统范围。这个命令成为了早期容器技术的基石,因为它实现了基本的文件系统隔离,确保进程不能访问其指定根目录之外的任何文件或目录。
这种隔离能力对于安全性至关重要,特别是在监控潜在的恶意活动时。通过创建一个隔离的环境,或所谓的“黑盒”,系统管理员能够更安全地运行和监控可疑的代码或程序。
因此这个以文件形式进行隔离的命令为现代容器技术奠定了一个重要的思想基础:隔离。 后续的很多演变也都是基于“隔离”进行变化。
在2002年,linux社区迎来了一个重要的里程碑:引入了linux名称空间(namespace)功能。
名称空间是一种轻量级的虚拟化技术,它允许不同的进程拥有自己的独立视图,包括文件系统、进程id(pid)、用户id(uid)、网络接口等关键系统资源。
因此每个进程都在一个独立的环境中运行,这意味着在一个名称空间中所做的更改(例如文件系统的修改、网络配置等)不会影响到其他名称空间。
这种隔离不仅提高了系统的安全性,因为它限制了进程可能造成的潜在影响,也使得多个应用能够在同一个物理服务器上同时运行,而互不干扰。
在容器化的上下文中,名称空间提供了实现容器隔离的关键技术。因为每个容器实际上就是一组不同的名称空间和一些其他资源(如下文提到的cgroups)的集合。
cgroups(控制组)是linux内核的一个特性,最初由google工程师paul menage和rohit seth在2006年提出。
它通过将进程分组,并对这些分组进行资源控制和隔离,从而允许系统管理员精确地控制和限制进程组使用的资源量,如cpu时间、系统内存、网络带宽或磁盘i/o等。通过这种方式,能够有效避免一个进程出现问题把同机器上的其他进程的资源耗尽或占用, 成为了实现资源隔离和保证系统稳定性的强大工具。
因此linux的cgroups是现代容器技术中不可或缺的一部分,它提供核心的资源隔离和限制的底层实现原理。
lxc是linux发布的系统级虚拟化功能。
它允许用户在同一宿主机上运行多个隔离的linux系统实例。每个实例,或称为容器,都拥有自己的文件系统、网络配置和进程空间,但与传统虚拟机相比,lxc容器共享宿主机的内核,使得它们更为轻量级和高效。
lxc的理念在于封装系统,这意味着每个lxc容器都运行着完整的操作系统,包括其所有的服务和进程。
缺点在于每个lxc的体积相当大,当系统内的部件需要修改,必须重写很多配置,导致维护和更新过程相对繁琐和耗时。
基于lxc的缺点,有了相应改进,才有了后面docker容器的诞生和迅猛发展。
docker的容器化能力直接来源自lxc。后面docker的开发人员又自己用go语言开发了libcontainer避免了对lxc的强依赖。
对比于lxc, docker容器的理念在于封装应用。容器通常只包含运行单个应用所必需的最小环境,这使得它们非常轻量级和快速。当应用或其依赖需要更新时,只需修改有关部分并重新构建容器,这通常可以在几秒钟内完成。
除了轻量化以应用为中心的构建外,docker对比lxc还有以下七点优势
- 跨机器的绿色部署: 将所有环境依赖打包到一起,避免对机器的依赖。
- 自动构建: 无需关注目标机器具体配置,使用任务构建工具在容器中自动构建。
- 多版本支持: 支持git一样管理容器版本。
- 组件重用, 可以在基础镜像上构建专业化镜像。
- 共享,有公共的镜像仓库。
- 工具生态可以很方便扩展。
但docker并不是没有缺点。由于它主要关注应用层,这就需要开发者和系统管理员对应用的依赖和环境有深入的了解,以确保在不同环境中一致性和安全性的维护。
k8s(kubernetes)是容器编排框架, 把大型软件系统运行所依赖的集群环境也进行了另一种形式的虚拟化,令集群得以实现跨数据中心的绿色部署,实现自动扩缩。
可以用一个例子来理解k8s和docker之间的关系:
kubernetes 则相当于餐厅的经理,负责整体的流程和调度。它确保所有菜肴(容器)都能按时准备好,并且根据顾客的需求(负载)来增减特定的菜肴数量。比如,如果一道菜特别受欢迎,kubernetes可以指示厨房(集群)制作更多的这道菜(即扩展容器)。如果某个炉子坏了(节点故障),它会将菜肴分配到其他炉子上(重新调度容器)。
按工程语言描述,kubernetes负责管理由这些容器组成的应用集合,确保它们按预期方式运行。它处理部署、替换故障容器、服务发现、负载均衡、扩展和缩减容器数量等任务。
虽然k8s最开始完全绑定依赖docker, 但通过引入容器运行时接口(container runtime interface, cri), 允许 kubernetes 与多种容器运行时兼容,如cri-o、containerd等, 因此kubernetes 能够更加专注于其核心目标:集群场景下的容器编排,并成为了
对于传统本地搭建k8s集群而言,具有以下劣势:
- 高成本: 自行搭建和维护kubernetes集群需要大量的前期投资,包括硬件、网络设施等。
- 复杂性: 搭建和维护一个高效、稳定的k8s环境需要深厚的技术知识和经验。
- 维护负担: 需要持续投入人力去管理和维护硬件、软件、网络等。
- 缩放困难: 根据业务需求快速扩展或缩小资源可能会非常复杂和耗时。在业务初期发展阶段,纯靠经验很难快速覆盖各种缩放场景。
因此随着云计算的普及和成熟,容器化技术也开始步入云服务时代。这一时期,云服务提供商纷纷推出了各自的容器服务产品,如华为云的cce(云容器引擎)服务等, 企业和开发者也越来越多地转向云平台来部署和管理容器应用,享受云计算带来的灵活性、可扩展性和成本效益。
通过使用云服务提供的容器化能力,可以做到:
- 简化管理: 云服务提供商通常提供易于使用的管理界面和api,简化了集群的搭建、管理和扩展。
- 快速部署: 可以在十几分钟内就能启动和配置一个完整的k8s环境。例如通过,我们可以快速熟悉容器创建的整个过程。
- 自动扩缩容: 云服务通常提供自动扩缩容功能,根据实际负载自动调整资源。比如cce的弹性伸缩,可以
从工作负载和节点两个维度进行伸缩。
同时我们能够见到的各种云服务也会依赖cce云容器引擎的能力快速构建基础核心能力,例如大数据或ai等服务也可以利用cce的高度可扩展性和弹性来处理海量数据,支持复杂的数据处理和分析任务。
可以看到,随着时间的推进,容器化技术经历了丰富的演变过程,从早期的简单隔离到如今的云服务时代,每一个阶段都为信息技术领域带来了深远的影响,也是对市场需求快速响应的结果。
因此随着技术的不断进步和创新,相信容器化会继续引领软件行业的发展,推动更多创新应用的诞生。
- 点赞
- 收藏
- 关注作者
评论(0)