容器技术背景#

本文讨论容器技术一般指LXC或docker容器采用的技术
windows容器技术有所不同，但思想仍有共同之处，仍具有参考意义

1. 容器解决的问题是什么？#

实现批量化部署
解决依赖冲突（依赖隔离）
相比于虚拟化技术，降低资源损耗

2. 容器技术如何解决上述问题？#

针对问题1，通过运行配置妥当的镜像（如：docker run || docker compose）或通过统一的部署脚本（如：docker file）实现标准且一致的环境搭建
针对问题2，如果在同一台设备上运行两个服务发现依赖冲突，简单且有效的解决方案显然是将两个服务分别运行在两台“设备”上。容易想到虚拟化出两个隔离的环境。容器技术的解决思路与之相似，采用Namespaces，Cgroups，UnionFS等技术隔离出多个环境从而解决此问题
针对问题3，虚拟化技术有以下缺陷：
- 镜像过大，包含完整OS，耗费大量存储空间
- 启停缓慢，需要完整启动整个操作系统
- 性能损耗大，需要维护完整操作系统的各项操作
容器化技术采用如下的方案或技术解决了这些问题：
1. 减小镜像大小：
  - 共享内核（Namespaces，Cgroups等）——所有容器共享宿主机内核，镜像只需要包含应用与用户空间工具（如：/bin /lib）
  - 分层存储（UnionFS）——不同镜像可以复用相同的基础层，采用CoW（Copy-on-Write）技术修改只读层文件同时减少冗余存储
  - 极简基础镜像——最简化基础镜像，只保留必要依赖
  - 动态构建优化——在构建镜像时分阶段编译并最终抛弃无用文件（如编译工具链）
2. 快速启停：
  - 因为只关心程序本身的运行，所以无需进行操作系统启停，只需要维护利用Namespaces，Cgroups等技术隔离出的程序专属空间即可，因此相比于虚拟机，启停速度大大加快
3. 减少性能损耗：
  - 虚拟机本质上运行了一个完整的操作系统，与直接运行程序（程序—>操作系统）相比，运行在虚拟机中的程序（程序—>虚拟机操作系统—>虚拟化层—>宿主机操作系统）在软件层面显然绕了远路，许多操作系统层面的操作重复执行了，而这些**冗余执行直接导致了资源的消耗。容器化技术通过共享内核（Namespaces，Cgroups等），从根本上避免了这一问题**，所以性能损耗大大减少。

3. LXC、containerd、Docker 和 Kubernetes（k8s）的关系#

1. LXC（Linux Containers）#

定位：早期的操作系统级虚拟化技术
功能：基于 Linux 内核的 Cgroups 和 Namespaces，实现资源隔离和进程沙箱化
作用：直接管理容器，但需手动配置，缺乏镜像管理等高层功能
现状：被更现代的容器运行时（如 runc、containerd）取代，是技术演进的基础

LXC仍用于特定场景（如LXD容器管理工具），但Docker/Kubernetes生态已转向OCI标准（如runc）

2. containerd#

定位：容器运行时核心组件，专注容器生命周期管理
功能：
- 管理镜像（拉取、推送、存储）
- 通过 runc（OCI 标准实现）创建容器
- 监控容器状态、日志等
与 Docker 的关系：Docker 引擎内部依赖 containerd 作为默认运行时（自 Docker 1.11 起）
与 Kubernetes 的关系：Kubernetes 通过 CRI（容器运行时接口） 直接调用 containerd，无需 Docker 引擎

3. Docker#

定位：开发者友好的容器化工具链
功能：
- 镜像构建（Dockerfile 和 docker build）
- 容器管理（CLI 命令如 docker run）
- 网络、存储插件等扩展功能
架构：
- Docker 引擎：用户交互层
- containerd：底层容器运行时（通过 containerd-shim 调用 runc）
与 Kubernetes 的关系：
- 早期 Kubernetes 依赖 Docker 引擎，现在与 containerd 直接交互
- Docker 仍广泛用于镜像构建和本地开发，镜像可被 Kubernetes 集群使用

4. Kubernetes（k8s）#

定位：容器编排系统，管理分布式容器化应用
功能：
- 自动化部署、扩缩容、服务发现
- 跨节点调度容器
- 通过 CRI 与容器运行时（如 containerd、CRI-O）交互
与底层组件的关系：
- 不直接操作容器，通过 CRI 调用 containerd 等运行时
- 自 1.20 版本起，Kubernetes 弃用对 Docker 的直接支持，并于1.24版本正式移除。推荐使用 containerd 或 CRI-O