You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
//* The Operator will deploy an OpenShift `Route` as the default entrypoint to the registry. If you prefer a different entrypoint (e.g. `Ingress` or direct `Service` access that configuration will need to be done manually).
By default, {productname} deployments include managed *Horizontal Pod Autoscalers (HPAs)* for key components to ensure availability and performance during load spikes or maintenance events. HPAs automatically adjust the number of running pods based on observed CPU and memory utilization.
6
+
7
+
A typical {productname} deployment includes the following pods:
8
+
9
+
* Two pods for the {productname} application (`example-registry-quay-app-*`)
10
+
* One Redis pod for {productname} logging (`example-registry-quay-redis-*`)
11
+
* One PostgreSQL pod for metadata storage (`example-registry-quay-database-*`)
12
+
* Two `Quay` mirroring pods (`example-registry-quay-mirror-*`)
13
+
* Two pods for Clair (`example-registry-clair-app-*`)
14
+
* One PostgreSQL pod for Clair (`example-registry-clair-postgres-*`)
15
+
16
+
HPAs are managed by default for the `Quay`, `Clair`, and `Mirror` components, each starting with two replicas to prevent downtime during upgrades, reconfigurations, or pod rescheduling ev
The following sections cover advanced configuration options for when the default deployment settings do not meet your organization's needs for performance, security, or existing infrastructure integration.
= Configuring resources for managed components on {ocp}
4
4
@@ -18,122 +18,9 @@ The following components should not be set lower than their minimum requirements
18
18
* `clair`: Recommended of 2 GB memory, 2 vCPUs
19
19
* `clairpostgres`: Minimum of 200 MB
20
20
21
-
You can configure resource requests on the {ocp} UI, or by directly by updating the `QuayRegistry`YAML.
21
+
You can configure resource requests on the {ocp} UI or directly by updating the `QuayRegistry`CR via the CLI.
22
22
23
23
[IMPORTANT]
24
24
====
25
25
The default values set for these components are the suggested values. Setting resource requests too high or too low might lead to inefficient resource utilization, or performance degradation, respectively.
26
-
====
27
-
28
-
[id="configuring-resources-ocp-ui"]
29
-
== Configuring resource requests by using the {ocp} UI
30
-
31
-
Use the following procedure to configure resources by using the {ocp} UI.
32
-
33
-
.Procedure
34
-
35
-
. On the {ocp} developer console, click *Operators* -> *Installed Operators* -> *Red Hat Quay*.
36
-
37
-
. Click *QuayRegistry*.
38
-
39
-
. Click the name of your registry, for example, *example-registry*.
40
-
41
-
. Click *YAML*.
42
-
43
-
. In the `spec.components` field, you can override the resource of the `quay`, `clair`, `mirroring` `clairpostgres`, and `postgres` resources by setting values for the `.overrides.resources.limits` and the `overrides.resources.requests` fields. For example:
44
-
+
45
-
[source,yaml]
46
-
----
47
-
spec:
48
-
components:
49
-
- kind: clair
50
-
managed: true
51
-
overrides:
52
-
resources:
53
-
limits:
54
-
cpu: "5" # Limiting to 5 CPU (equivalent to 5000m or 5000 millicpu)
55
-
memory: "18Gi" # Limiting to 18 Gibibytes of memory
56
-
requests:
57
-
cpu: "4" # Requesting 4 CPU
58
-
memory: "4Gi" # Requesting 4 Gibibytes of memory
59
-
- kind: postgres
60
-
managed: true
61
-
overrides:
62
-
resources:
63
-
limits: {} <1>
64
-
requests:
65
-
cpu: "700m" # Requesting 700 millicpu or 0.7 CPU
66
-
memory: "4Gi" # Requesting 4 Gibibytes of memory
67
-
- kind: mirror
68
-
managed: true
69
-
overrides:
70
-
resources:
71
-
limits: <2>
72
-
requests:
73
-
cpu: "800m" # Requesting 800 millicpu or 0.8 CPU
74
-
memory: "1Gi" # Requesting 1 Gibibyte of memory
75
-
- kind: quay
76
-
managed: true
77
-
overrides:
78
-
resources:
79
-
limits:
80
-
cpu: "4" # Limiting to 4 CPU
81
-
memory: "10Gi" # Limiting to 10 Gibibytes of memory
82
-
requests:
83
-
cpu: "4" # Requesting 4 CPU
84
-
memory: "10Gi" # Requesting 10 Gibi of memory
85
-
- kind: clairpostgres
86
-
managed: true
87
-
overrides:
88
-
resources:
89
-
limits:
90
-
cpu: "800m" # Limiting to 800 millicpu or 0.8 CPU
91
-
memory: "3Gi" # Limiting to 3 Gibibytes of memory
92
-
requests: {}
93
-
----
94
-
<1> Setting the `limits` or `requests` fields to `{}` uses the default values for these resources.
95
-
<2> Leaving the `limits` or `requests` field empty puts no limitations on these resources.
96
-
97
-
[id="configuring-resources-ocp-yaml"]
98
-
== Configuring resource requests by editing the QuayRegistry YAML
99
-
100
-
You can re-configure {productname} to configure resource requests after you have already deployed a registry. This can be done by editing the `QuayRegistry` YAML file directly and then re-deploying the registry.
101
-
102
-
.Procedure
103
-
104
-
. Optional: If you do not have a local copy of the `QuayRegistry` YAML file, enter the following command to obtain it:
= Configuring resource requests by using the {ocp} UI
4
+
5
+
Use the following procedure to configure resources by using the {ocp} UI.
6
+
7
+
.Procedure
8
+
9
+
. On the {ocp} developer console, click *Operators*->*Installed Operators*->*Red Hat Quay*.
10
+
11
+
. Click *QuayRegistry*.
12
+
13
+
. Click the name of your registry, for example, *example-registry*.
14
+
15
+
. Click *YAML*.
16
+
17
+
. In the `spec.components` field, you can override the resource of the `quay`, `clair`, `mirroring``clairpostgres`, and `postgres` resources by setting values for the `.overrides.resources.limits` and the `overrides.resources.requests` fields. For example:
18
+
+
19
+
[source,yaml]
20
+
----
21
+
spec:
22
+
components:
23
+
- kind: clair
24
+
managed: true
25
+
overrides:
26
+
resources:
27
+
limits:
28
+
cpu: "5" # Limiting to 5 CPU (equivalent to 5000m or 5000 millicpu)
29
+
memory: "18Gi" # Limiting to 18 Gibibytes of memory
30
+
requests:
31
+
cpu: "4" # Requesting 4 CPU
32
+
memory: "4Gi" # Requesting 4 Gibibytes of memory
33
+
- kind: postgres
34
+
managed: true
35
+
overrides:
36
+
resources:
37
+
limits: {} <1>
38
+
requests:
39
+
cpu: "700m" # Requesting 700 millicpu or 0.7 CPU
40
+
memory: "4Gi" # Requesting 4 Gibibytes of memory
41
+
- kind: mirror
42
+
managed: true
43
+
overrides:
44
+
resources:
45
+
limits: <2>
46
+
requests:
47
+
cpu: "800m" # Requesting 800 millicpu or 0.8 CPU
48
+
memory: "1Gi" # Requesting 1 Gibibyte of memory
49
+
- kind: quay
50
+
managed: true
51
+
overrides:
52
+
resources:
53
+
limits:
54
+
cpu: "4" # Limiting to 4 CPU
55
+
memory: "10Gi" # Limiting to 10 Gibibytes of memory
56
+
requests:
57
+
cpu: "4" # Requesting 4 CPU
58
+
memory: "10Gi" # Requesting 10 Gibi of memory
59
+
- kind: clairpostgres
60
+
managed: true
61
+
overrides:
62
+
resources:
63
+
limits:
64
+
cpu: "800m" # Limiting to 800 millicpu or 0.8 CPU
65
+
memory: "3Gi" # Limiting to 3 Gibibytes of memory
66
+
requests: {}
67
+
----
68
+
<1> Setting the `limits` or `requests` fields to `{}` uses the default values for these resources.
69
+
<2> Leaving the `limits` or `requests` field empty puts no limitations on these resources.
You can re-configure {productname} to configure resource requests after you have already deployed a registry. This can be done by editing the `QuayRegistry` YAML file directly and then re-deploying the registry.
6
+
7
+
.Procedure
8
+
9
+
. Edit the `QuayRegistry` CR by entering the following command:
Support for {ocp}_edge termination_ routes is provided through the `tls` component. This separation allows independent control of route management and TLS certificate handling.
6
+
7
+
`EXTERNAL_TLS_TERMINATION: true` is the default, opinionated setting, which assumes the cluster manages TLS termination.
8
+
9
+
[NOTE]
10
+
====
11
+
* When `tls` is *managed*, the cluster's default wildcard certificate is used.
12
+
* When `tls` is *unmanaged*, you must supply your own SSL/TLS certificate and key pair.
13
+
====
14
+
15
+
Multiple valid configurations are possible, as shown in the following table:
16
+
17
+
.Valid configuration options for TLS and routes
18
+
[width="100%",cols="2,2,2,2,3",options="header"]
19
+
|===
20
+
|Option | Route | TLS | Certs provided | Result
21
+
| My own load balancer handles TLS | Managed | Managed | No | Edge route using default cluster wildcard certificate
22
+
| {productname} handles TLS | Managed | Unmanaged | Yes | Passthrough route with certificates mounted in the {productname} pod
23
+
| {productname} handles TLS | Unmanaged | Unmanaged | Yes | Certificates set inside the {productname} pod; user must manually create a route
0 commit comments