Implement a multi-architecture OpenShift cluster with s390x LPAR

Learn how to integrate s390x workers into your OpenShift cluster in order to layer new microservices over existing architecture.

Access the Developer Sandbox

Now that we have the ignition files modified, we’re able to get our installation run successfully and join the node to the cluster. Once done, we will be able to get our s390x architecture workload deployed as needed.

In order to get full benefit from taking this lesson, you need:

  • A GitHub account.

In this lesson, you will:

  • Install a logical partition (LPAR)
  • Create a custom configuration file using ConfigMap in OpenShift.
  • Set up simple GitHub authentication.

Boot and install

Next, we need to import the SSH key signature for the SFTP server into HMC. Then, we can set up the SFTP server as the boot source and select the .INS file (Figure 1).

Set the SFTP server as the boot source.
Figure 1: Set the SFTP server as the boot source.

Now we’re ready to start the logical partition (LPAR) and observe the installation process in the Operating System Messages view (Figure 2).

A list of the Operating System Messages.
Figure 2: A list of the Operating System Messages.

If the installation runs through successfully, the LPAR will reboot and show a login prompt. 

At that point, we need to stop the LPAR, switch the boot source to SAN, and start it again.

Next, you will learn how to join the new node to your existing cluster. 

Join the node to the cluster

The newly installed node is running and should show up in our cluster as shown in Figure 3:

Nodes in the OCP console with an LPAR node joined.
Figure 3: Nodes in the OCP console with an LPAR node joined.

Approve the certificate-signing request to complete joining the node to the cluster, then make sure all the pods on the node start correctly and the node transitions into a Ready state (Figure 4).

Pods on LPAR node in the OCP console.
Figure 4: Pods on LPAR node in the OCP console.

Deploy an s390x-architecture workload

As a test, we can deploy a simple s390x architecture bash pod:

kind: Deployment apiVersion: apps/v1 metadata:   name: s390x-demo   namespace: s390x-demo   labels:	app: s390x-demo spec:   replicas: 1   template:   	labels:     	app: s390x-demo	spec:   	containers:     	- name: bash       	  image: 'docker.io/s390x/bash:latest'     	  command:         	- sh         	- '-c'         	- echo 'Hello from s390x!' && sleep 3600       	nodeSelector:     	kubernetes.io/arch: s390x

Confirm it runs (Figure 5):

A demo workload running on LPAR through Red Hat OpenShift.
Figure 5: A demo workload running on LPAR through Red Hat OpenShift.

Summary

Now that you have s390x worker nodes in your OpenShift cluster, you're ready to take advantage of mainframe capabilities within your cloud-native infrastructure. 

Here are some paths forward:

Workload migration

Start by identifying workloads that would benefit from s390x's strengths:

  • High-throughput transaction processing applications

  • Cryptographic operations leveraging IBM Hyperprotect crypto modules

  • I/O-intensive workloads requiring consistent performance

  • Applications requiring strict isolation and security boundaries

Multi-architecture CI/CD

Update your build pipelines to create multi-architecture container images. Tools like Buildah and Podman support building for multiple architectures, ensuring your applications can run seamlessly across both x86 and s390x nodes.

The integration of s390x into your OpenShift cluster isn't just about adding nodes. It's about bridging decades of enterprise computing evolution. You now have a platform where COBOL can coexist with Go, where DB2 stored procedures can be invoked by microservices, and where the reliability of mainframe hardware underpins cloud-native applications.

Welcome to truly hybrid computing.

Ready to learn more? 

Previous resource
Modify the ignition files