关于docker:Docker基础知识

Docker 基础知识

容器

基本概念

• 容器是一种 计算机虚拟化技术，是云原生体系中的重要组成部分，其代表性的利用包含：Docker、Podman 等
• 容器是轻量的、可执行的独立软件包，其蕴含软件运行所需的所有内容：代码、运行时环境、零碎工具、零碎库和设置
• 容器赋予了软件独立性（具备很好的可移植性），使其免受外在环境差别（例如，开发和测试环境的差别）的影响，艰深的说就是使得软件能够带环境装置

虚拟机

• 虚拟机能够实现与容器相似的性能，能够在一种操作系统中运行另外的操作系统，虚拟机不受宿主机环境的影响，虚拟机对于宿主机来说也仅仅是一般的文件，对宿主机的其余部分无影响，然而虚拟机技术有以下的毛病：

  • 资源占用多
  • 体积臃肿
  • 启动慢
• 以 Docker 为代表的 Linux 容器技术（Linux Containers，缩写为 LXC）解决了上述问题

容器虚拟机比照

• 容器虚拟化的是操作系统而不是硬件，容器之间是共享同一套操作系统资源的，一个运行中的容器实质上是一个非凡的过程

  • 容器是一个 应用层形象 ，用于将代码和依赖资源打包在一起。多个容器能够在同一台机器上运行，共享操作系统内核，但各自作为 独立的过程在用户空间中运行 。与虚拟机相比， 容器占用的空间较少（容器镜像大小通常只有几十兆），霎时就能实现启动

• 虚拟机技术则是虚构出一套硬件后，在其上运行一个残缺操作系统。相对来说容器的隔离级别会稍低一些

  • 虚拟机 (VM) 是一个 物理硬件层形象 ，用于将一台服务器变成多台服务器。管理程序容许多个 VM 在一台机器上运行。每个 VM 都蕴含一整套操作系统、一个或多个利用、必要的二进制文件和库资源，因而 占用大量空间，耗费大量资源，启动也非常迟缓

• 容器与虚拟机是能够共存的，不是取代的关系

  • 两者有不同的应用场景。虚拟机更擅长于彻底隔离整个运行环境（隔离更彻底）。例如，云服务提供商通常采纳虚拟机技术隔离不同的用户。而 Docker 通常用于隔离不同的利用，例如前端，后端以及数据库

    <img src=”https://images.demoli.xyz/image-20210808191333415.png” alt=”image-20210808191333415″ style=”zoom:67%;” />

容器劣势

• 绝对虚拟机来说，容器更加轻量级，耗费资源少，能够疾速启动

• 可移植性强，在软件开发、测试，运维的各个期间都能统一的运行

  • 因而反对麻利的 DevOps 开发，缩短生产周期

    所谓的 DevOps 就是 是两个传统角色 Dev(Development)和 Ops(Operations)的联合，Dev 负责开发，Ops 负责部署上线，说白了就是要有一个理解 Dev 的人能把 Ops 的事干了

• 绝对强的隔离性，一个容器呈现故障并不会影响其余容器的运行连续性

容器劣势

• 安全性问题，因为容器的隔离性只是过程级别的隔离，相比拟传统虚拟机，容器潜在的平安危险更高。它们须要多种级别的安全措施

  • 最常说的一个毛病就是在容器外部执行 top 命令能够看到宿主机的运行状态

跟 Namespace 状况相似，Cgoups 对资源的限度能力也有很多不欠缺的中央，其中被提及最多的是 /proc 文件系统的问题。/proc 目录存储着以后内核运行状态的一系列非凡文件，用户能够通过拜访这些文件，查看零碎以及以后正在运行的过程的信息，比方 CPU 应用状况、内存占用率等，这些文件也是 top 指令查看零碎信息的次要数据起源。

