如何使用 Kaniko在 Kubernetes 集群中构建容器镜像

前言

如何构建 Kube.NETes 所需的容器镜像？我想你答案肯定是 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 就介绍到这里。