我有以下复制控制器在Kubernetes上的GKE:

apiVersion: v1
kind: ReplicationController
metadata:
  name: myapp
  labels:
    app: myapp
spec:
  replicas: 2
  selector:
    app: myapp
    deployment: initial
  template:
    metadata:
      labels:
        app: myapp
        deployment: initial
    spec:
      containers:
      - name: myapp
        image: myregistry.com/myapp:5c3dda6b
        ports:
        - containerPort: 80
      imagePullPolicy: Always
      imagePullSecrets:
        - name: myregistry.com-registry-key

现在,如果我说

kubectl rolling-update myapp --image=us.gcr.io/project-107012/myapp:5c3dda6b

执行滚动更新,但不重新拉取。为什么?


当前回答

要么你已经手动删除了所有的豆荚,以再次拉出图像来重新创建。

or

运行下面的命令 Kubectl rollout重启deploy /deployment_name Kubectl rollout重启部署/nginx

这个命令应该重新创建所有的pod。

对于这两种情况,imagepullPolicy应该设置为Always。

其他回答

当给定映像参数时,滚动更新命令假定映像与复制控制器中当前存在的映像不同。

如果你想在特定的pod上执行直接的图像更新,你也可以使用kubectl set image。

https://kubernetes.io/docs/concepts/workloads/controllers/deployment/

这个答案的目的是在节点已经下载了同名图像的情况下强制拉取图像,因此即使您将新图像推到容器注册表中,当您启动一些pod时,您的pod会显示“image already present”。

对于Azure容器注册表中的一个案例(可能AWS和GCP也提供了这个):

您可以查看Azure容器注册表,通过检查清单创建日期,可以确定哪个映像是最近的映像。 然后,复制它的摘要散列(格式为sha256:xxx…xxx)。 您可以通过运行下面的命令来缩小当前的副本。注意,这显然会停止容器并导致停机。

kubectl scale --replicas=0 deployment <deployment-name> -n <namespace-name>

然后您可以获得部署的副本。通过运行Yaml:

kubectl get deployments.apps <deployment-name> -o yaml > deployment.yaml

然后将带有图像字段的行从<image-name>:<tag>更改为<image-name>@sha256:xxx…Xxx,保存文件。 现在你可以再次放大你的复制品了。新图片将以其独特的摘要被拉出。

注意:假设imagePullPolicy: Always字段存在于容器中。

有一个命令可以直接这样做:

创建一个新的kubectl rollout restart命令,用于滚动重新启动部署。

pull请求被合并了。它是1.15(更新日志)或更高版本的一部分。

现在,命令kubectl rollout restart deploy your - deployment结合imagePullPolicy: Always策略将允许您使用最新版本的映像重新启动所有pod。