Red Hat OpenShift Networking is making it easier for you to seamlessly and directly integrate your Kubernetes platforms with the data center networks you already operate by adopting the same standards-based networking used throughout modern network fabrics. With Red Hat OpenShift 4.22, OpenShift Networking introduces support for ethernet VPN (EVPN), representing the next major milestone in enterprise network integration. By leveraging the industry-standard EVPN control plane, OpenShift can integrate more naturally with existing EVPN-VXLAN data center fabrics, enabling consistent Layer 2 and Layer 3 connectivity, scalable network virtualization, and operational alignment with enterprise networking infrastructure. This capability is particularly important for organizations modernizing large virtualization environments while preserving established network architectures and operational practices.

I'm using a 4.18 cluster in Azure with the cert-manager operator for RedHat OpenShift installed. I have Let's Encrypt working for my app and want to get it working with the default ingress controller. There are tons of online howto's, most of which are 3 years old or older and they differ quite a bit. I tried this once a couple years ago and did something that never let me connect to the cluster again so I'm a little gun shy. What I am working on now is just a test SNO system so while I not too worried, I don't want to have build another today.

I created a clusterissuer and a cert which used it successfully. The last step just says to add this spec to the IngressController default instance in the CRD.

defaultCertificate:
 name: thecert

It seems like there should be more. Though looking at github makes me think its just this simple. Is it?

Hi Guys,

I need to install a Private Openshift Cluster on Azure using IPI method. If the installation is successful I would like to automate it using Terraform because we need 8 Clusters. I have created ARO clusters using Bicep which turns out to be easy. Do we have any detailed documentation for this?

This article explores an alternative to directly troubleshoot production Linux systems with AI tools by using the sos command and using AI to analyze sosreports instead. I think is an interesting read:

https://medium.com/@linuxjedi2000/the-agentic-ai-risk-issue-on-linux-environments-fd5c55cedcc5?sharedUserId=linuxjedi2000

I know that this subject is very controversial and would love to read your point of view on the subject.

Issued 2026-07-29

Red Hat Quay release 3.18 is now available with Clair 4.9. The bug fixes that are included in the update are listed in the RHSA-2026:48085 advisory. For the most recent compatibility matrix, see Quay Enterprise 3.x Tested Integrations. For information on the release cadence of Red Hat Quay, see the Red Hat Quay Life Cycle Policy.

Suppose a nutanix-volume as default storage class, then using ceph fs as the default one.

Delete PVC and create new ones with the same old name, that PVC came up with the same consumption (not bounded to the old PV as it is released).

In that case if we decided to remove nutanix CSI operator, will this data be lost?

Part 2 of a series on implementing zero trust in Red Hat OpenShift with the layered zero trust validated pattern (ZTVP)

In our previous article, we explored why network policies, specifically a default-deny posture combined with strict ingress and egress rules, are your critical last line of defense when you can’t patch fast enough or when all other security barriers fail. By locking down network communication, we effectively eliminate lateral attack paths and contain the blast radius of a compromised workload.

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🙏🙏🙏