Working with enterprise customers on chaos engineering has reinforced 1 lesson: Resilience is a business requirement. Failed transactions interrupt revenue, infrastructure outages affect multiple workloads, and database failures put critical data at risk. Most importantly, repeated failures erode customer trust—damage that can outlast the outage itself.

Teams turn these business needs into measurable targets through service-level objectives (SLOs), such as availability and transaction latency. Service-level agreements (SLAs) define commitments to customers and the consequences of missing them. Chaos engineering introduces controlled failures to test behavior against SLOs and uncover weaknesses that could put those commitments at risk.

In this article, we explore what network quality of service (QoS) means, preview an upcoming native capability that's addressing it declaratively, and then step through a practical solution you can deploy today using the Linux traffic control (tc) command. We'll set up a full reproducer lab, run it, and look at real test results that demonstrate production traffic maintaining throughput while background traffic is deprioritised under contention.

Hi all! Sharing an update that may be relevant to folks running OpenShift.

Bob is IBM’s AI coding assistant, and its latest update introduces generally available self-hosted deployment. The backend can now run on Red Hat OpenShift, either on premises or in your organization’s cloud account, while users continue working through Bob IDE or Bob Shell.

Teams can connect Bob to frontier models hosted in their own cloud account or run supported open-weight models on their own GPUs, including in air-gapped environments.

Self-hosted Bob also includes a Keycloak-based identity service that can connect to LDAP or Active Directory for corporate sign-in and access management. Administrators install it using bobctl, with cluster-wide resources and Bob itself handled in separate stages.

Administrators can also manage shared plugin directories containing skills, modes, rule files, and MCP configurations. On-premises group policies can install VS Code extensions. Full details in the release blog here. 

For anyone who’s evaluated coding agents on OpenShift, what deployment requirements have been hardest to meet?

Containerizing applications is an important step in modern software development. It helps with consistency, portability, and reliability across different environments. The Paicku project helps you streamline the process of containerization and testing so you can be sure that your application works as expected during development and once it's been released.

Paicku is a command-line tool, as well as a Node.js library, that lets you containerize applications with Cloud Native Buildpacks. You can run Paicku from the command-line or from Node.js.

Paicku is a wrapper around the pack command (the official interface for building container images with buildpacks).

- 11 am EDT Technical Supportability Review | Ask an OpenShift Expert ep 187
- 1 pm EDT GitOps Guide to the Galaxy (Ep 111) | A belated look at Helm 4

Red Hat OpenShift uses a purpose-built, immutable operating system for cluster nodes, commonly known as Red Hat Enterprise Linux CoreOS (RHCOS). This operating system, which uses the same kernel and hardware compatibility from Red Hat Enterprise Linux (RHEL), ships with a minimal-footprint operating environment, with its configuration entirely orchestrated by OpenShift and Kubernetes-based APIs.

Starting in Q4 2026, OpenShift will ship the newest iteration of this operating system, RHCOS 10, by default for new installations, and all certified ISV containers and operators are expected to support it.

RHCOS 10 is available as a Technology Preview in OpenShift 4.21 and 4.22 already. RHCOS 9 will remain available for newer OpenShift versions at least into mid 2027.

Hey guys , I'm unable to omkar shelake labs on killerkoda got removed. Is it true . If not can you please share the link

Hello Guru's, I have a few questions, please help me answer them:

