如何使用 Kaniko在 Kubernetes 集群中構建容器鏡像
前言
如何構建 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: 1783Kaniko 更多參數
- --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 就介紹到這里。
