Red Hat Summit Red Hat SummitSupportoConsoleSviluppatoriInizia una provaContatti

Questo contenuto non è disponibile nella lingua selezionata.

Chapter 7. Deploying Red Hat Quay on infrastructure nodes

Deploying Red Hat Quay on infrastructure nodes dedicates specific nodes for registry workloads to improve performance and isolate critical components. You can use infrastructure machine sets or label and taint worker nodes to control where quay pods are scheduled.

By default, all quay-related pods are scheduled on available worker nodes in your OpenShift Container Platform cluster. In some environments, you might want to dedicate certain nodes specifically for infrastructure workloads—such as registry, database, and monitoring pods—to improve performance, isolate critical components, or simplify maintenance.

OpenShift Container Platform supports this approach using infrastructure machine sets, which automatically create and manage nodes reserved for infrastructure.

As an OpenShift Container Platform administrator, you can achieve the same result by labeling and tainting worker nodes. This ensures that only infrastructure workloads, like quay pods, are scheduled on these nodes. After your infrastructure nodes are configured, you can control where quay pods run using node selectors and tolerations.

The following procedures is intended for new deployments that install the Red Hat Quay Operator in a single namespace and provide their own backend storage. The procedure shows you how to prepare nodes and deploy Red Hat Quay on dedicated infrastructure nodes. In this procedure, all quay-related pods are placed on dedicated infrastructure nodes.

7.1. Labeling and tainting nodes for infrastructure use
Copia collegamento

To dedicate nodes for infrastructure workloads like quay pods, you can label and taint worker nodes with the infra role. This prevents user workloads from being scheduled on infrastructure nodes and ensures only infrastructure pods run on these dedicated nodes.

Note

The following procedure labels three worker nodes with the infra label. Depending on the resources relevant to your environment, you might have to label more than three worker nodes with the infra label.

  1. Obtain a list of worker nodes in your deployment by entering the following command: 

    $ oc get nodes | grep worker
     
    NAME                                                              STATUS   ROLES                  AGE    VERSION
---
example-cluster-new-c5qqp-worker-b-4zxx5.c.quay-devel.internal   Ready    worker                 401d   v1.31.11
example-cluster-new-c5qqp-worker-b-kz6jn.c.quay-devel.internal   Ready    worker                 402d   v1.31.11
example-cluster-new-c5qqp-worker-b-wrhw4.c.quay-devel.internal   Ready    worker                 401d   v1.31.11
---

  2. Add the node-role.kubernetes.io/infra= label to the worker nodes by entering the following command. The number of infrastructure nodes required depends on your environment. Production environments should provision enough infra nodes to ensure high availability and sufficient resources for all quay-related components. Monitor CPU, memory, and storage utilization to determine if additional infra nodes are required. 

    $ oc label node --overwrite <infra_node_one> <infra_node_two> <infra_node_three> node-role.kubernetes.io/infra=

  3. Confirm that the node-role.kubernetes.io/infra= label has been added to the proper nodes by entering the following command: 

    $ oc get node | grep infra
     
    ---
example-cluster-new-c5qqp-worker-b-4zxx5.c.quay-devel.internal   Ready    infra,worker           405d   v1.32.8
example-cluster-new-c5qqp-worker-b-kz6jn.c.quay-devel.internal   Ready    infra,worker           406d   v1.32.8
example-cluster-new-c5qqp-worker-b-wrhw4.c.quay-devel.internal   Ready    infra,worker           405d   v1.32.8
---

  4. When a worker node is assigned the infra role, there is a chance that user workloads could get inadvertently assigned to an infra node. To avoid this, you can apply a taint to the infra node, and then add tolerations for the pods that you want to control. Taint the worker nodes with the infra label by entering the following command: 

    $ oc adm taint nodes -l node-role.kubernetes.io/infra \
  node-role.kubernetes.io/infra=reserved:NoSchedule --overwrite
     
    node/example-cluster-new-c5qqp-worker-b-4zxx5.c.quay-devel.internal modified
node/example-cluster-new-c5qqp-worker-b-kz6jn.c.quay-devel.internal modified
node/example-cluster-new-c5qqp-worker-b-wrhw4.c.quay-devel.internal modified

7.2. Creating a project with node selector and tolerations
Copia collegamento

To ensure that Red Hat Quay pods run on infrastructure nodes, you can create a project with node selector and tolerations annotations. These annotations direct pods to infrastructure nodes and allow them to tolerate the node taints.

