Containers, OpenShift and co-location with z/OS

Containers and Kubernetes run on Linux on Z just as on other platforms, as long as images are built for s390x. Running Linux next to z/OS on the same machine allows fast, private connections such as HiperSockets, but it is not the right answer for every workload.

Containers on s390x

A container image contains binaries, so it is built for a particular architecture. Image registries handle this with multi-architecture images: one image name and tag points to a manifest list with a separate image for each platform, such as linux/amd64, linux/arm64 and linux/s390x. When a node on IBM Z pulls the image, the runtime chooses the s390x variant automatically. Many official base images on public registries publish an s390x variant; check before you depend on one.

Building a multi-architecture image (illustrative)

$ docker buildx build \
    --platform linux/amd64,linux/s390x \
    -t registry.example.com/payments/api:1.4.0 \
    --push .

$ docker buildx imagetools inspect registry.example.com/payments/api:1.4.0
  Platform:  linux/amd64
  Platform:  linux/s390x

Reading the build commandWhat it means

buildx build

Docker's builder that can produce images for several platforms in one go

--platform linux/amd64,linux/s390x

Build one image for x86 and one for IBM Z, published under the same tag

--push

Push the images and the manifest list to the registry

imagetools inspect

Show which platforms a tag actually contains, a quick check before deploying

Building for a foreign architecture on an x86 laptop usually uses emulation, which is slow but fine for small images. Many teams add a native s390x build agent to their CI/CD pipeline instead.

Kubernetes and OpenShift on Z

Upstream Kubernetes supports s390x, and Red Hat OpenShift Container Platform is supported on IBM Z and LinuxONE, with cluster nodes running as z/VM or KVM guests or in LPARs (supported combinations depend on the OpenShift version). From a developer's point of view an OpenShift cluster on Z is the same: the same oc and kubectl commands, the same deployments, routes and operators. The differences are that every image must have an s390x variant and that capacity is measured in IFLs.

Co-location with z/OS

When Linux and z/OS share a machine, they can talk without leaving the box. HiperSockets is a hardware feature that provides TCP/IP connections between LPARs on the same CPC through memory, with no physical network adapter, cable or switch involved. Applications see a normal IP network. For z/OS to Linux traffic, sites can also use SMC-D (Shared Memory Communications - Direct), which lets TCP connections between eligible LPARs on the same machine move data through shared memory, when both sides are configured for it.

A typical co-located design

Mobile appinternet

API layercontainers on Linux on Z

HiperSocketsin-memory TCP/IP

z/OSCICS, Db2, MQ

Latency: no external network hops between the front end and the system of record.
Security: traffic between the LPARs never appears on a physical network, which simplifies some network controls (encryption and access control are still required by most policies).
Resilience: fewer network devices in the path to fail.

When not to use Linux on Z

Situation	Why it is a poor fit
Key software is x86-only	No s390x build means no deployment, whatever the other benefits
GPU-dependent work	These workloads are generally better served elsewhere
A single small application with no link to z/OS	Little consolidation benefit to justify the platform skills and setup
Team has no Linux on Z skills and no support model	Operational risk outweighs gains until skills and ownership exist
Highly elastic, short-lived capacity	Public cloud bursting may be simpler and cheaper

Containers on s390x

Kubernetes and OpenShift on Z

Co-location with z/OS

When not to use Linux on Z

Common mistakes

What you will see at work

Key terms