IKS: Kubernetes on IBM Cloud

IBM Kubernetes Service (IKS) Overview

IBM Kubernetes Service (IKS) is a managed Kubernetes platform that handles the control plane, etcd, and cluster lifecycle management while you focus on deploying and managing your containerized applications. IKS supports both Classic Infrastructure and VPC deployments, with VPC being the recommended approach for new clusters due to its superior networking capabilities, security isolation, and integration with modern IBM Cloud services.

IKS differentiates itself from other managed Kubernetes offerings through its deep integration with IBM Cloud services (Logging, Monitoring, Container Registry, Key Protect, Secrets Manager), built-in security features (Kubernetes security benchmarks, image vulnerability scanning, pod security admission), and the unique ability to run both community Kubernetes and Red Hat OpenShift on the same platform. This guide focuses on community Kubernetes via IKS; see the ROKS guide for OpenShift-specific content.

This guide covers cluster creation and architecture, worker pool management, networking modes, storage integration, security hardening, logging and monitoring, and production best practices for running IKS at scale.

Cluster Architecture

Control Plane

The IKS control plane (API server, etcd, scheduler, controller manager) is fully managed by IBM and runs in IBM-owned infrastructure, separated from your worker nodes. The control plane is automatically backed up, patched, and scaled. For production workloads, the control plane is highly available by default, running across multiple zones in the region. You can access the Kubernetes API server through both public and private service endpoints.

Worker Nodes

Worker nodes are VPC virtual server instances that run your containerized workloads. You choose the flavor (machine type) based on your workload requirements. IBM Cloud offers a wide range of flavors organized into families:

• bx2 (Balanced): General-purpose with balanced CPU-to-memory ratio (e.g., bx2.4x16, bx2.8x32, bx2.16x64). Best for most workloads.
• cx2 (Compute): Higher CPU-to-memory ratio for compute-intensive tasks (e.g., cx2.4x8, cx2.8x16).
• mx2 (Memory): Higher memory-to-CPU ratio for memory-intensive workloads (e.g., mx2.4x32, mx2.8x64).
• gx3 (GPU): Equipped with NVIDIA GPUs for ML training and inference (e.g., gx3.16x80x1L4).
• ux2 (Ultra High Memory): Very high memory for in-memory databases and analytics.

Creating an IKS Cluster

# Create a VPC-based IKS cluster across 3 zones
ibmcloud ks cluster create vpc-gen2 \
  --name prod-cluster \
  --zone us-south-1 \
  --vpc-id <vpc-id> \
  --subnet-id <subnet-z1-id> \
  --flavor bx2.8x32 \
  --workers 3 \
  --kube-version 1.30 \
  --disable-public-service-endpoint

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

ibmcloud ks zone add vpc-gen2 \
  --cluster prod-cluster \
  --zone us-south-3 \
  --subnet-id <subnet-z3-id> \
  --worker-pool default

# Check cluster status
ibmcloud ks cluster get --cluster prod-cluster

# Configure kubectl
ibmcloud ks cluster config --cluster prod-cluster
kubectl get nodes

Worker Pools

Worker pools group worker nodes with the same flavor, enabling you to run different machine types for different workload requirements. A common pattern is to have a default pool for general workloads, a memory-optimized pool for databases, and a GPU pool for machine learning.

# Create a GPU worker pool
ibmcloud ks worker-pool create vpc-gen2 \
  --name gpu-pool \
  --cluster prod-cluster \
  --flavor gx3.16x80x1L4 \
  --size-per-zone 1 \
  --label workload=gpu

# Add a taint to the GPU pool
kubectl taint nodes -l workload=gpu nvidia.com/gpu=true:NoSchedule

# Create a high-memory pool
ibmcloud ks worker-pool create vpc-gen2 \
  --name memory-pool \
  --cluster prod-cluster \
  --flavor mx2.8x64 \
  --size-per-zone 2 \
  --label workload=memory

Networking

Pod and Service Networking

IKS uses Calico as the Container Network Interface (CNI) plugin, providing network policy enforcement, IPAM, and pod-to-pod networking. By default, pods receive IP addresses from the pod subnet CIDR (172.17.0.0/18) and services use the service subnet CIDR (172.21.0.0/16). These ranges are internal to the cluster and do not conflict with VPC subnets.