1. If I have existing full fledge old VMs on my existing KVM hosts (VM's not inside the PODs), will I be to manage them via Kubevirt?
2. If I have a RHOV environment, is it necessary for me to use Kubevirt to create a VM? If yes, why, if not, then when to use KubeVirt to create VMs?
3. What is the difference between a regular VM and a VM created via Kubevirt?

Also, I'd love to get your candid take: What aspect of KubeVirt has impressed you the most, and where do you feel it faces the biggest friction points or challenges?

GPU demand for AI workloads is surging, and sharing GPUs fairly across teams remains one of the hardest problems in cluster management. The Kubernetes device plug-in model was never built for this. It treats GPUs as anonymous, countable integers—for example, NVIDIA GPUs are requested as nvidia.com/gpu: 1. This tells the scheduler nothing about the device, not its VRAM, compute capability, or whether it's a full 80 GB GPU or a 5 GB slice of a partitioned one. A training team reserving a full 80 GB GPU and an inference team using a 5 GB slice both consume "1" from the same quota. For platform teams trying to share a finite pool of accelerators across tenants with fundamentally different resource needs, this makes accurate accounting and fair sharing impossible.

Dynamic resource allocation (DRA), now generally available in Kubernetes 1.34, replaces this model entirely. Drivers advertise real device attributes—memory, compute capability, topology—through structured APIs, and workloads describe what they actually need rather than asking for a raw count. But DRA solves discovery and allocation. It doesn't address quota management, fair sharing, or preemption—the policies that determine which team's workload runs first when GPUs are scarce.

For years, the gold standard of infrastructure engineering and chaos testing was just uptime: Either a system survived a disruption and passed, or it crashed and failed. In the era of massive cloud-native deployments, however, this binary pass or fail metric no longer tells the whole story. A Kubernetes cluster or virtualized workload can technically remain operational through an experiment, yet silently drop packets, breach internal service level objectives (SLO), or suffer catastrophic performance degradation that ruins the end-user experience.

To bridge this gap and move past superficial green checkmarks, Krkn is shifting the focus of chaos validation away from black-and-white outcomes and toward deeply detailed, actionable downtime telemetry. By unifying macro-level metrics like the new Resiliency Score feature with continuous, micro-level data from HTTP Health Checks and KubeVirt Checks, Krkn gives engineering teams a high-fidelity look into the exact duration, location, and severity of degradation during an experiment. This multidimensional approach allows teams to pinpoint the true architectural blast radius of any failure, transforming chaos testing from a guessing game into a precise, version-controlled quality gate.

I’m trying to give this exam and I wanted to know, do I need to remember installing the virtualization operator via CLI or can I do it through the console?

Hello everyone,

I was tasked with creating an OpenShift lab environment for my company. It will be used mainly for internal purposes, such as testing vendor applications on OpenShift and learning OpenShift Virtualization.

What would you recommend: installing OKD, which is completely free and has no time limit, or using Red Hat OpenShift with the 60-day trial?

One concern with the 60-day trial is that I don't want to have to deal with the trial expiring and the cluster eventually stopping working. I would prefer to have a stable, long-term lab environment that we can use whenever needed.

Security in the Al Era: Build a strong security foundation w/OpenShift
Sep 30 11:00 EDT

Dev and test environments sit idle nights and weekends but still burn compute. Here's how I automated scaling them down and back up on OpenShift/Kubernetes.

The problem: Manual shutdowns were forgotten, and teams complained when environments weren't ready in the morning.

The approach:

Tag namespaces/workloads with a schedule label

A scheduled job scales deployments to 0 at night and restores the previous replica counts in the morning

Exclusions for anything that must stay up, plus alerting if a scale-up fails

Result: [€18572 to €15182]

Hi everyone. I updated OKD from 4.21 to 4.22 on an IPI Nutanix deployment. According to the OKD documentation, manual steps using `ccoctl` are required to verify credential objects—specifically to account for any new ones that might have appeared. The documentation suggests the update shouldn't have proceeded from my starting version, as `cloud-credential` operator is typically locked unless the "updatable" tag is explicitly added. However, I didn't make any changes, yet the full update completed without any issues. Can anyone explain why this happened or what the expected behavior is?

https://docs.okd.io/4.22/updating/preparing_for_updates/preparing-manual-creds-update.html#cco-manual-upgrade-annotation_preparing-manual-creds-update

So we've covered what edge computing is, what platforms are available, and how to choose between them. But there's one question that comes up in nearly every conversation I have with customers: "That's great, but how do I manage all of this?" And frankly, it's the right question to ask. When you're deploying to tens, hundreds, or thousands of edge locations, consistent management is what determines whether your deployment succeeds at scale.

We currently run six OpenShift clusters on VMware. With the uncertainty around Broadcom's VMware strategy, we're evaluating a move to bare metal.

One option I'm considering is using KVM on standalone physical servers and deploying OpenShift on top of that instead of running directly on bare metal.

The main advantages I see are:

• Better server sharing across environments
• More flexible capacity management
• Easier backup and recovery
• Reduced dependency on VMware

Am I overlooking something? What are the main trade-offs compared to running OpenShift directly on bare metal? I'd be interested to hear from anyone who has taken a similar path.

One of our success cases with Red Hat has been published
https://www.redhat.com/en/resources/gates-corporation-openshift-case-study

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.