如何使用 Kaniko在 Kubernetes 集群中构建容器镜像-51CTO.COM

前言

如何构建 Kubernetes 所需的容器镜像？我想你答案肯定是 Docker，没错，Docker 确实是首选。我们在使用 Jenkins 进行 CI/CD构建容器镜像的时候，做法通常是将 Jenkins 服务部署在物理机上，然后使用物理机的 docker build 命令来构建镜像。但是在 Jenkins on K8s 环境下，Jenkins Master 和 Jenkins Slave 都以 Pod 形式运行在 Kubernetes 集群的 Node 上，我们的构建环境都是 Pod ，没有 docker 命令。

众所周知 Kubernetes 在 V1.24.x 版本之后默认采用 containerd 作为容器运行时，不再支持 Docker，我们想用宿主机上的 /var/run/docker.sock 也用不了了。我们就需要另一种方式在 Kubernetes 集群中构建容器镜像，本文将介绍 Kaniko工具。

什么是Kaniko

Github地址：https://github.com/GoogleContainerTools/kaniko

Kaniko 是Google开源的一款在 Kubernetes 用来构建容器镜像的工具，它是一个从 Dockerfile 构建容器镜像的工具，就像 Docker 一样，但主要区别在于 Kaniko 可以在容器内运行，这意味着它可以在 Kubernetes 集群内运行。不需要特权模式，也不需要公开任何套接字。不需要在我们集群的节点上运行 Docker，因此我们使用哪个容器引擎来运行容器并不重要。重要的是 Kaniko 可以在容器内构建容器镜像，并在 Kubernetes 集群内自动构建，这就和宿主机上的 Docker 解绑了，更加安全可靠。特点如下：

docker in docker
不依赖 Docker守护进程
不需要 privilege 权限，安全构建
仅需一条命令
支持 Dockerfile 构建

现在，让我们一步一步来探索 Kaniko。

在Kubernetes中使用Kaniko

Kaniko 以容器的方式来运行的，同时需要三个参数: Dockerfile，上下文，以及远端镜像仓库的地址。

工作原理：

读取并解析指定的Dockerfile
提取基础镜像的文件系统（Dockerfile 中的 FROM 镜像）
在独立的Dockerfile中分别运行每个命令
每次运行后都会对用户空间文件系统的做快照
每次运行时，将快照层附加到基础层并更新镜像元数据
最后推送镜像

前提条件：

需要一个运行的 kubernetes 集群
需要创建一个 Kubernetes secret，其中包含推送到镜像仓库所需的身份验证信息
需要准备好Dockerfile

创建Dockerfile

编写一个Dockerfile 文件，并创建configmap 在k8s中：

[root@localhost ~]# cat Dockerfile
FROM ubuntu
ENTRYPOINT ["/bin/bash", "-c", "echo hello"]

[root@localhost ~]# kubectl create configmap kaniko-dockerfile --from-file=./Dockerfile
configmap/kaniko-dockerfile created

创建镜像仓库凭证的Secret

创建一个配置kaniko推送到阿里云镜像仓库的凭证，找一台有安装docker的机子，登录仓库：

[root@localhost ~]# docker login --username=xxx registry.cn-shanghai.aliyuncs.com
Password:
WARNING! Your password will be stored unencrypted in /root/.docker/config.json.
Configure a credential helper to remove this warning. See
https://docs.docker.com/engine/reference/commandline/login/#credentials-store
 
Login Succeeded

登入成功之后，会生成一个config.json的文件，使用该文件创建一个secret供kaniko容器使用。

centos环境中文件位置：/root/.docker/config.json
ubuntu环境中文件位置：/home/ubuntu/.docker/config.json

[root@localhost ~]# kubectl create secret generic kaniko-secret --from-file=/root/.docker/config.json
secret/kaniko-secret created

启动kaniko容器用来构建镜像

kaniko_build_image.yaml：

apiVersion: v1
kind: Pod
metadata:
  name: kaniko
spec:
  containers:
  - name: kaniko
    image: gcr.io/kaniko-project/executor:latest
    args: ["--dockerfile=/workspace/Dockerfile",
            "--context=dir://workspace",
            "--destination=registry.cn-shanghai.aliyuncs.com/kubesre02/kaniko-demo:1.0"] # 替换成自己的仓库地址
    volumeMounts:
      - name: kaniko-secret
        mountPath: /kaniko/.docker
      - name: dockerfile
        mountPath: /workspace
  volumes:
    - name: kaniko-secret
      secret:
        secretName: kaniko-secret
        items:
          - key: config.json
            path: config.json
    - name: dockerfile
      configMap:
        name: kaniko-dockerfile

args 部分：这部分就是上面所讲的，kaniko运行时需要三个参数: Dockerfile(--dockerfile)，上下文(--context)，远端镜像仓库(--destination)
secret 部分：推送至指定远端镜像仓库需要认证，所以以secret的方式挂载到/kaniko/.docker/这个目录下，文件名称为config.json

