乐趣区

关于k8s:加速-Kubernetes-镜像拉取

减速 Kubernetes 镜像拉取

Kubernetes pod 启动时会拉取用户指定的镜像,一旦这个过程耗时太久就会导致 pod 长时间处于 pending 的状态,从而无奈疾速提供服务。

镜像拉取的过程参考下图所示:

Pod 的 imagePullPolicy 镜像拉取策略有三种:

  • IfNotPresent:只有当镜像在本地不存在时才会拉取。
  • Always:kubelet 会比照镜像的 digest,如果本地已缓存则间接应用本地缓存,否则从镜像仓库中拉取。
  • Never:只应用本地镜像,如果不存在则间接失败。

阐明:每个镜像的 digest 肯定惟一,然而 tag 能够被笼罩。


从镜像拉取的过程来看,咱们能够从以下三个方面来减速镜像拉取:

  1. 缩减镜像大小:
    应用较小的根底镜像、移除无用的依赖、缩小镜像 layer、应用多阶段构建等等。
    举荐应用 docker-slim
  2. 放慢镜像仓库与 k8s 节点之间的网络传输速度。
  3. 被动缓存镜像:
    Pre-pulled 预拉取镜像,以便后续间接应用本地缓存,比方能够应用 daemonset 定期同步仓库中的镜像到 k8s 节点本地。

题外话 1:本地镜像缓存多久?是否会造成磁盘占用问题?

本地缓存的镜像肯定会占用节点的磁盘空间,也就是说缓存的镜像越多,占用的磁盘空间越大,并且缓存的镜像默认始终存在,并没有 TTL 机制(比如说多长时间当前主动过期删除)。

然而,k8s 的 GC 机制会主动清理掉镜像。当节点的磁盘使用率达到 HighThresholdPercent 高百分比阈值时(默认 85%)会触发垃圾回收,此时 kubelet 会依据应用状况删除最旧的不再应用的镜像,直到磁盘使用率达到 LowThresholdPercent(默认 80%)。

题外话 2:镜像 layer 层数真的越少越好吗?

咱们常常会看到一些文章说在 Dockerfile 里应用更少的 RUN 命令之类的缩小镜像的 layer 层数而后缩减镜像的大小,layer 越少镜像越小这的确没错,然而某些场景下得失相当。首先,如果你的 RUN 命令很大,一旦你批改了其中某一个小的局部,那么这个 layer 在构建的时候就只能从新再来,无奈应用任何缓存;其次,镜像的 layer 在上传和下载的过程中是能够并发的,而独自一个大的层无奈进行并发传输。

退出移动版