正文
摘要
前面一部分学习了 buildkit的简单搭建
也学习会了如果build images的简单处理
但是搭建镜像只是万里长征第一步.
如何进行微服务部署,才是关键的第二步.
公司最近使用基于K3S的K8S发行版
基于此 准备进行下一步的学习
简单结论
Buildkit 能够极大的减少镜像的大小
并且能够提高导入和导出的效率.
但是ctr 和 k3s ctr 虽然命名空间名字一样
但是没法打通, 需要找K3S的原厂沟通确认.
遇到的坑
我这边安装完buildkit 使用 ctr 命令
ctr ns ls
NAME LABELS
buildkit
k8s.io
和安装完k3s 只有使用的命令
k3s ctr ns ls
NAME LABELS
k8s.io
结果是完全不一样的
两个命令空间完全不相同
联系了下同事也没解决狗这个问题. 所以准备还是使用原始额导入导出的方式.
说明一下镜像信息
使用 docker build的OpenJDk的镜像大小为: 388MB
但是使用 buildkit 构建的镜像大小为: 167.4M
大小了巨大的缩减
同样的我们基于我们环境搭建的镜像:
[+] Building 642.9s (8/8) FINISHED
大小为: 2.5 GiB
但是用docker搭建的镜像为:
real 14m59.480s
大小为: 5.98 GB
注意两个机器的配置稍有不同.
执行导入和导出的速度
buildkit方式导出:
time ctr -n k8s.io i export /myapp/myapp2211.tar.gz docker.io/library/myapp2211
real 1m35.661s
user 0m50.195s
sys 0m25.067s
总用量 2.5G
不同机器Docker方式导出:
#注意不能使用这种方式导出. K3S不认这种导出的介质
#time docker save myapp2211 |gzip > myapp2211.tar.gz
# 可以使用 -o 的方式来处理, 不能会报错:ctr: archive/tar: invalid tar header
time docker save myapp2211 -o myapp2211_docker.tar.gz
real 2m26.156s
user 0m2.280s
sys 0m5.578s
总用量 5.7G
K3S执行导入
导入 buildkit的镜像时间:
time k3s ctr i import /myapp/myapp2211.tar.gz
real 1m46.226s
user 0m11.998s
sys 0m4.479s
同一个机器导入 buildkit的镜像时间:
time k3s ctr images import /myapp2211_docker.tar.gz
5.7G的镜像最终报错了. 原因不明.
构建deployment 进行验证
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: myapp
name: myapp-deployment
namespace: default
spec:
replicas: 1
selector:
matchLabels:
app: myapp
template:
metadata:
labels:
app: myapp
spec:
containers:
- image: docker.io/library/myapp2211
imagePullPolicy: Never
ports:
- containerPort: 5200
name: myapp
服务运行情况
kubectl apply -f myapp-deployment.yaml
kubectl get pods
NAME READY STATUS RESTARTS AGE
myapp-deployment-79cc44bbb5-wv9xc 1/1 Running 0 2m39s
kubectl logs -f xxxxpods
运行信息
PROCESSOR_ARCH: ${PROCESSOR_ARCHITECTURE}
JAVA_HOME: /opt/java/openjdk
JAVA_VERSION: 1.8.0_292
IGIX_SERVER_HOME: ${XXXX_SERVER_HOME}
SPRING BOOT: 2.4.13 (v2.4.13)
ACTIVE PROFILES: prod
PROCESS ID: 1
TotalMemorySize ${TotalMemorySize}
-------------------------------------------------------