创建pod，查看状态，并看log是否正常完成。

[root@localhost ~]# kubectl apply -f kaniko_build_image.yaml
pod/kaniko created

[root@localhost ~]# kubectl get pod
NAME                       READY   STATUS    RESTARTS   AGE
kaniko                     1/1     Running   0          3s
 
[root@localhost ~]# kubectl logs -f kaniko
INFO[0000] Retrieving image manifest ubuntu            
INFO[0000] Retrieving image ubuntu from registry index.docker.io
INFO[0003] Built cross stage deps: map[]               
INFO[0003] Retrieving image manifest ubuntu            
INFO[0003] Returning cached image manifest             
INFO[0003] Executing 0 build triggers                  
INFO[0003] Building stage 'ubuntu' [idx: '0', base-idx: '-1']
INFO[0003] Skipping unpacking as no commands require it.
INFO[0003] ENTRYPOINT ["/bin/bash", "-c", "echo hello"]
INFO[0003] Pushing image to registry.cn-shanghai.aliyuncs.com/kubesre02/kaniko-demo:1.0
INFO[0004] Pushed registry.cn-shanghai.aliyuncs.com/kubesre02/kaniko-demo@sha256:d1855cc00550f9048c88b507626e0f24acf4c22e02856e006b2b9fdb0b80e567

查看阿里云镜像仓库已经上传上去了：

用kaniko生成的镜像来测试下是否可用：

[root@localhost ~]# docker run -it --rm registry.cn-shanghai.aliyuncs.com/kubesre02/kaniko-demo:1.0
Unable to find image 'registry.cn-shanghai.aliyuncs.com/kubesre02/kaniko-demo:1.0' locally
1.0: Pulling from kubesre02/kaniko-demo
445a6a12be2b: Pull complete
Digest: sha256:49bb962115b70a15a99b87e48fda28a883758081e41aef14766833d3a1578069
Status: Downloaded newer image for registry.cn-shanghai.aliyuncs.com/kubesre02/kaniko-demo:1.0
hello

出来hello即成功。

自定义一个Kaniko镜像

官方 kaniko 镜像是基于 scratch 构建的，里面没有 shell，想在 kaniko 原生镜像里在调用 shell 命令是很麻烦的。所以我们可以自定义我们自己私有的 Kaniko 镜像。kaniko 的关键文件其实是/kaniko目录下的二进制文件，官方推荐是用 gcr.io/kaniko-project/executor 镜像，我们就可以拷贝这个/kaniko目录下的 executor 到我们自己的私有镜像 Dockerfile：


FROM gcr.io/kaniko-project/executor:latest AS plugin
 
FROM ubuntu
 
ENV DOCKER_CONFIG /kaniko/.docker
 
COPY --from=plugin /kaniko/executor /usr/local/bin/kaniko
 
RUN mkdir -p /kaniko/.docker/
COPY config.json /kaniko/.docker/

上面 Dockerfile 构建了一个基于Ubuntu的Docker镜像：

(1) FROM gcr.io/kaniko-project/executor:latest AS plugin

从名为gcr.io/kaniko-project/executor:latest的Docker镜像开始构建一个临时阶段，并将其命名为plugin。
这个步骤是在一个已经包含了Kaniko工具的Docker镜像中构建一个中间容器。

(2) FROM ubuntu

接下来创建一个新的Docker镜像，基于官方的Ubuntu基础镜像。

(3) ENV DOCKER_CONFIG /kaniko/.docker

设置环境变量DOCKER_CONFIG为/kaniko/.docker，这是Kaniko工具使用的Docker配置目录。这是为了确保Kaniko可以找到必要的Docker配置信息。

(4) COPY --from=plugin /kaniko/executor /usr/local/bin/kaniko

从之前构建的plugin阶段的镜像中复制/kaniko/executor文件到新的镜像的/usr/local/bin/kaniko路径下。这将把Kaniko二进制文件复制到新的Ubuntu镜像中，以便后续在该镜像中使用。

(5) RUN mkdir -p /kaniko/.docker/

在新的镜像中创建/kaniko/.docker/目录，用于存放Docker配置文件。

(6) COPY config.json /kaniko/.docker/

将本地的config.json文件复制到新的镜像的/kaniko/.docker/目录下。这个config.json文件很可能包含了Docker仓库的认证信息和其他配置，以便Kaniko可以访问和推送Docker镜像。

最终，这个Docker镜像将包含了Ubuntu操作系统和Kaniko工具，并配置了Kaniko所需的Docker环境，使得可以在容器内使用Kaniko构建Docker镜像，并且有了 shell 环境，同时保持了一定程度的隔离性和安全性。构建并上传镜像：

[root@localhost ~]# docker build -t registry.cn-shanghai.aliyuncs.com/kubesre02/kaniko:latest .
Sending build context to Docker daemon  212.1MB
Step 1/6 : FROM gcr.io/kaniko-project/executor:latest AS plugin
 ---> 03375da0f864
