2. Day 2-operations on OpenShift Operations Training

2.1 Infrastructure nodes

Mon, 01 Jan 0001 00:00:00 +0000

Not exactly a day 2-operations task, but one that immensily simplifies operations. The concept of infrastructure nodes was more prominently advertised by Red Hat when OpenShift 3 was the latest and greatest. This evidently changed somehow for OpenShift 4, but with a bit of legwork we’re able to create those, too.

Infra nodes are dedicated worker nodes intended for infrastructure components such as the image registry, routers or the whole monitoring stack. Providing dedicated nodes helps ensuring that there’s always enough resources for infrastructure components.

2.2 Infrastructure components

Mon, 01 Jan 0001 00:00:00 +0000

Now that we have fresh infra nodes up and running, let’s see to it that they have something to do. The usual suspects to run on infrastructure nodes are:

routers
registry
most of the monitoring components
most of the logging components

Red Hat provides a detailed list of what components don’t incur OpenShift Container Platform worker subscriptions . So if you have any other components listed there that are not going to be looked at in this training, it could make perfect sense to move these components as well.

2.3 Restore

Mon, 01 Jan 0001 00:00:00 +0000

Task 2.3.1: Restoring user workload backups

In the backup lab you created a scheduled backup of all resources in namespace uptime-app-prod. Now we are going to test the restore procedure.

Warning

To keep your restore time as short as possible, make sure you read through the whole procedure, understand it and maybe even prepare all resources for the restore before deleting the project!

Make sure you read above warning, then go ahead and delete the project uptime-app-prod.

2.4 Update

Mon, 01 Jan 0001 00:00:00 +0000

In this lab we will update our OpenShift 4 cluster to the latest stable errata release.

Updating an OpenShift 4 cluster is a fully automated process that is managed by several cluster operators. If the cluster has Internet access, updates are provided over-the-air, otherwise you need to synchronize the new images to an internal registry prior to starting the update or use a pull-through registry.

Check “Updating a restricted network cluster” for details on updating a cluster in a disconnected environment.

2.5 Worker nodes

Mon, 01 Jan 0001 00:00:00 +0000

We initially installed this cluster using only worker nodes. We then successfully created infra nodes and moved all infrastructure components onto them. Now, essentially the only real workload that’s running on the 3 worker nodes is our uptime application.

Without going into detail yet on how and where you can find dashboards and metrics for capacity monitoring, it’s safe to say that one small Python app doesn’t need 3 worker nodes with 8 CPU cores and 32 GB of memory. So we are going to decrease the number of worker nodes to 2 and also reduce their size.

2.6 Control plane nodes

Mon, 01 Jan 0001 00:00:00 +0000

Note

While many occurrences of “master” have been replaced throughout OpenShift and Kubernetes, this is unfortunately not yet the case for Machine resources. This is why you are going to encounter a mixture of “control plane” and “master” terms in this lab.

During this lab, we will learn how to replace a failed control plane node. As long as we do not lose the majority of our control plane nodes, we can simply replace those that failed. If we lose the majority (e.g., 2 out of 3), we need to restore the state of etcd from a previously created snapshot, which will not be covered in this lab.