Red Hat OpenShift on IBM Cloud (ROKS)

Red Hat OpenShift on IBM Cloud (ROKS)

Red Hat OpenShift on IBM Cloud (ROKS) is a fully managed OpenShift Container Platform that combines the enterprise-grade Kubernetes distribution from Red Hat with IBM Cloud managed infrastructure. ROKS handles the OpenShift control plane, etcd, container runtime, and platform operators while you focus on deploying applications. IBM manages the upgrade lifecycle, security patching, and high availability of the control plane components.

ROKS is the natural choice for organizations that have standardized on OpenShift for their container platform, especially those running OpenShift on-premises who want a consistent experience in the public cloud. ROKS includes all OpenShift features: built-in CI/CD pipelines (Tekton), service mesh (Istio-based), developer console, OperatorHub, source-to-image (S2I) builds, and integrated monitoring with Prometheus and Grafana.

This guide covers ROKS cluster creation, the differences between ROKS and IKS, OpenShift Routes and networking, OperatorHub integration, Cloud Pak deployment, image streams, builds, and production best practices.

ROKS vs IKS: Key Differences

Both ROKS and IKS run on the same IBM Cloud infrastructure and share many features, but there are important differences:

• Platform: ROKS runs Red Hat OpenShift Container Platform; IKS runs community Kubernetes.
• Minimum workers: ROKS requires at least 2 worker nodes per zone (4 vCPUs each); IKS has no minimum beyond 1 worker.
• Networking: ROKS uses OpenShift Routes (HAProxy-based) in addition to Kubernetes Ingress; IKS uses only Kubernetes Ingress with ALB.
• Container runtime: ROKS uses CRI-O; IKS uses containerd.
• Developer experience: ROKS includes the OpenShift web console, developer perspective, built-in CI/CD, and S2I builds.
• Operators: ROKS includes OperatorHub with hundreds of certified operators; IKS requires manual operator installation.
• Pricing: ROKS worker nodes cost approximately 30% more than equivalent IKS workers due to the OpenShift license.
• COS dependency: ROKS requires a Cloud Object Storage instance for internal registry storage; IKS does not.

Creating a ROKS Cluster

# Create a COS instance (required for ROKS internal registry)
ibmcloud resource service-instance-create roks-registry-cos \
  cloud-object-storage standard global

# Create a ROKS cluster on VPC
ibmcloud oc cluster create vpc-gen2 \
  --name prod-roks \
  --zone us-south-1 \
  --vpc-id <vpc-id> \
  --subnet-id <subnet-z1-id> \
  --flavor bx2.16x64 \
  --workers 3 \
  --version 4.15_openshift \
  --cos-instance <cos-instance-crn> \
  --disable-public-service-endpoint

# Add workers in additional zones
ibmcloud oc zone add vpc-gen2 \
  --cluster prod-roks \
  --zone us-south-2 \
  --subnet-id <subnet-z2-id> \
  --worker-pool default

# Get cluster credentials
ibmcloud oc cluster config --cluster prod-roks --admin

# Verify connection
oc get nodes
oc get clusterversion

OpenShift Routes and Networking

OpenShift Routes are the native mechanism for exposing services externally in ROKS. Routes are managed by the OpenShift Router (HAProxy-based) and provide features beyond standard Kubernetes Ingress, including custom TLS configurations, blue-green deployments via traffic splitting, and automatic certificate management.

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: my-app-route
  namespace: production
spec:
  host: app.example.com
  port:
    targetPort: 8080
  tls:
    termination: edge
    insecureEdgeTerminationPolicy: Redirect
    certificate: |
      -----BEGIN CERTIFICATE-----
      ...
      -----END CERTIFICATE-----
    key: |
      -----BEGIN RSA PRIVATE KEY-----
      ...
      -----END RSA PRIVATE KEY-----
  to:
    kind: Service
    name: my-app-service
    weight: 100
  alternateBackends:
  - kind: Service
    name: my-app-service-canary
    weight: 10

Network Policies

ROKS supports both Kubernetes NetworkPolicy and OpenShift-specific network policy features. By default, all pods in a ROKS cluster can communicate with each other. Use network policies to implement micro-segmentation and restrict traffic between namespaces.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-ingress
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-same-namespace
  namespace: production
