【问题标题】:How can we see cached images in kubernetes?我们如何在 Kubernetes 中查看缓存的图像?
【发布时间】:2020-07-01 14:59:42
【问题描述】:

我使用 kops 作为 kubernetes 部署。

我注意到,每当在部署文件中输入具有相同标签号的图像时,如果 imagepullpolicy 未设置为 always,系统将采用前一个图像

有什么方法可以在 kubernetes 环境中查看容器的所有缓存图像?

假设我有一个图像 test:56 当前正在部署中运行,并且之前使用了 test:1 到 test:55,那么 kubernetes 是否缓存这些图像?如果是的话在哪里可以找到?

【问题讨论】:

    标签: docker kubernetes containers kubernetes-pod docker-image


    【解决方案1】:
    • 对您的环境的评论:

      我注意到,每当在部署文件中输入具有相同标签号的图像时,如果 imagepullpolicy 未设置为 always,系统将采用前一个图像

    pre-pulled image 可用于预加载某些图像以提高速度或作为对私有注册表进行身份验证的替代方法,从而优化性能。

    docker 将始终缓存所有在本地使用的图像。

    由于您使用的是 EKS,请记住,如果您有节点运行状况管理(意味着如果节点发生故障将被替换),新节点将不会从旧节点缓存图像,因此这始终是一个好主意将图像存储在 your Cloud Provider Registry 等注册表或本地注册表中。

    • 让我们解决您的第一个问题:

      有没有什么方法可以在 kubernetes 环境中查看容器的所有缓存图像?

    是的,您必须使用 docker images 列出存储在您的环境中的图像。

    • 第二个问题:

      假设我有一个映像 test:56 当前在部署中运行,并且之前使用了 test:1 到 test:55,那么 Kubernetes 是否缓存这些映像?如果是的话在哪里可以找到?

    我为你准备了一个例子:

    • 我根据官方的busybox镜像部署了几个pod:
    $ kubectl run busy284 --generator=run-pod/v1 --image=busybox:1.28.4
    pod/busy284 created
    $ kubectl run busy293 --generator=run-pod/v1 --image=busybox:1.29.3
    pod/busy284 created
    $ kubectl run busy284 --generator=run-pod/v1 --image=busybox:1.28
    pod/busy28 created
    $ kubectl run busy284 --generator=run-pod/v1 --image=busybox:1.29
    pod/busy29 created
    $ kubectl run busy284 --generator=run-pod/v1 --image=busybox:1.30
    pod/busy284 created
    $ kubectl run busybox --generator=run-pod/v1 --image=busybox
    pod/busybox created
    

    现在让我们检查存储在docker images中的图像

    $ docker images
    REPOSITORY                                TAG                   IMAGE ID            CREATED             SIZE
    k8s.gcr.io/kube-proxy                     v1.17.3               ae853e93800d        5 weeks ago         116MB
    k8s.gcr.io/kube-controller-manager        v1.17.3               b0f1517c1f4b        5 weeks ago         161MB
    k8s.gcr.io/kube-apiserver                 v1.17.3               90d27391b780        5 weeks ago         171MB
    k8s.gcr.io/kube-scheduler                 v1.17.3               d109c0821a2b        5 weeks ago         94.4MB
    kubernetesui/dashboard                    v2.0.0-beta8          eb51a3597525        3 months ago        90.8MB
    k8s.gcr.io/coredns                        1.6.5                 70f311871ae1        4 months ago        41.6MB
    k8s.gcr.io/etcd                           3.4.3-0               303ce5db0e90        4 months ago        288MB
    kubernetesui/metrics-scraper              v1.0.2                3b08661dc379        4 months ago        40.1MB
    busybox                                   latest                83aa35aa1c79        10 days ago         1.22MB
    busybox                                   1.30                  64f5d945efcc        10 months ago       1.2MB
    busybox                                   1.29                  758ec7f3a1ee        15 months ago       1.15MB
    busybox                                   1.29.3                758ec7f3a1ee        15 months ago       1.15MB
    busybox                                   1.28                  8c811b4aec35        22 months ago       1.15MB
    busybox                                   1.28.4                8c811b4aec35        22 months ago       1.15MB
    

    您可以看到列出的所有推送的图像。

    最好使用命令docker system prune 清理系统中的旧资源,以不时释放服务器上的空间。

    如果您有任何疑问,请在 cmets 中告诉我。

    【讨论】:

    • 非常感谢,这真的很有帮助
    • 更重要的是,如果我的图像标签始终为:latest 并且我的图像拉取策略未设置为always。在那种情况下会发生什么@willrof?
    • @ShahidaliKhan 很高兴能提供帮助。如果您将图像设置为latest,它将始终拉动,就像always 一样,这不是最佳实践,因为您将很难跟踪正在运行的版本。你可以在这里看到它:kubernetes.io/docs/concepts/configuration/overview/…
    猜你喜欢
    • 1970-01-01
    • 2018-11-18
    • 1970-01-01
    • 2022-08-18
    • 2016-12-16
    • 2016-08-03
    • 1970-01-01
    • 2010-12-24
    • 1970-01-01
    相关资源
    最近更新 更多