word文檔 如何解密，【徽信；sjk6070】Kubernetes pod 啟動時會拉取用戶指定的鏡像，一旦這個過程耗時太久就會導致 pod 長時間處于 pending 的狀態，從而無法快速提供服務。

鏡像拉取的過程參考下圖所示：

k8s image pull

Pod 的 imagePullPolicy 鏡像拉取策略有三種：

IfNotPresent：只有當鏡像在本地不存在時才會拉取。

Always：kubelet 會對比鏡像的 digest ，如果本地已緩存則直接使用本地緩存，否則從鏡像倉庫中拉取。

Never：只使用本地鏡像，如果不存在則直接失敗。

說明：每個鏡像的 digest 一定唯一，但是 tag 可以被覆蓋。

從鏡像拉取的過程來看，我們可以從以下三個方面來加速鏡像拉取：

縮減鏡像大?。?/p>

使用較小的基礎鏡像、移除無用的依賴、減少鏡像 layer 、使用多階段構建等等。

推薦使用 docker-slim

加快鏡像倉庫與 k8s 節點之間的網絡傳輸速度。

主動緩存鏡像：

Pre-pulled 預拉取鏡像，以便后續直接使用本地緩存，比如可以使用 daemonset 定期同步倉庫中的鏡像到 k8s 節點本地。

題外話 1：本地鏡像緩存多久?是否會造成磁盤占用問題?

本地緩存的鏡像一定會占用節點的磁盤空間，也就是說緩存的鏡像越多，占用的磁盤空間越大，并且緩存的鏡像默認一直存在，并沒有 TTL 機制(比如說多長時間以后自動過期刪除)。

但是，k8s 的 GC 機制會自動清理掉鏡像。當節點的磁盤使用率達到 HighThresholdPercent 高百分比閾值時(默認 85% )會觸發垃圾回收，此時 kubelet 會根據使用情況刪除最舊的不再使用的鏡像，直到磁盤使用率達到 LowThresholdPercent(默認 80% )。

題外話 2：鏡像 layer 層數真的越少越好嗎?

我們經常會看到一些文章說在 Dockerfile 里使用更少的 RUN 命令之類的減少鏡像的 layer 層數然后縮減鏡像的大小，layer 越少鏡像越小這確實沒錯，但是某些場景下得不償失。首先，如果你的 RUN 命令很大，一旦你修改了其中某一個小的部分，那么這個 layer 在構建的時候就只能重新再來，無法使用任何緩存;其次，鏡像的 layer 在上傳和下載的過程中是可以并發的，而單獨一個大的層無法進行并發傳輸。

審核編輯：湯梓紅