Kubernetes Engine-Pod部署未更新为最新映像

Question

我正在关注Google Cloud Platform的本教程：https://cloud.google.com/kubernetes-engine/docs/tutorials/hello-app。基本上，我从Github在Google Cloud（使用Google Cloud Shell）和本地机器上都克隆了示例hello-app项目，因为我想练习同时使用云方法和本地计算机（使用Google Cloud）来完成本教程。 SDK）-然后将Docker映像推送到云中，然后在Kubernetes上构建并运行它。

1-我的第一个步骤是在进入步骤8时，将源代码字符串从“ Hello，World”更改为“ Hello，world！”。版本2”，以及Go文件中的字符串“版本：1.0.0”至“版本：2.0.0”，基本上是以下几行：

fmt.Fprintf(w, "Hello, world! Version 2\n")
fmt.Fprintf(w, "Version: 2.0.0\n")

我意识到我更改了本地计算机上的源代码（而不是云上的源代码）。然后，我进入控制台中的Google Cloud Shell，重新构建带有v2标签的Docker映像，然后将其推送到Google Container Registry（没有意识到我正在从存储的未更改代码项目中构建映像在云端上，而不是在我的本地计算机上）。当我使用kubectl通过图像更新对现有部署进行滚动更新时，毫不奇怪，它没有用。 因此，基本上要解决此问题，我需要从本地计算机上（已更改）的源代码项目构建映像，并将该映像推送到Google Container Registry（使用Google Cloud SDK Shell）。这就是理论（我至少是从我的理解出发）。考虑到上一步完成的操作，我创建了一个具有完全相同标签（即v2）的图像，请记住，容器注册表中已经存储了v2图像（代码不变）。我想知道它是否会简单地覆盖它在Container Registry中的现有映像（查看Container Registry> Images部分，我可以看到几秒钟前显示的带有Update的v2映像）。 现在，所有步骤均已设置完毕，最后一步是使用图像更新将滚动更新应用于现有部署：

kubectl set image deployment/hello-web hello-web=gcr.io/${PROJECT_ID}/hello-app:v2

当我得到答复时，这是成功的：

deployment.extensions/hello-web image updated

但是，当我导航到Kubernetes Engine>工作负载时，尽管状态显示为= OK，但要在Kubernetes上查看已部署的应用程序，在Managed pods部分中，它显示了从昨天开始运行的pod和前一天（在Created on日期栏中），而不是今天（6月29日）的部署：

1（a）-这引起了我的提问（仍然与第一个问题有关），上表的Revision列，这是否意味着我从映像中部署新容器的次数？因为确实我确实尝试了几次此步骤，但没有成功地解决此问题（我认为可能是4次）。 回到主要问题，类似地，如果我尝试使用Load Balancer服务的外部IP来加载网站，它不会显示更改的代码。另外，当我查看到Container Registry中推送的最新图像时，通过导航到Container Registry>图像，可以看到几分钟前上传的图像的v2版本。因此，Container Registry确实具有我上传的最新图像（这意味着它会覆盖Container Registry中具有相同图像名称的先前版本2。否则，如果无法覆盖它，它应该会失败）。因此，我不太了解，最后一步（下面）是否应该从Container Registry部署最后一个映像v2？

kubectl set image deployment/hello-web hello-web=gcr.io/${PROJECT_ID}/hello-app:v2

我不确定我缺少什么。

2-当我刚接触Docker时，我想知道是否有一种方法可以从Container Registry中提取图像，并查看Image中的源代码。否则，如何验证哪个映像包含哪个版本的源代码？这可能会引起很多混乱，因为许多版本的图像以及同样多版本的源代码历史记录会发生变化。您如何确定哪个源代码提交对应于哪个Docker映像？

3-最后，在任何情况下，任何人都可以提供有关管理Kubernetes的最佳实践的建议。假设您从更新的映像版本部署了一个容器，但是在出现问题或缺少功能之后才意识到这一点，因此您想回滚到以前的部署。因此，有管理此类方案的最佳实践。

为冗长的文字致歉，在此先感谢您。

Answer 1

对部署进行更改时，只有在对部署文本进行更改时，Kubernetes才会实际执行某些操作。在您的示例中，当您kubectl set image ...:v2时，由于该部署已经在v2上进行，因此它会看到Pod的当前状态与期望的状态匹配，并且什么也不做。如果您kubectl delete pod可以重新创建它们，但是Kubernetes会再次看到它在节点上已经有一个v2映像，然后重新启动它。

最简单的最简单方法是确定发布了v2（如果不是您期望的v2），然后将更改后的图像构建/推送/部署为v3。

（还考虑基于源控件提交ID或日期戳的图像版本控制方案，这将更易于唯一且无状态地生成。）

Answer 2

1-）您确定：v2尚未运行吗？

1a）修订版是部署的修订版。您所做的每个更改都会增加修订。将图片从：v1更改为：v2应该会对其进行更改。

2）您可以使用--entrypoint bash启动任何特定的图像并浏览。如果您的代码可读，则可以像在其他任何计算机上一样阅读。如果已编译，它将变得更加困难。

另一方面，您应该信任自己的构建过程/构建管道来正确标记构建，并且仅检查标记就足以确信正在运行正确的版本。