Application Load Balancer (ALB)

IKS includes a managed Ingress controller based on the Kubernetes Ingress resource. The ALB handles TLS termination, path-based routing, and health checks for your applications. For VPC clusters, a VPC Load Balancer is automatically created to distribute traffic to the ALB pods.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app-ingress
  annotations:
    kubernetes.io/ingress.class: "public-iks-k8s-nginx"
spec:
  tls:
  - hosts:
    - app.example.com
    secretName: my-tls-secret
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 8080
      - path: /
        pathType: Prefix
        backend:
          service:
            name: web-service
            port:
              number: 3000

Storage

IKS integrates with several IBM Cloud storage services through CSI drivers:

• VPC Block Storage: Persistent block volumes that attach to a single worker node. Choose from predefined IOPS tiers or custom IOPS.
• IBM Cloud Object Storage: S3-compatible object storage mounted as PVCs using the s3fs FUSE driver. Best for shared read-heavy workloads.
• IBM Cloud File Storage: NFS-based file storage for shared access across multiple pods. Available in Classic Infrastructure clusters.
• Portworx: Enterprise-grade software-defined storage for stateful workloads requiring replication, snapshots, and encryption.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
  - ReadWriteOnce
  storageClassName: ibmc-vpc-block-5iops-tier
  resources:
    requests:
      storage: 100Gi

Security

Image Security

IBM Cloud Container Registry (ICR) provides a private registry for storing and scanning container images. Vulnerability Advisor automatically scans images for known CVEs, CIS benchmark violations, and configuration issues. Enable image enforcement policies to prevent deploying images with critical vulnerabilities.

# Push an image to ICR
docker tag my-app us.icr.io/my-namespace/my-app:v1.0
docker push us.icr.io/my-namespace/my-app:v1.0

# Check vulnerability scan results
ibmcloud cr va us.icr.io/my-namespace/my-app:v1.0

Pod Security

IKS supports Kubernetes Pod Security Admission (PSA) to enforce security standards at the namespace level. Configure your namespaces with the appropriate security level:

apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

Secrets Management

Integrate IBM Cloud Secrets Manager with IKS to automatically inject secrets into your pods. The Secrets Manager CSI driver mounts secrets as volumes, and the External Secrets Operator syncs secrets from Secrets Manager into Kubernetes Secret objects.

Logging and Monitoring

IKS integrates natively with IBM Cloud Log Analysis (powered by LogDNA/Mezmo) and IBM Cloud Monitoring (powered by Sysdig). Deploy the logging and monitoring agents during cluster creation or add them later:

# Deploy the logging agent
ibmcloud ob logging config create \
  --cluster prod-cluster \
  --instance <log-analysis-instance-id>

# Deploy the monitoring agent
ibmcloud ob monitoring config create \
  --cluster prod-cluster \
  --instance <monitoring-instance-id>

Cluster Updates and Maintenance

IBM manages control plane updates automatically, but worker node updates require you to initiate the process. Use the rolling update strategy to update worker nodes one at a time with zero downtime:

# Check available updates
ibmcloud ks cluster get --cluster prod-cluster

# Update worker nodes (one at a time)
ibmcloud ks worker update \
  --cluster prod-cluster \
  --worker <worker-id>

# Or replace all workers in a pool (creates new workers first)
ibmcloud ks worker-pool rebalance \
  --cluster prod-cluster \
  --worker-pool default

Production Checklist

• Deploy across at least 3 availability zones with a minimum of 3 workers per zone.
• Disable the public service endpoint for the Kubernetes API.
• Enable cluster autoscaler with appropriate min/max bounds.
• Use Pod Disruption Budgets (PDBs) for critical workloads.
• Encrypt secrets at rest using Key Protect integration.
• Enable container image vulnerability scanning and enforcement.
• Configure resource requests and limits for all pods.
• Deploy logging and monitoring agents for observability.
• Use network policies (Calico) to restrict pod-to-pod communication.
• Implement GitOps with ArgoCD or Flux for declarative deployments.