记录 k8s 中，使用 kaniko 遇到的坑。

最近在折腾用 argo workflow 搭建 CI 。在处理 kaniko build 镜像的那一步，感觉遇到了几个坑。简单记录一下，以供参考。

1. kaniko build 很慢。因为每次都要从上游 pull 镜像。
2. Dockerfile 里有 VOLUME 指令，会导致对应的目录被 ignored 。
3. COPY 命令不会自己解软链。


后两个都没什么好说的。知道了就能避坑。主要讲讲第一个问题。


kaniko 的 build 感觉比 docker 慢很多。除了这个 issue https://github.com/GoogleContainerTools/kaniko/issues/875 里提到的优化参数可以使用外，最主要的一点是节点与 registry 之间的网络要非常非常的好。

因为 kaniko 的 build 不像你在本地使用 docker 那样会加载本地已经存在的 base 镜像。kaniko 可以理解为没有 “本地” 这个概念，每一次的 build 都要从 registry 拉取 base 镜像。企业使用 AWS 之类的这些云服务，他们的节点与各大 registry 之间的网络通常都非常好，所以使用他们这些服务的人自然感受不到每次拉取 base 镜像带来的影响。自建的 k8s 集群要解决这个问题，有两种方案：

1). 自己缓存镜像到一个 pv 上，每次使用 /kaniko/warmer 命令预热。首次预热，会把镜像存储到 pv 上，后续预热都会跳过。不过这个方案存在一个 OCI 兼容性 bug ，官方至今未解决。见 issue https://github.com/GoogleContainerTools/kaniko/issues/2423 。

2). 在集群内，自建一个 registry 镜像服务。kaniko 有映射 registry 的参数，把各大 registry 的地址都映射到这个自建的镜像服务上。这样，首次构建后由于镜像服务上已经有了 base 镜像，下次在构建的时候就会快很多。虽然 kaniko 每次 build 还是要重新 pull 镜像。但是由于两个 “节点” 都在同一个区域集群里，他们的通讯非常快。影响也就很小。