spec:
  podSelector: {}
  ingress:
  - from:
    - podSelector: {}

OperatorHub and Operators

ROKS includes OperatorHub, a marketplace of Kubernetes operators that automate the deployment and management of complex applications. Operators available through OperatorHub include databases (PostgreSQL, MongoDB, Redis), messaging (Kafka, RabbitMQ), monitoring (Prometheus, Grafana), and IBM Cloud Paks.

# List available operators
oc get packagemanifests -n openshift-marketplace

# Install an operator via CLI
cat <<YAML | oc apply -f -
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: strimzi-kafka-operator
  namespace: openshift-operators
spec:
  channel: stable
  name: strimzi-kafka-operator
  source: community-operators
  sourceNamespace: openshift-marketplace
YAML

Source-to-Image (S2I) Builds

OpenShift S2I automatically builds container images from source code without requiring a Dockerfile. S2I combines your application source with a builder image that contains the runtime environment and build tools. This simplifies the developer experience and enforces consistent, secure base images across the organization.

# Create an application from source code
oc new-app https://github.com/example/nodejs-app.git \
  --name=my-node-app \
  --strategy=source

# Create from source with a specific builder image
oc new-app nodejs:18~https://github.com/example/nodejs-app.git \
  --name=my-node-app

# Watch the build progress
oc logs -f buildconfig/my-node-app

# Expose the application via a route
oc expose service my-node-app

Cloud Paks on ROKS

IBM Cloud Paks are enterprise software packages designed to run on OpenShift. They provide pre-integrated, AI-powered solutions for specific business domains. Running Cloud Paks on ROKS eliminates the infrastructure management burden while providing the full Cloud Pak functionality.

• Cloud Pak for Data: AI, data management, and governance platform with Watson Studio, Db2, and DataStage.
• Cloud Pak for Integration: Application and data integration with MQ, API Connect, Event Streams, and App Connect.
• Cloud Pak for Business Automation: Workflow automation, content management, and business rules.
• Cloud Pak for Security: Threat management, data security, and identity access management.
• Cloud Pak for Watson AIOps: IT operations management with AI-powered incident resolution.

Image Streams

Image streams are an OpenShift concept that provides an abstraction layer over container image references. Instead of referencing specific image tags in your deployments, you reference image stream tags that can be updated independently. This enables automatic rollouts when new images are pushed and simplifies image promotion across environments.

# Import an external image into an image stream
oc import-image my-app:latest \
  --from=us.icr.io/my-namespace/my-app:v2.0 \
  --confirm

# Tag an image for promotion
oc tag my-app:latest my-app:production

# Set up automatic deployment on image change
oc set triggers deployment/my-app \
  --from-image=my-app:production \
  --containers=my-app

Monitoring and Logging

ROKS includes built-in monitoring with Prometheus and Grafana through the OpenShift Monitoring stack. This provides out-of-the-box dashboards for cluster health, node utilization, pod performance, and API server metrics. For application-level monitoring, enable user workload monitoring to allow your applications to expose custom Prometheus metrics.

For centralized logging, integrate with IBM Cloud Log Analysis or use the OpenShift Logging operator (based on Vector and Elasticsearch/Loki) for in-cluster log aggregation.

Security Hardening

• Enable the Security Context Constraints (SCCs) that match your security requirements; avoid granting privileged SCC.
• Use OAuth integration to connect ROKS authentication with your corporate identity provider.
• Enable audit logging and forward audit events to IBM Cloud Activity Tracker.
• Restrict image sources using image policy configurations to only allow pulls from trusted registries.
• Use OpenShift compliance operators to scan the cluster against CIS benchmarks.
• Enable encryption at rest using IBM Key Protect for etcd and persistent volumes.

Production Checklist

• Deploy at least 3 workers per zone across a minimum of 2 zones.
• Use bx2.16x64 or larger flavors for production workloads.
• Disable public service endpoint for cluster API access.
• Configure cluster autoscaler with appropriate limits.
• Integrate with IBM Container Registry for image management.
• Set up GitOps with ArgoCD (OpenShift GitOps operator).
• Enable user workload monitoring for application metrics.
• Configure resource quotas and limit ranges per namespace.
• Use network policies to implement namespace isolation.
• Apply OpenShift entitlements from existing Cloud Pak licenses.