然而，如果你在容器里执行 top 指令，就会发现，它显示的信息竟然还是宿主机的 CPU 和内存数据。这是因为 /proc 文件系统并不知道用户通过 Cgroups 给这个容器做了什么样的资源限度，所以它返回的还是整个宿主机的。那么这个问题会导致，容器内的应用程序读取到的 CPU 核数、可用内存等信息还是宿主机的，而不是做了限度之后的。这就是容器相比拟于虚拟机另一个不尽如人意的中央

当然，为了解决下面的那个问题。直观的做法就是容器不挂载宿主机的该目录就能够了，能够通过 lxcfs 来实现隔离，lxcfs 在宿主机上保护过程组的信息，而后容器启动的时候将 lxcfs 保护的过程组信息所在的目录挂载到容器的 /proc 目录，在容器中获取 /proc 信息时，实际上获取的是宿主机上对该容器的过程组信息

• 容器对有状态利用，例如数据存储利用是不敌对的，个别须要将数据与利用拆散，容器一旦关机，其中的数据可能会永恒隐没
• 容器资源监控，云环境异常简单，因而须要深度监控平安问题

Docker

根底定义

• Docker 是代表性的容器技术，其应用 Google 公司推出的 Go 语言 进行开发实现，基于 Linux 内核提供的 CGroups 性能 和Namespace，以及 UnionFS 等技术实现
• Docker 技术最后齐全基于传统的 LXC 构建，然而后续又增加了 容器构建，分层镜像以及镜像仓库等性能，这使得容器技术真正风行了起来

Docker 劣势

• Docker 容器基于 分层镜像 运行，分层镜像能够实现文件共享，能够尽量升高磁盘用量，更快地实现镜像传输以及容器构建
• Docker 容器基于 开放式规范，可能在所有支流 Linux 版本、Microsoft Windows 以及包含 VM、裸机服务器和云在内的任何基础设施上运行
• Docker 赋予利用的隔离性不仅限于彼此隔离，还独立于底层的基础设施。Docker 默认提供最强的隔离，因而利用呈现问题，也只是单个容器的问题，而不会波及到整台机器
• Docker 提供了丰盛的 API，不仅能够在 Shell 环境下执行操作，也能够应用多种语言进行管制，比方 docker-java、go-dockerclient 等

Docker 劣势

• 过程治理与传统的 Linux 容器不同，例如 终止子过程之后，须要清理孙过程，而对于这类事件，传统 Linux 容器会自行处理。Docker 的使用者能够在开始时更改配置文件和设置性能，从而打消这些顾虑
• 容器化下，容器与宿主机共享内核，带来安全隐患
• 在 Docker 中 有些其它 Linux 子系统和设施未指定命名空间。比方 SELinux、Cgroups 以及 /dev/sd* 设施。这意味着，如果攻击者管制了这些子系统，主机也将不保

• Docker 守护过程也可能成为安全隐患。为应用和运行 Docker 容器，须要应用 Docker 守护过程，来为容器提供继续运行时环境。而Docker 守护过程须要 root 权限，Docker 守护过程有被劫持攻打的危险

  Docker 守护程序绑定到 Unix 套接字而不是 TCP 端口。默认状况下，Unix 套接字由 root 领有，而非用户只能通过 sudo 应用它。如果要以非 root 用户应用 Docker，可参考非 Root 用户应用 Docker

  • Podman 就不须要应用 root 权限的守护过程，因而绝对 Docker 更平安一些

Docker 应用场景

• 面向产品：产品交付
• 面向开发：简化环境配置
• 面向测试：多版本测试
• 面向运维：环境一致性、DevOps
• 面向架构：自动化扩容（微服务）

Docker 与 Podman

• 自从 Kubernetes 发表不再反对 Docker 作为容器运行时 后，Docker 将要被 Podman 或者 Containerd 取代的声音就甚嚣尘上

• Podman 能够治理和运行任何合乎 OCI（Open Container Initiative）标准的容器和容器镜像。Podman 提供了一个与 Docker 兼容的命令行前端来治理 Docker 镜像

  Podman 的命令行工具与 Docker 相似，比方构建镜像、启停容器等。甚至能够通过 alias docker=podman 能够进行替换。因而，即使应用了 Podman，依然能够应用 Docker.io 作为镜像仓库，这也是兼容性最要害的局部

