OpenShift Version Lifecycle: Upgrade Strategy and Support Policy Complete Guide

OpenShift updates frequently—about every four months there's a new version. Not upgrading fears falling behind, but upgrading fears breaking things.

Understanding version lifecycle is key to operations planning. Knowing which versions still have support, when to upgrade, and how to plan upgrade paths helps you balance stability with new features.

This article provides a complete introduction to OpenShift version management to help you develop an appropriate upgrade strategy. If you're not familiar with OpenShift yet, we recommend first reading the OpenShift Complete Guide.

---

Version Naming Rules

Version Number Format

OpenShift version number format: 4.X.Y

• 4: Major version number, currently OpenShift 4.x series
• X: Minor version number, represents feature updates
• Y: Patch version number, represents security and bug fixes

Examples:

• 4.16.0: Initial version of 4.16
• 4.16.5: 5th patch version of 4.16
• 4.17.0: Initial version of 4.17

Release Cycle

OpenShift releases a new minor version approximately every 4 months:

2024
├── Q1: 4.15
├── Q2: 4.16
├── Q3: 4.17
└── Q4: 4.18

2025
├── Q1: 4.18 (continued)
├── Q2: 4.19 (expected)
└── ...

Patch versions (4.X.Y) are released as needed irregularly, usually with new patches every 1-2 weeks.

EUS vs Regular Versions

EUS (Extended Update Support) is "Long-term Support Version":

Version Type	Support Period	Version Numbers	Target Audience
Regular Version	~14 months	Odd (4.15, 4.17)	Teams willing to upgrade frequently
EUS Version	~24 months	Even (4.14, 4.16, 4.18)	Enterprises seeking stability

EUS Advantages:

• Longer support time
• Can skip intermediate versions when upgrading (e.g., 4.14 → 4.16)
• Suitable for production environments

---

Lifecycle Support Policy

Support Phases

Each OpenShift version goes through these phases:

Phase	Description	Content
Full Support	Complete support	Feature updates + security fixes + bug fixes
Maintenance Support	Maintenance support	Security fixes + critical bug fixes only
Extended Update Support	Extended support (EUS)	Paid extended support
End of Life (EOL)	End of support	No more updates provided

Regular Version Lifecycle

Release ─────► Full Support ─────► Maintenance ─────► EOL
              (~6 months)          (~8 months)

              Total ~14 months

EUS Version Lifecycle

Release ─────► Full Support ─────► Maintenance ─────► EUS ─────► EOL
              (~6 months)          (~6 months)       (~12 months)

              Total ~24 months

Version Status Quick Reference

2025 Version Status (refer to official announcements for accuracy):

Version	Type	Status	Expected EOL
4.18	EUS	Full Support	2026 Q4
4.17	Regular	Maintenance	2025 Q3
4.16	EUS	Maintenance	2026 Q2
4.15	Regular	EOL	2025 Q1
4.14	EUS	EUS Support	2025 Q4
4.13	Regular	EOL	2024
4.12	EUS	EOL	2024

---

Version Feature Comparison

4.14 Key Features

• HyperShift GA (Hosted Control Plane)
• RHEL 9 as node OS
• OVN-Kubernetes improvements
• Serverless enhancements

4.16 Key Features

• OpenShift Lightspeed (AI assistant) preview
• Cluster API Provider enhancements
• Multi-architecture support improvements
• Logging 6.0 introduction

4.17 Key Features

• Security enhancements
• Performance optimizations
• Operator updates

4.18 Key Features

• OpenShift AI enhancements
• Virtualization improvements
• Stability improvements

API Change Notes

Watch for API deprecations when upgrading:

# Check if using soon-to-be-deprecated APIs
oc get apirequestcounts | grep -v "0$"

Common API changes to watch:

• PodSecurityPolicy → Pod Security Standards
• Some Beta APIs graduating to Stable
• Old CRD version deprecations

---

Upgrade Strategy Planning

Upgrade Path Selection

Regular Upgrade (sequential upgrade):

4.14 → 4.15 → 4.16 → 4.17 → 4.18

Only upgrade one minor version at a time, most stable but frequent.

EUS to EUS Upgrade:

4.14 → 4.16 → 4.18

Skip intermediate odd versions, reduce upgrade frequency.

Note: EUS to EUS upgrade requires intermediate steps:

4.14 → 4.15 (pause) → 4.16

Actually still goes through 4.15, but don't need to stay long on 4.15.

Production Environment Recommended Strategy

Development ────► Testing ────► UAT ────► Production
  (Latest)        (N-1)        (N-1)      (EUS)

Example:
Development: 4.18
Testing: 4.17
UAT: 4.17
Production: 4.16 (EUS)

Pre-upgrade Preparation

1. Confirm Upgrade Path

# View upgradeable versions
oc adm upgrade

# View all available versions
oc adm upgrade --include-not-recommended

2. Check Cluster Health

# Check all Operator status
oc get clusteroperators

# Confirm no Degraded
oc get co | grep -v "True.*False.*False"

3. Check API Compatibility

# Check if using soon-to-be-removed APIs
oc get apirequestcounts

4. Backup etcd

# On Master node
/usr/local/bin/cluster-backup.sh /home/core/backup

5. Confirm Application Compatibility

• Check if Operators support target version
• Validate in test environment first

