目录

十月末-solo博客

talk less,code more.

X

"囫囵吞枣" 三、虚拟化技术的发展

虚拟化技术的发展

image.png

Hypervisor——虚拟的开始

硬件性能过剩、切换操作系统、隔离工作环境等诸多因素,主机虚拟化 (虚拟机)相关的技术一直是行业需要。
Hypervisor:对虚拟机提供运行完整的“虚拟硬件环境”并管理的软件。
Hypervisor实现可以分为两类:

  • 全虚拟化:在本地的系统上安装Hypervisor软件来提供运行虚拟机的环境,通过软件模拟完整的底层硬件设备和外部I/O设备,性能损失程度大。
  • 半虚拟化:物理机系统本身就是Hypervisor,CPU指令改成系统接口供虚拟机调用,性能高效

CPU自身支持虚拟化技术,如inter-VT和AMD-v,可以辅助全虚拟化硬件加速。常见的Hpervisor有VMware、Virtual Box、Hyper-V、XEN、KVM+Qemu等。这些技术隔离了“虚拟硬件”,大部分通过硬件辅助虚拟化加速,减少虚拟机物理硬件性能损失。

CONTAINER——集装箱的远航

LXC(linux container)

Hypervisor的缺点是资源隔离粒度不够精细,比如在创建虚拟机时,分配CPU和内存的对象是整个虚拟系统。并且对磁盘只能限制容量,磁盘I/O限制往往依赖系统内核实现。

轻量操作系统虚拟化的技术在类unix上发展的很早,可以追溯到1979年诞生建立与原系统隔离的系统目录的chroot命令,1999年FreeBSD jail更一步,将系统分区为多个子系统。2005年系统级虚拟化主机(VPS)的OpenVZ 问世(现在去买一些服务器依旧会提供基于OpenVZ的VPS方案,也经常会超售)。2006 年,Google 推出 Process Containers,用来对一组进程资源进行限制、记账、管理,第二年就并入了 Linux 内核主干,并正式更名为 Cgroups。以及2008年集linux 的namespace(隔离)和Cgroup(控制)于一身的**LXC(linux container)**技术。

namespace
  • PID namespace:保障进程隔离,每个容器都以PID=1的init进程来启动。
  • MNT namespace: 保障每个容器都有独立的目录挂载路径。
  • UTS namespace:保障每个容器都有独立的主机名或域名。
  • NET namespace:保障每个容器都有独立的网络栈、socket和网卡设备。
  • IPC namespace:只有在相同IPC命名空间的容器才可以利用共享内存、信号量和消息队列通信。
  • User namespace:用于隔离容器中UID、GID以及根目录等。可配置映射宿主机和容器中的UID、GID。
  • Cgroup namespace:保障容器容器中看到的 cgroup 视图像宿主机一样以根形式来呈现,同时让容器内使用 cgroup 会变得更安全。
Cgroup
  • cpu/cpuset/cpuacct group:设置CPU share、cpuacct控制CPU使用率
  • memory group:控制内存使用量;
  • device group:控制在容器中看到的device设备,保障安全。
  • freezer group:容器停止时Freezer当前容器进程都写入cgroup,进程冻结。
  • blkio group:限制容器到磁盘的IOS、BPS;
  • pid group:限制容器里面可用到的最大进程数量。

联合文件系统

everything is file

在主机虚拟化的概念中,虚拟主机都要有完整的“虚拟硬件”,使得上层的系统和应用都运行在“真实环境”中。但是,如果思考一下实际的场景——用户交互的对象只有应用,那么只提供让应用能隔离运行的虚拟环境能极大减小部署开销。

系统本身是文件。如果有这么一种文件系统:文件之间按层级隔离并组合,越上层的文件会覆盖掉底层相同的文件。在这种“文件系统下”不同应用之间的可以复用同一个只可读的底层的系统镜像层,在应用各自独立的文件系统加入可读写的层文件覆盖掉底层的文件。最后统一挂载到根目录,这便是联合文件系统(Union File System)技术。这样通过UFS,实现了上层应用的隔离。

dockerfile.png

docker

“Docker”一词来自英国口语,意为码头工人(Dock Worker),即从船上装卸货物的人。

伴随着云基础设施的完善和 PaaS 概念的逐步普及,不少的大厂开始布局PaaS平台服务,2011年Vmware开源的Cloud Foundry平台(现属于Pivotal)和同时期Red Hat发布的OpenShift等等。一个迫在眉睫的问题摆在眼前:PaaS如何方便的给用户提供上层的应用服务?

2013年,dotCloud公司发布了其PaaS业务的容器开源项目——Docker,并同年将公司也更名为Docker。Docker将lxc的资源隔离和UFS的特性结合,推出了容器镜像(docker image),一种新型的应用打包、分发和运行机制。容器镜像将应用运行环境 ,包括代码、依赖库、工具、资源文件和元信息等,打包成一种操作系统发行版 无关的不可变更 软件包。Docker早期依赖lxc组件,后来引入了基于Go语言构建的Libcontainer,消除了对LXC的依赖。容器技术革命的火焰正式点燃,云原生应用变革的技术帷幕拉开。

