我正在关注Google Cloud Platform的本教程:https://cloud.google.com/kubernetes-engine/docs/tutorials/hello-app。基本上，我是从Github上从Github克隆示例hello-app项目的，无论是在Google Cloud上(使用Google Cloud Shell)还是在本地机器上，因为我想练习使用云方法和本地计算机(使用Google Cloud SDK)来完成本教程-然后，我将Docker镜像推送到云中，然后在Kubernetes上构建并运行它。
1-我的第一个步骤8是将源代码字符串从“Hello，World”更改为“Hello，world!”。版本2”，以及Go文件中的字符串“Version:1.0.0”到“Version: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引擎>工作负载时，尽管状态显示为=
OK，但在kuetnetes上查看了Kubernetes上已部署的应用程序，但在Managed pods部分中，它显示了从昨天和前一天(在Created on日期列中)运行的pod。今天(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的最佳实践提供建议。假设您从更新的镜像版本部署了容器，但是在出现问题或缺少功能后才意识到这一点，因此您想回滚到以前的部署。因此，有管理此类方案的最佳实践。
对冗长的文字表示歉意，在此先感谢您。
最佳答案
对部署进行更改时，只有在对部署文本进行更改时，Kubernetes才会实际执行某些操作。在您的示例中，当您使用kubectl set image ...:v2时，由于部署已经在v2上，因此它会看到Pod的当前状态与期望的状态匹配，并且不执行任何操作。如果您使用kubectl delete pod可能导致它们被重新创建，但是Kubernetes会再次看到它在节点上已经有一个v2镜像并再次启动它。
最简单的清除方法是确定是否发布了v2(如果不是您期望的v2)，然后将更改后的镜像构建/推送/部署为v3。
(还要考虑基于源控件提交ID或日期戳的图像版本控制方案，这将更易于唯一且无状态地生成。)
关于docker - Kubernetes Engine-Pod部署未更新为最新镜像，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/56821629/