3

我有一个本地 docker 镜像，它被推送到私有 Azure 容器注册表。然后在 Azure Kubernetes 服务中，我有一个使用此映像的集群 - 来自 ACR。

现在我想更新图像（意识到我需要安装 zip 和解压缩）。我启动了一个本地容器，进行更改，提交它们并将新图像推送到 ACR。不幸的是，这还不够。我的 pod 仍在使用以前版本的图像，没有 zip。

更多细节和我尝试过的：

  • 在掌舵图中，我使用的是“最新”标签；

  • 比较我本地“最新”图像的摘要 sha 和我在 ACR 中的内容 - 它们是相同的；

  • 在本地启动“最新”容器（docker run -it --rm -p 8080:80 My-REPO.azurecr.io/MY-IMAGE:latest） - 它已安装 zip

  • 删除了 Kubernetes 中现有的 pod；新创建的仍然缺少 zip

  • 删除版本并重新创建它 - 仍然没有。

  • 我正在使用docker push MY-REPO.azurecr.io/MY-IMAGE:latest

所以我的问题是——我错过了什么？如何正确更新此设置？

4

1 回答 1

7

您应该寻找这样的设置：

  1. 你的 Docker 镜像有一些独特的标签，不是latest; 日期戳通常可以正常工作。

  2. 您的 Helm 图表应将标记作为values.yaml文件中的参数。

  3. 您应该使用 Kubernetes Deployment（而不是裸 Pod）；在其 pod 规范部分将图像指定为image: MY-REPO.azurecr.io/MY-IMAGE:{{ .Values.tag }}.

  4. 当你有一个新版本时，你可以helm update --set tag=20190214；这会将更新的部署规范推送到 Kubernetes；这将导致它使用新映像创建新 Pod，然后使用旧映像销毁旧 Pod。

您遇到的基本问题是 YAML 文件中的一些文本差异对于使 Kubernetes 采取一些行动很重要。如果它已经有MY-IMAGE:latest，并且您尝试kubectl apply使用完全相同的图像字符串或等效相同的 pod 或部署规范，它将确定没有任何变化并且不需要做任何事情。类似地，当您删除并重新创建 pod 时，节点会认为它已经有一个MY-IMAGE:latest图像并且不需要去拉取任何东西；它只是重复使用它已经拥有的相同（过时的）图像。

与您描述的工作流程相关的一些最佳实践：

  • 不要使用...:latest图像标签（或任何其他固定字符串）；相反，请使用一些唯一值，例如时间戳、源代码管理提交 ID 或发布版本，每次进行部署时都会有不同的标签。

  • 不要使用裸豆荚；改用更高级别的控制器，通常是部署。

  • 永远不要使用docker commit。（如果您的图像在生产中崩溃，您如何解释“哦，我手动更改了一些东西，覆盖了生产正在使用的图像，并强制重新启动所有内容，但我没有记录我实际做了什么”？） Dockerfile，将其签入源代码管理，并用于docker build制作图像。（更好的是，设置一个 CI 系统，以便在您签到时为您构建它们。）

于 2019-02-14T23:58:36.390 回答