Kaniko运用gcr.io/ Kaniko -project/executor作为镜像运转。这关于Kubernetes来说是行得通的，但是关于本地构建来说不是很方便，并且在某种水平上违犯了它的初衷，由于我们得先运用Docker来运转Kaniko镜像，然后再去构建镜像。也就是说，假设正在为Kubernetes集群中构建镜像的工具停止选型(例如在CI/CD Pipeline中)，那么Kaniko能够是一个不错的选择，由于它是无守护顺序的，而且(能够)更安全。
从我团体的阅历来看——我在Kubernetes/OpenShift集群中运用了Kaniko和Buildah来构建镜像，我以为两者都能很好地完成义务，但在运用Kaniko时，我看到了一些将镜像导入仓库时的，会有随机构建崩溃和失败的状况。
第三个竞争者是Buildkit，也可以称为下一代的Docker build。它是Moby项目的一部分。在Docker里可以运用DOCKER_BUILDKIT=1 Docker build…作为实验特性停止启用。那么，它的中心价值究竟有哪些?它引入了许多改良和炫酷的特性，包括并行构建、跳过未运用的阶段、更好的增量构建和无根构建。但是另一方面，它依然需求运转守护进程(buildkitd)才能运转。所以，假设你不想摆脱Docker，但是想要一些新的特性和更好的改良，那么运用Buildkit能够是最好的选择。
和前面一样，这里我们也还有一些“光鲜亮丽的产品”，它们也都有十分详细的场景，虽然并不是我们的首选：
Source-To-Image(S2I)是一个不需求Dockerfile直接从源代码构建镜像的工具包。这个工具在复杂的、预期的场景和任务流中运转的很好，但是假设有太多的定制，或许该项目没有预期的规划，你很快就会觉得这个工具很烦人和笨拙。假设你对Docker还不是很有决计，或许假设在OpenShift集群上构建镜像，那么你可以尝试思索一下运用S2I，由于运用S2I构建是一个内置特性。
Jib是谷歌的另一个工具，专门用于构建Java镜像。它包括Maven和Gradle插件，可以轻松地构建镜像，而不会搅扰Dockerfile。
最后一个但并不是不重要的是Bazel，它是谷歌的另一款工具。它不只用于构建容器镜像，而且是一个残缺的构建系统。假设你只是想构建一个镜像，那么研讨Bazel能够有点过头，但相对是一个很好的学习体验，所以假设你想尝试，rules_docker相对是一个很好的终点。
容器运转时
最后一个大块儿是容器运转时，它担任运转容器。容器运转时是整个容器生命周期/栈的一部分，除非你对速度、安全性等有一些十分详细的要求，否则普通是不需求对其停止搅扰。所以，假设读者看到这里曾经厌倦，那么可以跳过这一部分。假设不是，那么有关容器运转时的选择，如下：
runC是基于OCI容器运转时标准创立的，且最盛行的容器运转时。Docker(经过containerd)、Podman和crio运用它，所以简直一切东西都依赖于LXD。它简直是一切产品/工具的默许首选项，所以即使你在阅读本文后保持Docker，但你依然会用到runC。
runC的另一款替代方产品为Crun，称号相似(容易混杂)。这是Red Hat开发的工具，完全用C编写(runC是用Go编写的)。这使得它比runC更快，内存效率更高。思索到它也是OCI兼容的运转时。所以，假设你想做个测试，切换起来很容易。虽然它如今还不是很盛行，但在RHEL 8.3技术预览版中，它将作为一个替代OCI运转时，同时，思索到它是红帽的产品，我们能够最终会看到它会成为Podman或CRI-O的默许首选项。
说到CRI-O。前面我说过，CRI-O实践上不是一个容器引擎，而是容器运转时。这是由于CRI-O不包括比如推送镜像这样的特性，而这正是容器引擎的特性。作为运转时的CRI-O在外部运用runC运转容器。通常状况下不需求在单机尝试这个工具，由于它被构建为用于Kubernetes节点上的运转时，可以看到它被描画为“Kubernetes需求的一切运转时，仅此而已”。因此，除非你正在设置Kubernetes集群(或OpenShift集群——CRI-O曾经是默许首选项了)，否则不大能够会接触到这个。
本节的最后一个内容是containerd，它是CNCF的一个毕业的项目。它是一个守护进程，充任各种容器运转时和操作系统的API。在后台，它依赖于runC，是Docker引擎的默许运转时。谷歌Kubernetes引擎(GKE)和IBM Kubernetes效劳(IKS)也在运用。它是Kubernetes容器运转时接口的一个部署(与CRI-O相反)，因此它是Kubernetes集群运转时的一个很好的备选项。
镜像检测与分发
容器栈的最后一部分是镜像的检测与分发。这有效地替代了docker inspect，还(可选地)添加了远程镜像仓库之间复制/映射镜像的才能。
这里独一要提到的可以完成这些义务的工具是Skopeo。它由红帽公司开发，是Buildah，Podman和CRI-O的配套工具。除了我们都从Docker中知道的基本的skopeo inspect之外，Skopeo还可以运用skopeo copy复制镜像，它允许你在远程镜像仓库之间映射镜像，而无需先将它们拉到本地仓库。假设你运用本地仓库，此功用也可以作为pull/push。
另外，我还想提一下Dive，这是一个反省、探测和剖析镜像的工具。它对用户更友好一些，提供了更可读的输入，可以更深化地探测镜像，并剖析和权衡其效率。它也适宜在CI管道中运用，它可以测量你的镜像能否“足够高效”，或许换句话说——它能否糜费了太多空间。
结论
本文的目的并不是要压服大家完全丢弃Docker，而是向大家展现构建、运转、管理和分发容器及其镜像的整个场景和一切选项。包括Docker在内的每一种工具都有其优缺陷，评价哪一组工具最适宜你的任务流和场景才是最重要的，真心希望本文能在这方面协助到你。
【编辑引荐】
IT工程师都需求掌握的容器技术之Dockerfile
浅谈云计算：OpenStack、Docker、K8S的演进史
Docker 底层原理浅析
Docker：恢复对开源项目的有限制拜访
究竟什么是Docker？什么是K8S？
(责任编辑：admin)