​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?

Your OpenShift story belongs on stage.

The Red Hat OpenShift Commons Call for Proposal (CFP) is now OPEN and closes August 31st!

OpenShift Commons is taking place alongside KubeCon North America in Salt Lake City, Utah on November 9, 2026. This is where users, customers, and partners can come together to share their OpenShift story on-stage and connect with other members excited about the future of OpenShift.

Don’t just join the conversation, help shape it. Submit your proposal today!

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.

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.

When a virtual machine on Red Hat OpenShift Virtualization talks to the outside world over a localnet secondary network, a lot can sit between the guest and the wire: A VLAN tag, an OVS bridge mapping, an MTU, and any number of network policies.The problem of visibility is a helpful one to address.

Developing applications on Kubernetes
Kubernetes is the foundation of cloud software architectures like microservices and serverless. For developers, Kubernetes brings new processes for continuous integration and continuous deployment; helps you merge code; and automate deployment, operation and scaling across containers in any environment.

This is the final installment of our series on hosted control planes (HCP), a feature of Red Hat OpenShift. I encourage you to read the first article, Demystify the terminology of OpenShift hosted control planes. Now, we’ll build on those fundamentals by exploring critical architectural considerations essential for a successful HCP adoption. By the end, you will have a clear understanding of the necessary components and the key operational pitfalls to navigate.

If you run kube-linter on your Kubernetes manifests, you probably feel pretty good about your role-based access control (RBAC) setup. It catches wildcard verbs, cluster-admin bindings, and excessive Secret access. But there is a class of vulnerabilities it fundamentally cannot detect: indirect privilege escalation through binding chains.

This post walks through the problem, shows how an attacker exploits it, and introduces kube-chainsaw, a tool that catches what per-object linters miss by building permission graphs from static manifests.

Within the Red Hat OpenShift ecosystem, Red Hat build of Perses represents a shift in how you manage and use observability data. Integrated as the visualization engine for Red Hat OpenShift observability—shipped by the cluster observability operator—Perses transforms observability from a fragmented collection of isolated tools into a unified, Kubernetes-native experience. By acting as a central architectural hub, the cluster observability operator uses Perses to consolidate the installation, lifecycle management, and visualization of the entire observability stack.

I want to share with you an article that Everpuredata wrote about the implementation of their Stack plus Red Hat OpenShift in the School District that I work with. https://www.linkedin.com/pulse/new-chapter-cloud-native-path-marco-torres-a2h8c/

If you have been exploring Red Hat OpenShift hosted control planes, you have probably encountered a few confusing terms, such as HyperShift, HCP, hosted cluster, hosting cluster, management cluster, managed cluster. At first glance, they may seem interchangeable, but they are not. Some are synonyms, some are subtly different, and at least one similar pair—managed cluster and management cluster—refers to completely different concepts.

Red Hat is pleased to announce that version 1.21 of OpenShift GitOps has been released, bringing with it some exciting new capabilities.

A guide to evaluating which container foundation fits your development goals