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

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

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

在 Red Hat Quay 缓存代理中，提供了以下功能：

特定的组织可以定义为上游 registry 的缓存。
配置作为特定上游 registry 的缓存的 Quay 组织。此存储库可以通过 Quay UI 定义，并提供以下配置：
- 私有存储库的上游 registry 凭证或提高速率限制。
- 到期计时器以避免超过缓存机构大小。
通过配置应用程序全局配置/关闭。
整个上游 registry 缓存或只是一个命名空间，例如，所有 docker.io 或仅 docker.io/library。
所有缓存拉取的日志记录。
Clair 的缓存镜像扫描功能。

15.1. 代理缓存架构
复制链接

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

Proxy cache overview

当用户从 Red Hat Quay 上的上游存储库中拉取（如 postgres:14 ）时，存储库会检查是否存在镜像。如果镜像不存在，则会启动新的拉取。拉取(pull)后，镜像层被保存到并行用户的缓存和服务器。下图描述了此情境的架构概述：

Pulled image overview

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

Updating opposing layers overview

如果上游镜像和缓存的版本相同，则不会拉取任何层，缓存的镜像会被传递给用户。

在某些情况下，用户会在上游 registry 停机时启动拉取。如果出现这种情况发生于配置的陈旧期限，则发送存储在缓存中的镜像。如果在配置的过时期后拉取(pull)发生，则错误会传播到用户。以下镜像描述了在配置的过时期限后拉取发生时的架构概述：

Staleness pull overview

Quay 管理员可以利用组织的可配置大小限制来限制缓存大小，以便后端存储消耗保持可预测。这可以通过根据使用镜像的频率从缓存丢弃镜像来实现。下图描述了此情境的架构概述：

返回顶部