πŸ“šBook Signing at KubeCon EU 2026Meet us at Booking.com HQ (Mon 18:30-21:00) & vCluster booth #521 (Tue 24 Mar, 12:30-1:30pm) β€” free book giveaway!RSVP Booking.com Event
Deployments intermediate ⏱ 20 minutes K8s 1.28+

OpenShift 4.21: New Features and Upgrade Guide

OpenShift 4.21 new features, K8s 1.34 alignment, upgrade from 4.20. Non-EUS release with latest innovations: in-place pod resize GA, DRA improvements.

By Luca Berton β€’ β€’ πŸ“– 7 min read

πŸ’‘ Quick Answer: OpenShift 4.21 is a non-EUS (standard) release based on Kubernetes 1.34. It gets 12 months of support. Available only via sequential upgrade from 4.20. Key highlights: in-place pod resize GA, Dynamic Resource Allocation improvements, OLM v1 as default, and enhanced observability. Non-EUS releases are typically used in dev/staging or by teams wanting the latest features.

The Problem

OpenShift 4.21 brings the latest Kubernetes innovations to production. As a non-EUS release, it has a shorter support window (12 months vs 18 for EUS). Teams must decide: upgrade to 4.21 for new features, or stay on 4.20 EUS and wait for 4.22 EUS.

Release Overview

PropertyValue
VersionOpenShift Container Platform 4.21
Kubernetes version1.34
RHCOS baseRHEL 9.6+
Release typeStandard (non-EUS)
Support duration12 months
GA dateQ4 2026 (estimated)
Previous version4.20 (EUS)
Next EUS4.22
flowchart LR
    V420["4.20<br/>(EUS, 18mo)"] -->|"Upgrade"| V421["4.21<br/>(Standard, 12mo)"]
    V421 -->|"Upgrade"| V422["4.22<br/>(EUS, 18mo)"]
    V420 -.->|"EUS-to-EUS<br/>(skip 4.21)"| V422
    
    style V420 fill:#2ecc71
    style V421 fill:#f39c12
    style V422 fill:#2ecc71

Who Should Upgrade to 4.21?

ScenarioRecommendation
Production workloads, conservativeStay on 4.20 EUS β†’ upgrade to 4.22 EUS
Dev/staging environmentsUpgrade to 4.21 β€” test new features early
Need in-place pod resize GAUpgrade to 4.21
Need DRA for GPU schedulingUpgrade to 4.21
Want OLM v1 as defaultUpgrade to 4.21
Don’t want short support windowStay on 4.20 EUS

New Features and Enhancements

Kubernetes 1.34 Alignment

  • In-place pod resize GA β€” Change CPU/memory requests/limits without pod restart
  • Sidecar container improvements β€” Enhanced lifecycle ordering, resource accounting
  • CEL admission policies GA β€” Replace webhook-based admission with in-process CEL
  • Job success/failure policies GA β€” Fine-grained job completion criteria
  • Recursive read-only mounts β€” Enhanced security for read-only volume mounts

In-Place Pod Resize (GA)

The headline feature β€” change resource allocations without pod restarts:

# Deploy with initial resources
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  template:
    spec:
      containers:
        - name: app
          image: my-app:latest
          resources:
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              cpu: 500m
              memory: 512Mi
          resizePolicy:
            - resourceName: cpu
              restartPolicy: NotRequired    # CPU changes don't restart
            - resourceName: memory
              restartPolicy: RestartContainer  # Memory increases may need restart
# Resize without restart
kubectl patch pod my-app-xxx --subresource resize --type merge -p '
{
  "spec": {
    "containers": [{
      "name": "app",
      "resources": {
        "requests": {"cpu": "200m", "memory": "256Mi"},
        "limits": {"cpu": "1", "memory": "1Gi"}
      }
    }]
  }
}'

# Check resize status
kubectl get pod my-app-xxx -o jsonpath='{.status.resize}'
# "Proposed" β†’ "InProgress" β†’ "" (complete)

kubectl get pod my-app-xxx -o jsonpath='{.status.containerStatuses[0].allocatedResources}'
# Shows currently allocated resources

Dynamic Resource Allocation (DRA) Enhancements

# DRA for GPU scheduling β€” structured parameters
apiVersion: resource.k8s.io/v1beta1
kind: ResourceClaim
metadata:
  name: gpu-claim
spec:
  devices:
    requests:
      - name: gpu
        deviceClassName: gpu.nvidia.com
        selectors:
          - cel:
              expression: "device.attributes['gpu-memory'].compareTo(quantity('40Gi')) >= 0"
    constraints:
      - requests: ["gpu"]
        matchAttribute: "topology-key"    # Co-locate GPUs
---
# Pod using DRA claim
apiVersion: v1
kind: Pod
metadata:
  name: ai-workload
spec:
  containers:
    - name: training
      image: nvcr.io/nvidia/pytorch:24.07-py3
      resources:
        claims:
          - name: gpu-claim
  resourceClaims:
    - name: gpu-claim
      resourceClaimName: gpu-claim

OLM v1 (Default)

# OLM v1 replaces Subscriptions with ClusterExtensions
# 4.21 makes OLM v1 the default operator management

# Install an operator via ClusterExtension (new way)
cat << 'EOF' | oc apply -f -
apiVersion: olm.operatorframework.io/v1
kind: ClusterExtension
metadata:
  name: cert-manager
