关注「WeiyiGeek」公众号
设为「特别关注」每天带你玩转网络安全运维、应用开发、物联网IOT学习！
希望各位看友【关注、点赞、评论、收藏、投币】，助力每一个梦想。
本章目录
目录
首发地址: https://mp.weixin.qq.com/s/wchtH6i0xKrIrqSuYKmWkg
原文地址: https://blog.weiyigeek.top/2022/9-1-684.html
0x00 前言简述
快速介绍
什么是Kaniko?
kaniko 是一个在容器或 Kubernetes 集群内从 Dockerfile 构建容器镜像的工具 ( Build Container Images In Kubernetes )。
温馨提示: kaniko不是谷歌官方发布支持的产品.
为啥用Kaniko?
由于 kaniko 不依赖于 Docker 守护进程，并且完全在用户空间中执行 Dockerfile 中的每个命令，这使得能够在轻松或安全地运行在无Docker守护程序的环境（如标准Kubernetes集群 V1.24.x）中构建容器映像。
在 Kubernetes V1.24.x 版本之后默认采用 containerd.io 作为缺省的cri，不在支持 docker-shim 意味着我们不需要安装 docker 环境
Kaniko 是如何工作的?
kaniko 执行器镜像负责从 Dockerfile 构建镜像并将其推送到注册表，其流程大致如下：
- 首先在执行者图像中，我们提取基础镜像的文件系统（Dockerfile 中的 FROM 镜像）。
- 其次我们执行 Dockerfile 中的命令，之后在用户空间中对文件系统进行快照每一个。
- 然后在每个命令之后，我们将一层更改的文件附加到基础 图像（如果有）并更新图像元数据。
Kaniko 已知功能问题
- kaniko 不支持构建 Windows 容器。
- kaniko 不支持 v1 Registry API。(由于其不安全性当前基本都是使用V2协议, 例如 Harbor)
- kaniko 不支持在除官方kaniko映像之外的任何Docker映像中运行二进制Kanico可执行文件（即YMMV）。
kaniko 构建上下文
描述: kaniko 的构建上下文与您发送 Docker 守护程序以进行映像构建的构建上下文非常相似；它代表一个包含 Dockerfile 的目录，kaniko 将使用它来构建您的图像。
例如, Dockerfile 中的 COPY 命令应该引用构建上下文中的文件, 所以您需要将构建上下文存储在 kaniko 可以访问的位置。
目前kaniko 支持以下存储解决方案：
- GCS Bucket
- S3 Bucket
- Azure Blob Storage
- Local Directory
- Local Tar
- Standard Input
- Git Repository
运行 kaniko 时，使用 --context 带有适当前缀的标志指定构建上下文的位置, 如果您不指定前缀 kaniko 将假定一个本地目录, 该参数可用值：
SourcePrefixExampleLocal Directorydir://[path to a directory in the kaniko container]dir:///workspaceLocal Tar Gztar://[path to a .tar.gz in the kaniko container]tar://path/to/context.tar.gzStandard Inputtar://[stdin]tar://stdinGCS Bucketgs://[bucket name]/[path to .tar.gz]gs://kaniko-bucket/path/to/context.tar.gzS3 Buckets3://[bucket name]/[path to .tar.gz]s3://kaniko-bucket/path/to/context.tar.gzAzure Blob Storagehttps://[account].[azureblobhostsuffix]/[container]/[path to .tar.gz]https://myaccount.blob.core.windows.net/container/path/to/context.tar.gzGit Repositorygit://[repository url][#reference][#commit-id]git://github.com/acme/myproject.git#refs/heads/mybranch#例如，要使用名为 kaniko-bucket 的 GCS 存储桶，您需要传入 --context=gs://kaniko-bucket/path/to/context.tar.gz 。
温馨提示：kaniko 允许的唯一标准输入是 .tar.gz 格式, 如果要创建压缩 tar，您可以运行 tar -C -zcvf context.tar.gz .命令。- $ ls cache/
- Dockerfile
- # 压缩上下文目录
- $ tar -C cache/ -zcvf context.tar.gz .
- ./
- ./Dockerfile
- # 查看压缩文件
- $ tar -ztvf context.tar.gz
- drwxr-xr-x root/root 0 2022-09-08 23:03 ./
- -rw-r--r-- root/root 52 2022-09-08 23:04 ./Dockerfile
- Caching Layers ：kaniko 可以在远程存储库中缓存由RUN（由flag--cache-RUN-layers配置）和COPY（由flag--cache-COPY-layeers配置）命令创建的层。
在执行命令之前 kaniko 会检查层的缓存，如果存在 kaniko将拉取并提取缓存层，而不是执行命令。如果没有 kaniko将执行命令，然后将新创建的层推送到缓存。
用户可以通过设置 --cache=true 标志选择缓存,并且可以通过--cache-repo 标志提供用于存储缓存层的远程存储库, 如果未提供此标志则将从提供的--destination推断缓存的repo。
温馨提示: 在缓存未命中后，kaniko无法从缓存中找到读取层，所有后续层都将在本地构建，而无需咨询缓存。
- Caching Base Images: kaniko 可以将图像缓存在本地目录中，该目录可以卷装载到KanikoPod中。为此必须首先填充缓存, 我们在 gcr.io/kaniko-project/warmer 提供了一个kaniko缓存预热映像：
--image : 指定所需任意数量的图像, 填充缓存后 使用与上述相同的 --cache=true 标志选择缓存, 本地缓存的位置通过 --cache-dir 标志提供，默认为 /cache 与缓存预热器一样, 在实践中通常与 Kubernetes 集群和持久缓存卷一起使用。
示例： docker run -v $(pwd):/workspace gcr.io/kaniko-project/warmer:latest --cache-dir=/workspace/cache --image= --image=
0x01 部署使用
环境依赖
- kaniko 图像镜像
- 一个 Kubernetes 集群 或者 一个 Containerd 容器运行环境。
- 一个 dockerhub 帐户 用于将构建的图像公开。
小试牛刀之在Kubernetes集群中构建并发布镜像
描述: 此处我们准备在一个K8S集群中使用kaniko提供的镜像，按照提供的Dockerfile指令进行镜像构建，并上传到 docker hub 仓库中，以下为操作流程、
操作流程
步骤 01.首先, 为了加快构建速度, 我们提前在集群中拉取 gcr.io/kaniko-project/executor 镜像到本地, 由于国内无法直接拉取此处我采用这篇【使用Aliyun容器镜像服务对海外gcr、quay仓库镜像进行镜像拉取构建】 文章中的方法进行拉取构建国外gcr.io仓库中的镜像。- # 此处我已经创建了国内可以访问拉取的 executor 镜像, 不想在Aliyun容器镜像服务中进行创建拉取的朋友可以直接使用如下仓库地址。
- registry.cn-hangzhou.aliyuncs.com/weiyigeek/kaniko-executor:latest
- # 使用 ctr 或者 crictl 进行镜像拉取
- $ crictl pull registry.cn-hangzhou.aliyuncs.com/weiyigeek/kaniko-executor:latest
- $ crictl images | grep "kaniko-executor"
- registry.cn-hangzhou.aliyuncs.com/weiyigeek/kaniko-executor latest da9592dbe1de3 25.8MB
[code]# 创建存放dockerfile目录以及持久化缓存目录mkdir -vp /storage/dev/soft/kaniko/{cache,demo}cd /storage/dev/soft/kaniko/demotee dockerfile |