Procedure

  1. Add the node-selector annotation to the namespace by entering the following command: 

    $ oc annotate namespace <namespace> openshift.io/node-selector='node-role.kubernetes.io/infra='

  2. Add the tolerations annotation to the namespace by entering the following command: 

    $ oc annotate namespace <namespace> scheduler.alpha.kubernetes.io/defaultTolerations='[{"operator":"Equal","value":"reserved","effect":"NoSchedule","key":"node-role.kubernetes.io/infra"},{"operator":"Equal","value":"reserved","effect":"NoExecute","key":"node-role.kubernetes.io/infra"}]' --overwrite
     
    namespace/<namespace> annotated
    Important

    The tolerations in this example are specific to two taints commonly applied to infra nodes. The taints configured in your environment might differ. You must set the tolerations accordingly to match the taints applied to your infra nodes.

7.3. Installing the Red Hat Quay Operator on the annotated namespace
Copia collegamento

To install the Red Hat Quay Operator on infrastructure nodes, you can install it in the namespace that has node-selector and tolerations annotations. This ensures the Operator and its pods run on the dedicated infrastructure nodes.

Procedure

  1. On the OpenShift Container Platform web console, click Operators OperatorHub.
  2. In the search box, type Red Hat Quay.
  3. Click Red Hat Quay Install.
  4. Select the update channel, for example, stable-3 and the version.
  5. Click A specific namespace on the cluster for the installation mode, and then select the namespace that you applied the node-selector and tolerations annotations to.
  6. Click Install.

  1. Confirm that the Operator is installed by entering the following command: 

    $ oc get pods -n <annotated_namespace> -o wide | grep quay-operator
     
    quay-operator.v3.15.1-858b5c5fdc-lf5kj   1/1     Running   0          29m   10.130.6.18   example-cluster-new-c5qqp-worker-f-mhngl.c.quay-devel.internal   <none>           <none>

7.4. Creating the Red Hat Quay registry
Copia collegamento

To create a Red Hat Quay registry that runs on infrastructure nodes, you can create a QuayRegistry custom resource in the annotated namespace. You must patch the registry components (clair, postgres, redis, and so on) with toleration annotations so they can schedule onto the infra worker nodes.

Procedure

  1. On the OpenShift Container Platform web console, click Operators Installed Operators Red Hat Quay.
  2. On the Red Hat Quay Operator details page, click Quay Registry Create QuayRegistry.

  3. On the Create QuayRegistry page, set the monitoring and objectstorage fields to false. The monitoring component cannot be enabled when Red Hat Quay is installed in a single namespace. For example: 

    # ...
    - kind: monitoring
      managed: false
    - kind: objectstorage
      managed: false
# ...
  4. Click Create.

  5. Optional: Confirm that the pods are running on infra nodes.

    1. List all Quay-related pods along with the nodes that they are scheduled on by entering the following command: 

      $ oc get pods -n <annotated_namespace> -o wide | grep example-registry
       
...
NAME                                               READY   STATUS      RESTARTS   AGE   IP             NODE                                                              NOMINATED NODE   READINESS GATES
example-registry-clair-app-5f95d685bd-dgjf6        1/1     Running     0          52m   10.128.4.12    example-cluster-new-c5qqp-worker-b-wrhw4.c.quay-devel.internal   <none>           <none>
...

  1. Confirm that the nodes listed include only nodes labeled infra by running the following command: 

    $ oc get nodes -l node-role.kubernetes.io/infra -o name

    Example output

    node/example-cluster-new-c5qqp-worker-b-4zxx5.c.quay-devel.internal modified
node/example-cluster-new-c5qqp-worker-b-kz6jn.c.quay-devel.internal modified
node/example-cluster-new-c5qqp-worker-b-wrhw4.c.quay-devel.internal modified

    Note

    If any pod appears on a non-infra node, revisit your namespace annotations and deployment patching.

    1. Restart all pods for the Red Hat Quay registry by entering the following command: 

      $ oc delete pod -n <annotated_namespace> --all

    2. Check the status of the pods by entering the following command: 

      $ oc get pods -n <annotated_namespace>
       
      ...
NAME                                               READY   STATUS      RESTARTS   AGE
example-registry-clair-app-5f95d685bd-dgjf6        1/1     Running     0          5m4s
...
Red Hat logoGithubredditYoutubeTwitter

Formazione

Prova, acquista e vendi

Community

Informazioni sulla documentazione di Red Hat

Aiutiamo gli utenti Red Hat a innovarsi e raggiungere i propri obiettivi con i nostri prodotti e servizi grazie a contenuti di cui possono fidarsi. Esplora i nostri ultimi aggiornamenti.

Rendiamo l’open source più inclusivo

Red Hat si impegna a sostituire il linguaggio problematico nel codice, nella documentazione e nelle proprietà web. Per maggiori dettagli, visita il Blog di Red Hat.

Informazioni su Red Hat

Forniamo soluzioni consolidate che rendono più semplice per le aziende lavorare su piattaforme e ambienti diversi, dal datacenter centrale all'edge della rete.

Theme

© 2026 Red HatTorna in cima