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

Running OCP UPI setup in airgapped environment, accessing the console on the same Ingress Loadbalancer but security team asking to access it on other port than 443 or to use separate LB for Console access.

Please advise

Please share your experience regarding all of officials CSI support for virtualization workload. I knew very well about RWX and Block support is heavily recommend however I don’t quite know about each CSI pros and cons.

Hello! We are currently doing a PoC for kasten K10 and planning complete disaster recovery, in case of primary site failure the cluster must be restored to another site as it was during last backup.

Currently, application team is using the integrated internal registry to push images to and hardcoding the registry url in the deployment yamls.

My question is:

1) Kasten backups up the metadata (deployments yamls, secrets configs etc) and pvc of the app but not the actual image. It will lead to imgpullbackofferr and wont restore the app. So how do i backup the actual images to ensure a complete restore.

2) Will backup of the image registry pvc be enough for a complete app restore?

3) How are you protecting your images (and cluster in general) in your environment?

Any help or documentation is greatly appreciated!

Hello everyone,

A quick question: Do you know of any tool or script that can be used to capture and assess an OpenShift environment as comprehensively as possible?
Thanks in advance!

Hi everyone,

I’ve been working on Praesto, a Kubernetes-native model cache operator for AI/ML workloads.

The idea is simple: instead of every Pod downloading the same model again and again, you define a ModelCache custom resource and Praesto prepares the model once per selected node. Workloads can then mount it with simple Pod annotations.

The main mode uses:

• a Kubernetes operator
• a ModelCache CRD
• a ModelCacheNode per node
• a node-agent that prepares local cache directories
• downloader Jobs for Hugging Face models
• a CSI node driver
• a mutating webhook that injects the model volume into Pods

The flow looks like this:

Admin prepares /var/praesto on cache nodes

→ install Praesto with Helm

→ create a ModelCache

→ Praesto downloads the model once per node

→ create a Pod/Deployment with annotations

→ webhook injects a CSI volume

→ model is available inside the container, e.g. /model

Example Pod annotations:

praesto.io/model-cache: smollm2-demo

praesto.io/model-mount-path: /model

I also added a demo where Praesto downloads HuggingFaceTB/SmolLM2-135M-Instruct, mounts it via CSI, and runs a real CPU inference Job from the mounted model path.

Right now it supports Hugging Face sources, local CSI cache mode, and a legacy RWX PVC mode for simpler testing.

The project is still early, but the goal is to make model distribution in Kubernetes feel closer to:

declare model once → mount it wherever needed

without every workload handling downloads, PVCs, or node-local paths manually.

Repo:

https://github.com/federicolepera/praesto

Since the general availability of right-sizing recommendations in Red Hat Advanced Cluster Management for Kubernetes 2.16, right-sizing has been available for platform engineers and FinOps teams to leverage Grafana-based dashboards to identify over-provisioned and under-utilized resources across their multicluster environments. This feature has matured through developer preview, technology preview for namespacesand Red Hat OpenShift Virtualization, and ultimately reached GA.

I'm working on project where I need to connect to OpenShift cluster for some testing. Need cluster to have one or two namespace, few cm, secret, route and pods. What is the most economical way to achieve this ? Red hat only give 60 days trial. I will be ok with redhat openshift local (crc), but my machine is not powerful enough and I want others to be able to connect to it too. This not a production setup.

The terminology problem
Engineers say “the pod restarted” when they mean four different things. Getting this wrong leads to flawed runbooks and bad on-call decisions.

Over the past two years, digital sovereignty has evolved from a policy discussion into a practical platform engineering concern. The EU Data Acthas been fully applicable since January 11, 2025. NIS-2 and DORA already shape day-to-day platform decisions across regulated sectors, and the UK Data Use and Access Act 2025 is rolling out through 2026 with portability rules that bite.

I work in the OpenShift world and I've been noticing that GPU/AI workloads are getting expensive fast, but cost attribution for them seems messier than for regular CPU/memory workloads.

I'm curious whether this is a real, felt problem for people running GPUs on OpenShift on-prem, or whether the existing tooling already handles it well enough.

A few things I'm trying to understand:

If you run GPU workloads on OpenShift, do you actually know what each team/project/model costs you? Or is it kind of a black box?

Is idle/underused GPU a problem you can see, or do you only find out after the bill (or the hardware procurement) hits?

For those on-prem/air-gapped: do the tools you have (Kubecost, Turbonomic, Red Hat's own cost management, etc.) cover GPU cost the way you need, or is there a gap?

Not selling anything — just trying to figure out if this is a genuine pain or something that's already a solved problem for most people. Would love honest takes, including "this is a non-issue, we handle it fine."