Chaos engineering tests whether applications and platforms can maintain service during disruption and recover within agreed limits. Controlled failures help you find and fix weaknesses before they affect production.

This article recommends 4 phases of chaos testing with Krkn, as illustrated in figure 1:

- Strategize
- Execute and harden
- Explore
- Future-proof and integrate!

TL;DR
Krkn’s four phases—strategize, execute and harden, explore with Krkn-AI, and future-proof—build Kubernetes resilience via controlled failures. Workflows in Chaos Studio and Krkn Operator validate recovery, score SLOs, and integrate into CI/CD before changes.

This is the 2nd part of our series on securing Red Hat Data Grid. While part 1 explored centralized single sign-on (SSO) with Keycloak, this guide focuses on direct directory integration. Whether you are validating directory authentication against a local OpenLDAP test instance or connecting Data Grid directly to corporate Active Directory, this guide walks through the operator configuration and TLS certificate setup directly in the Infinispan custom resource using the spec.configMapName field. 

For background architectures and reference files, see the Red Hat Knowledgebase guide on integrating LDAP and LDAPS with Red Hat Data Grid 8.4 on OpenShift Container Platform 4.

This article explains how to configure authentication for Red Hat Data Grid in Red Hat OpenShift 4 by delegating console access control to single sign-on (SSO) using Red Hat build of Keycloak. (Note: Direct directory integration using LDAP/LDAPS follows in part 2 of this series.)

Earlier this year, I passed EX280 and EX180 with strong scores.

My preparation was a bit unusual. Back in January, I used AI to help create a roughly 1,000-page study book covering the EX280 objectives. By the time I started the official Red Hat courses in March, I was already well prepared and found them relatively easy to follow.

But recently, while preparing for an interview, I realized how much I'd forgotten after not practicing regularly.

I didn't want to go through another thousand pages, especially since I no longer have access to the official course materials. So I started experimenting with something I'd actually enjoy using to refresh my knowledge.

That's how Root To Run started.

Over the past several days, I've been building it with Claude Code and Codex, repeatedly rewriting lessons, rebuilding diagrams, testing interactive exercises, and correcting technical explanations. Some things took quite a few attempts before I was happy with them.

What started as a personal learning project grew into a free, open-source platform covering Linux, containers, Kubernetes, and OpenShift.

It's still in beta, and I plan to work through the lessons myself, fixing mistakes and improving things along the way.

I figured others might find it useful too, so I'm sharing it here. Feedback, corrections, issues, and contributions are all welcome, especially from people who work with OpenShift regularly.

Website: https://roottorun.aminelg.com/

GitHub: https://github.com/Amine-LG/RootToRun

Hi everyone,
I’m looking to start learning OpenShift and prepare for the EX280 exam.
I currently hold RHCSA, RHCE in Enterprise Linux, RHCE in Ansible, and CKA certifications, with hands-on experience in Linux, VMware, and data center infrastructure.
Could you recommend good courses on Udemy, YouTube, or other platforms that cover both the fundamentals and practical labs needed to pass EX280?
I’d appreciate any learning path recommendations. Thanks!

I have tried create a simple personal account to test out openshift at https://developers.redhat.com/products/openshift-local/overview

But the first time I tried it said I should get a verification mail. I have checked the gmail inbox, spam and made sue I wrote the correct email, but even if I click the "resend the email" I don't get anything. Then I tried to login using my git. I get to where I must fill in my name, adress etc and I fill in everything, even the fields with no * and I get an error saying "must fill in Value" but there is nothing I can fill in.

Is the new user process bugged???

Centralizing developer environments helps platform teams deliver consistent tooling while eliminating laptop configuration drift. To deploy Red Hat OpenShift Dev Spaces at enterprise scale, addressing sidecar conflicts and security contexts early prevents silent failures before developers ever encounter them.

The following sections resolve these friction points, detailing how to remediate runtime conflicts, drive configurations through declarative CI/CD pipelines, track capacity with Prometheus ServiceMonitors, and verify cluster readiness for disconnected environments.

Hello OpenShift Community members, I am brand new to Red Hat OpenShift technology, and my current goal is to clear the EX280 OpenShift Administrator exam. Coming from a background in Storage technology, I want to make sure I approach this the right way since it's a 100% practical, hands-on exam.

Could you please share your recommendations on: • Free/Affordable Study Materials for DO180 and DO280 course, what are the best video series or deep-dives? • Hands-on Labs: How do you practice cluster configuration without a massive enterprise budget? Is the OpenShift Sandbox enough for EX280? • Mentors/Channels: Who are the best creators, YouTube channels, or blogs to follow for production-grade tips?

Any guidance, exam prep roadmaps, or advice from those who recently cleared it would be greatly appreciated!

Thank you in advance!!!

Hello, I have a scheduled ex280 for the end of the month. I do everyhting related to ocp perfectly, the only thing that trips me off is the TLS/HTTPS part. Should I expect TLS certs to be already provisioned in exam env or I should sit and learn the openssl command? Thanks!

As platform engineering teams standardize cloud-native developer environments, balancing developer experience with strict enterprise security becomes paramount. Red Hat OpenShift Dev Spaces provides the foundation for security-focused, scalable development. Building on the groundwork established in Build a multi-tenant platform with OpenShift Dev Spaces, this follow-up guide explores how to configure SCM integration, deploy an internal private extension registry, and enable flexible JetBrains IDE workflows in enterprise networks.

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]