《凤凰架构》C11-虚拟化容器

目录

一、容器的崛起

二、以容器构建系统

三、以应用为中心进行封装

---

一、容器的崛起

1）兼容与虚拟化

兼容

类型	ISA兼容	ABI兼容	环境兼容
层次	底层硬件/指令集	编译后程序与系统的接口	高层运行环境
影响	是否能执行指令	是否能正确调用函数、链接库	是否能成功运行整个程序
举例	x86 指令集	C 函数调用、参数传递方式	是否有 glibc、libstdc++
是否可运行	是（可能跑错）	是（不保证行为正确）	是（功能完整才能正确运行）
兼容边界	不需要重编译	不需要重编译或重新链接	不需要改配置、补依赖
	最基础	中等	最宽泛

ISA兼容 √  ISA兼容  × 环境兼容

虚拟化用于解决上述的三类兼容性问题，引入一个“中间层”，隔离软件和硬件的直接绑定。

类型	虚拟化对象	虚拟化层次	核心机制	典型应用	优点	缺点/限制
指令集虚拟化	不同 CPU 架构指令集	CPU 指令级	动态二进制翻译 / 指令解释	QEMU、Rosetta、DynamoRIO	支持跨架构执行，兼容性强	翻译性能开销大，复杂度高
硬件虚拟化	物理硬件（CPU、内存、IO设备）	最底层，模拟整台机器	Hypervisor（裸机或托管型）	VMware、KVM、VirtualBox	高隔离性，能运行任意操作系统	启动慢，资源开销大，性能损失
操作系统虚拟化	用户空间资源（进程、网络、文件系统）	宿主操作系统层面的隔离	Linux Namespace + cgroups	Docker、LXC、OpenVZ	启动快，资源占用少，易扩展和部署	共享内核，隔离性低于硬件虚拟化
运行库虚拟化	应用运行时依赖库（系统调用接口）	应用依赖层面	动态库重定向、函数拦截、兼容层模拟	Wine、Proton、LD_PRELOAD、Python venv	解决跨平台库兼容问题，灵活轻量	不涉及系统资源隔离，兼容性复杂
语言层次虚拟化	编程语言字节码或解释代码	语言/运行时层	语言虚拟机（JVM、CLR） 、解释器	JVM、.NET CLR、Python解释器、V8	跨平台，安全隔离，支持动态优化	需额外运行时开销，不能完全虚拟底层

硬件虚拟化 即虚拟机Hypervisor

操作系统虚拟化 即容器化。只提供操作系统内核以上的部分ABI兼容和环境兼容，如果没有其他虚拟化手段的辅助，在Win上不可能运行Linux镜像。

2）发展历史

1979               2002                2007              2013               2015               2020
 |                  |                   |                 |                  |                  |
 |------------------|-------------------|-----------------|------------------|------------------|------------->
chroot           Namespace            cgroups            LXC                Docker             Kubernetes
(文件系统隔离)    (多资源隔离)        (资源限制与管理)  (轻量级容器管理)       (容器化革命)           (容器编排)
                                                                                                                       

1979 隔离文件 chroot

设计初衷：提供一个简易的文件系统隔离机制，让进程可以被限制在某个目录树内，防止访问系统其他部分。

2002 隔离访问 namespace

每个 Namespace 提供独立的系统资源视图，进程间互不干扰。早期只隔离进程ID（PID Namespace），随后逐步加入更多类型的命名空间，如网络（NET Namespace）、挂载点（MNT Namespace）、IPC、UTS、User 、Time等。

名称	缩写	作用
Mount	mnt	隔离挂载点（文件系统）
PID	pid	隔离进程 ID 空间
Network	net	隔离网络资源，如网卡、IP地址、端口等
IPC	ipc	隔离进程间通信
UTS	uts	隔离主机名和域名
User	user	隔离用户/组 ID
Cgroup	cgroup	隔离对 cgroups 本身的访问权限
Time	time	隔离系统时间视图

2007 隔离资源 cgroups

对进程组的资源使用进行限制、管理和监控，包括 CPU、内存、磁盘I/O 和网络等。解决传统资源分配难以动态管理的问题，防止资源争抢和“噪声邻居”现象。

2013 封装系统 LXC

利用 namespace + cgroups特性的上层封装，实现轻量级系统级容器，降低用户使用内核隔离的门槛，系统级资源虚拟化。

2015 封装应用 Docker

进一步封装容器应用，实现跨机器的软件绿色部署，引入镜像管理、分层文件系统、仓库等机制，简化容器创建与分发。

2020 封装集群 Kubernetes

容器编排平台，实现自动化部署、扩展、管理和服务发现，支持大规模容器集群管理。

二、以容器构建系统

1）Pod

✅ 核心定义

