【问题标题】:kubernetes gcp caching old imagekubernetes gcp 缓存旧镜像
【发布时间】:2020-05-23 11:54:54
【问题描述】:

我正在运行 GKE 集群,并且有一个部署使用我推送到 GCP 上的 Container Registry 的映像,问题是 - 即使我构建映像并使用 latest 标记推送它,部署仍会继续创建新的缓存了旧的 pod - 有没有办法在不重新部署的情况下更新它(也就是不先破坏它)?

kubernetes 存在一个已知问题,即即使您更改配置映射,旧配置仍然存在,您可以重新部署或使用解决方法

kubectl patch deployment $deployment -n $ns -p \
  "{\"spec\":{\"template\":{\"metadata\":{\"annotations\":{\"date\":\"`date +'%s'`\"}}}}}"

缓存图像有类似的东西吗?

【问题讨论】:

  • 类似的意思是说是否有类似 kubectl 补丁部署的东西来更新部署映像而不是删除它并从新的 yaml 重新创建?
  • 是的,完全一样,资源限制/请求也是如此-一旦创建部署,除非重新部署,否则您无法升级其资源-我正在寻找后一种解决方案,如何使用命令进行-更新图片和更新资源,如果您知道任何答案,我将不胜感激

标签: kubernetes google-cloud-platform


【解决方案1】:

我认为您正在寻找我在 kubernetes documentation 中找到的 kubectl 集或补丁。

要更新部署映像,您可以使用kubectl set

kubectl set image deployment/name_of_deployment name_of_deployment=image:name_of_image

要更新您的 pod 的图像,您可以使用 kubectl patch

kubectl patch pod name_of_pod  -p '{"spec":{"containers":[{"name":"name_of_pod_from_yaml","image":"name_of_image"}]}}'

您始终可以使用kubectl edit 进行编辑,这使您可以直接编辑可以通过命令行工具检索的任何 API 资源。

kubectl edit deployment name_of_deployment

如果您还有其他问题,请告诉我。

【讨论】:

    【解决方案2】:

    1) 你应该改变你的思维方式。破坏吊舱也不错。应用程序停机是不好的。您应该始终以可以容忍一个 pod 死亡的方式来计划您的部署。对无状态应用使用多个副本,对有状态应用使用集群。使用 Kubernetes 滚动更新对您的部署进​​行任何更改。滚动更新有许多非常重要的设置,它们直接影响应用程序的正常运行时间。请仔细阅读。

    2) Kubernetes 启动旧镜像的原因是它默认使用 imagePullPolicy: IfNotPresent。使用imagePullPolicy: Always,它将始终尝试在重新部署时提取最新版本。

    【讨论】:

    • 你刚刚给了我一个很棒的想法,这可能是众所周知的,但我刚刚明白了;我应该将给定部署的副本扩展到 2 个,一旦新配置使用新配置,优雅地关闭旧配置; - 或者总是有两个并在升级后终止一个;唯一的问题是,如果所有内容都重复,则可能需要更大的 cpu/ram 请求
    猜你喜欢
    • 1970-01-01
    • 2021-04-23
    • 2016-07-24
    • 2019-05-01
    • 2017-04-16
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2019-12-20
    相关资源
    最近更新 更多