• 二者的区别如下：

  • Docker 须要一个以 root 执行的守护过程维持运行，带来了安全隐患，Podman 不须要守护程序，也不须要 root 用户运行，绝对平安

  • 在 Docker 的容器管理体系中，须要多个 daemon 能力调用到 runC（下文有形容），而Podman 间接调用 runC，通过 common 这个守护过程作为容器过程的管理工具（不须要 root 权限）

    在 Podman 体系中，有个称之为 common 的守护过程，其运行门路通常是 /usr/libexec/podman/conmon，它是各个容器过程的父过程，每个容器各有一个，common 的父过程则通常是 1 号过程。Podman 中的 common 其实相当于 Docker 体系中的 containerd-shim

Docker 基本概念

镜像

• Docker 镜像是一个非凡的 文件系统，除了提供容器运行时所需的程序、库、资源、配置等文件外，还蕴含了一些为运行时筹备的一些配置参数（如匿名卷、环境变量、用户等）

• 镜像的设计充分利用 联结文件系统 的技术，镜像的构建过程就是一层一层叠加文件系统的过程，最顶层的则是镜像运行时，容器外部能够看到的文件内容是镜像的 分层文件系统层层叠加的成果

  • 联结文件系统的具体实现包含 UnionFS、aufs、OverlayFS 等等

• 镜像构建时，会一层层构建，前一层是后一层的根底。每一层构建完就不会再产生扭转，后一层上的任何扭转只产生在本人这一层。

  • 比方，删除前一层文件的操作，理论不是真的删除前一层的文件，而是仅在 以后层标记为该文件已删除 。在最终容器运行的时候，尽管不会看到这个文件，然而实际上该文件会始终追随镜像。因而，在构建镜像的时候，须要额定小心， 每一层尽量只蕴含该层须要增加的货色，任何额定的货色应该在该层构建完结前清理掉。
  • 用户构建镜像（Dockerfile）的每一步操作都会构建一个新的层，因而反对 在应用 Dockerfile 进行容器镜像构建时执行构建回滚，因而也能很好地反对应用 Docker 执行 CI/CD 时执行疾速版本回退

• 为什么应用联结文件系统

  • 应用联结文件系统的目标之一是使得镜像的构建能够复用之前的文件，增快构建的速度，同时能够反对镜像的自定义革新，即在原有镜像的根底之上加更多的层，实现镜像的自在定制构建
  • 多个容器能够共享同一个镜像的文件，缩小了容器的启动工夫与空间耗费
  • 能够 对最顶层的可读写层（即容器运行时）的状态进行保留（docker commit 产生容器的快照镜像），以实现复用
• 对于镜像的构建，参考[Docker 镜像构建]()

容器

• 镜像和容器在逻辑上的关系，就像是面向对象程序设计中的类和实例一样，镜像是动态的定义，容器是镜像运行时的实体
• 容器的本质是宿主机上的过程，但与间接在宿主执行的过程不同，容器过程运行于属于本人的独立的命名空间
• 容器在镜像的根底之上的运行实质上能够了解为 在镜像的分层只读文件系统上增加了一个可写层 ，能够称之为 容器的存储层 ，容器存储层的生存周期和容器一样，容器沦亡时，容器存储层也随之沦亡。因而， 任何保留于容器存储层的信息都会随容器删除而失落

• 在容器内对镜像文件的读写，是基于 copy-on-write 技术的

  • 所谓的记录删除操作实际上就是对应的文件在容器层就不可见了
  • 越顶层的层优先级越高，这也就是为什么在以后层的批改，会笼罩下边的层的批改的以及所有的增删改查都要放到以后最上层进行操作的起因