Pod 是 Kubernetes 中的逻辑概念，与 Node（节点）、Cluster（集群）、Federation（联邦）等实体资源不同。Pod是容器编排中的最小调度单元，主要用于封装并管理一组紧密协作的容器。

✅ 职责一：容器组（共享环境）

一个 Pod 可包含一个或多个容器，这些容器通常紧密耦合、协同工作。容器之间通过一个 Infra Container（基础容器） 协调：

• 共享命名空间：UTS（主机名）、IPC（进程间通信）、NET（网络栈，IP、端口等）

• 隔离命名空间：PID（进程 ID 空间）、cgroups（资源使用限制与隔离）

这种组合结构，使得容器组在行为上更像一个逻辑“服务实例”，而非多个孤立单体。

✅ 职责二：原子性调度单位

跨集群节点调度，从以单个容器为调度单位，转为以 Pod 为基本调度原子单元。保证协同的容器能分配在同一机器/节点上，得以共享名称空间。

2）控制回路

核心思想：期望状态（Desired State） + 实际状态（Current State）

控制器不断监控“实际状态”，如果发现差异，自动修正实际状态向期望状态靠近

✅ 系统实现“自愈”、“可控变更”等核心特性，是 Kubernetes 实现声明式架构的关键机制。

✅ 常见控制器：

① ReplicaSet 控制器（副本集控制器）

• 作用：确保某个 Pod 组始终运行指定副本数量

• 控制点：

  • Pod 异常退出 ➜ 自动重建

  • 节点宕机 ➜ 调度到其他节点

• 优势：服务不中断、容器故障自动恢复

例子：你声明副本数为 3，哪怕有 1 个 Pod 挂掉，ReplicaSet 会立刻重建它。

---

② Deployment 控制器（部署控制器）

• 作用：管理 Pod 的滚动升级、版本变更

• 控制点：

  • 支持镜像版本更新（滚动更新、蓝绿发布、回滚）

  • 管理多个 ReplicaSet 的版本演进

• 优势：更新不中断服务，支持变更审计和版本管理

例子：你更新镜像版本到 v2，Deployment 会逐个替换 Pod，确保系统平稳过渡。

---

③ Horizontal Pod Autoscaler（HPA，自动扩缩控制器）

• 作用：根据负载动态调整副本数量，实现弹性伸缩

• 控制点：

  • 基于指标（如 CPU 利用率、QPS）调整副本数

  • 实时响应业务负载变化

• 优势：系统资源效率最大化，高峰期间扩容，闲时缩容

例子：CPU 使用率超过 80% ➜ 自动将副本数从 3 增加到 6。

✅ 其他控制器

控制器名称	作用简述
StatefulSet	有状态应用控制器，适用于数据库、队列等
DaemonSet	确保每个节点上都运行一个副本
Job / CronJob	控制一次性任务或定时任务
Vertical Pod Autoscaler	动态调整单个 Pod 的资源请求限制

三、以应用为中心进行封装

1）演进路径

手写 YAML（最原始）
│
├─▶ Kustomize（Base、Overlay 和 Patch）
│     └── 面向配置管理，根据环境生成不同配置部署。
│     └── 特点：声明式、结构清晰、无需模板语法，减少配置重复。
│     └── 缺陷：无法处理复杂逻辑与参数组合，缺乏打包/版本能力。
│
├─▶ Helm（模板化 + 包管理）
│     ├── Chart：Helm 的核心单元。支持应用全生命周期管理、依赖、版本控制。
│     └── 特点：强大模板引擎 + 参数化配置，生态丰富。
│     └── 缺陷：模板语法较复杂；有状态服务依赖管理能力有限。
│
├─▶ Helmfile / ArgoCD（GitOps 实践工具）
│     └── 用于统一管理多环境部署，支持 Helm/Kustomize。
│     └── 特点：声明式环境集成 + GitOps 自动同步。
│
└─▶ Operator（程序化自动运维）
      ├── 基于 CRD（自定义资源）扩展 Kubernetes 功能。
      └── 封装复杂业务逻辑，实现状态控制、自动伸缩、自愈、备份等。
      └── 特点：自动化程度高，适合中间件、数据库等状态复杂系统。

 衍生发展：
    ├─▶ Serverless（函数即服务，按事件触发运行代码，完全脱离底层部署）
    └─▶ Platform Engineering（平台工程：将基础设施封装为自助式、模块化的开发平台）

2）OAM

OAM(Open Application Model) 开放应用模型是一种抽象、通用的模型，对云原生运维的抽象标准化尝试。

角色	关注点	问题	OAM 对应概念
开发人员	业务逻辑实现	谁负责开发应用组件？	Component（组件）
运维人员	程序平稳运行	谁定义应用的运行方式与运维特性？	Trait（运维特征）
平台人员	基础设施能力	谁封装底层平台细节、提供能力边界？	Runtime/Scope（平台运行时）