spec:
  source:
    sourceType: Catalog
    catalog:
      packageName: cert-manager
      channels: ["stable"]
  install:
    namespace: cert-manager
    serviceAccount:
      name: cert-manager-installer
EOF

# vs old way (OLM v0 β€” still works but deprecated):
# apiVersion: operators.coreos.com/v1alpha1
# kind: Subscription
# spec:
#   channel: stable
#   name: cert-manager
#   source: redhat-operators
#   sourceNamespace: openshift-marketplace

Enhanced Observability

  • Cluster Observability Operator GA β€” Unified monitoring, logging, tracing
  • OpenTelemetry Collector GA β€” Replace Fluentd/Vector with OTel pipelines
  • Distributed tracing (Tempo) GA β€” Production-ready trace storage
  • Network observability β€” eBPF-based flow collection, DNS analytics
  • Metrics federation improvements β€” Better multi-cluster metrics aggregation

Networking

  • Gateway API 1.2 β€” Support for BackendTLSPolicy, session persistence
  • OVN-Kubernetes multi-homing GA β€” Multiple network interfaces without Multus
  • Network segmentation policies β€” Enhanced micro-segmentation for multi-tenancy
  • Egress IP improvements β€” Better failover for egress IP addresses

Platform Engineering

  • HyperShift improvements β€” Hosted control planes with better node management
  • MachineSet enhancements β€” Improved capacity-based autoscaling
  • Cluster profiles β€” Predefined configuration templates for different workload types
  • Enhanced audit logging β€” Structured JSON audit logs with enriched metadata

Upgrade from 4.20 to 4.21

# 1. Pre-flight
oc get co | grep -v "True.*False.*False"
oc adm upgrade

# 2. Check deprecated APIs
oc get apirequestcounts | grep "4.21"

# 3. Backup
oc debug node/master-0 -- chroot /host /usr/local/bin/cluster-backup.sh /home/core/backup

# 4. Set channel and upgrade
oc adm upgrade channel stable-4.21
oc adm upgrade --to-latest

# 5. Monitor
watch 'oc get clusterversion; echo; oc get mcp'

Deprecated and Removed Features

FeatureStatus in 4.21Action Required
OLM v0 (Subscriptions)Deprecated (still works)Migrate to ClusterExtensions
Builds v1 (BuildConfig)DeprecatedMigrate to Shipwright
Fluentd log collectorRemovedUse Vector or OTel Collector
OpenShift Service Mesh 2.xDeprecatedMigrate to Sail Operator (Istio)
oc adm catalog commandsDeprecatedUse oc-mirror v2

Version Comparison: 4.20 vs 4.21

Feature4.20 (EUS)4.21
Kubernetes1.331.34
In-place pod resizeBetaGA
OLM v1AvailableDefault
DRA structured paramsBetaEnhanced
Sidecar containersGAImproved
Support duration18 months12 months
Production recommendedβœ… Yes⚠️ For early adopters
Gateway API1.1 GA1.2 GA
OTel CollectorTech PreviewGA

Common Issues

IssueCauseFix
OLM v0 Subscription warningsOLM v1 is now defaultMigrate to ClusterExtension CRDs
Fluentd pods missingRemoved in 4.21Deploy Vector or OTel Collector
In-place resize not workingFeature gate not enabled on older nodesEnsure all nodes are upgraded
Service mesh brokenOSSM 2.x deprecatedInstall Sail Operator
Operator install failsOLM v1 catalog resolutionCheck ClusterExtension status, verify catalog

Best Practices

  • Don’t use 4.21 in production unless you need its features β€” 4.20 EUS has longer support
  • Test in-place pod resize thoroughly β€” behavior differs for CPU (no restart) vs memory (may restart)
  • Migrate to OLM v1 now β€” it’s the future, even if v0 still works
  • Plan your path to 4.22 EUS β€” 4.21 is a stepping stone
  • Replace Fluentd before upgrading β€” it’s removed, not just deprecated
  • Monitor DRA carefully β€” new scheduling path, different failure modes

Key Takeaways

  • 4.21 is non-EUS β€” 12 months support, best for dev/staging or early adopters
  • Kubernetes 1.34 brings in-place pod resize GA β€” change resources without restarts
  • OLM v1 becomes the default β€” start migrating from Subscriptions to ClusterExtensions
  • Fluentd removed β€” must use Vector or OpenTelemetry Collector
  • DRA improvements make GPU scheduling more flexible
  • Production clusters should stay on 4.20 EUS and wait for 4.22 EUS
  • Upgrade path: 4.20 β†’ 4.21 (sequential only)
#openshift #openshift-4.21 #upgrade #release-notes #kubernetes-1.34
Luca Berton
Written by Luca Berton

Principal Solutions Architect specializing in Kubernetes, AI/GPU infrastructure, and cloud-native platforms. Author of Kubernetes Recipes and creator of CopyPasteLearn courses.

Kubernetes Recipes book cover

Want More Kubernetes Recipes?

This recipe is from Kubernetes Recipes, our 750-page practical guide with hundreds of production-ready patterns.

Luca Berton Ansible Pilot Ansible by Example Open Empower K8s Recipes Terraform Pilot CopyPasteLearn ProteinLens