前言

通常情况下，我们在使用dockerfile构建镜像的时候要与Docker后台进程交互访问，也就是需要本机root权限。如果是在Docker后台进程无法暴露的场景下，生成容器镜像就变得很困难。kaniko是Google开源的一个工具，可以帮助开发及运维人员从容器或Kubernetes集群内的Dockerfile构建容器镜像，而无需访问Docker守护程序。这样，您可以在容器内执行构建作业，而无需授予对主机文件系统的任何访问权限，你只需要将构建清单创建为Kubernetes批处理作业，然后使用你选择的任何CI工具将其应用于集群。该工作负责构建映像并将其上传到指定的容器注册表。

kaniko的工作方式

1.读取指定的Dockerfile。

2.将基本映像（在FROM指令中指定）提取到容器文件系统中。

3.在独立的Dockerfile中分别运行每个命令。

4.每次运行后都会对用户空间文件系统的做快照。

5.每次运行时，将快照层附加到基础层。

kaniko工作原理

kaniko作为一个容器镜像运行，它接受三个参数：一个 Dockerfile ，一个构建上下文以及将镜像推送到的注册表。它在执行程序镜像中提取基本镜像的文件系统。然后，在Dockerfile中执行任何命令，快照用户空间中的文件系统。Kaniko在每个命令后都会将一层已更改的文件附加到基本镜像。最后，执行程序将新镜像推送到指定的注册表。由于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-username= --docker-password= --docker-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更新nginx-deployment.yaml和nginx-service.yaml

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中完成相同的任务。

往期精彩文章

kubernetes全栈技术+企业案例演示【带你快速掌握和使用k8s】

kubernetes面试题汇总

DevOps视频和资料免费领取

kubernetes技术分享-可用于企业内部培训

谈谈我的IT发展之路

kubernetes系列文章第一篇-k8s基本介绍

kubernetes系列文章第二篇-kubectl

了解pod和pod的生命周期-这一篇文章就够了

Kubernetes中部署MySQL高可用集群

Prometheus+Grafana+Alertmanager搭建全方位的监控告警系统-超详细文档

k8s1.18多master节点高可用集群安装-超详细中文官方文档

k8s中蓝绿部署、金丝雀发布、滚动更新汇总

运维常见问题汇总-tomcat篇

关于linux内核参数的调优，你需要知道

kubernetes持久化存储volume

kubernetes挂载ceph rbd和cephfs

报警神器Alertmanager发送报警到多个渠道

jenkins+kubernetes+harbor+gitlab构建企业级devops平台

kubernetes网络插件-flannel篇

kubernetes网络插件-calico篇

kubernetes认证、授权、准入控制

限制不同的用户操作k8s资源

面试真题&技术资料免费领取-覆盖面超全~

Prometheus监控MySQL

Prometheus监控Nginx

Prometheus监控Tomcat

linux面试题汇总

测试通过storageclass动态生成pv

通过编写k8s的资源清单yaml文件部署gitlab服务

helm安装和使用-通过helm部署k8s应用

Prometheus Operator-上篇-安装和使用篇

Prometheus Operator-下篇

通过kubeconfig登陆k8s的dashboard ui界面

通过token令牌登陆k8s dashboard ui界面

kubernetes集群的etcd数据库详细介绍

Linux网络流量监控工具

kubernetes搭建EFK日志管理系统

prometheus operator监控k8s集群之外的haproxy组件

kubernetes ConfigMap存储卷

技术交流群
学无止境，了解更多关于kubernetes/docker/devops/openstack/openshift/linux/IaaS/PaaS相关内容，想要获取更多资料和免费视频，可按如下方式进入技术交流群

原文链接：https://blog.csdn.net/weixin_38320674/article/details/107650424?utm_medium=distribute.pc_feed.none-task-blog-personrec_tag-4.nonecase&depth_1-utm_source=distribute.pc_feed.none-task-blog-personrec_tag-4.nonecase&request_id=5f384d10b51ffe58eedc1b0a