ifnotpresent 有时更慢，因需本地检查镜像元数据，触发完整解析与校验；多层碎片化时 stat 和 tar 前校验开销大；:latest 或无 tag 镜像会被强制设为 always。
镜像拉取策略设为 IfNotPresent 为什么有时反而更慢？
因为 K8s 会先检查本地是否存在镜像，而这个检查在某些容器运行时（如 containerd）可能触发一次完整的镜像元数据解析，比直接从 registry 拉取还重；尤其当节点上镜像层多、overlayfs 元数据碎片化时，stat 和 tar 解包前的校验开销明显上升。
- 默认
imagePullPolicy: IfNotPresent只对:latest或无 tag 镜像无效——K8s 强制设为Always，这点常被忽略 - 如果镜像用语义化版本（如
v1.2.3）且确定不会复用旧层，Never可跳过所有远程和本地检查，但要求镜像已预装到所有节点 -
Always在 registry 响应快、镜像层缓存命中率高时，实际延迟可能低于IfNotPresent，尤其搭配registry mirror和pull-through cache
如何让 Always 策略真正“快”起来？
关键不在策略本身，而在绕过冗余校验和加速层传输。K8s 不控制拉取逻辑，它依赖底层 CRI（如 containerd）；优化点集中在运行时配置和镜像构建阶段。
- 在 containerd 的
/etc/containerd/config.toml中启用disable_snapshot_platform_check = true，避免每次拉取都校验平台兼容性（尤其多架构镜像） - 使用
buildkit构建镜像时加--cache-from和--cache-to，让 layer digest 更稳定，提升 registry 层级缓存命中率 - 避免在
Dockerfile中用COPY . /app这类大体积无差别拷贝——它会让哪怕一行代码改动都失效整个 layer，导致Always下必须拉完整新层
imagePullSecrets 配置错误导致的隐性超时怎么定位？
错误不是报 Unauthorized 就完事——很多私有 registry 在认证失败时会故意延迟响应（防暴力探测），K8s 默认等待 30 秒才超时，这期间 Pod 卡在 Pending，日志里只显示 ContainerCreating，非常难关联到凭证问题。
- 用
kubectl describe pod <name></name>查看 Events，重点找Failed to pull image后是否跟了context deadline exceeded -
imagePullSecrets必须和 Pod 在同一 namespace，且 secret 类型必须是kubernetes.io/dockerconfigjson，名字拼错或 base64 编码损坏都会静默失败 - 临时验证：在目标节点手动运行
crictl pull --creds user:pass registry.example.com/app:v1.2.3，能快速区分是网络、权限还是配置问题
Golang 应用镜像瘦身对启动延迟的实际影响有多大？
镜像体积本身不直接影响拉取时间，但间接决定层传输量和解压耗时；Golang 静态编译二进制 + 多阶段构建可砍掉 90% 以上体积，效果立竿见影。
立即学习“go语言免费学习笔记（深入）”；
- 别用
golang:alpine作为最终镜像基础——它仍含 apk、ca-certificates 等无关文件；用scratch或distroless/static更干净 - 开启 Go 编译的
-ldflags="-s -w"，去掉调试符号和 DWARF 信息，通常减小 15–30% 二进制体积 - 注意：如果用了 cgo（如访问系统 DNS 或 OpenSSL），就不能用
scratch，否则运行时报no such file or directory——这是最常踩的坑
真正卡住启动的，往往不是“拉多大”，而是“拉哪几层”和“解哪几层”。Golang 二进制单层镜像 + 正确的 pull policy + 运行时缓存配置，三者缺一不可；少配一个，前面优化全白费。
