更新 Kubernetes 中的部署映像答案

【问题标题】：Update a Deployment image in Kubernetes更新 Kubernetes 中的部署映像
【发布时间】：2017-06-03 19:12:16
【问题描述】：

我对 Kubernetes 非常陌生，使用的是 k8s v1.4、Minikube v0.15.0 和 Spotify maven Docker 插件。
我项目的构建过程会创建一个 Docker 镜像，并直接推送到 Minikube 的 Docker 引擎中。

Pod 由我创建的 Deployment 创建（使用副本集），策略设置为 type: RollingUpdate。

我在文档中看到了这一点：

注意：当且仅当 Deployment 的 pod 模板（即 .spec.template）发生更改时才会触发 Deployment。

我正在寻找一种简单的方法/解决方法来自动化流程：构建触发 > 推送新的 Docker 映像（不更改版本） > 部署将更新 pod > 服务将公开新的 pod。

【问题讨论】：

如果你根本不改变镜像，那么没有办法确保你在每个 pod 中获取新镜像，除非你设置 ImagePullPolicy: Always 并杀死每个 pod 并进行部署重新创建它。但是，如果您每次都创建一个新的 docker 镜像，那么更新标签也是有意义的。
@AnirudhRamanathan 因为我不是每次都创建一个“新”图像，只是更新图像，我将采用第一种方法，所以有一种方法可以自动杀死旧的 pod？
ImagePullPolicy: Always 不适用于本地图像，因此同时我手动删除具有特定标签的 pod，然后副本集使用更新的图像创建它们。想知道是否有任何方法可以自动完成。

标签： docker kubernetes minikube

【解决方案1】：

如果不更改容器映像名称或标签，您只需将应用程序缩放到 0 并返回到原始大小，例如：

kubectl scale --replicas=0 deployment application
kubectl scale --replicas=1 deployment application

正如 cmets 中所述，ImagePullPolicy: Always 是您的配置所必需的。

在更改图像时，我发现这是更新图像最直接的方式

kubectl set image deployment/application app-container=$IMAGE

不更改图像会导致您在出现问题时无能为力。因此，我不建议在开发环境之外使用它。

编辑：小奖励 - 前后保持比例同步可能看起来......喜欢：

replica_spec=$(kubectl get deployment/applicatiom -o jsonpath='{.spec.replicas}')
kubectl scale --replicas=0 deployment application
kubectl scale --replicas=$replica_spec deployment application

干杯

【讨论】：

有办法用 Kubernetes API 做同样的事情吗？
你好 - 见：stackoverflow.com/questions/41792851/…
如果您先缩小再放大，您的应用程序不会停机吗？如果是，我怎样才能避免停机？
是的，有停机时间 - 这是 2017 年的答案，还有其他方法可以触发更新，例如kubectl rollout restart ...

【解决方案2】：

如果您至少有 1.15 版本，请使用以下功能

kubectl rollout restart deployment/deployment-name

在此处了解更多信息kubectl rollout restart

【讨论】：

对我来说实际上是kubectl rollout restart deploy <name>。

【解决方案3】：

我很好奇您为什么不更改图像版本（：

另一个选项（除了kubectl rollout restart）是使用kubectl patch：

kubectl patch deployment name -p "{\"spec\":{\"template\":{\"metadata\":{\"labels\":{\"version\":\"$BUILD_SHA_OR_DATE\"}}}}}}"

使用此命令，您可以灵活地更改部署规范中的特定字段，例如 标签选择器、pod 标签、环境变量等'

(*) 另一个更适合调试但值得一提的选项是检查您的推出的修订历史记录：

$ kubectl rollout history deployment my-dep
deployment.apps/my-dep
 
REVISION  CHANGE-CAUSE
2         <none>
4         <none>
5         <none>
6         <none>
11        <none>
12        <none>

然后通过运行返回到上一个版本：

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

然后回到新的。

(**) CHANGE-CAUSE 是<none>，因为您应该使用--record 标志运行更新——就像提到的here：

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

(***) 有一个 discussion 关于弃用此标志。

【讨论】：

在我的情况下，当从同一个分支部署开发/暂存环境时，我们不会更改映像版本。标签/版本只是分支蛞蝓。这样我们就可以更轻松地进行清理并节省注册表空间。但我全心全意寻找更好的方法:)
我推荐使用 git commit（或者像我一样的前 8 位）作为图像标签，这样你可以很容易地找到相应的提交，并强制 k8s 获得正确的版本。注意：如果您只是更改图像中应用程序的 src，则注册表中占用的空间将只是 src 的大小，而不是图像的完整大小