• 依照 Docker 最佳实际的要求，容器不应该向其存储层内写入任何数据 ，容器存储层要放弃无状态化。 所有的文件写入操作，都应该应用数据卷（Volume）、或者绑定宿主目录 ，在这些地位的读写会跳过容器存储层，间接对宿主(或 网络存储 — 比方 ceph 的 rbd 插件 ) 产生读写，其性能和稳定性更高。数据卷的生存周期独立于容器，容器沦亡，数据卷不会沦亡。因而，应用数据卷后，容器能够随便删除，数据却不会失落

  • 尽管容器的可读写层的生命周期比拟短，然而能够在应用容器时 应用 docker commit 和 push 指令，保留这个被批改过的可读写层，并上传到 Docker Hub 上，供其他人应用
  • 参考[容器的长久化计划]()

• 除了顶层的可读可写层以及底层的只读镜像层之外，还有一个非凡的层 –init 层 ， 须要被读写，然而又不想被 commit 提交做增量批改的一个层就是 init 层（自身应该是只读的镜像层的一部分），专门用来寄存 /etc/hosts 等信息（启动容器时写入 hostname）

• 容器的生命周期

  • created：初建状态 docker create

  • running：运行状态 docker start或者是docker run

    • 容器启动时的后盾逻辑是怎么的？

      1. docker 客户端执行命令，命令通过 Unix 套接字或者 tcp 链接的形式申请到 docker daemon（也就是 dockerd 过程）
      2. dockerd 过程通过 gRpc 向 containerd 这个规范层发出请求，申请创立一个容器
      3. containerd 首先判断本地仓库是否有对应的镜像，如果有间接用该镜像创立容器，没有的话，须要先拉取镜像

      4. 创立一个 dockerd-shim 过程，并以此过程为父过程创立 runc 过程运行一个容器过程

         1. 容器过程应用 namespace 进行资源命名空间的限度；应用 cgroup 实现资源的调配与审计
         2. 容器过程须要挂载对应的联结文件系统（privot_root），也就是镜像层下面加一层可写层
         3. 如果应用的默认的桥接网络的话，会从网桥的子网 IP 中抉择未应用的 IP 进行调配

  • stopped：进行状态 docker stop

    • 通过 docker stop 进行容器，其原理是给运行中的容器发 sigterm 信号 ，如果容器为 1 号过程承受并解决 sigterm，则期待 1 号过程处理完毕后就退出，如果期待一段时间后还是没有解决，则会通过发送sigkill 命令强制终止容器
  • paused：暂停状态 docker pause
  • deleted：删除状态 docker rm

仓库

• 一个集中的存储、散发镜像的服务，Docker Registry、Docker Hub 就是这样的服务
• 应用镜像的标签（tag）进行镜像的版本治理
• 能够应用官网的镜像仓库 Docker Hub，或者国内的一些同步的镜像仓库，也能够本人搭建 Docker Registry 服务，能够联合 Docker Auth 与 keycloak 等来执行访问控制与用户管制，参考公有仓库部署

Docker 的底层逻辑

虚拟化技术

• 虚拟化技术是一种资源管理技术，是将计算机的各种实体资源)（CPU、内存、磁盘空间、网络适配器等），予以形象、转换后出现进去并可供宰割、组合为一个或多个电脑配置环境。由此，突破实体构造间的不可切割的阻碍，使用户能够比本来的配置更好的形式来利用这些电脑硬件资源。这些资源的新虚构局部是不受现有资源的架设形式，地区或物理配置所限度。个别所指的虚拟化资源包含计算能力和数据存储

  • 虚拟化的技术是通过硬件的形象实现更好的调配组合硬件资源，实现资源的最大化利用

LXC 虚拟化技术

• LXC，其名称来自Linux 软件容器（Linux Containers）的缩写，一种操作系统层虚拟化（Operating system–level virtualization）技术，实际上是 Linux 内核容器性能的一个用户空间接口。它将应用软件零碎打包成一个软件容器（Container），内含应用软件自身的代码，以及所须要的操作系统外围和库。通过对立的名字空间和共用 API 来调配不同软件容器的可用硬件资源，发明出应用程序的独立沙箱运行环境，使得 Linux 用户能够容易的创立和管理系统或利用容器

