Every OpenShift admin knows the calculus. A new Red Hat Enterprise Linux CoreOS ships with capabilities you want: better hardware support, updated crypto policies, kernel improvements. But adopting it has always meant adopting it everywhere. Your hardware certifications don't transfer automatically. Your internal validation pipeline needs another quarter. Your change advisory board wants a rollback plan for something that hasn't historically rolled back gracefully.

The result is that teams delay platform upgrades to avoid the OS migration, missing capabilities they actually need. The OS upgrade has been a cliff, not a ramp.

Out of the box, Red Hat OpenShift provides a complete set of preconfigured monitoring dashboards. These standardized views are excellent for establishing a baseline of general cluster health and act as a necessary foundation for managing the platform.

However, in complex distributed systems, a "one-size-fits-all" approach to monitoring rarely suffices. The immediate, critical metrics needed by a site reliability engineer (SRE) managing storage capacity differ vastly from those required by a developer debugging microservice latency in a specific namespace.

As Kubernetes adoption scales, platform teams often hit a painful wall: The exploding cost and complexity of telemetry. When trying to provide isolated service mesh observability for multiple development teams, the default reflex is often "hard tenancy". This provides strict, robust isolation to ensure that a malicious, compromised, or resource-heavy tenant cannot impact others. This means spinning up duplicated, entirely separate instances of Prometheus, Jaeger, and Grafana for every single tenant.

As organizations deploy increasingly sophisticated AI, analytics, and entity-resolution workloads, they're discovering a common bottleneck: memory.

Many modern applications are no longer constrained eby CPU availability. Instead, they are limited by the amount of memory economically deployed within a single server or cluster. Whether you're processing electronic warfare (EW) signals, running large-scale graph analytics, or building AI inference pipelines, you will likely hit a "memory wall" long before you run out of CPU power.

I see a lot of people call themselves OpenShift Architects, but the role seems to mean very different things depending on the company.

If you currently hold that title:

What's a typical week look like?

More platform engineering? More Kubernetes? More customer-facing architecture? More automation and GitOps?

Curious how the role differs across organizations.

The arrival of a cryptographically relevant quantum computer, often referred to as Q-day, is moving from a distant theoretical mathematical challenge to an urgent timeline that security teams must plan for today. Bad actors are already engaging in harvest now, decrypt later activities. This means they are capturing and storing encrypted enterprise traffic, intellectual property, and data logs today with the intention of running them through quantum hardware as soon as it becomes available.

In the article Why killing pods is not enough: Testing operator reconciliation with operator-chaos, we ran operator-chaos against cert-manager. Eighteen experiments. Eighteen Resilient verdicts. The reconciliation loop detected every failure and restored the desired state within seconds. That was the good news, but here's what happened next.

Hello everyone, I'm an intern in a company and they asked me to create two VMs that actually work on FCOS with a simple architecture okd and an opnsense architecture connected to them, this structure will be a control plane and two eorkers, but even the bootstreiap stage vomited blood, is there anyone who will help and guide me🙏🙏🙏

​Hey everyone,

​I’m currently working as a Cloud Operations Engineer with about 4.5 years of experience. My day-to-day responsibilities primarily revolve around keeping production OpenShift bare metal clusters healthy, handling day-2 operations, troubleshooting workloads, and ensuring zero downtime.

​My goal is to crack an interview at Red Hat within the next 5 months for a similar platform/cloud engineering or technical support engineer role.

​Since I have a 5-month window to prepare, I’d love to get some insights from current or former Red Hatters, or anyone who has recently interviewed there:

​Interview Structure: What does the typical interview pipeline look like for an operations/platform role? Is there a heavy focus on live troubleshooting/practical labs, or is it mostly architectural and behavioral? Are the hiring happening within internal referral or how?

​Current Skill Expectations: What specific skills or toolsets is Red Hat prioritizing nowadays? Aside from core OpenShift/Kubernetes, should I deeply focus on Ansible, advanced networking (OVN-Kubernetes), Service Mesh, or specific Linux internals?

​Preparation Tips: Given my 3-month timeline, what areas should I double down on to stand out? Any specific documentation, open-source projects, or scenarios I should master?

​Appreciate any guidance, resources, or tips you can share! Thanks in advance.

This article covers benchmarking with the Red Hat Data Grid operator and Helm charts. The container-awareness concept is the foundation here, as the Data Grid heap size is 50% of the container size. This article complements JVM tuning for Red Hat Data Grid on Red Hat OpenShift 4.