Step 2/6 : FROM ubuntu
 ---> aa786d622bb0
Step 3/6 : ENV DOCKER_CONFIG /kaniko/.docker
 ---> Using cache
 ---> f7cd726aa130
Step 4/6 : COPY --from=plugin /kaniko/executor /usr/local/bin/kaniko
 ---> Using cache
 ---> 8fcac536196f
Step 5/6 : RUN mkdir -p /kaniko/.docker/
 ---> Using cache
 ---> 1afce75446a3
Step 6/6 : COPY config.json /kaniko/.docker/
 ---> Using cache
 ---> 4a2873a75a7c
Successfully built 4a2873a75a7c
Successfully tagged registry.cn-shanghai.aliyuncs.com/kubesre02/kaniko:latest
 
[root@localhost ~]# docker push registry.cn-shanghai.aliyuncs.com/kubesre02/kaniko:latest
The push refers to repository [registry.cn-shanghai.aliyuncs.com/kubesre02/kaniko]
0cb4fb37580b: Pushed
c9dbd3644e5a: Pushed
33a2214b827c: Pushed
c5077dd8160b: Pushed
948c7f86fd48: Pushed
403aab81b15b: Pushed
7bff100f35cb: Pushed
latest: digest: sha256:b5642885f1333a757625cbe36a9b1102aba27646f2572acab79861a74dba1050 size: 1783

Kaniko 更多参数

--context：指定构建上下文的路径。默认情况下，上下文是Dockerfile所在的目录。可简写 -c
--dockerfile：指定要使用的Dockerfile的路径。默认情况下，Kaniko会在上下文中查找名为Dockerfile的文件。可简写 -f
--destination：指定构建完成后的Docker镜像名称，可以包括标签。例如：myregistry/myimage:tag。可简写 -d
--cache：启用或禁用Kaniko的构建缓存功能。默认情况下，缓存是启用的。
--cache-ttl：设置构建缓存的生存时间。例如，--cache-ttl=10h表示缓存在构建完成后的10小时内有效。
--cache-repo：指定用于存储构建缓存的Docker仓库。默认情况下，缓存存储在本地。
--cache-dir：指定用于存储构建缓存的本地目录路径。
--skip-tls-verify：跳过TLS证书验证，用于不安全的Docker仓库。
--build-arg：传递构建参数给Dockerfile中的ARG指令。例如：--build-arg key=value。
--insecure：允许从不受信任的Registry拉取基础镜像。
--insecure-registry：允许连接到不受信任的Registry。
--verbosity：设置构建的详细程度，可以是panic、error、warning、info、debug或trace。
--digest-file：指定一个文件，用于存储构建生成的镜像的摘要（Digest）。
--oci-layout-path：指定OCI（Open Container Initiative）布局文件的路径，用于存储构建过程的元数据。

更多参考官方：https://github.com/GoogleContainerTools/kaniko#additional-flags

Kaniko 构建缓存

--cache-copy-layers 此参数在执行命令之前 kaniko 会检查层的缓存，如果存在 kaniko将拉取并提取缓存层，而不是执行命令。如果没有 kaniko将执行命令，然后将新创建的层推送到缓存。用户可以通过设置 --cache=true 参数决定是否启用缓存，并且可以通过--cache-repo 标志提供用于存储缓存层的远程存储库，如果未提供此标志则将从提供的 –destination 推断缓存的repo。通常 --cache=true --cache-copy-layers=true 这两个参数同时使用。

CI/CD 中使用Kaniko

jenkins pipline 中使用：

基于 Kubernetes 的动态生成 Jenkins Slave pod CI/CD，以下是一个简化的Pipeline示例：

// 镜像仓库地址
def registry = "registry.cn-shanghai.aliyuncs.com/kubesre02/demo"
 
pipeline {
    agent {
        kubernetes {
      yaml """
kind: Pod
metadata:
  name: kaniko
spec:
  containers:
  - name: kaniko
    # 使用自定义的 kaniko 镜像
    image: registry.cn-shanghai.aliyuncs.com/kubesre02/kaniko:latest
    imagePullPolicy: Always
    command:
    - cat
    tty: true
"""
      }
    }
   
    stages {
        stage('拉代码') {
            steps {
                git clone ...
            }
        }
       
        stage('构建镜像') {
            steps {
                // 使用 kaniko 来构建镜像
                container(name: 'kaniko') {
                    Dockerfile 内容...
                    sh "kaniko -f Dockerfile -c ./ -d $registry:$BUILD_NUMBER --force"
                }
            }
        }
         
        stage('部署') {
            steps {
                部署...
            }
        }
         
    }
}

可以看出，Kaniko 是非常适合在Kubernetes平台上构建容器镜像的，而且易于集成到 DevOps Jenkins pipeline 里，好了，kaniko 就介绍到这里。