• 与传统虚拟化技术相比，LXC 的劣势在于：

  • 与宿主机应用同一个内核，性能损耗小
  • 不须要指令级模仿
  • 不须要即时 (Just-in-time) 编译
  • 容器能够在 CPU 外围的本地运行指令，不须要任何专门的解释机制
  • 防止了准虚拟化和零碎调用替换中的复杂性
  • 轻量级隔离，在隔离的同时还提供共享机制，以实现容器与宿主机的资源共享

• Docker 并不是齐全依赖 LXC 虚拟化技术，比方镜像的构建与以及容器的构建过程并不是依赖 LXC 的（Docker 在 LXC 的根底上提供了更加丰盛的性能）

  • 传统的 Linux 容器应用 init 零碎来治理多种过程。这意味着，所有应用程序都作为一个整体运行。与此相反，Docker 技术激励应用程序各自独立运行其过程，并提供相应工具以实现这一性能

namespace

• namespace 是 Linux 内核用来隔离内核资源的形式

  • 通过 namespace 能够让一些过程只能看到与本人相干的一部分资源，而另外一些过程也只能看到与它们本人相干的资源（实现资源的限度与隔离），这两拨过程基本就感觉不到对方的存在。具体的实现形式是把一个或多个过程的相干资源指定在同一个 namespace 中
  • Linux namespaces 是对全局系统资源的一种封装隔离，使得处于不同 namespace 的过程领有独立的全局系统资源，扭转一个 namespace 中的系统资源只会影响以后 namespace 里的过程，对其余 namespace 中的过程没有影响

• namespace 分为以下几种：

  • PID ns

    • 过程编号的隔离，所以容器中的利用的 pid 为 1

  • Net ns

    • 每个 net 名字空间有独立的网络设备，IP 地址，路由表，/proc/net 目录

  • User ns

    • 每个名字空间能够有不同的用户和组 id, 也就是说能够在名字空间内用外部的用户执行程序而非主机上的用户

  • UTS ns

    • UTS(“UNIX Time-sharing System”) 名字空间容许每个名字空间领有独立的 hostname 和 domain name, 使其在网络上能够被视作一个独立的节点而非主机上的一个过程

  • Mount ns

    • 相似 chroot，将一个过程放到一个特定的目录执行。mnt 名字空间容许不同名字空间的过程看到的文件构造不同，这样每个名字空间中的过程所看到的文件目录就被隔离开了。同 chroot 不同，每个名字空间中的容器在 /proc/mounts 的信息只蕴含所在名字空间的 mount point

  • IPC ns

    • 不同名字空间的交互采纳 Linux 常见的过程间交互办法(interprocess communication – IPC)，包含信号量、音讯队列和共享内存等

cgroup

• cgroup 是 Control Groups 的缩写，是 Linux 内核提供的一种能够限度、调配、记录（统计）、隔离过程组 (process groups)所应用的物理资源 (如 cpu、memory、i/ o 等等) 的机制

• 有了 namespace 之后，为什么还须要 cgroup 呢：

  • namespace 是为了隔离过程组之间的资源，而 cgroup 是为了对一组过程进行对立的资源监控和限度
  • 应用了 namespace 之后，容器对应的过程只能看到以后过程对应的命名空间中的资源，然而 从宿主机的角度来看，这只是一个一般的过程，能够和其余过程一起竞争资源，能够应用全副的宿主机资源，这显然不合乎容器的概念，因而引入 cgroup 对容器的资源进行限度与审计
  • 在 Linux 中，cgroup 给用户裸露进去的操作接口是文件系统（其实就是通过写配置文件来配置 cgroup），即操作接口是以文件和目录的形式组织在操作系统的 /sys/fs/cgroup 门路下
• cgroup 的缺点在于前文说的 top 命令的问题（隔离不彻底）以及只能限度资源耗费的最大值，而不能断绝其余程序占用本人的资源

chroot

