在 Kubernetes (k8s) 中,Pod 容器镜像的拉取策略通过 imagePullPolicy
属性来控制。这一策略决定了 kubelet 如何以及何时从容器镜像仓库中拉取镜像。以下是三种主要的镜像拉取策略及其详细说明:
- Always:
- 说明: 这是默认的拉取策略。当设置为
Always
时,kubelet 在每次创建 Pod 或者重启容器时,无论本地节点上是否已存在该镜像,都会尝试从镜像仓库中拉取最新的镜像。这确保了你总是使用仓库中最新的镜像版本,但可能会导致不必要的网络流量和拉取时间,尤其是在频繁重启容器的场景下。 - 适用场景: 对于那些需要保证运行时镜像总是最新版本的应用特别有用,例如持续集成/持续部署(CI/CD)环境或对安全性要求极高的应用。
- IfNotPresent:
- 说明: 当设置为
IfNotPresent
时,kubelet 首先检查本地节点上是否已存在指定的镜像。如果存在,就直接使用本地镜像;如果不存在,则会从镜像仓库中拉取。这种方式可以减少不必要的镜像拉取操作,加快启动速度,同时节省网络带宽。 - 适用场景: 对于开发环境、测试环境或生产环境中不经常更新镜像的服务来说,此策略较为合适。它能够利用缓存提高效率,同时保持一定的灵活性。
- Never:
- 说明: 当设置为
Never
时,kubelet 不会试图从镜像仓库拉取镜像,仅使用节点上已有的镜像。如果本地节点缺少请求的镜像,Pod 将无法启动,并报告错误。 - 适用场景: 这个策略适用于那些完全离线部署的环境,或者确信节点上已预先放置好所有所需镜像的场景。此策略可以确保绝对不与外部网络交互以获取镜像,增加安全性,但同时也限制了动态更新镜像的能力。
你可以针对每个容器单独设置 imagePullPolicy
,或者在不显式设置时,默认采用镜像标签决定策略(例如,如果镜像是 :latest
标签,则默认为 Always
,其他具体标签则可能为 IfNotPresent
)。理解并正确配置这些策略对于优化 Kubernetes 集群的运行效率、安全性和资源管理至关重要。
如何不配置imagePullPolicy
,默认是什么?
在 Kubernetes 中,如果没有在 Pod 的 YAML 配置文件中明确设置 imagePullPolicy
,其默认值取决于容器镜像的标签:
- 如果容器镜像的标签是
:latest
或者没有明确指定标签(即默认为:latest
),那么默认的imagePullPolicy
是Always
。这意味着每次创建或重启 Pod 时,Kubernetes 都会尝试从注册表中拉取最新的镜像。 - 对于带有明确标签(而非
:latest
)的镜像,例如:v1.0
,默认的imagePullPolicy
往往是IfNotPresent
。这意味着 kubelet 会检查本地是否存在该镜像,如果存在则使用,否则从注册表拉取。
修改pod imagePullPolicy
方法
要修改已运行 Pod 的 imagePullPolicy
为 Always
,不能直接修改正在运行的 Pod,因为 Kubernetes 的 Pod 对象是不可变的。你需要采取以下步骤:
- 修改 Deployment 或 StatefulSet (或其他控制器) 的 YAML:如果你的 Pod 是由 Deployment、StatefulSet、DaemonSet 或其他控制器管理的,你需要编辑对应的 YAML 文件。找到容器定义的部分,添加或修改
imagePullPolicy
字段为Always
。例如:
test.yaml
apiVersion: apps/v1
kind: Deployment
meta
name: test-app
spec:
replicas: 5
template:
meta
labels:
app: test-app
spec:
containers:
- name: test-container
image: test-image:1.9
imagePullPolicy: Always # 添加或修改此行
- 应用更新:保存 YAML 文件后,使用
kubectl apply -f test.yaml
命令来应用更改。这将会更新 Deployment(或相应的控制器),并按照新的imagePullPolicy
设置滚动更新 Pod。 - 验证更改:使用
kubectl describe pod <pod-name>
命令检查 Pod 的详细信息,确认imagePullPolicy
已经被正确设置为Always
。同时,注意观察 Pod 是否有因更新而重新调度和启动的情况。
请注意,直接管理的静态 Pod
(即不是由控制器管理的 Pod)需要先删除原有 Pod,然后使用更新了 imagePullPolicy
设置的新 YAML 文件重新创建。但这种方式不推荐,因为它缺乏自我修复能力,推荐使用控制器来管理 Pod。