Upgrade planning needs to consider business impact and rollback strategy. Book an architecture consultation and let us help you develop an upgrade plan.

---

Upgrade Execution

Web Console Upgrade

Simplest method:

1. Go to Administration → Cluster Settings
2. Check Update channel (confirm correct channel)
3. If updates available, click Update
4. Select target version
5. Click Update to start upgrade

Progress will be displayed during upgrade.

CLI Upgrade

# View current version
oc get clusterversion

# View upgradeable versions
oc adm upgrade

# Upgrade to specific version
oc adm upgrade --to=4.16.5

# Upgrade to latest stable
oc adm upgrade --to-latest

Upgrade Monitoring

Monitor status during upgrade:

# Monitor overall progress
watch oc get clusterversion

# Monitor Operator status
watch oc get clusteroperators

# Monitor Node status
watch oc get nodes

# View detailed events
oc get events -n openshift-cluster-version --sort-by='.lastTimestamp'

Upgrade Order

OpenShift upgrade order:

1. Control Plane (API Server, etcd, Controllers)
   ↓
2. Machine Config (node configuration)
   ↓
3. Worker Nodes (rolling update)
   ↓
4. Operators (upgrade individually)

The entire process typically takes 1-3 hours, depending on cluster size.

---

Upgrade Considerations

Compatibility Checks

Operator Compatibility:

# View installed Operators
oc get csv -A

# Confirm Operators support target version
# Usually documented in Operator docs

Application Compatibility:

• Confirm Ingress Controller settings
• Confirm Network Policies still work
• Confirm PVCs function normally

Operator Upgrades

Operators have their own upgrade mechanism:

# View Operator subscription settings
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
spec:
  installPlanApproval: Automatic  # or Manual

• Automatic: Auto-upgrade (default)
• Manual: Requires manual approval

Storage Considerations

Upgrades may affect storage:

• Confirm CSI Driver compatibility
• Confirm PV/PVC status is normal
• Recommend backing up important data before upgrade

Maintenance Window

Although upgrades are rolling, recommend:

• Choose low-traffic periods
• Have rollback plan ready
• Notify relevant teams

---

Common Upgrade Issues

Upgrade Stuck

Symptom: Upgrade progress doesn't move for long time

Troubleshoot:

# Check Cluster Version status
oc describe clusterversion version

# Check stuck reason
oc get clusterversion -o jsonpath='{.items[*].status.conditions}'

# Check Machine Config Pool
oc get mcp

Common causes:

• Some Operator upgrade failed
• Node update stuck
• etcd health issues

Unhealthy Operator

Symptom: Some Operator shows Degraded

Troubleshoot:

# Check specific Operator status
oc describe clusteroperator <operator-name>

# Check related Pods
oc get pods -n openshift-<operator>

# Check Pod logs
oc logs -n openshift-<operator> <pod-name>

Node Upgrade Failure

Symptom: Worker Node update failed

Troubleshoot:

# Check Machine Config Pool
oc describe mcp worker

# Check specific Node
oc describe node <node-name>

# SSH to Node to check
oc debug node/<node-name>
journalctl -u kubelet

Rollback Strategy

OpenShift doesn't support direct rollback to old versions. If upgrade fails:

1. Minor issues: Wait for Operator auto-repair
2. Moderate issues: Manually fix failed components
3. Severe issues: Restore from etcd backup

Best Practices:

• Always backup etcd before upgrade
• Validate in test environment first
• Reserve sufficient upgrade time window

---

FAQ

Q1: Should I use EUS or regular versions?

Production environments recommend EUS. Reasons: (1) Longer support time, reduces upgrade frequency; (2) Can skip-version upgrade, saves time and effort; (3) More stable, more thoroughly verified. Dev/test environments can use regular versions to discover issues early.

Q2: Will upgrades affect running applications?

Well-designed applications won't be affected. OpenShift uses rolling updates to upgrade Worker Nodes, restarting only some nodes at a time. But ensure: (1) Applications have sufficient replicas; (2) Use PodDisruptionBudget; (3) Have health checks configured.

Q3: Can I skip multiple versions when upgrading?

EUS to EUS can (e.g., 4.14 → 4.16). But can't skip too many versions (e.g., 4.12 directly to 4.18). Upgrade paths have restrictions—follow Red Hat's published supported paths. Use oc adm upgrade to see available target versions.

Q4: Can I rollback if upgrade fails?

OpenShift doesn't support version rollback. If upgrade fails midway, usually need to: (1) Wait for auto-repair; (2) Manually fix issues; (3) Worst case, restore from backup. So always backup etcd before upgrade and validate in test environment first.

Q5: Does upgrading require downtime?

Theoretically no. OpenShift uses rolling updates, Control Plane and Worker Nodes are updated one by one. But in practice: (1) Some applications may be briefly unavailable; (2) API may have brief interruption; (3) Recommend doing during maintenance window.

---

OpenShift Upgrades are Major Projects

Thorough planning is needed to ensure smooth operations. From version selection to upgrade execution, every step can have issues.

Book an architecture consultation and let experts help you assess upgrade risks.

---

Reference Resources

• OpenShift Complete Guide
• OpenShift Architecture Deep Dive
• OpenShift Installation Tutorial
• OpenShift Advanced Features Guide
• OpenShift Logging Complete Guide
• OpenShift Pricing and Licensing Analysis
• Red Hat OpenShift Life Cycle Policy