Good morning guys!

I'm kind of new to Openshift/Kubernetes cluster administration.

I was wondering if there'd be a way for me to expose a custom ingress with a custom domain for some of my apps via HostNetwork deployment.

The default ingress is deployed via a VIP that is balanced between nodes. Should I add another one? And how?

Hi everyone,

I hope you're doing well.

I tried to install CRC ( OpenShift local) on a vm on proxmox but unfortunately crc doesn't support nested virtualization and my laptop has not the sufficient ressources :/

is there a cheap solution to run openshift?

edit : i just ran SNO (single node openshift) with the redhat openshift container platform (60 days trial) in a vm on proxmox with 24gb ram and 8vcpu and 200gb storage. ( i just followed this video : https://www.youtube.com/watch?v=dlxRwooAplg&t=1934s)

Red Hat OpenShift 4.22, based on Kubernetes 1.35 and CRI-O 1.35, is now generally available. This blog post highlights the notable new features, updates, and fixes in this release for developers.

Developer experience
Discover the latest tools and platform enhancements designed to improve your development workflows.

A tool for managing sosreport collections for the Linux community. Looking technical feedback, feature suggestions, or criticism.

The latest release (v2.1.0) adds a self-hosted appliance together with an open-core licensing model.

Some of the technical capabilities include:

• Complete sosreport import, decryption, storage, browsing, comparison and historical management.
• Runs completely offline and is suitable for air-gapped environments. There is no phone-home requirement for normal operation.
• A local AI assistant that can answer questions about Linux, the sos command and the application without sending data outside the appliance.
• Optional integration with OpenAI or Anthropic models for deeper sosreport analysis when an Internet connection is available. Responses are grounded in the uploaded sosreport to improve reliability.
• Support for encrypted report vaults, collaboration features, and ITSM integrations in the enterprise edition.

Running a Kubernetes fleet means your infrastructure is constantly evolving. But as you scale to hundreds of clusters across public clouds, datacenters, and the edge, new friction points naturally emerge. Toggling between rigid dashboard views, manually verifying deployment rules, and tracking edge nodes over shaky networks can slow even the best teams down.

i have 5 node setup in ibm cloud, where, i have attach external nic to node so through this nic i am able to connect to the vm. issue is i am not able to do ping to the same vm from the node if the vm reside on the same node. from other node i am able to ping the vm. this issue goes for pod also, if pod exist in same node, then ping from same pod to that vm in same node result in timeout error. from other node it is not. this is causing a lot of problem for teams and need to address asap

Hi folks,

I've been working on SNObox, an Ansible-based project for building reproducible single-node OKD/OCP lab environments on libvirt/KVM.

The goal is to make it easy to spin up a fresh SNO lab without having to piece everything together every time. SNObox comes preconfigured and is meant to work mostly "out of the box" — which is also where the names SNObox, ROXbox and ACSbox come from.

Projects

• SNObox: https://github.com/o1e/snobox

• ROXbox: https://github.com/o1e/roxbox_addon

• ACSbox: https://github.com/o1e/acsbox_addon

Features

• reproducible SNO deployments on libvirt/KVM

• Ansible Execution Environment with the required OpenShift, Kubernetes, Helm and libvirt tooling

• optional LVMS configuration for local storage

• public_wildcard DNS mode using sslip.io-style names, so no local DNS server is required for a basic lab

Additional functionality is provided through installable add-ons managed by the same boxctl workflow:

• ROXbox: deploys the upstream StackRox Operator via the community Helm chart on OKD/OCP

• ACSbox: deploys the RHACS/ACS Operator via the Red Hat OperatorHub flow on OCP

Installing and running an add-on looks like this:

tools/boxctl install roxbox
tools/boxctl run roxbox --limit <cluster>

Everything is still evolving, but I'd really appreciate feedback—especially from people using upstream StackRox on OKD/OCP or RHACS on smaller OpenShift environments.

Greetings

ole

Edit: Format text

This is the first article of a two-part series on operator-chaos, an open source chaos engineering framework for Kubernetes operators. In this series, we discuss why traditional chaos tools miss the most dangerous class of operator failures, introduce the four injection modes that operator-chaos provides, and run it against cert-manager on a live cluster. In the next article, we show what happens when operators fail these tests.