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