• chroot 用来为容器环境挂载特定的根文件系统，chroot（change root filesystem）的作用是指定特定过程的根门路为指定地位，Docker 应用此命令指定容器的根目录的地位，同时还会在该目录挂载一个残缺的操作系统的文件系统（即应用联结文件系统，共享的镜像层文件）

  • chroot 只扭转以后过程的 /，pivot_root 扭转以后 mount namespace 的 /。pivot_root 能够认为是 chroot 的改良版

Docker 架构

• Docker 实际上是一个 client/server 的架构，如下图所示

<img src=”https://images.demoli.xyz/image-20210810233212064.png” alt=”image-20210810233212064″ style=”zoom:80%;” />

客户端

• 平时应用的 docker 指令就是客户端的一部分，Docker 组件向服务端发送申请后，服务端依据申请执行具体的动作将后果返回给 Docker，Docker 解析服务端的返回后果，并将后果通过命令行规范输入展现给用户。这样一次残缺的客户端服务端申请就实现了

• 客户端与服务端的通信形式

  • 客户端和服务端能够通过 Unix 套接字通信

    • 默认的 dockerd（Docker 服务端）生成的 socket 文件寄存在 /var/run/docker.sock，此文件只能由 root 用户或具备 sudo 权限的用户拜访
  • 采纳 TCP 的形式与服务端通信，配置格局为：tcp://host:por，为了保障平安，通常还须要应用 TLS 认证
  • 通过 fd 文件描述符的形式，配置格局为：fd://，这种格局个别用于 systemd 治理的零碎中
  • 还能够应用各种语言的 sdk 与 docker 的服务端交互，比方 docker-java、go-dockerclient 等

服务端

• 服务端实际上是一个叫做 dockerd 的后盾过程（也就是上图中的docker daemon）

  • 相对来说 dockerd 更多的就是一个 server，用来接管申请和解析申请，真正的容器镜像治理由containerd 保护

runc

• 实际上是 Docker 的 libcontainer 这个容器运行时库的改良，是一个用来运行容器的轻量级工具，实现了 OCI 规范，是利用 LXC 技术创立容器过程的底层工具

containerd

• contained 通过 contained-shim 启动并治理 runc，能够说contained 是真正治理容器的生命周期的组件，因而该组件也被拆分进去作为独自的我的项目保护，K8s 不再反对 Docker 后，能够无缝迁徙到应用 containerd 作为容器运行时，containerd 能够实现以下工作：

  • 镜像治理
  • 治理存储相干资源
  • 治理网络资源

  • 承受 dockerd 的申请

    • dockerd 通过 gRPC 与 containerd 通信，因为 dockerd 与底层的容器运行时 runC 两头有了 containerd 这一 OCI 规范层，使得 dockerd 能够确保接口向下兼容

containerd-shim

• containerd-shim 的次要作用是将 containerd 和真正的容器过程解耦，应用 containerd-shim 作为容器过程的父过程，从而实现重启 Docker 时不影响曾经启动的容器过程

  • **-shim的意思是垫片，相似于拧螺丝时夹在螺丝和螺母之间的垫片，相当于是一个中间件的性能，相似的组件还有晚期版本 K8s 中的docker-shim
  • 当有需要去替换 runc 运行时工具库时，例如替换为平安容器 kata container 或 Google 研发的 gViser，则须要减少对应的 shim(kata-shim 等)，以上两者均有本人实现的 shim
• containerd 和 shim 并不是父子过程关系，runc启动完容器后自身会间接退出，containerd-shim 则会成为容器过程的父过程，负责收集容器过程的状态，上报给 containerd，并在容器中 pid 为 1 的过程退出后接管容器中的子过程进行清理，确保不会呈现僵尸过程

docker-init

• 在运行容器时能够指定 –init 参数，向容器中引入 docker-init 过程，作为 1 号过程来治理所有的过程（namespace 下的所有子过程），例如回收僵尸过程等等

  • container-shim 只在容器中的 pid 为 1 的过程退出后才会发挥作用

ctr

• ctr 实际上是 containerd-ctr，它是 containerd 的客户端，次要用来开发和调试，在没有 dockerd 的环境中，ctr 能够充当 docker 客户端的局部角色，间接向 containerd 守护过程发送操作容器的申请

