GCP发布Kaniko：在非特权容器和Kubernetes中构建容器镜像的工具

Google发布了“Kaniko”，一种用于在未授权容器或Kubernetes集群中构建容器镜像的开源工具。虽然Kaniko也是根据用户给定的Dockerfile构建镜像，但是并不依赖于Docker守护进程，而是在用户空间中完全执行每个命令，并对所导致的文件系统更改做快照。

要从一个标准Dockerfile构建镜像，通常依赖于对Docker守护进程的交互访问，这需要具有运行Docker守护进程主机的root访问权限。在宣布Kaniko发布的GCP（Google Cloud Platform）官方博客帖子中指出，对于Kubernetes集群等环境，不方便甚至是不能安全地暴露Docker守护进程，这使得容器镜像难以构建。

Kaniko解决了上述挑战，它无需授权root访问权限，即可从Dockerfile构建容器镜像。Kaniko支持通过Docker和gcloud SDK，运行在标准Kubernetes集群（使用Kubernetes Secrets，其中只包括向Docker仓库推送最终镜像所需的认证信息）、Google Container Builder中，或是在本地运行。

Kaniko以容器镜像方式运行，它需要指定三个参数：Dockerfile、构建上下文，以及推送最终镜像的仓库（registry）名。所使用的镜像是从空白（Scratch）镜像开始构建的。空白镜像中只包括了静态的Go二进制文件，以及推送和拉取镜像所需配置文件。Kaniko执行器可获取并抽取给定基础镜像中的文件系统，并将其置于容器的根文件系统。这里所说的“基础镜像”，就是在给定的Dockerfile中由FROM指令所指定的镜像。

之后，Kaniko按Dockerfile定义的顺序，依次执行Dockerfile中的每个指令，并在执行完一个指令后，对文件系统做一次快照。快照创建于用户空间中，在文件系统中按层次组织，并依次将当前快照与先前存储在内存中的状态进行对比。快照将文件系统的任何更改存储为基础镜像的一个新层，并将任何相关的更改反映到镜像元数据中。在Dockerfile中所有指令执行完成后，新构建的镜像将由Kaniko执行器推送到指定的Docker仓库。所有上述步骤，完全是在执行器镜像的用户空间中完成的。这就是为什么Kaniko能避免授权主机访问，因为“Docker守护进程和CLI并未参与其中”。

Kaniko容器镜像构建流程图（图片来源：GCP官方博客）

Kaniko支持执行大部分Dockerfile指令，但目前尚不支持SHELL、HEALTHCHECK、STOPSIGNAL和ARG指令，也未支持多阶段构建（Multi-Stage）Dockerfile。据Kaniko团队称，解决这些局限的相关工作正在开展中。

目前还有一些类似于Kaniko的工具，其中包括img、orca-build、buildah、FTL和Bazel rules_docker。img支持在容器内以非root用户运行，但是需要容器具有“RawProc访问权限”，这样才能创建嵌套容器（与之相对比，Kaniko并不需要创建嵌套容器，因此也不需要具有RawProc访问权限）。orca-build依赖runC环境实现从Dockerfile构建镜像，但是runC本身不能运行在容器中。buildah需要具有运行Docker守护进程同样的权限。

FTL和Bazel的目的在于对一小部分镜像实现尽可能最快速的Docker镜像创建。Kankio的README文件指出，“它们可以看成是‘快速路径’的一种特殊情况，可与Kaniko提供的对通用Dockerfile的支持联合使用”。

对于如何将镜像构建融合到容器开发构建和部署的整个生命周期中，感兴趣的读者可以参阅InfoQ的前期报道“Google发布Skaffold，简化Kubernetes应用程序持续开发”。文中总结了适用于此过程的多种工具，并给出了推荐的过程。

据Kaniko GitHub代码库的README.md文件所述，该工具目前尚不能用于生产环境，欢迎对项目给出贡献、特性请求和软件缺陷报告。关于Kaniko发布的更多信息，参见GCP官方博客帖子“Kaniko介绍：无需授权在Kubernetes和GCP中构建容器镜像”。

查看英文原文： GCP Release “kaniko”, a Tool to Build Container Images Inside Unprivileged Containers or Kubernetes