利用Kaniko构建容器镜像

2021年09月15日 阅读数:4
这篇文章主要向大家介绍利用Kaniko构建容器镜像,主要内容包括基础应用、实用技巧、原理机制等方面,希望对大家有所帮助。
本系列文章一共6篇,本文是该系列的第4篇文章,前3篇文章以下:


  1. 将来咱们如何构建容器镜像?git

  2. 利用Podman和Buildah构建容器镜像github

  3. 利用Img构建容器镜像后端


本期咱们来聊一聊一个名叫Kaniko的开源项目。
Kaniko项目最初于2018年由谷歌提出。Kaniko的建立之初是寻求在执行容器镜像构建时消除对特权帐户的依赖。若是你一直关注本系列文章,那么如今您将已经知道,无特权的容器镜像构建是注重安全性的公司最须要的功能之一。这与在Kubernetes集群中构建容器镜像相似。
Kaniko是如何工做的?缓存


方法安全

利用Kaniko构建容器镜像_容器镜像


Kaniko使用你熟悉的方式来构建容器镜像;包含构建指令和构建上下文的Dockerfile,其中包含Dockerfile和镜像所需的任何其元素。
可是,与原生的Docker客户端构建命令不一样,它执行构建步骤时不须要Docker守护程序。
Kaniko使用本身的“executor[1]”执行构建步骤,该构建步骤在容器(多是Kubernetes Pod)中运行。固然,须要使构建上下文对容器或Pod可用,使得它能在构建中被使用。由于构建步骤是在容器内执行的,因此仍然最终依赖Docker守护程序或其余容器运行时,但重要的区别是构建步骤自己是由执行程序代码执行的。
“executor”遍历Dockerfile中定义的每一个构建步骤。它拉取为构建阶段准备的源镜像,并解压缩其rootfs。而后,它按顺序执行每一个Dockerfile指令,并随其添加或更改rootfs的内容。若是对rootfs进行了更改,则“executor”对文件系统作快照化,更改“diff”层,并在必要时更新镜像元数据。经过将文件系统的先前状态与Dockerfile指令执行后的状态进行比较,能够实现快照。除了操做彻底在用户空间中执行以外,这与overlayfs之类的copy-on-write文件系统的行为并没有不一样。构建步骤完成后,将diff层依次添加到基础镜像中以造成新镜像。
你可能会问“最后怎样处理镜像?镜像会不会随着容器或Pod消失?”
“executor”必定但愿镜像制做命令中能够指定镜像仓库的名字,这样新的镜像就能够被推送到镜像仓库,从而完成镜像制做的全过程。
下面的一段YAML文件定义了运行在Kaniko“executor”的Pod:
 
 

spec:
  containers:
  - name: executor
    image: gcr.io/kaniko-project/executor:latest
    args: [
      "--context",
      "git://github.com/mycorp/my-app.git",
      "--destination",
      "quay.io/mycorp/my-app:1d03df1",
            ]app


构建上下文分布式

利用Kaniko构建容器镜像_容器镜像


在定义构建上下文源时,Kaniko很是灵活。卷挂载可用于指定包含上下文的本地目录(到容器),而且上面的示例着重说明了如何使用Git存储库做为源。
联想到Kaniko的出身,若是云存储不能被Kaniko用做构建上下文的来源是使人难以置信的。毫无疑问,Kaniko支持使用由三个主要公有云服务商提供的对象存储解决方案。 K8s已经成为一线大厂分布式平台的标配技术。你是否是还在惆怅怎么掌握它?来这里,大型互联网公司一线工程师亲授,不来虚的,直接上手实战,3天时间带你搭建K8s平台,快速学会K8s,点击下方图片可了解培训详情。

利用Kaniko构建容器镜像_容器镜像_03

构建缓存

利用Kaniko构建容器镜像_容器镜像


容器镜像构建的一个极其重要的部分是可以利用以前镜像构建过程当中的调用步骤,该调用一般所以目的而被缓存。若是构建步骤将产生相同的输出,则构建器将使用缓存的内容,而不是从新执行构建步骤。
Kaniko提供了两种缓存功能来加强镜像构建:
  1. 源镜像能够下载到本地卷中共享,“executor”容器在调用时便可使用。这样能够避免“executor”容器在每次调用时都提取相同的源镜像,从而节省了构建时间。为此,Kaniko提供了“暖心”的功能。你只须要将须要缓存的镜像和其余相关镜像存放在指定的本地目录便可。ide

  2. 在镜像构建期间建立的中间镜像层也是构建缓存的关键要素。Kaniko启用了在执行RUN Dockerfile指令期间建立镜像的缓存,可是这些镜像存储在远程镜像仓库。在“executor”处理RUN指令以前,指定的镜像仓库会检查对应层。若是找到,则将其从镜像仓库中提取,而不是从正在执行的指令中提取。工具


安全ui

利用Kaniko构建容器镜像_容器镜像


因为Kaniko避免使用Docker守护进程的build API端点来执行构建步骤,所以在安全性方面有很大帮助。可执行程序能够做为非特权容器运行,不须要将Docker守护进程套接字安装到该容器中。这是在Kubernetes上的Pod中安全运行容器镜像构建过程当中的重要一步。
不利之处在于,构建步骤可能须要以root(uid = 0)用户身份执行。通常而言,容器应以非root用户身份运行——容器中的root就是主机上的root。若是基本镜像的rootfs组件被root用户拥有,或者须要以root特权执行命令,那么Kaniko毫无办法。
以root用户身份运行执行程序容器这类问题能够有扑救措施。经过提供额外的隔离措施,能够保护运行“executor”序容器的主机。Google本身的gVisor[2]就是这种隔离的一个很好的例子,Kata Containers[3]运行时也是如此。


结论

利用Kaniko构建容器镜像_容器镜像


Kaniko是镜像构建器工具的新工具之一,其目的是消除对Docker守护程序的长期依赖。它很好地作到了这一点,并在Kubernetes集群中提供了可靠的容器镜像构建体验。这样就能够避免一般用Docker守护程序进行构建相关的安全隐患。所以,Kaniko是一种主流的镜像构建工具,它的常规功能也做为Tekton Pipelines[4]的后端构建任务。
但广受欢迎的Kaniko并无彻底实现无根容器镜像构建,并且还延续了基于Dockerfile的构建的顺序性。
相关连接:
  1. https://console.cloud.google.com/gcr/images/kaniko-project/GLOBAL/executor@sha256:9c40a04cf1bc9d886f7f000e0b7fa5300c31c89e2ad001e97eeeecdce9f07a29?tag=latest

  2. https://gvisor.dev/

  3. https://katacontainers.io/

  4. https://github.com/tektoncd/pipeline


原文连接:https://www.giantswarm.io/blog/container-image-building-with-kaniko