通过容器技术,应用构建部署的方式发生了翻天复地的变化:在构建应用时,可以直接通过创建代码环境容器,在容器中完成应用编译;在部署应用时,讲二进制的应用打包为镜像,极大的方便了应用的部署和迁移。正如Docker的口号所说:Build once, Run anywhere 。并且通过cgroup等相关技术,实现资源弹性伸缩,正好符合云时代的弹性服务需求。

2015 年 6 月 22 日,由 Docker 公司牵头,CoreOS、Google、RedHat 等公司共同宣布,Docker 公司将自家的 Libcontainer 捐出,并改名为 RunC 项目,交由一个完全中立的基金会管理,然后以 RunC 为依据,大家共同制定一套容器和镜像的标准和规范。这便是OCI(Open Container Initiative)Linux基金会项目(主义一个月后,在谷歌的推动下,CNCF也成立了)。OCI旨在推动开源技术社区制定容器镜像和运行时规范,使不同厂家的容器解决方案具备互操作能力,这也就是容器的OCI标准

容器技术并不等价于Docker,还有CoreOS主导的rkt、Oracle推出Solaris Containers 等等,但Docker已经成为了容器技术的事实标准

kubernetes——云原生时代的舵手

kubernetes,希腊语含义是舵手

用容器技术“打包”应用,那么对于由多个功能模块构成的应用该如何打包呢?还记得“微服务”的理念吗?用一个镜像封装应用的一个进程功能,对应一个微服务,将应用解耦;再运行多个不同功能的容器,将完整的业务系统耦合出来。

但随着微服务架构上云后,问题变得异常复杂,比如应用的不同服务可能在的云服务器上,或者应用本身就是分布式架构,不同服务之间的启动顺序往往是存在依赖的,需要对多个异地容器统一管理;单一的服务故障可能导致整个系统故障出故障,为了降低故障率,往往会为服务部署多个冗余的“副本容器”。如何解决部署的依赖(容器编排)问题、如何在不同计算机上管理调度数量庞大的容器、容器之间如何发现(服务发现),如何在多个副本之间负载均衡、如何定点故障、如何等等问题随着容器技术的发展摆在了眼前。

我们需要一种系统——用来管理容器的系统!2015年,CNCF首个开源项目发布——Kubernetes。

kubernetes,简称k8s,最初源于谷歌内部的Borg 和 Omega 系统。这套系统已经在 Google 内部运行了10年以上,并还在支持Google 每周数十亿容器的运行。

将中间字母的缩写为字母数的做法并不少见,比如internationalization,缩写为i18n。

k8s提供了以下的功能

  • 服务发现:通过ip或域名暴露容器服务
  • 负载均衡:如果到容器的流量很大,k8s可以分配网络流量
  • 存储管理:允许挂载本地存储或者公有云提供商来持久化数据
  • 自动部署和回滚:允许指定部署容器的状态,控制状态切换的时间
  • 自动装箱:指定每个容器的资源分配,k8s自动调度容器到合适的node
  • 自我修复:重新启动失败的容器、替换容器等
  • 密钥与配置管理:不重建容器的情况下部署和更新密钥和应用程序配置

除了k8s,其实还有其他的容器编排工具比如DC/OSDocker Swarm等等,但在容器编排领域k8s已经成为事实标准。

后话

容器相关技术为云原生时代补齐了最后一块拼图,随着 2017 年各大厂在 CNCF 这张谈判桌上达成了 Kubernetes 兼容性认证流程,Kubernetes 编排服务市场迎来一轮大爆发,到 2018 年各大云厂商的 K8s 容器编排服务就完整就位了。亚马逊推出了EKS,微软Azure推出了AKS,谷歌推出了GKE,华为推出了CCE,阿里推出了ACK,腾讯推出了TKE等等。

那么Docker公司呢?2019 年 11 月 13 日,私有云基础设施公司 Mirantis 在其官方博客宣布,收购 Docker 公司企业级业务,包括接管它的 700 多个客户,这标志着 Docker 公司从 2013 年开始的商业化探索彻底失败。

如今,站在风口上,仍然可能飞不起来。

参考

容器技术之发展简史-刘奖

Docker——what is container

《Borg, Omega, and Kubernetes》

Redhat——what is a linux container

《循序渐进学docker》

《Cloud Native Devops with kubernetes》

《Kubernetes 中文指南/云原生应用架构实战手册》


标题:"囫囵吞枣" 三、虚拟化技术的发展
作者:bingoct
地址:https://blog.bingoct.top/articles/2022/02/21/1645431316262.html
Creative Commons License
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.