docker-proxy

• 容器端口映射的一些 iptables 配置，由 docker-proxy 过程实现

容器和镜像标准接口 OCI

• OCI 是 Docker 公司与 CoreOS 和 Google 独特创立的，该接口提供了运行时标准（形容如何运行filesystem bundle）与镜像标准（指定了镜像的格局与相干的镜像操作）

  filesystem bundle(文件系统束): 定义了一种将容器编码为文件系统束的格局，即以某种形式组织的一组文件，并蕴含所有符合要求的运行时对其执行所有规范操作的必要数据和元数据，即 config.json 与 根文件系统

• Runc 是 OCI 的参考实现，是 Docker 的一部分，也是 K8s 的 Kernel API 规范

  • K8s 的三层形象：Orchestration API -> Container API -> Kernel API

    • 资源调度与编排的规范就是 k8s
    • 容器规范就是 CRI
    • 容器底层规范就是 OCI

容器运行时接口 CRI

• CRI 是一组 K8s 定义的对于容器和镜像操作的 gRPC 接口

• Docker 自身（借助 dockershim）、containerd（cri-plugin）、cri- o 就是这个接口的实现

  • dockershim 显然也是一个垫片，用来实现 OCI 到 CRI 的兼容，晚期版本的 k8s 应用 dockershim 实现对 Docker 的反对
  • containerd 自身是从 Docker 中分离出来的，默认是实现 OCI 接口的，然而在用到 K8S 中后，通过退出 CRI-Plugin，使其反对 CRI 接口
• 此接口标准是 K8S 中的容器接口标准

容器技术的倒退瞻望

• 随着互联网的倒退到万物智联，5G、AIoT 等新技术的涌现，随处可见的计算需要曾经成为事实。针对不同计算场景，容器运行时会有不同需要。KataContainer、Firecracker、gVisor、Unikernel 等新的容器运行时技术层出不穷，别离解决 平安隔离性 、 执行效率 和通用性 三个不同维度的要求 。OCI(Open Container Initiative) 规范的呈现，使不同技术采纳统一的形式进行容器生命周期治理，进一步促成了容器引擎技术的继续翻新
• 基于 MicroVM 的平安容器占比将逐步减少，提供更强的平安隔离能力。虚拟化和容器技术的交融，已成为将来 重要趋势。在公共云上，阿里云容器服务曾经提供了对基于 KataContainer 的阿里云的袋鼠容器引擎反对，能够运行不可信的工作负载，实现平安的多租隔离
• 基于软硬一体设计的 秘密计算容器 开始展露头角。比方阿里云平安、系统软件、容器服务团队以及蚂蚁金服可信原生团队独特推出了面向秘密计算场景的开源容器运行时技术栈 inclavare-containers，反对基于 Intel SGX 秘密计算技术的秘密容器实现，如蚂蚁金服的 Occlum、开源社区的 Graphene 等 Libary OS。它极大升高了秘密计算的技术门槛，简化了可信利用的开发、交付和治理
• WebAssembly作为新一代可移植、轻量化、利用虚拟机，在 IoT，边缘计算，区块链等场景会有宽泛的利用前景。WASM/WASI 将会成为一个跨平台容器实现技术。近期 Solo.io 推出的 WebAssembly Hub 就将 WASM 利用通过 OCI 镜像规范进行对立治理和散发，从而更好地利用在 Istio 服务网格生态中

补充

• 分享一篇有意思的文章：如何辨别以后正在应用的 shell 环境是物理机、虚拟机还是容器

参考

• Docker 官网文档
• Redhat-Docker 是什么
• Podman 是什么
• 7 种 Docker 代替工具
• 深入研究 Docker 联结文件系统
• JavaGuide Docker
• Docker 核心技术 — Linux Namespace
• 容器底层 -Cgroups 的应用
• 容器资源的限度设定
• Docker 架构原理以及简略应用
• 文言 Kubernetes Runtime
• 深刻了解 container– 容器运行时
• 罕用虚拟化技术