加速Kubernetes镜像拉取当一个Kubernetespod启动时，它会拉取用户指定的镜像。一旦这个过程耗时过长，pod就会长期处于pending状态，无法快速提供服务。镜像拉取流程如下图所示：PodimagePullPolicy镜像拉取策略共有三种：IfNotPresent：只有本地不存在的镜像才会被拉取。always：kubelet会比较镜像的摘要，如果在本地缓存，则直接使用本地缓存，否则从镜像仓库中拉取。Never：只使用本地镜像，不存在则直接失败。注意：每个图像的摘要必须是唯一的，但标签可以被覆盖。从镜像拉取过程来看，我们可以从以下三个方面加快镜像拉取速度：减小镜像大小：使用更小的基础镜像，去除无用的依赖，减少镜像层数，使用多阶段构建等。推荐使用docker-slim来加快镜像仓库与k8s节点之间的网络传输速度。Activecachemirroring：Pre-pull预拉镜像，方便以后直接使用本地缓存。比如可以使用daemonset将仓库中的镜像周期性的同步到本地的k8s节点上。题外话1：本地图片缓存多长时间？它会导致磁盘使用问题吗？本地缓存的图片肯定会占用节点的磁盘空间，也就是说缓存的图片越多，占用的磁盘空间就越大，而且缓存的图片默认一直存在，没有TTL机制（比如多久后会自动过期删除）。但是k8s的GC机制会自动清理镜像。当节点的磁盘使用率达到HighThresholdPercent高百分比阈值（默认85%）时，将触发垃圾回收。此时kubelet会根据使用情况删除最早不再使用的image，直到磁盘使用率达到LowThresholdPercent（默认80%）。题外话2：镜像层越少越好吗？我们经常看到一些文章在Dockerfile中使用较少的RUN命令来减少镜像的层数，进而减小镜像的大小。诚然，层数越少，图像越小，但在某些场景下是得不偿失的。首先，如果你的RUN命令非常大，一旦你修改了其中的一小部分，图层构建时只能重新启动，不能使用缓存；其次，镜像层是上传和下载。可以并发，但是不能并发传输单个大层。
