前言
通常情况下，我们在使用dockerfile构建镜像的时候要与Docker后台进程交互访问，也就是需要本机root权限。如果是在Docker后台进程无法暴露的场景下，生成容器镜像就变得很困难。kaniko是Google开源的一个工具，可以帮助开发及运维人员从容器或Kubernetes集群内的Dockerfile构建容器镜像，而无需访问Docker守护程序。这样，您可以在容器内执行构建作业，而无需授予对主机文件系统的任何访问权限，你只需要将构建清单创建为Kubernetes批处理作业，然后使用你选择的任何CI工具将其应用于集群。该工作负责构建映像并将其上传到指定的容器注册表。
1.读取指定的Dockerfile。
2.将基本映像（在FROM指令中指定）提取到容器文件系统中。
3.在独立的Dockerfile中分别运行每个命令。
4.每次运行后都会对用户空间文件系统的做快照。
5.每次运行时，将快照层附加到基础层。
kaniko工作原理kaniko作为一个容器镜像运行，它接受三个参数：一个 Dockerfile ，一个构建上下文以及将镜像推送到的注册表。它在执行程序镜像中提取基本镜像的文件系统。然后，在Dockerfile中执行任何命令，快照用户空间中的文件系统。Kaniko在每个命令后都会将一层已更改的文件附加到基本镜像。最后，执行程序将新镜像推送到指定的注册表。由于Kaniko在执行程序镜像的用户空间中完全执行了这些操作，因此它完全避免了在用户计算机上需要任何特权访问。
Kaniko解决了在Kubernetes构建的问题，但是构建的项目、目标 registry 的认证、Dockerfile的分发，还是需要我们自己考虑。
前提条件：
1.需要一个运行的 kubernetes 集群；
安装k8s集群可参考如下：
k8s1.18多master节点高可用集群安装-超详细中文官方文档
2.需要有一个用来存储dockerfile和kubernetes资源清单yaml文件的github仓库
3.需要有一个存储docker镜像的docker hub镜像仓库
创建一个容器注册表的secret
让我们从设置容器注册表secret开始。必须通过容器注册表进行身份验证才能推送生成的映像。
将需要以下内容：
docker-server—需要在其中托管映像的Docker注册表服务器。如果使用的是Docker Hub，请使用https://index.docker.io/v1/。 docker-username — Docker注册表用户名。 docker-password — Docker注册表密码。 docker-email —在Docker注册表上配置的电子邮件。
运行以下命令，替换上面的值：
kubectl create secret docker-registry regcred --docker-server=<docker-server> --docker-username=<username> --docker-password=<password> --docker-email=<email>
通过dockerfile构建一个镜像
cat dockerfile
FROM nginx RUN echo 'This is version 3' > /usr/share/nginx/html/index.html
cat build.yaml
apiVersion: batch/v1 kind: Job metadata: name: kaniko spec: template: spec: containers: - name: kaniko image: gcr.io/kaniko-project/executor:latest args: ["--dockerfile=Dockerfile", "--context=git://github.com/bharatmicrosystems/kubernetes-kaniko-nginx.git#refs/heads/master", "--destination=bharamicrosystems/nginx:v3"] volumeMounts: - name: kaniko-secret mountPath: "/kaniko/.docker" restartPolicy: Never volumes: - name: kaniko-secret secret: secretName: regcred items: - key: .dockerconfigjson path: config.json
上面的资源清单build.yaml文件是一个Job控制器。清单使用gcr.io/kaniko-project/executor:latest镜像创建一个容器，并使用以下参数运行它：
docker-file— dockerfile的路径。context— Docker上下文。在这种情况下，我们已经指出了我们的GitHub存储库destination—用于推送构建映像的Docker存储库。
此外，它还会在/kaniko/.docker目录下安装docker config JSON文件以实现docker存储库的身份验证。上面我们已经定义过了。
cat nginx-deployment.yaml
--- apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment namespace: web annotations: fluxcd.io/automated: "true" spec: selector: matchLabels: app: nginx replicas: 2 template: metadata: labels: app: nginx spec: containers: - name: nginx image: bharamicrosystems/nginx:v3 ports: - containerPort: 80
上面是通过deployment部署的nginx，使用的镜像bharamicrosystems/nginx:v3就是我们在build.yaml文件中构建的镜像，将NGINX容器暴露给外部负载均衡器。
cat nginx-service.yaml
apiVersion: v1 kind: Service metadata: name: nginx-service namespace: web spec: selector: app: nginx ports: - port: 80 targetPort: 80 type: NodePort
使用Kaniko构建容器映像
kubectl apply -f build.yaml
验证是否部署成功
kubectl get pod
显示如下说明部署成功：
NAME READY STATUS RESTARTS AGE kaniko-jztf6 1/1 Running 0 66s
查看对应的pod日志，输出如下
kubectl logs kaniko-jztf6 -f
E0523 15:36:17.247145 1 aws_credentials.go:77] while getting AWS credentials NoCredentialProviders: no valid providers in chain. Deprecated. For verbose messaging see aws.Config.CredentialsChainVerboseErrors INFO[0001] Retrieving image manifest nginx INFO[0001] Retrieving image manifest nginx INFO[0002] Built cross stage deps: map[] INFO[0002] Retrieving image manifest nginx INFO[0002] Retrieving image manifest nginx INFO[0003] Executing 0 build triggers INFO[0003] Unpacking rootfs as cmd RUN echo 'This is version 3' > /usr/share/nginx/html/index.html requires it. INFO[0005] RUN echo 'This is version 3' > /usr/share/nginx/html/index.html INFO[0005] Taking snapshot of full filesystem... INFO[0007] Resolving 5400 paths INFO[0008] cmd: /bin/sh INFO[0008] args: [-c echo 'This is version 3' > /usr/share/nginx/html/index.html] INFO[0008] Running: [/bin/sh -c echo 'This is version 3' > /usr/share/nginx/html/index.html] INFO[0008] Taking snapshot of full filesystem... INFO[0008] Resolving 5400 paths
kubectl apply -f nginx-service.yaml
kubectl apply -f nginx-service.yaml
Kaniko一些构建参数
与其他工具的比较
与kaniko相似的工具包括img和orca-build。像kaniko一样，这两个工具都可以从Dockerfiles构建容器映像，但是具有不同的方法和安全性的取舍。img工具在容器中以非特权用户身份构建，而kaniko在容器中以非特权用户身份以root用户身份构建。orca-build工具通过包装runc来执行构建，该runc使用内核命名间隔技术执行RUN命令。通过在容器中以root用户身份执行命令，我们可以在kaniko中完成相同的任务。
