dockerfile详解_容器原理架构详解（一）

目录

1、 容器原理架构

1.1 容器与虚拟化

1.2 容器应用架构

1.3 容器引擎架构

1.4 Namespace与Cgroups

1.5 容器镜像原理

2 K8S原理架构

2.1 K8S主要功能

2.2 K8S 系统架构

2.3 Pod原理与调度

--

容器原理架构详解（二），待续

3. K8S存储方案

4. K8S网络方案

5. 应用编排与管理

6. 服务与负载均衡

7. 应用监控运维

8. 容器安全方案

-----------------

1. 容器原理架构

1.1 容器与虚拟化

如图1，虚拟化技术通过Hypervisor实现VM与底层硬件的解耦。而容器（container）技术是一种更加轻量级的操作系统虚拟化技术，将应用程序及其运行依赖环境打包封装到标准化、强移植的镜像中，通过容器引擎提供进程隔离、资源可限制的运行环境，实现应用与OS平台及底层硬件的解耦，一次打包，随处运行。容器基于镜像运行，可部署在物理机或虚拟机上，通过容器引擎与容器编排调度平台实现容器化应用的生命周期管理。

图1：虚拟化与容器架构

VM中包含GuestOS，调度与资源占用都比较重。而容器仅包含应用运行所需的文件，管理容器就是管理应用本身。如表1，容器具有极其轻量、秒级部署、易于移植、敏捷弹性伸缩等优势；但VM是OS系统级隔离，而容器是进程级隔离，容器的安全性相对更弱一些，需要一些额外的安全技术或安全容器方案来弥补。作为云原生的核心技术，容器、微服务与DevOps/ CICD）等技术已成为应用架构转型或实现技术中台不可或缺组件。

表1：容器与虚拟化对比

1.2 容器应用架构

容器概念始于1979年提出的UNIX chroot，而2008年推出功能比较完善的Linux容器LXC，但标准化与可移植性面临较大挑战。2013 推出的Docker突破性的解决了容器标准化与可移植性问题，成为当前最流行的开源容器容器引擎。2016年OCI组织推出了开放容器标准，包括容器运行时标准（runtime spec）和容器镜像标准（image spec），推动了容器技术的广泛应用。如图2，docker应用是一种C/S架构，包括3个部分

1） Docker Client：Docker的应用/管理员，通过相应的docker 命令通过HTTP或REST API等方式与docker daemon实现docker服务使用与管理。

2） Docker Host：运行各种组件docker组件提供容器服务。其中Docker Daemon负责监听client的请求并管理docker对象（容器、镜像、网络、磁盘等）；Docker Image提供容器运行所需的所有文件；Linux 内核中的namespace负责容器的资源隔离，而Cgroup负责容器资源使用限制。

3） Docker Registry：容器镜像仓库，负责docker镜像存储管理。 可以用镜像仓库如DockerHub或者自建私有镜像仓库。可以通过docker push/pull 往镜像仓库上传/下载镜像。

所以，Docker运行过程就是Client发送Docker run命令到Dockerd，Dockerd从本地或镜像仓库获取Docker镜像，然后通过镜像启动运行容器实例。

图2：Docker容器应用架构

1.3 容器引擎架构

容器引擎负责容器的生命周期管理与资源管理，2017年4月docker公司将docker项目改名为Moby。Moby容器引擎的内部架构如图3：

1） Moby daemon：通过HTTP/S或Restful API对外提供容器、镜像、网络与存储的管。

2） Containerd：容器运行时管理引擎，向上提供gRPC调用，镜像与容器的基本管理。通过containerd shim插件模块实现对不同容器运行时模块的动态接管，保障Moby daemon或containerd动态升级时对业务不产生影响。

3） 容器运行时RunC：基于OCI标准实现，负责容器的配置文件、运行环境与生命周期管理。另外应对Docker容器安全性不足，新推出Kata、gVisor等安全容器技术。

图3： Moby容器引擎架构

1.4 Namespace与Cgroups

Linux namespace

Linux namespace负责容器的工作空间与资源隔离。容器中namespace通过unshare系统调用来创建，Linux内核提供了7中namespace：

1) PID namespace：保障进程隔离，每个容器都以PID=1的init进程来启动。

2) MNT namespace: 保障每个容器都有独立的目录挂载路径。

3) UTS namespace：保障每个容器都有独立的主机名或域名。

4) NET namespace：保障每个容器都有独立的网络栈、socket和网卡设备。

5) IPC namespace：只有在相同IPC命名空间的容器才可以利用共享内存、信号量和消息队列通信。

6) User namespace：用于隔离容器中UID、GID以及根目录等。可配置映射宿主机和容器中的UID、GID。

7) Cgroup namespace：保障容器容器中看到的 cgroup 视图像宿主机一样以根形式来呈现，同时让容器内使用 cgroup 会变得更安全。

Linux Cgroups

Cgroups对容器进程进行层次化分组，并按组实现资源限制和策略控制。

1) Cgroupfs驱动：需要限制CPU或内存使用时，直接把容器进程的PID写入相应的CPU或内存的cgroup。

2) systemd cgroup驱动：提供cgroup管理，所有的cgroup写操作需要通过systemd的接口来完成，不能手动修改。

Linux内核提供了很多Cgroup控制器，容器中常用的是

1）cpu/cpuset/cpuacct group：设置CPU share、cpuacct控制CPU使用率

2）memory group：控制内存使用量；

3）device group：控制在容器中看到的device设备，保障安全。

4）freezer group：容器停止时Freezer当前容器进程都写入cgroup，进程冻结。

5）blkio group：限制容器到磁盘的IOS、BPS；

6）pid group：限制容器里面可用到的最大进程数量。

1.5 容器镜像原理

容器镜像就是容器运行时所需要的二进制文件与依赖包的集合，存储在只读的Dockerfile中。镜像基于分层的联合文件系统UnionFS来实现，Ubuntu里基于AUFS实现，新推出OverlayFS比AUFS性能更好，部署更简单，两者核心原理是类似的。图5为容器镜像基于OverlayFS（推荐更高效稳定的Overlay2）的分层架构，其文件处理如表2。

1) lowerdir：镜像层，保存只读的容器镜像文件，多个容器共享；

2) upperdir：容器层，可读可写，采用写时复制COW，每个容器独有。

3) merged：统一视图层，整合各层内容，挂载的容器rootfs下，统一呈现。