第 15 章 Red Hat Quay 作为上游 registry 的代理缓存

随着容器开发日益普及,客户逐渐依赖 Docker 或 Google Cloud Platform 等上游 registry 中的容器镜像来启动和运行服务。现在,对于用户可以从这些 registry 中拉取的次数,registry 存在速率限制和节流。

通过此功能,Red Hat Quay 将充当代理缓存,以绕过上游 registry 的限制。添加缓存功能也会加快拉取性能,因为镜像是从缓存中拉取的,而不是从上游依赖项中提取。只有在上游镜像摘要与缓存的镜像不同时,才会更新缓存的镜像,从而减少速率限制和潜在的节流。

在 Red Hat Quay 缓存代理技术预览中,可以使用以下功能:

  • 特定机构可以定义为上游 registry 的缓存。
  • 配置 Quay 组织,充当特定上游 registry 的缓存。此软件仓库可以通过 Quay UI 定义,并提供以下配置:

    • 私有存储库的上游 registry 凭证或提高速率限制。
    • 过期计时器以避免超过缓存机构大小。

      注意

      因为缓存代理仍标记为 技术预览,所以还没有支持存储配额。当此功能在以后的 Red Hat Quay 版本中成为 正式发行 (GA)时,过期计时器将由其他计时器补充,以防出现重复的上游 registry 问题。

  • 通过配置应用程序全局配置/关闭。
  • 整个上游 registry 的缓存或只有一个命名空间,例如:所有 \docker.io 或只 \docker.io/library
  • 会拉取所有缓存的日志记录。
  • Clair 的缓存镜像扫描功能。

15.1. 代理缓存架构

下图显示了代理缓存功能的预期设计流和架构。

Proxy cache overview

当用户从 Red Hat Quay 上的上游存储库拉取(如 postgres:14 )时,程序库会检查是否存在镜像。如果镜像不存在,则启动新的拉取。拉取后,镜像层将保存到同时缓存和服务器到用户。下图描述了这种情况的架构概述:

Pulled image overview

如果缓存中存在镜像,用户便可依赖 Quay 的缓存与上游源保持最新状态,以便自动拉取来自缓存的较新的镜像。当上游 registry 中已覆盖了原始镜像的标签时,会出现这种情况。下图描述了当上游镜像和缓存镜像版本不同的版本时会发生什么情况的架构概述:

Updating opposing layers overview

如果上游镜像和缓存的版本相同,则不会拉取任何层,并将缓存的镜像提供给用户。

在某些情况下,用户在上游 registry 关闭时启动拉取。如果这种情况与配置的陈旧期发生,则存储在缓存中的镜像。如果在配置的过时期限后发生拉取,则错误会传播到用户。下图显示了在配置的过时期限后拉取(pull)时的架构概述:

Image: cache-proxy-staleness-pull.png[Staleness pull overview]

Quay 管理员可以利用组织的可配置大小限制来限制缓存大小,以便后端存储消耗可以预测。实现方法是根据镜像使用的频率从缓存中丢弃镜像。下图描述了这种情况的架构概述: