This is a cache of https://docs.openshift.com/gitops/1.13/gitops_workloads_infranodes/running-gitops-control-plane-workloads-on-infrastructure-nodes.html. It is a snapshot of the page at 2024-11-24T01:01:37.838+0000.
Running GitOps control plane workloads on infrastructure nodes | GitOps workloads on infrastructure nodes | Red Hat OpenShift GitOps 1.13
    OpenShift docs are moving and will soon only be available at docs.redhat.com, the home of all Red Hat product documentation. Explore the new docs experience today.
  1. Documentation
    2. history bug_report picture_as_pdf
×

Running GitOps control plane workloads on infrastructure nodes

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.

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

Moving GitOps control plane workloads to 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=

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

    $ oc edit gitopsservice -n openshift-gitops

  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

  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

  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

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.

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.

Moving the GitOps Operator pod to infrastructure nodes

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)
    1 Replace <node_name> with the name of the node you want to label as infrastructure node.
    Example output
    node/<node_name> labeled

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

    $ oc -n openshift-gitops-operator edit subscription openshift-gitops-operator

  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
    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

  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
    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)
    1 Ensure that the listed <node_name> is the node with the node-role.kubernetes.io/infra label.

Additional resources