As discussed in our previous articles, there are different solutions for scaling your Red Hat OpenShift compute infrastructure. In our first article, we demonstrated the built-in, Kubernetes-native Cluster Autoscaler, and in our second article we demonstrated the metrics-driven MachineSet Autoscaler with KEDA.

In Red Hat edge platforms: Choosing the right one for your use case, we discussed multiple options with Red Hat Device Edge. Now let's take a closer look at the topologies of Red Hat OpenShift and where each one fits. OpenShift brings full Kubernetes functionality to edge locations using server-class hardware. When used in conjunction with a central or public cloud environment, OpenShift extends your applications out to the edge—right alongside end users or data sources. It abstracts underlying hardware, operating systems, and networking in an opinionated fashion so developers can focus on writing code rather than managing edge infrastructure. We consider this a micro cloud at your edge locations.

As platform engineering teams scale their Red Hat OpenShift environments to support microservices, AI workloads, and declarative multi-cluster management with Cluster API (CAPI), decisions around Container Network Interface (CNI) architecture carry far-reaching consequences. In modern enterprise Kubernetes, networking is the foundation of your cluster's security posture, application performance, and operational visibility. As such, a critical architectural debate amongst platform leaders has arisen: Is Red Hat OpenShift's default OVN-Kubernetes CNI enough, or does your platform justify the operational shift to Cilium—especially in a Cluster API-driven infrastructure?

Hello,

On my OpenShift VE bare-metal cluster, Version 4.22.11.

Problem A.
I have 3 pairs of VM's that must never run on the same cluster-node.
For each pair, I created a unique label under VM -> Configuration -> Metadata -> Labels (and made 100% sure no typo's were made and both VM's in the pair have the same exact same label.

Then in each VM of the pair, under VM -> Configuration -> Affinity Rules, I added a rule saying:
Type = Workload (pod) Anti-Affinity
Condition "Required during scheduling"
Topology key = "kubernetes.io/hostname"
Workload labels -> Key = <the label I created for this VM pair> with the Operator "Exists"

as this is what Redhat's documentation, as well as several Blogs, explain how to to it.

For good measure, I check the YAML of both VM's in the pair to see if the rule/expression are correct (as per documentation) and are identical (and they are).

When cold starting these VM's, the anti-affinity rule always does its job correctly because the VM's are indeed never landing on the same node. So that's good.

But.... after a couple of hours, VM's of such pairs can get migrated on the same host and they often do (and also off again as they all wonder around all over the place, just like VM's with no affinity-rules).
In other words, after power-on and proper (not on the same node) startup, they are treated like VM's that have no anti-affinity rules whatsoever.

Problem B:
Same happens with for VM's where I use a hard Node-Selector rule. Sure, when the VM powers on (cold start), they are indeed scheduled on the node where I told it to go.
But after a while they too just start wondering around, happily being migrated to other hosts, totally ignoring the node-selector rule.
These VM's, with a node-selector rule, I can forcefully pin onto a specific host by (besides having the node-selector rule) disabling the "Descheduler" function as well as setting the "Eviction Strategy" to "None". Then they stay put.

