第 12 章 Red Hat Quay 作为上游 registry 的代理缓存
随着容器开发的流行，客户越来越依赖于上游 registry （如 Docker 或 Google Cloud Platform）中的容器镜像来获取服务。现在，registry 对用户可从这些 registry 中拉取的次数有速率限制和节流。
通过此功能，Red Hat Quay 将作为代理缓存来绕过上游 registry 中的 pull-rate 限制。添加缓存功能也会加快拉取性能，因为镜像是从缓存而不是上游依赖项中拉取的。只有在上游镜像摘要与缓存的镜像不同时，缓存的镜像才会更新，从而减少速率限制和潜在的节流。
在 Red Hat Quay 缓存代理中，提供以下功能：
- 特定的机构可以定义为上游 registry 的缓存。
配置充当特定上游 registry 的缓存的 Quay 组织。此存储库可以使用 Quay UI 定义，并提供以下配置：
- 私有存储库或增加速率限制的上游 registry 凭证。
- 过期计时器以避免超过缓存机构大小。
- 通过配置应用程序对/关闭全局配置。
-
整个上游 registry 或只缓存单个命名空间，例如，所有
docker.io或只包括docker.io/library。 - 记录所有缓存拉取。
- Clair 的缓存镜像扫描性。
12.1. 代理缓存架构
下图显示了代理缓存功能的预期设计流和架构。
当用户从 Red Hat Quay 上的上游存储库拉取镜像（例如 postgres:14 ）时，存储库会检查镜像是否存在。如果镜像不存在，则启动一个新的拉取(pull)。拉取后，镜像层会保存到并行用户的缓存和服务器。下图描述了这种情况的架构概述：
如果缓存中存在镜像，用户可以依赖 Quay 的缓存来与上游源保持最新状态，以便自动拉取缓存中较新的镜像。当上游 registry 中覆盖原始镜像的标签时会出现这种情况。下图描述了当上游镜像和缓存镜像版本不同时发生的情况概述：
如果上游镜像和缓存的版本相同，则不会拉取层，并将缓存的镜像传送到用户。
在某些情况下，用户会在上游 registry 停机时启动拉取。如果在配置的过时的周期内发生这种情况，则会传输存储在缓存中的镜像。如果在配置的过时的周期后拉取发生，则会向用户传播错误。下图描述了在配置过时的时间后进行拉取时的架构概述：
Quay 管理员可以利用组织的可配置大小限制来限制缓存大小，以便后端存储消耗保持可预测状态。这可以通过根据使用镜像的频率从缓存中丢弃镜像来实现。下图描述了这种情况的架构概述：
