Kubernetes Kaniko
参考：https://mp.weixin.qq.com/s?__biz=MzUxNTg5NTQ0NA==&mid=2247485123&idx=1&sn=95d3785fe862567329e38e002cf93e19&chksm=f8f36c27517a7d37b330f6e78fd66a019b05fcee6b37d3044a487f5af451a1b75f1188c19e5f&scene=126&sessionid=1704951873#rd如何构建 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/kanikoKaniko 是Google开源的一款在 Kubernetes 用来构建容器镜像的工具，
它是一个从 Dockerfile 构建容器镜像的工具，就像 Docker 一样，但主要区别在于 Kaniko 可以在容器内运行，
这意味着它可以在 Kubernetes 集群内运行。不需要特权模式，也不需要公开任何套接字。不需要在我们集群的节点上运行 Docker，
因此我们使用哪个容器引擎来运行容器并不重要。重要的是 Kaniko 可以在容器内构建容器镜像，并在 Kubernetes 集群内自动构建，
这就和宿主机上的 Docker 解绑了，更加安全可靠。特点如下：
docker in docker
不依赖 Docker守护进程
不需要 privilege 权限，安全构建
仅需一条命令
支持 Dockerfile 构建
现在，让我们一步一步来探索 Kaniko在Kubernetes中使用Kaniko
#1、创建Dockerfile
[root@k8s-master01 kaniko]# cat Dockerfile
FROM ubuntu
ENTRYPOINT ["/bin/bash", "-c", "echo hello"]
[root@k8s-master01 kaniko]# kubectl create configmap kaniko-dockerfile --from-file=./Dockerfile
configmap/kaniko-dockerfile created
#2、创建镜像仓库凭证的Secret
# 几个节点都要登录保证后续登录正常 推送正常
# 创建一个配置kaniko推送到 阿里云镜像仓库的凭证，找一台有安装docker的机子，登录仓库
[root@k8s-master01 kaniko]# docker login --username=xxx registry.cn-beijing.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
#3、登入成功之后，会生成一个config.json的文件，使用该文件创建一个secret供kaniko容器使用。
# centos环境中文件位置：/root/.docker/config.json
[root@k8s-master01 kaniko]# kubectl create secret generic kaniko-secret --from-file=/root/.docker/config.json
secret/kaniko-secret created
#4、启动kaniko容器用来构建镜像
[root@k8s-master01 kaniko]# cat kaniko_build_image.yaml
apiVersion: v1
kind: Pod
metadata:
name: kaniko
spec:
containers:
- name: kaniko
#image: gcr.io/kaniko-project/executor:latest
image: gcr.lank8s.cn/kaniko-project/executor:latest
args: ["--dockerfile=/workspace/Dockerfile",
"--context=dir://workspace",
"--destination=registry.cn-shanghai.aliyuncs.com/birkhoff/kaniko-Dockerfile:v1.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
[root@k8s-master01 kaniko]# kubectl apply -f kaniko_build_image.yaml
pod/kaniko created
[root@k8s-master01 kaniko]# kubectl get pods
NAME READY STATUS RESTARTS AGE
kaniko 1/1 Running 0 2s
[root@k8s-master01 kaniko]# kubectl logs -f kaniko
INFO[0000] Retrieving image manifest ubuntu
INFO[0000] Retrieving image ubuntu from registry index.docker.io
INFO[0014] Built cross stage deps: map[]
INFO[0014] Retrieving image manifest ubuntu
INFO[0014] Returning cached image manifest
INFO[0014] Executing 0 build triggers
INFO[0014] Building stage 'ubuntu' [idx: '0', base-idx: '-1']
INFO[0014] Skipping unpacking as no commands require it.
INFO[0014] ENTRYPOINT ["/bin/bash", "-c", "echo hello"]
INFO[0014] Pushing image to registry.cn-hangzhou.aliyuncs.com/birkhoff/kaniko-test:1.0
INFO[0184] Pushed registry.cn-hangzhou.aliyuncs.com/birkhoff/kaniko-test@sha256:b0c6f543b4d8bb8c9b8ed0d4859d20d8fd861efbaa31ac98071706f4d685792c
#用kaniko生成的镜像来测试下是否可用-hello显示出来了
[root@k8s-master01 kaniko]# docker run -it --rm registry.cn-hangzhou.aliyuncs.com/birkhoff/kaniko-test:1.0
Unable to find image 'registry.cn-hangzhou.aliyuncs.com/birkhoff/kaniko-test:1.0' locally
1.0: Pulling from birkhoff/kaniko-test
a48641193673: Pull complete
Digest: sha256:b0c6f543b4d8bb8c9b8ed0d4859d20d8fd861efbaa31ac98071706f4d685792c
Status: Downloaded newer image for registry.cn-hangzhou.aliyuncs.com/birkhoff/kaniko-test:1.0
hello 
自定义一个Kaniko镜像
官方 kaniko 镜像是基于 scratch 构建的，里面没有 shell，想在 kaniko 原生镜像里在调用 shell 命令是很麻烦的。
所以我们可以自定义我们自己私有的 Kaniko 镜像。kaniko 的关键文件其实是/kaniko目录下的二进制文件，
官方推荐是用 gcr.io/kaniko-project/executor 镜像，
我们就可以拷贝这个/kaniko目录下的 executor 到我们自己的私有镜像 Dockerfile：[root@k8s-master01 zdy]# cp /root/.docker/config.json .
[root@k8s-master01 zdy]# cat Dockerfile
FROM gcr.lank8s.cn/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镜像，
FROM gcr.io/kaniko-project/executor:latest AS plugin
从名为gcr.io/kaniko-project/executor:latest的Docker镜像开始构建一个临时阶段，并将其命名为plugin。
这个步骤是在一个已经包含了Kaniko工具的Docker镜像中构建一个中间容器。
FROM ubuntu
接下来创建一个新的Docker镜像，基于官方的Ubuntu基础镜像。
ENV DOCKER_CONFIG /kaniko/.docker
设置环境变量DOCKER_CONFIG为/kaniko/.docker，这是Kaniko工具使用的Docker配置目录。这是为了确保Kaniko可以找到必要的Docker配置信息。
COPY --from=plugin /kaniko/executor /usr/local/bin/kaniko
从之前构建的plugin阶段的镜像中复制/kaniko/executor文件到新的镜像的/usr/local/bin/kaniko路径下。这将把Kaniko二进制文件复制到新的Ubuntu镜像中，以便后续在该镜像中使用。
RUN mkdir -p /kaniko/.docker/
在新的镜像中创建/kaniko/.docker/目录，用于存放Docker配置文件。
COPY config.json /kaniko/.docker/
将本地的config.json文件复制到新的镜像的/kaniko/.docker/目录下。这个config.json文件很可能包含了Docker仓库的认证信息和其他配置，以便Kaniko可以访问和推送Docker镜像。
最终，这个Docker镜像将包含了Ubuntu操作系统和Kaniko工具，并配置了Kaniko所需的Docker环境，使得可以在容器内使用Kaniko构建Docker镜像，并且有了 shell 环境，同时保持了一定程度的隔离性和安全性。构建并上传镜像：[root@k8s-master01 zdy]# docker build -t registry.cn-hangzhou.aliyuncs.com/birkhoff/kaniko:customize .
[+] Building 79.5s (11/11) FINISHED docker:default
=> [internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 275B 0.0s
=> [internal] load .dockerignore 0.0s
=> => transferring context: 2B 0.0s
=> [internal] load metadata for docker.io/library/ubuntu:latest 15.5s
=> [internal] load metadata for gcr.lank8s.cn/kaniko-project/executor:latest 0.4s
=> [plugin 1/1] FROM gcr.lank8s.cn/kaniko-project/executor:latest@sha256:f913ab076f92f1bdca336ab8514fea6e76f0311e52459cce5ec090c120885c8b 63.2s
=> => resolve gcr.lank8s.cn/kaniko-project/executor:latest@sha256:f913ab076f92f1bdca336ab8514fea6e76f0311e52459cce5ec090c120885c8b 0.0s
=> => sha256:f913ab076f92f1bdca336ab8514fea6e76f0311e52459cce5ec090c120885c8b 3.12kB / 3.12kB 0.0s
=> => sha256:4d0182087ab9e2272ac77f6067f1549a6d803bd2163f367335766493c579f108 2.00kB / 2.00kB 0.0s
=> => sha256:c584974b87ed07c55bb3cbca5063bdc56d4e0c092872eb09a7e4b2347fa2436a 3.60kB / 3.60kB 0.0s
=> => sha256:24ac6486824c19f4e93c5ced995f8af71aad3d91d7a12e2f1ba1cf1baf4cd119 144B / 144B 0.7s
=> => sha256:12e76367120f87420d7a129e2903be9d9f6fb4a5a84a8c67c407e6ef5a48feb2 115.23kB / 115.23kB 1.5s
=> => extracting sha256:24ac6486824c19f4e93c5ced995f8af71aad3d91d7a12e2f1ba1cf1baf4cd119 0.0s
=> => sha256:9ccaebf3f717c39cabfca6b82c3c86b615de14a00366a1c44ff17ffddeaa9a47 511B / 511B 1.6s
=> => extracting sha256:12e76367120f87420d7a129e2903be9d9f6fb4a5a84a8c67c407e6ef5a48feb2 0.0s
=> => sha256:1415c527ba9e2e175d3fff39bdb2bbaecf211d6a1dfac7d884d636461421a886 4.96MB / 4.96MB 19.1s
=> => extracting sha256:9ccaebf3f717c39cabfca6b82c3c86b615de14a00366a1c44ff17ffddeaa9a47 0.0s
=> => sha256:2bef7b2979b2e244b6792026dbc885afc524aa9c5402af901e12a3f55eb6d7c6 5.85MB / 5.85MB 19.2s
=> => extracting sha256:1415c527ba9e2e175d3fff39bdb2bbaecf211d6a1dfac7d884d636461421a886 0.1s
=> => sha256:fb761cd73d99aa0654a84951e643fed78501508476d8aaad4607d7a4d2cc561d 7.13MB / 7.13MB 35.3s
=> => extracting sha256:2bef7b2979b2e244b6792026dbc885afc524aa9c5402af901e12a3f55eb6d7c6 0.1s
=> => sha256:6b6593a4fbdf6b2d49490663a333ab7376dc18b3c7a20cd285e73e9f97c887ba 129B / 129B 19.4s
=> => sha256:7dae52ebc01be1a371c7991d5ca912349cb813648a31fa33cc094f6103e5464c 99B / 99B 35.7s
=> => sha256:b19157c35055333d85bf48cc68f611d5155ade22a1c2c41ef6ffe6b2c6ed426c 12.44MB / 12.44MB 62.6s
=> => extracting sha256:fb761cd73d99aa0654a84951e643fed78501508476d8aaad4607d7a4d2cc561d 0.1s
=> => extracting sha256:6b6593a4fbdf6b2d49490663a333ab7376dc18b3c7a20cd285e73e9f97c887ba 0.0s
=> => extracting sha256:7dae52ebc01be1a371c7991d5ca912349cb813648a31fa33cc094f6103e5464c 0.0s
=> => extracting sha256:b19157c35055333d85bf48cc68f611d5155ade22a1c2c41ef6ffe6b2c6ed426c 0.5s
=> [stage-1 1/4] FROM docker.io/library/ubuntu@sha256:626ffe58f6e7566e00254b638eb7e0f3b11d4da9675088f4781a50ae288f3322 63.4s
=> => resolve docker.io/library/ubuntu@sha256:626ffe58f6e7566e00254b638eb7e0f3b11d4da9675088f4781a50ae288f3322 0.0s
=> => sha256:626ffe58f6e7566e00254b638eb7e0f3b11d4da9675088f4781a50ae288f3322 1.42kB / 1.42kB 0.0s
=> => sha256:7cc0576c7c0ec2384de5cbf245f41567e922aab1b075f3e8ad565f508032df17 529B / 529B 0.0s
=> => sha256:ba6acccedd2923aee4c2acc6a23780b14ed4b8a5fa4e14e252a23b846df9b6c1 1.46kB / 1.46kB 0.0s
=> => sha256:7b1a6ab2e44dbac178598dabe7cff59bd67233dba0b27e4fbd1f9d4b3c877a54 28.57MB / 28.57MB 61.8s
=> => extracting sha256:7b1a6ab2e44dbac178598dabe7cff59bd67233dba0b27e4fbd1f9d4b3c877a54 1.5s
=> [internal] load build context 0.0s
=> => transferring context: 232B 0.0s
=> [stage-1 2/4] COPY --from=plugin /kaniko/executor /usr/local/bin/kaniko 0.1s
=> [stage-1 3/4] RUN mkdir -p /kaniko/.docker/ 0.2s
=> [stage-1 4/4] COPY config.json /kaniko/.docker/ 0.0s
=> exporting to image 0.1s
=> => exporting layers 0.1s
=> => writing image sha256:91cc4d59f25aeed61a23740035c4b4e9544501da0c898bdf8ad6c8d916f6f26b 0.0s
=> => naming to registry.cn-hangzhou.aliyuncs.com/birkhoff/kaniko:customize
[root@k8s-master01 zdy]# docker push registry.cn-hangzhou.aliyuncs.com/birkhoff/kaniko:customize
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
// 镜像仓库地址
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 {
部署...
}
}
}
}
浙公网安备 33010602011771号