更新2019-06-24

根据@Jodiug注释，如果你的版本是1.15，你可以使用命令:

kubectl rollout restart deployment/demo

阅读更多关于这个问题的内容:

https://github.com/kubernetes/kubernetes/issues/13488

在kubernetes的GitHub项目上有一个关于这个主题的有趣讨论。参见问题:https://github.com/kubernetes/kubernetes/issues/33664

从这里所描述的解决方案来看，我建议两种方案中的一种。

第一个

1.准备部署

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: demo
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: demo
    spec:
      containers:
      - name: demo
        image: registry.example.com/apps/demo:master
        imagePullPolicy: Always
        env:
        - name: FOR_GODS_SAKE_PLEASE_REDEPLOY
          value: 'THIS_STRING_IS_REPLACED_DURING_BUILD'

2.部署

sed -ie "s/THIS_STRING_IS_REPLACED_DURING_BUILD/$(date)/g" deployment.yml
kubectl apply -f deployment.yml

第二(一行):

kubectl patch deployment web -p \
  "{\"spec\":{\"template\":{\"metadata\":{\"labels\":{\"date\":\"`date +'%s'`\"}}}}}"

当然，在这两种情况下都需要imagePullPolicy: Always。

您可以为pod配置一个宽限期(例如30秒或更长时间，这取决于容器启动时间和映像大小)，并设置“imagePullPolicy: "Always"。并使用kubectl delete pod pod_name。 将创建一个新容器，并自动下载最新的映像，然后终止旧容器。

例子:

spec:
  terminationGracePeriodSeconds: 30
  containers:
  - name: my_container
    image: my_image:latest
    imagePullPolicy: "Always"

我目前正在使用Jenkins进行自动构建和图像标记，它看起来像这样:

kubectl --user="kube-user" --server="https://kubemaster.example.com"  --token=$ACCESS_TOKEN set image deployment/my-deployment mycontainer=myimage:"$BUILD_NUMBER-$SHORT_GIT_COMMIT"

另一个技巧是初始运行:

kubectl set image deployment/my-deployment mycontainer=myimage:latest

然后:

kubectl set image deployment/my-deployment mycontainer=myimage

它实际上会触发滚动更新，但要确保您还设置了imagePullPolicy: "Always"。

更新:

我发现的另一个不需要更改图像名称的技巧是更改将触发滚动更新的字段的值，如terminationGracePeriodSeconds。您可以使用kubectl edit deployment your_deployment或kubectl apply -f your_deployment来实现这一点。Yaml或使用这样的补丁:

kubectl patch deployment your_deployment -p \
  '{"spec":{"template":{"spec":{"terminationGracePeriodSeconds":31}}}}'

只要确保你总是改变数字值。

kubectl rollout restart deployment myapp

这是当前触发滚动更新并保留旧副本集的方式，用于kubectl rollout提供的其他操作(如回滚)。

我正在使用Azure DevOps来部署容器化应用程序，我很容易通过使用构建ID来克服这个问题

每次构建并生成新的Build ID时，我使用这个Build ID作为docker image的标记

映像名称：生成标识

一旦你的映像成功构建(CI)，在CD管道在部署yml文件我给映像名称为

映像名称：环境：构建ID

buildid是azure devops变量，其值为build ID。

所以现在每次我有新的更改要构建(CI)和部署(CD)。

如果您需要CI/CD的构建定义，请评论。

我使用Gitlab-CI构建映像，然后将其直接部署到GCK。如果使用一个巧妙的小技巧来实现滚动更新，而不改变容器的任何实际设置，即将标签更改为当前的commit-short-sha。

我的命令如下所示:

kubectl patch deployment my-deployment -p "{\"spec\":{\"template\":{\"metadata\":{\"labels\":{\"build\":\"$CI_COMMIT_SHORT_SHA\"}}}}}}"

在这里，您可以使用标签的任何名称和任何值，只要它随每次构建而更改。

玩得开心!

另一个更适合调试但值得一提的选项是检查你的版本的修订历史:

$ kubectl rollout history deployment my-dep
deployment.apps/my-dep
 
REVISION  CHANGE-CAUSE
1         <none>
2         <none>
3         <none>

要查看每个修订的详细信息，请运行:

 kubectl rollout history deployment my-dep --revision=2

然后运行以下命令返回到之前的版本:

 $kubectl rollout undo deployment my-dep --to-revision=2

然后再回到新的地方。 比如运行ctrl+z -> ctrl+y (:

(*) CHANGE-CAUSE是<none>，因为你应该像这里提到的——record标志一样运行更新:

kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1 --record

(**)有一个关于弃用这个标志的讨论。