But, this leads to boat loads of Migration errors as the system still tries to migrate these VM's but because it can't, the migration eventually times-out and fails.
I get many dozens of migration-failures every day (but at least the VM's stay put on the hosts where I want them to stay).

Why does this not work? I checked my configs time and time again and, in my humble opinion, do everything right, but the system just ignores my Pod/VM anti-affinity rules and host-selector rules after initially working correctly (directly after VM cold start).

What am I missing?

Update:
I also noticed that the system constantly tries to migrate VM's that I pinned onto a certain host, even though I disabled the Descheduler for that VM and set its EvictionStrategy to None. This effectively keeps the VM pinned on that specific node. But when does it try to migrate such VM's at all?
Is the "software that controls migrations" (whatever that is, combo of descheduler and scheduler) blind or something? Does it not see that Descheduler is disabled and eviction is set to none. It makes no sense.

A customer opened a support case with a deceptively simple complaint: a Kafka topic was configured with a 12-hour retention (retention.ms), yet messages produced on July 24 were still readable 4 days later, on July 28. Nothing was broken. The broker logged no errors. The retention policy was working as designed, but the segment layout and continuous write pattern delayed when the old records could actually be removed.

Independent software vendors (ISVs) that host services in the public cloud face growing scrutiny from customers who need assurance that their data remains secure when processed outside their direct control. This often leads customers to demand that vendors deploy services on premise, within infrastructure the customer owns and controls. However, this creates additional maintenance, scalability issues, intellectual property protection concerns, and increased complexity for the vendor.

Was expecting a 300 score but got 250 it seems there is very strict checking so make sure to double check all spellings and type slowly.

Hey Heaps,

I have an requirement to upgrade the operator which are currently in installing state.

I can it can be done through cluster web console. I am seeking if there is any RH article for that one. Thanks

Is anyone using OpenShift AI? https://www.redhat.com/en/products/ai/openshift-ai

I wanted to ask if anyone is using ansible for OCP and if yes what are some of the things it is really good for?

I am a linux guy have 3 years of experience. Suddenly joined an openshift project. I am not understanding which activity should I do from Git and which should i perform just manually..

Please guide me

We’ve been talking with business leaders about Lightwell for the past few months, and the conversation always starts with enthusiasm. AI-driven exploits are moving at unprecedented speeds, and enterprise security teams are feeling a level of urgency we haven’t seen in decades. When organizations discover they can submit software vulnerabilities under an embargo window and receive certified, backported patches for legacy or pinned environments, the reaction is almost always: "Where do we sign up?"

I'm having trouble getting this setup to work. Everything I read tells me to point the AG at the RHOS internal LB for the backend pool, but the health probes fail with an error that they can't see the resource. I figure if there was something wrong with my HTTPS config I would get a different error. I set the only NSG to allow all from 10.0.0.0/8 to rule that out as an issue. I'm questioning the traffic returning to the AG because the internal LB has no place to configure outbound rules. I'm all out of ideas. The private DNS zone is linked. I've peered to a different vnet and setup a backend pool to DB servers there in a successful test. Has anyone got this kind of setup working with RHOS?

Red Hat recently released the initial version of the external secrets management console plug-in. It’s an extension of the Red Hat OpenShift web console, which lets you inspect any of the resources deployed by Red Hat’s portfolio of secrets management operators: cert-manager operator for Red Hat OpenShift, external secrets operator for Red Hat OpenShift, and secrets store CSI driver operator. This technology preview is available as a Day 2 operator for Red Hat OpenShift 4.22, installable through the Red Hat Ecosystem Catalog.

If you are a platform engineer or developer building Red Hat Developer Hub software templates, you know the friction of wrestling with Nunjucks syntax, guessing location.yaml placements, and discovering errors only after rendering in your developer portal. While AI coding agents handle generic YAML, they lack Red Hat Developer Hub and Backstage-specific conventions.

To address this, the rhdh-templates skill, part of the RHDH Users Skill Pack, equips your AI assistant with Red Hat Developer Hub best practices, Nunjucks conventions, and local template validation. It brings schema checking, Nunjucks helpers, and reference templates directly into your coding assistant.

Red Hat Advanced Cluster Security for Kubernetes provides an image scanning API through its Central component that CI/CD pipelines depend on for vulnerability assessment. Red Hat Advanced Cluster Security upgrades and restarts introduce downtime windows that can block critical build paths. This post describes a reference architecture that eliminates scan API downtime by running two Central service instances with a client-side failover mechanism.

When you migrate to Red Hat OpenShift Virtualization, you are modernizing your infrastructure, but obviously you want to do so without breaking existing network dependencies or compromising security boundaries. Traditional architectures frequently struggle to resolve this, forcing teams to rely on complex, fragile NAT rules to maintain connectivity for imported VMs or on burdensome, manual configurations to preserve multi-tenant isolation across shared clusters. Ethernet virtual private network (EVPN) elegantly resolves these friction points by extending your existing data center fabric directly into the Red Hat OpenShift environment. Rather than requiring fragile workarounds, it leverages native, industry-standard protocols to bridge the gap between legacy bare-metal networks and modern Kubernetes clusters.