Chapter 7. Red Hat Quay sizing and subscriptions
Red Hat Quay scales from proof of concept to large deployments such as Quay.io. You can use sample sizing tables and subscription guidance to plan capacity for your environment.
Scalability of Red Hat Quay is one of its key strengths, with a single code base supporting a broad spectrum of deployment sizes, including the following:
- Proof of Concept deployment on a single development machine
- Mid-size deployment of approximately 2,000 users that can serve content to dozens of Kubernetes clusters
- High-end deployment such as Quay.io that can serve thousands of Kubernetes clusters world-wide
Sizing depends on many factors, such as the number of users, images, concurrent pulls and pushes, so standard sizing recommendations are not available.
The following are the minimum requirements for systems running Red Hat Quay (per container/pod instance):
- Quay: minimum 6 GB; recommended 8 GB, 2 or more vCPUs
- Clair: recommended 2 GB RAM and 2 or more vCPUs
- Storage: recommended 30 GB
-
NooBaa: minimum 2 GB, 1 vCPU (when you select the
objectstoragecomponent in the Operator) - Clair database: minimum 5 GB required for security metadata
Stateless components of Red Hat Quay can be scaled out, but scaling increases load on stateful backend services.
7.1. Red Hat Quay sample sizings
Sample Red Hat Quay sizing tables list approximate resources for proof of concept, mid-size, and high-end deployments. You can use these figures as a starting point and adjust based on your workload.
The following table shows approximate sizing for Proof of Concept, mid-size, and high-end deployments. Whether a deployment runs appropriately with the same metrics depends on many factors not shown below.
| Metric | Proof of concept | Mid-size | High End (Quay.io) |
|---|---|---|---|
| No. of Quay containers by default | 1 | 4 | 15 |
| No. of Quay containers max at scale-out | N/A | 8 | 30 |
| No. of Clair containers by default | 1 | 3 | 10 |
| No. of Clair containers max at scale-out | N/A | 6 | 15 |
| No. of mirroring pods (to mirror 100 repositories) | 1 | 5-10 | N/A |
| Database sizing | 2-4 Cores; 6-8 GB RAM; 10-20 GB disk | 4-8 Cores; 6-32 GB RAM; 100 GB - 1 TB disk | 32 cores; 244 GB; 1+ TB disk |
| Object storage backend sizing | 10-100 GB | 1 - 20 TB | 50+ TB up to PB |
| Redis cache sizing | 2 Cores; 2-4 GB RAM | 4 cores; 28 GB RAM | |
| Underlying node sizing (physical or virtual) | 4 Cores; 8 GB RAM | 4-6 Cores; 12-16 GB RAM | Quay: 13 cores; 56 GB RAM. Clair: 2 cores; 4 GB RAM |
Redis cache sizing applies only when you use Quay builders; otherwise Redis sizing is not significant.
7.2. Red Hat Quay subscription information
Red Hat Quay subscriptions are based on deployments and include Standard or Premium support. You can review subscription models and entitlements when planning your registry deployment.
Deployment means an installation of a single Red Hat Quay registry using a shared data backend.
With a Red Hat Quay subscription, the following options are available:
- You can deploy any number of pods, such as Quay, Clair, Builder, and so on.
- Red Hat Quay pods can run in multiple data centers or availability zones.
- Storage and database backends can be deployed across multiple data centers or availability zones, but only as a single, shared storage backend and single, shared database backend.
- Red Hat Quay can manage content for an unlimited number of clusters or standalone servers.
- Clients can access the Red Hat Quay deployment regardless of their physical location.
- You can deploy Red Hat Quay on OpenShift Container Platform infrastructure nodes to minimize subscription requirements.
- You can run the Container Security Operator (CSO) and the Quay Bridge Operator (QBO) on your OpenShift Container Platform clusters at no additional cost.
Red Hat Quay geo-replication requires a subscription for each storage replication. The database, however, is shared.
7.3. Using Red Hat Quay with or without internal registry
You can run Red Hat Quay as an external registry in front of multiple OpenShift Container Platform clusters that use internal registries, or rely on cluster-internal registries alone. You can choose the approach that fits your image governance and distribution needs.
The required coordination of Secrets and ImageStreams is automated by the Quay Bridge Operator, which can be launched from the OperatorHub for OpenShift Container Platform.
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}