Red Hat OpenShift 4.18 expands cloud-native networking

Red Hat is updating its OpenShift platform with a series of capabilities that will provide more advanced networking and virtualization functionality for cloud-native deployments.

OpenShift is Red Hat’s commercially supported Kubernetes distribution. The open-source Kubernetes technology in recent years has become the de facto standard for cloud-native deployments, running on all major cloud hyperscalers and supported by a long list of vendors, including Red Hat. With OpenShift 4.18, Red Hat is integrating a series of enhanced networking capabilities, virtualization features, and improved security mechanisms for container and VM environments.

In particular, OpenShift 4.18 integrates what Red Hat refers to as VM-friendly networking.

“VM-friendly networking refers to Kubernetes networking enhancements that provide data center networking capabilities that are common in virtual machine (VM) deployments, that are already familiar to network administrators,” said Ju Lim, senior manager, OpenShift product management, and distinguished engineer at Red Hat, in an interview with Network World.

Custom user-defined networks (UDN)

Lim noted that the VM-friendly capabilities support seamless integration between a Kubernetes cluster network and existing external networks. The first of these enhancements is custom user-defined networks (UDN).

The custom UDNs are being integrated into the open virtual networking (OVN) Kubernetes container networking interface (CNI). CNI is an open-source network plugin for Kubernetes that enables different networking drivers to be easily implemented. Custom UDNs also benefit from the addition of Virtual Routing and Forwarding (VRF) support.

UDN improves the flexibility and segmentation capability of the default layer 3 Kubernetes pod network for VM administrators by enabling custom, isolated-by-default layer 2, layer 3, and localnet network segments, Lim explained. The segment can act as either primary or secondary networks for container pods and VMs. 

Lim noted that UDN custom network segmentation will enable organizations to do a few things. For example, it can be used as an easy way to create multi-tenant environments, creating a flat layer 2 network to be used as the VM primary network for live migrating VMs across nodes in the Kubernetes cluster.

BGP support extends cloud-native networking

OpenShift 4.18 also debuts enhanced user-defined networks with Border Gateway Protocol (BGP). BGP support is being added to UDN as a routing protocol for pod/VM addressability and VPN support. 

Lim explained that BGP enables dynamically exposing cluster-scoped network entities into a provider’s network, as well as programming BGP-learned routes from the provider’s network into OVN-Kubernetes. 

“This is particularly useful for integration with third-party load balancers needing direct access to backend OpenShift pods or VMs,” she said.

UDN will also add integrated support of Ethernet VPN (EVPN) to BGP, allowing for the extension of a UDN segment into one or more external networks. Lim noted that what that can enable for example, is a VM to be directly referenced by its (static) L2 network address, rather than requiring NAT translation at the cluster edge.

Security gets a boost with secret store container storage interface (CSI)

One of the more challenging aspects of cloud-native Kubernetes deployments is managing secrets. Secret are passwords and access credentials for services, and they should not be exposed or hard coded into applications. A common best practice that has been used by many organizations is to use a third-party secrets management technology.

The new Secret Store CSI Driver bridges the gap between external secret management solutions and Kubernetes native workloads. Lim explained that instead of relying solely on OpenShift’s built-in Secret objects, which store sensitive data as base64-encoded values within the etcd key-value store, the Secret Store CSI Driver creates a seamless integration with enterprise-grade external secret management systems like AWS Secrets Manager, Azure Key Vault, CyberArk Conjur and HashiCorp Vault.

“This approach represents the first step in enhancing OpenShift’s secret handling capabilities, aligning with enterprise security best practices while preserving the developer experience that makes Kubernetes and OpenShift powerful platforms for modern application development,” Lim said.

Source:: Network World