由于镜像拉取不到，下载到本地后修改Tag依然无法生效

如题，在这里折腾了好久，下载镜像后，修改TAG为tiller需要的那个镜像，仍然不生效。

最终只能通过修改deployment里面的镜像源。

不仅是K8S拉不到镜像，我直接用docker pull 我已经改过Tag后的镜像，它依然是去对应的官网去下载了。

请老师答疑解惑，虽然问题解决了，但是镜像这里实在是不明白为什么。

Mr_Raymond 2020-08-30

源自：容器编排-K8S 1-18 【性能监控Demo】rometheus时间序列监控，知其然

收起

2回答

张飞扬回答被采纳获得+3积分 2020-08-30 23:02:08

具体步骤截屏发出来看下？

收起回答

Mr_Raymond 提问者 #1

[root@k8s-master ~]# kubectl get pods --namespace kube-system NAME READY STATUS RESTARTS AGE tiller-deploy-589d7d9489-clmc5 0/1 ErrImagePull 0 33s [root@k8s-master ~]# kubectl describe pod tiller-deploy-589d7d9489-clmc5 --namespace=kube-system Back-off pulling image "gcr.io/kubernetes-helm/tiller:v2.16.10" [root@k8s-master ~]# docker pull registry.cn-hangzhou.aliyuncs.com/google_containers/tiller:v2.16.10 # 修改镜像Tag [root@k8s-master ~]# docker tag registry.cn-hangzhou.aliyuncs.com/google_containers/tiller:v2.16.10 gcr.io/kubernetes-helm/tiller:v2.16.10 [root@k8s-master ~]# docker images REPOSITORY TAG IMAGE ID CREATED SIZE gcr.io/kubernetes-helm/tiller v2.16.10 296a2861ce90 2 weeks ago 88.1MB [root@k8s-master ~]# docker pull gcr.io/kubernetes-helm/tiller:v2.16.10 Error response from daemon: Get https://gcr.io/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

2020-08-30 23:10:15
张飞扬 #2

讲QQ群的讨论总结如下： 1. 用Docker run就不会重新下载了。docker pull每次都要去对比下远端和本地的digest，一致的话就不会下载，远端查不到就报错。 2. K8s 改一下container的参数imagePullPolicy为Never 或者IfNotPresent都可以确保优先使用本地镜像。 3. 本地image可以在master和各个node上运行docker images查看。本次问题，发现是有node节点没有提前准备好本地镜像导致，所以K8S根据IfNotPresent规则使用远端镜像了。

2020-08-31 08:42:20

提问者 Mr_Raymond 2020-08-31 13:18:04

感谢飞扬老师的指导，总结分享一下：

环境： 3台虚拟机，分别是master slave1 slave2，K8S版本1.16.0

场景： helm init，tiller server服务启动不起来。发现gcr.io/kubernetes-helm/tiller:v2.16.10 镜像拉取不到，于是尝试在master节点从阿里云下载镜像

docker pull registry.cn-hangzhou.aliyuncs.com/google_containers/tiller:v2.16.10

因为tiller依赖的镜像名不一致，所以尝试修改阿里云镜像tag

docker tag registry.cn-hangzhou.aliyuncs.com/google_containers/tiller:v2.16.10 gcr.io/kubernetes-helm/tiller:v2.16.10

同时把阿里云的镜像删除 -- 因为这一步操作，阴差阳错，让我最后发现了问题。

docker rmi registry.cn-hangzhou.aliyuncs.com/google_containers/tiller:v2.16.10

此时发现tiller server依然无法启动。

查看tiller-deploy的配置

kubectl edit deployment tiller-deploy -n kube-system
containers:
        image: gcr.io/kubernetes-helm/tiller:v2.16.10
        imagePullPolicy: IfNotPresent

imagePullPolicy 为 IfNotPresent，会优先使用本地镜像，可是为什么还是拉取不到呢？

尝试修改tiller-deploy的镜像地址为阿里云地址

containers:
        image: registry.cn-hangzhou.aliyuncs.com/google_containers/tiller:v2.16.10
        imagePullPolicy: IfNotPresent

然后，tiller-server成功启动，虽然启动成功，但心中依然有着很多的疑问点。

由于之前删除了阿里云的镜像，此时在master节点，查看docker images，发现并没有阿里云的镜像！这有问题。后来，在slave1和slave2上分别查看docker images，最后在slave2上发现有阿里云的镜像。到这里，突然就明白了: 我只在master节点进行了一通操作，但实际上tiller-server可能并不部署在master节点上。

为了验证想法，修改tiller-deploy的地址为原地址gcr.io/kubernetes-helm/tiller:v2.16.10，重新部署了几次：当tiller server部署到master节点时，成功；当tiller server部署到slave1、slave2时都失败 -- 镜像拉取不到。

这说明：修改tag是有效的，imagePullPolicy的IfNotPresent也是按预期工作的，但是 - 只有master节点有这个镜像。

接下来，在所有节点上都使用同样的方法拉取阿里云镜像并修改tag，此时不管重新deploy多少次，都是成功的。

总结：

当镜像拉不到的时候，通过docker从其他镜像源拉取同样的镜像，并修改tag是可行的
确保每一个节点都有这个镜像 -- 如果deployment没有选择指定的node来部署
检查deployment文件的镜像拉取策略 imagePullPolicy如果是always，上面的修改也是无效的，需要修改为IfNotPresent(优先使用本地镜像)或Never(只使用本地镜像)
deployment没有特别指定的时候，会随机部署在集群的某个节点上。
小插曲，我修改阿里云镜像tag为原镜像后，继续尝试用docker pull 原镜像，发现还是去原镜像的官网拉取镜像。这是因为docker pull 每次都要去对比远端镜像和本地镜像的digest，一致的话就不会下载，查不到就报错。