Activity 1: Moving OpenShift v4 ingress pods to Infra nodes

Moving OpenShift v4 Ingress Pods to infrastructure nodes involves a few steps. Here’s a general guide:

Label the Infrastructure Nodes: You first need to label your infrastructure nodes. This can be done using the oc command line tool. Assume you have already set up your infrastructure nodes.

oc label node node-role.kubernetes.io/infra=””

Replace with the name of your node. Repeat this for all the infrastructure nodes.

Patch the Ingress Controller: The next step is to patch the IngressController to run on your infrastructure nodes. This involves changing the node selector for the IngressController to match your infrastructure nodes.

First, identify your IngressController name:

oc get ingresscontroller -n openshift-ingress-operator

Then, patch the IngressController to run on infra nodes:

oc patch ingresscontroller -n openshift-ingress-operator –type=merge -p ‘{“spec”:{“nodePlacement”:{“nodeSelector”:{“matchLabels”:{“node-role.kubernetes.io/infra”:””}}}}}’

Replace with the name of your IngressController.

Verify the Changes: After patching the IngressController, you should verify that the Ingress pods are now running on the infrastructure nodes. This can be done by checking the pods in the openshift-ingress namespace:

oc get pods -n openshift-ingress -o wide

Check the NODE column to ensure that the pods are now running on the infrastructure nodes.

Additional Considerations: Depending on your OpenShift setup, you might also need to consider taints and tolerations to ensure that other workloads do not get scheduled on your infrastructure nodes. This can be done by tainting the infra nodes and then adding tolerations to the IngressController.

To taint infra nodes:

oc adm taint nodes node-role.kubernetes.io/infra=:NoSchedule

To add tolerations to the IngressController:

oc patch ingresscontroller -n openshift-ingress-operator –type=merge -p ‘{“spec”:{“nodePlacement”:{“tolerations”:[{“effect”:”NoSchedule”,”key”:”node-role.kubernetes.io/infra”}]}}}’

Remember to replace and with your specific node names and controller names. These steps should effectively move your OpenShift v4 Ingress Pods to your infrastructure nodes.

Activity 2: Move Grafana Pods to Infra Nodes:

To move your Grafana monitoring pod to OpenShift v4 infra nodes below are the steps you may follow:

Access to OpenShift Cluster: Ensure you have administrative access to your OpenShift cluster.

Installed CLI Tools: You should have oc (OpenShift CLI) installed and configured to interact with your cluster.

Existing Grafana Setup: Your Grafana pod should be running in your current environment.
Knowledge of Infra Nodes: Ensure you know the labels or characteristics of your infra nodes.

Steps to Move Grafana to Infra Nodes:

1. Label Infra Nodes (if not already labeled)

Infra nodes in OpenShift are typically labeled for specific workloads. If they’re not already labeled, you can do so by running:

oc label nodes node-role.kubernetes.io/infra=””

Replace with the name of your infra nodes.

2. Create/Modify Node Selector for Grafana

You’ll need to adjust the node selector in your Grafana deployment to target infra nodes. This can be done by editing the deployment configuration.

a. Edit Grafana Deployment:

oc edit deployment -n

Replace and with your deployment’s name and namespace.

b. Add/Modify Node Selector:

In the deployment configuration, find the spec.template.spec.nodeSelector section and add or modify it to target infra nodes:

spec:
  template:
    spec:
      nodeSelector:
        node-role.kubernetes.io/infra: “”

3. Apply Resource Limits (Optional but Recommended)

Consider applying resource limits and requests to ensure your Grafana pod gets the necessary resources on the infra node.

resources:
  requests:
    memory: “1Gi”
    cpu: “500m”
  limits:
    memory: “2Gi”
    cpu: “1”

4. Monitor Pod Migration

After updating the deployment, OpenShift will schedule the Grafana pod on an infra node. Monitor the migration process:

oc get pods -n -o wide

Check that the Grafana pod is running on the intended infra node.

5. Validate Grafana Functionality

Once migrated, ensure that Grafana is functioning correctly. Access the Grafana UI and verify that your dashboards and data sources are working as expected.

Troubleshooting

If the Grafana pod fails to schedule on an infra node, check for taints on the infra nodes that might prevent scheduling.

Review pod logs if Grafana is not starting or functioning correctly after the move.

Post-Migration

Update any monitoring or alerting configurations if necessary.

Document the changes for future reference.

Moving your Grafana pod to infra nodes can optimize resource usage and performance, but always ensure you have a backup or a rollback plan in case of issues.