Red Hat Summit Red Hat SummitSupportConsoleDevelopersStart a trialContact

GitOps workloads on infrastructure nodes

Red Hat OpenShift GitOps 1.13

Enter a short description here.

Red Hat OpenShift Documentation Team

Abstract

A short overview and summary of the book's subject and purpose, traditionally no more than one paragraph long.

You can use infrastructure nodes to isolate infrastructure workloads for two primary purposes:

  • To prevent billing costs associated with the number of subscriptions
  • To separate maintenance and management

You can use the OpenShift Container Platform to run GitOps control plane workloads on infrastructure nodes. This includes the Operator pod and the control plane workloads created by the Red Hat OpenShift GitOps Operator in the openshift-gitops namespace by default, including the default Argo CD instance in this namespace.

With GitOps control plane workloads, you can securely and declaratively isolate the infrastructure workloads by creating multiple isolated Argo CD instances in a cluster, with full control over what an Argo CD instance is capable of. In addition, you can manage these Argo CD instances declaratively across multiple developer namespaces. By using taints, you can ensure that only infrastructure components run on these nodes.

Note

All other Argo CD instances installed in user namespaces are not eligible to run on infrastructure nodes.

You can move the GitOps control plane workloads installed by the Red Hat OpenShift GitOps to the infrastructure nodes. The following are the control plane workloads that you can move:

  • kam deployment
  • cluster deployment (backend service)
  • openshift-gitops-applicationset-controller deployment
  • openshift-gitops-dex-server deployment
  • openshift-gitops-redis deployment
  • openshift-gitops-redis-ha-haproxy deployment
  • openshift-gitops-repo-sever deployment
  • openshift-gitops-server deployment
  • openshift-gitops-application-controller statefulset
  • openshift-gitops-redis-server statefulset

Procedure

  1. Label existing nodes as infrastructure by running the following command: 

    $ oc label node <node-name> node-role.kubernetes.io/infra=
    Copy to Clipboard Toggle word wrap

  2. Edit the GitOpsService custom resource (CR) to add the infrastructure node selector: 

    $ oc edit gitopsservice -n openshift-gitops
    Copy to Clipboard Toggle word wrap

  3. In the GitOpsService CR file, add runOnInfra field to the spec section and set it to true. This field moves the control plane workloads in openshift-gitops namespace to the infrastructure nodes: 

    apiVersion: pipelines.openshift.io/v1alpha1
kind: GitopsService
metadata:
  name: cluster
spec:
  runOnInfra: true
    Copy to Clipboard Toggle word wrap

  4. Optional: Apply taints and isolate the workloads on infrastructure nodes and prevent other workloads from scheduling on these nodes. 

    $ oc adm taint nodes -l node-role.kubernetes.io/infra
infra=reserved:NoSchedule infra=reserved:NoExecute
    Copy to Clipboard Toggle word wrap

  5. Optional: If you apply taints to the nodes, you can add tolerations in the GitOpsService CR: 

    spec:
  runOnInfra: true
  tolerations:
  - effect: NoSchedule
    key: infra
    value: reserved
  - effect: NoExecute
    key: infra
    value: reserved
    Copy to Clipboard Toggle word wrap

To verify that the workloads are scheduled on infrastructure nodes in the Red Hat OpenShift GitOps namespace, click any of the pod names and ensure that the Node selector and Tolerations have been added.

Note

Any manually added Node selectors and Tolerations in the default Argo CD CR will be overwritten by the toggle and the tolerations in the GitOpsService CR.

You can move the GitOps Operator pod to the infrastructure nodes.

Prerequisites

  • You have installed the Red Hat OpenShift GitOps Operator in your cluster.
  • You have access to the cluster with cluster-admin privileges.

Procedure

  1. Label an existing node as infrastructure node by running the following command: 

    $ oc label node <node_name> node-role.kubernetes.io/infra=
    1
    Copy to Clipboard Toggle word wrap
    1
    Replace <node_name> with the name of the node you want to label as infrastructure node.

    Example output

    node/<node_name> labeled
    Copy to Clipboard Toggle word wrap

  2. Edit the Red Hat OpenShift GitOps Subscription resource by running the following command: 

    $ oc -n openshift-gitops-operator edit subscription openshift-gitops-operator
    Copy to Clipboard Toggle word wrap

  3. Add nodeSelector and tolerations to the spec.config field in the Subscription resource:

    Example Subscription

    apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: openshift-gitops-operator
  namespace: openshift-gitops-operator
spec:
  config:
    nodeSelector:
    1 
    
      node-role.kubernetes.io/infra: ""
    tolerations:
    2 
    
    - key: node-role.kubernetes.io/infra
      operator: Exists
      effect: NoSchedule
    Copy to Clipboard Toggle word wrap

    1
    This ensures that the operator pod is only scheduled on an infrastructure node.
    2
    This ensures that the pod is accepted by the infrastructure node.

    Example output

    subscription.operators.coreos.com/openshift-gitops-operator edited
    Copy to Clipboard Toggle word wrap

  4. Verify that the GitOps Operator pod is running on the infrastructure node by running the following command: 

    $ oc -n openshift-gitops-operator get po -owide
    Copy to Clipboard Toggle word wrap

    Example output

    NAME                                                            READY   STATUS    RESTARTS   AGE   IP              NODE            NOMINATED NODE   READINESS GATES
openshift-gitops-operator-controller-manager-abcd               2/2     Running   0          11m   94.142.44.126   <node_name>     <none>           <none>
    1
    Copy to Clipboard Toggle word wrap

    1
    Ensure that the listed <node_name> is the node with the node-role.kubernetes.io/infra label.

Legal Notice
Copy link

Copyright © 2024 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
Back to top
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2025 Red Hat