第 15 章 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 凭证。
- 过期计时器以避免绕过缓存机构大小。
- 通过配置应用程序配置全局 on/off。
-
整个上游 registry 或单个命名空间缓存，例如，所有
docker.io或docker.io/library。 - 所有缓存拉取的日志记录。
- Clair 缓存的镜像可扫描。
15.1. 代理缓存架构
下图显示了代理缓存功能的预期设计流和架构。
当用户从 Red Hat Quay 上的上游存储库拉取镜像（如 postgres:14 ）时，存储库会检查是否存在镜像。如果镜像不存在，则会启动新的拉取。拉取后，镜像层将保存到缓存和服务器并行用户。下图描述了此场景的架构概述：
如果缓存中的镜像存在，用户可以依赖 Quay 的缓存来与上游源保持最新状态，以便自动拉取缓存中的更新镜像。当在上游 registry 中覆盖了原始镜像的标签时会出现这种情况。下图描述了当上游镜像和镜像的缓存版本不同时会发生什么的架构概述：
如果上游镜像和缓存的版本相同，则不会拉取任何层，并将缓存的镜像传送到用户。
在某些情况下，用户在上游 registry 停机时启动拉取。如果使用配置的过时的周期发生这种情况，则会发送存储在缓存中的镜像。如果在配置的 staleness 到期后拉取发生，则错误会被传播到用户。以下镜像描述了在配置的过时周期后拉取时的架构概述：
Quay 管理员可以利用组织的可配置大小限制来限制缓存大小，以便后端存储消耗保持可预测的。这可以通过根据使用镜像的频率从缓存中丢弃镜像来实现。下图描述了此场景的架构概述：
