Okay, I'll admit I got a little too excited when the release notes for OpenShift 4.15 dropped this morning. I've been knee-deep in planning a major platform upgrade for our on-premise marketing automation infrastructure, and we're heavily reliant on OpenShift to run our event-driven campaign processors and customer data platform microservices. The promise of longer support cycles and new Kubernetes upstream features is always tempting, but as we all know, the devil is in the details—especially for a self-managed, air-gapped deployment.
So, I've been pouring over the release notes and the known issues list for the past few hours with my comparison spreadsheet open, and a few things have popped out that gave me pause. I'm hoping some of you who have already done test deployments or have more operational experience with the underlying platform changes can weigh in.
My primary concerns for our specific on-prem, "do-it-yourself" stack are:
* **The hard requirement for OVN-Kubernetes as the default SDN:** We're still using the old OpenShift SDN (ovs-subnet) in our 4.12 clusters because of some legacy network policy dependencies with our on-prem firewall rules. The notes state that clusters using OpenShift SDN cannot be upgraded in-place to 4.15; a migration to OVN-Kubernetes is required first. Has anyone gone through this network migration on-prem? I'm particularly worried about the potential for service disruption during the cutover for our stateful sets handling lead scoring and real-time analytics.
* **Changes to the `oc adm must-gather` command:** It now requires explicit `--image` or `--source` flags. This seems minor, but for our tier-3 support teams who have standardized troubleshooting playbooks, this is a breaking change in a critical diagnostic tool. We'll need to retrain and update all our runbooks, which adds operational overhead.
* **The deprecation of the Compliance Operator's `ScanSetting` API (compliance.openshift.io/v1alpha1):** We use this for CIS benchmarking on our master and worker nodes to satisfy internal security audits. Migrating to the new `v1` API means redefining all our scan profiles and schedules. Not a blocker, but another project to manage alongside the upgrade itself.
Beyond these, I'm also curious about the real-world experience with:
* The upgraded Kubernetes 1.28 core, specifically around Pod Scheduling Readiness and the changes to the `PodDisruptionBudget` API. Any impact on rolling updates for your marketing or data pipeline deployments?
* For those with large clusters (we're running 150+ nodes per cluster), does the stated improvement in etcd defragmentation actually translate to noticeable maintenance window reductions?
I love the new features on paper—like the enhanced monitoring for user-defined projects—but I need to be sure the upgrade path is smooth. A botched upgrade could take down our entire lead routing and email delivery ecosystem for days. So, please, share your early findings or red flags! My spreadsheet is ready for your data.
Test everything, trust nothing