🚀 OpenShift Cluster Upgrade Guide

Master OpenShift Cluster Upgrades Like a Pro

Keeping your OpenShift cluster up to date is essential for maintaining security, stability, performance, and access to the latest Kubernetes features. In this guide, you’ll learn how to safely upgrade an OpenShift cluster from v4.14.35 to v4.16.28 using industry best practices followed by enterprise DevOps teams.

---

📌 What You’ll Learn

• ✅ Perform comprehensive pre-upgrade health checks
• ✅ Verify Cluster Operators and MachineConfigPools
• ✅ Back up ETCD before upgrading
• ✅ Check the supported upgrade path
• ✅ Apply administrator acknowledgements (when required)
• ✅ Upgrade the cluster through the OpenShift Console or CLI
• ✅ Monitor upgrade progress
• ✅ Perform post-upgrade validation
• ✅ Execute production-ready sanity checks

---

📋 Prerequisites

Before starting the upgrade, ensure the following:

• OpenShift Cluster Operators are healthy
• All worker and master nodes are in the Ready state
• MachineConfigPools are updated
• No Pending Certificate Signing Requests (CSR)
• PodDisruptionBudgets are configured correctly
• ETCD backup has been completed
• Cluster monitoring is healthy
• Critical applications are functioning normally

---

🔍 Step 1: Verify the Supported Upgrade Path

Always check the official OpenShift Upgrade Graph before upgrading.

Upgrade Path

4.14.35
     │
     ▼
4.15.x
     │
     ▼
4.16.28

Following the supported upgrade path helps avoid unsupported version jumps and minimizes upgrade risks.

---

⚙️ Step 2: Start the Upgrade

Upgrade using either the OpenShift Web Console or the CLI.

oc adm upgrade --to=4.16.28

Monitor upgrade progress:

watch oc get clusterversion

---

🔐 Step 3: Administrator Acknowledgement

Some upgrades require administrator acknowledgement due to Kubernetes API removals.

Example:

oc -n openshift-config patch cm admin-acks \
--patch '{"data":{"ack-4.14-kube-1.28-api-removals-in-4.16":"true"}}' \
--type=merge

---

✅ Step 4: Post-Upgrade Validation

After the upgrade completes, verify:

oc get clusterversion

oc get co

oc get nodes

oc get pods -A

Restore the PodDisruptionBudget if it was modified:

oc patch pdb $(oc get pdb -n prod -o name) \
-n prod \
--type=merge \
-p '{"spec":{"minAvailable":1}}'

---

🧪 Production Sanity Checks

Verify the following before declaring the upgrade successful:

• Application login
• APIs responding correctly
• Routes and Ingress
• Storage and Persistent Volumes
• Monitoring dashboards
• Logging stack
• Cluster Operators
• CI/CD pipelines
• Database connectivity
• Business-critical workloads

---

💡 Best Practices

• Always perform an ETCD backup before upgrading.
• Never skip unsupported minor versions.
• Validate the upgrade path before proceeding.
• Monitor Cluster Operators throughout the upgrade.
• Complete post-upgrade validation before moving to the next version.
• Schedule upgrades during a maintenance window.

---

🎯 Conclusion

A successful OpenShift cluster upgrade is more than just updating the version—it’s about ensuring application availability, minimizing downtime, and maintaining cluster reliability. By following a structured upgrade process, you can perform production-grade upgrades with confidence.

---

👨‍💻 DevOps with Patil

If you found this guide helpful, explore more hands-on DevOps tutorials covering:

• Azure DevOps
• OpenShift
• Kubernetes
• Docker
• Helm
• Argo CD
• Terraform
• GitHub Actions
• Jenkins
• Linux
• Ansible
• Real-World DevOps Projects

Learn DevOps through practical, enterprise-grade examples with DevOps with Patil. 🚀