Red Hat OpenShift 4.16

Lebenszyklus von 3 Jahren für Red Hat OpenShift 4.14 und höher

Für Red Hat OpenShift 4.14 und alle folgenden Versionen mit gerader Versionsnummer gibt es jetzt optional einen zusätzlichen 12-monatigen Extended Update Support (EUS), der als Zusatzabonnement erhältlich ist. Damit verlängert sich der verfügbare Lebenszyklus für diese EUS-Releases von Red Hat OpenShift von der bisherigen 6-monatigen EUS-Laufzeit auf 3 Jahre. Weitere Details finden Sie in der Red Hat OpenShift Container Platform Life Cycle Policy.

Skalierung der Sicherheit mit dem Red Hat Advanced Cluster Security Cloud Service

Der Red Hat Advanced Cluster Security Cloud Service wurde von eingeschränkter Verfügbarkeit auf allgemeine Verfügbarkeit umgestellt. Red Hat Advanced Cluster Security Cloud Service ist ein vollständig verwalteter Kubernetes-nativer Sicherheits-Cloud-Service, der sowohl Red Hat OpenShift als auch Kubernetes-Plattformen von Drittanbietern unterstützt, darunter Amazon EKS, Google GKE und Microsoft AKS. Dieser Cloud-Service ermöglicht einen sicherheitsorientierten Ansatz für die Erstellung, Bereitstellung und Wartung von Cloud-nativen Anwendungen in der Hybrid Cloud, unabhängig von der zugrunde liegenden Kubernetes-Plattform.

Reduzieren Sie Kosten und optimieren Sie die Bereitstellungszeit von Clustern mit selbstverwalteten gehosteten Control Planes in AWS.

Gehostete Control Planes sind in der Multicluster Engine (MCE) für Kubernetes-Betreiber seit Version 2.4 standardmäßig aktiviert. Mit MCE Version 2.6 sind selbstverwaltete, gehostete Control Planes in AWS zusammen mit Red Hat OpenShift 4.16 allgemein verfügbar.

Hosted Control Planes machen die Verwaltung mehrerer OpenShift-Cluster in großem Maßstab effizienter und kostengünstiger. Sie zentralisieren das Management der Control Plane und ermöglichen eine bessere Ressourcennutzung und einfachere Wartung. Mit gehosteten Control Planes können Sie sich auf Ihre Anwendungen konzentrieren, indem Sie den Infrastruktur- und Verwaltungsaufwand reduzieren, die Cluster-Bereitstellungszeit optimieren und die Trennung von Verwaltung und Workload ermöglichen.

Externe Authentifizierungsserver in Red Hat OpenShift on AWS mit gehosteter Kontrollebene

Sie können jetzt Ihre eigene OpenID Connect (OIDC) Lösung in Red Hat OpenShift Service on AWS (ROSA) mit gehosteten Kontrollebenen integrieren, um Benutzer und Gruppen direkt mit dem Kubernetes API Server zu authentifizieren. ROSA-Cluster verwenden den AWS Security Token Service (STS) und OIDC, um Cluster-Operatoren den Zugriff auf die benötigten AWS-Ressourcen zu ermöglichen. Weitere Informationen finden Sie unter Vereinfachen Sie den Zugang zu Ihren ROSA-Clustern mit externem OIDC.

Sichere OpenShift Cluster-Vernetzung mit Admin Network Policy

Die nächste Generation von Kubernetes Network Policy wird nun vollständig in OpenShift-Bereitstellungen unterstützt, die OVN-Kubernetes für die Vernetzung verwenden. Admin Network Policy (auch bekannt als Global Network Policy) bietet Verbesserungen gegenüber der vorherigen Upstream-Implementierung von Network Policy. Einige der am meisten nachgefragten Features sind

Netzwerksicherheitsrichtlinien, die nur für Administratoren zugänglich sind und nicht von Namespace-Administratoren und Entwicklern überschrieben werden können.

Ein clusterweiter Gültigkeitsbereich. So können z.B. Egress-Richtlinien einmal an einer Stelle definiert werden und gelten dann für den gesamten Cluster-Verkehr.

Die Möglichkeit, spezifische, geprüfte Sicherheitsrichtlinien an Namespace-Administratoren und Entwickler zu delegieren, um ihnen die Flexibilität zu geben, die sie für die Anwendungsentwicklung benötigen.

Mit der Admin Network Policy können Sie

– Mandanten innerhalb eines Clusters mit Administratorrechten isolieren

– Erstellen einer festen Liste für Datenverkehr, der immer fließen muss

– eine unveränderliche Richtlinie für den gesamten Egress-Verkehr des Clusters festlegen. Beispielsweise können Sie den gesamten Datenverkehr durch ein Gateway-Gerät zur Überprüfung leiten.

– Definieren Sie eine Netzwerkverkehrsrichtlinie mit feiner Auflösung für hochselektive Verkehrsmuster, insbesondere für sensible Namensräume.

Reduzieren Sie den Zugriff nicht authentifizierter Benutzer oder Gruppen.

Ab OpenShift 4.16 gibt es eine Einschränkung der Berechtigungen für den Benutzer system:anonymous und die Gruppe system:unauthenticated.

Für Anwendungsfälle, die einen anonymen Zugriff erfordern, muss der Cluster-Administrator diese Berechtigungen explizit hinzufügen. Wenn Sie beispielsweise Webhooks für BuildConfigs von einem externen System (wie GitHub) verwenden, das das Senden von Authentifizierungstoken über HTTP nicht unterstützt, müssen Sie explizit system:webhook-Berechtigungen hinzufügen. Wir empfehlen dringend, in solchen Szenarien lokale Rollenverknüpfungen anstelle von Clusterrollenverknüpfungen zu verwenden. Ein Cluster-Administrator kann bei Bedarf ein ClusterRoleBinding für den anonymen Benutzer wieder hinzufügen, nachdem er die damit verbundenen Risiken und Vorteile abgewogen hat.

Einfachere Fehlerbehebung bei OpenShift-Updates mit oc adm Upgrade Status

Red Hat OpenShift 4.16 enthält einen neuen Befehl oc adm upgrade status, der als Technologievorschau verfügbar ist. Dieser Befehl zeigt den Fortschritt des Cluster-Updates an, eliminiert irrelevante Fehler und zeigt dem Administrator an, ob das Update gut läuft oder ob er eingreifen muss. Im Falle eines Updateproblems gibt der Befehl Informationen über die Vorgänge zurück, zusammen mit Hinweisen und Links zu relevanten Ressourcen (z.B. Red Hat Dokumentation oder Knowledge Base Artikel).

Vor-Ort-Migration zur Microsoft Entra Workload ID

Wenn Sie selbstverwaltetes Red Hat OpenShift auf Azure verwenden, können Sie jetzt mit minimaler Ausfallzeit zu Microsoft Entra Workload ID (früher Azure AD Workload Identity) migrieren.

Unterstützung für Microsoft Entra Workload ID wurde in Red Hat OpenShift 4.14 hinzugefügt, sodass Kunden Red Hat OpenShift-Cluster mit temporären, begrenzten Berechtigungen erstellen und verwalten können. Sie können nun Microsoft Entra Workload ID verwenden, ohne einen neuen Cluster erstellen zu müssen. Weitere Informationen finden Sie unter OpenShift mit Microsoft Entra Workload ID konfigurieren.

Optimierung der Cluster-Performance mit etcd-Einstellungsparametern

Sie können nun etcd so aktualisieren, dass Ihr Cluster eine geringere Latenz zwischen den etcd-Mitgliedern toleriert. Dazu setzen Sie die Latenzparameter für das Heartbeat-Intervall und die Leader-Selection-Timeouts auf Werte, die die Leistung optimieren und die Latenz verringern.

Auf diese Weise können Sie Szenarien mit langsameren, aber akzeptablen Festplatten oder gestreckten Clustern berücksichtigen, die den OpenShift Best Practices für Leistung und Skalierbarkeit entsprechen.

Optimieren Sie die automatische Cluster-Skalierung entsprechend der Workload-Anforderungen

Der Cluster-Autoscaler verwendet nun die Expander-Strategien LeastWaste, Priority und Random. Sie konfigurieren diese Expander, um die Auswahl der Maschinensätze bei der Skalierung Ihres Clusters zu beeinflussen.

Random: Empfohlen für eine gleichmäßige Verteilung der Arbeitslast über einen homogenen Cluster, in dem die Knotengruppen ähnliche Ressourcen zur Verfügung stellen.

LeastWaste: Für Cluster, bei denen Effizienz und Minimierung von Ressourcenverschwendung im Vordergrund stehen, insbesondere bei dynamischen Workloads, bei denen schnelle Skalierbarkeit und Flexibilität wichtiger sind.

Priorität: Für anspruchsvolle Skalierungsentscheidungen auf Basis benutzerdefinierter Prioritäten und geeignet für komplexe Cluster mit mehreren Knotengruppen.

Bringen Sie Ihren eigenen Load Balancer für die Bereitstellung vor Ort mit

Mit Red Hat OpenShift 4.16 können Sie Ihren eigenen Load Balancer in Verbindung mit einem Cluster auf einer beliebigen lokalen Infrastruktur verwenden (Bare Metal, VMware vSphere, Red Hat OpenStack Platform, Nutanix und andere). Für diese Konfiguration geben Sie loadBalancer.type:UserManaged in der Datei install-config.yaml Ihres Clusters an. Weitere Informationen zu diesem Feature finden Sie unter Services für einen User-Managed Load Balancer.

Verbessern Sie die Beobachtbarkeit Ihres Clusters durch erweitertes Monitoring und Troubleshooting

Red Hat OpenShift 4.16 führt signifikante Erweiterungen der Überwachungsfunktionen ein und bietet verbesserte Tools für die Überwachung, Fehlerbehebung und Optimierung eines Clusters. Es gibt Updates für die Komponenten des In-Cluster-Monitoring-Stacks wie Prometheus, Thanos und neue Alert-Regeln. Ein neuer Metrics Server vereinfacht das Sammeln von Metriken und die neue Monitoring Alert Manager View-Rolle verbessert die Sicherheit und Zusammenarbeit.

Diese Funktionen sind im Cluster Observability Operator Version 0.3.0 enthalten, der als zentraler Einstiegspunkt für die Installation und Verwaltung von Observability dient. Diese Version enthält auch Verbesserungen für OpenTelemetry und eine erweiterte Cluster Logging API Funktionalität.

Der Cluster Observability Operator bietet eine neue Version von Observability Signal Correlation für die Korrelation von Observability Signalen, Incident Detection für die Priorisierung von kritischen Alarmen und Verbesserungen im verteilten Tracing mit Tempo Operator Unterstützung für monolithisches Deployment. Visualisierungen des Distributed Tracing werden nun in der OpenShift Konsole angezeigt.

Observability Signal Correlation und Incident Detection sind beide in der Developer Preview verfügbar. Die Energieüberwachung, die für die Technologievorschau verfügbar ist, bietet jetzt eine Integration der Benutzeroberfläche (UI) für Entwickler und verbessert die Datengenauigkeit.

Red Hat OpenShift Virtualisierung

Im Bereich Red Hat OpenShift Virtualization ist die allgemeine Verfügbarkeit von Metro Disaster Recovery für virtuelle Maschinen (VMs) verfügbar, die Storage auf Red Hat OpenShift Data Foundation in Verbindung mit Red Hat Advanced Cluster Management for Kubernetes (RHACM) für die Verwaltung nutzen.

Red Hat hat eine Reihe von VM-Verbesserungen hinzugefügt. Zusätzliche vCPU-Ressourcen können nun deklarativ zu einer laufenden VM hinzugefügt werden. Es gibt eine verbesserte Speicherdichte mit sicherem Speicher-Overcommit, was die Skalierung von VMs mit CPU-Hotplug erleichtert.

Mit RHACM können Sie jetzt Multi-Cluster VMs überwachen. Von einem RHACM-Hub aus können Sie alle VMs in mehreren OpenShift-Clustern anzeigen. Sie können Berichte für alle VMs sammeln und schnell erstellen. Von einem RHACM Global Hub aus können Sie mit der Global Hub Search alle VMs über mehrere Hubs hinweg anzeigen.

Das Ökosystem wächst weiter mit Hardware-Partnern, Storage- und Netzwerkinfrastruktur-Partnern sowie Drittanbietern von Datensicherheitslösungen. Neben Veeam Box, Trilio und Storaware werden in Kürze auch Funktionen von Cohesity, Commvault, Rubrik und Veritas verfügbar sein.

Image-basiertes Update für OpenShift Single Node Cluster mit Lifecycle Agent

Die Telekommunikationspartner von Red Hat setzen Container für Radio Access Networks (RAN) ein und implementieren Lösungen auf OpenShift mit einem Knoten. Red Hat OpenShift 4.16 bietet einen „Shift Left“-Ansatz mit Image-basierten Updates (IBU). IBU bietet eine alternative Möglichkeit, einen OpenShift Single Node Cluster zu aktualisieren, wobei OpenShift Single Node Anwender einen großen Teil des Update-Prozesses in eine Vorproduktionsumgebung verlagern, um den Zeitaufwand für das Update am Produktionsstandort zu reduzieren.

IBU ermöglicht Z-Stream-Updates, kleinere Versionsupdates und direkte EUS-zu-EUS-Updates, bei denen die Zwischenversion übersprungen wird.

Bei dieser Aktualisierungsmethode wird der Lifecycle Agent verwendet, um ein OCI-Image von einem dedizierten Seed-Cluster zu erstellen, das auf dem Ziel-OpenShift-Cluster mit einem Knoten als neuem Ostree-Stateroot installiert wird. Ein Seed-Cluster ist ein Single-Node OpenShift-Cluster, der mit der Zielversion der OpenShift Container Platform, den verwendeten Operatoren und Konfigurationen, die für alle Ziel-Cluster gleich sind, bereitgestellt wird. Anschließend verwenden Sie das Seed-Image, um die Plattformversion auf einem beliebigen OpenShift Single Node Cluster zu aktualisieren, der die gleiche Kombination aus Hardware, Operatoren und Clusterkonfiguration aufweist wie der Seed-Cluster.

Sollte ein Update fehlschlagen oder die Anwendung nicht in einen funktionsfähigen Zustand zurückkehren, kann sie auf den Zustand vor dem Update zurückgesetzt werden – Achtung: Dies gilt nur für OpenShift Single Node Cluster. Dies stellt sicher, dass der Service so schnell wie möglich wiederhergestellt wird, unabhängig davon, ob das Update erfolgreich war oder fehlgeschlagen ist. IBU ist nahtlos in die Zero Touch Provisioning Workflows integriert, die Red Hat OpenShift GitOps und Red Hat Advanced Cluster Management nutzen.

Erstellen Sie eine eigenständige OpenShift-Appliance in großem Maßstab

Partner, die maßgeschneiderte, schlüsselfertige Appliances mit eigenständigem OpenShift und zusätzlichen Diensten in großem Umfang auf ihrer eigenen Hardware erstellen möchten, können dies jetzt mit dem OpenShift-basierten Appliance Builder tun, der für die Technology Preview verfügbar ist. Der OpenShift-basierte Appliance Builder ist ein Container-basiertes Dienstprogramm, das ein Disk-Image erstellt, das den Agent-basierten Installer enthält, der für die Installation mehrerer OpenShift-Cluster verwendet wird.

OpenShift Appliance Builder Arbeitsablauf

Verbesserte Vernetzung, GitOps-Management und nahtlose EUS-Updates für MicroShift

Für den Red Hat-Build von MicroShift führt die neueste Version drei Updates ein, um das Edge-Management zu verbessern:

Hinzufügen mehrerer Netzwerkschnittstellen zu Pods Multus CNI für MicroShift: Multus ermöglicht es Kubernetes-Pods, sich mit mehreren Netzwerken zu verbinden, was nützlich ist, wenn Sie SR-IOV verwenden oder komplexe VLAN-Konfigurationen haben. Wenn Multus auf MicroShift aktiviert ist, können Sie mit den CNI-Plugins bridge, macvlan oder ipvlan einfach mehrere Schnittstellen zu Pods hinzufügen.

Automatisieren Sie das Infrastruktur- und Applikationsmanagement mit GitOps für MicroShift: Mit GitOps für MicroShift können Sie Kubernetes-basierte Infrastrukturen und Applikationen über Cluster und Entwicklungszyklen hinweg konsistent konfigurieren und bereitstellen. GitOps with Argo CD for MicroShift ist ein leichtgewichtiges, optionales Add-On, das vom Red Hat OpenShift GitOps Operator abgeleitet wurde.

GitOps für MicroShift verwendet die Argo-CD-Kommandozeilenschnittstelle, um mit dem GitOps-Controller zu interagieren, der als deklarative GitOps-Engine fungiert.

Direkte EUS-Updates für MicroShift: MicroShift aktualisiert nun direkt von Extended User Support (EUS) Version 4.14 auf Version 4.16 in einem einzigen Neustart (Red Hat Enterprise Linux 9.4 wird für Version 4.16 benötigt).

3 year lifecycle for Red Hat OpenShift 4.14 and beyond

Available as an add-on subscription, there’s now an optional additional 12 months Extended Update Support (EUS) term for Red Hat OpenShift 4.14 and all subsequent even-numbered releases. This takes the full lifecycle available for these EUS releases of Red Hat OpenShift to 3 years, extended from the previous 6 month EUS term. Refer to Red Hat OpenShift Container Platform Life Cycle Policy for additional details.

Shift left and scale security with Red Hat Advanced Cluster Security Cloud Service

Red Hat Advanced Cluster Security Cloud Service is now promoted from limited availability to general availability. Red Hat Advanced Cluster Security Cloud Service is a fully managed Kubernetes-native security cloud service supporting both Red Hat OpenShift as well as non-Red Hat Kubernetes platforms, including Amazon EKS, Google GKE and Microsoft AKS. This cloud service lets you take a security-forward approach to building, deploying, and maintaining cloud-native applications at scale across the hybrid cloud, regardless of the underlying Kubernetes platform.

Reduce cost and optimize cluster deployment time with self-managed hosted control planes in AWS

Hosted control planes have been enabled by default in the multicluster engine (MCE) for Kubernetes operator since version 2.4. With MCE version 2.6, self-managed hosted control planes in AWS are generally available alongside Red Hat OpenShift 4.16.

Hosted control planes make it more efficient and cost effective for you to manage multiple OpenShift clusters at scale. It centralizes the control plane management and allows for better resource utilization and simpler maintenance. With hosted control planes, you get to focus on applications by reducing infrastructure overhead, management overhead, optimizing cluster deployment time, and enabling separation of concerns between management and workloads.

External auth servers in Red Hat OpenShift on AWS with hosted control plane

You can now bring your own OpenID Connect (OIDC) solution to Red Hat OpenShift Service on AWS (ROSA) with hosted control planes, so you can authenticate users and groups directly with the Kubernetes API server. ROSA clusters use AWS Security Token Service (STS) and OIDC to grant in-cluster operators access to necessary AWS resources. Learn more at Simplify access to your ROSA clusters using external OIDC.

Secure OpenShift cluster networking with Admin Network Policy

The next generation of Kubernetes Network Policy is now fully supported in OpenShift deployments using OVN-Kubernetes for networking. Admin Network Policy (also known as Global Network Policy) provides enhancements to the upstream’s previous Network Policy implementation. The most requested features include:

Administrator-privileged-only network security policies that cannot be overridden by namespace admins and developers

A cluster-wide scope. For example, egress policies can be defined a single time in one place and apply to all cluster traffic

The ability to delegate specific, vetted security policy to namespace administrators and developers, so they have the network policy flexibility they need for application development

The Admin Network Policy allows you to:

• Isolate tenants within a cluster with admin-privileged control
• Create a definitive allow-list for traffic that must always flow
• Specify an immutable policy for all cluster egress traffic. For example, you can force all traffic through a gateway device for inspection
• Define network traffic policy with fine resolution for highly selective traffic patterns, especially to and from sensitive namespaces

Reduce unauthenticated user or group access

Beginning with OpenShift 4.16, there’s a limit on the permissions given to the system:anonymous user and system:unauthenticated group. For use cases where anonymous access is needed, the cluster administrator must explicitly add those permissions. For example, if you’re using webhooks for BuildConfigs from an external system (like GitHub) that don’t support sending auth tokens over HTTP, then you’d need to explicitly add system:webhook permissions. We strongly recommend using local rolebindings instead of clusterrole bindings in such scenarios. A cluster administrator can add back a ClusterRoleBinding for the anonymous user as needed, after evaluating the risks and benefits associated with it.

Easier OpenShift update troubleshooting with oc adm upgrade status

Red Hat OpenShift 4.16 includes a new oc adm upgrade status command, which is available as a technology preview. This command displays cluster update progress, eliminating irrelevant noise, and shows the admin whether the update is going well or whether they need to intervene. In the event of an update issue, the command returns information about what’s happening, accompanied with guidance and links to relevant resources (such as Red Hat documentation or knowledge base articles).

In-place migration to Microsoft Entra Workload ID

If you’re using self-managed Red Hat OpenShift on Azure, then you can now migrate to Microsoft Entra Workload ID (formerly Azure AD Workload Identity) with minimal downtime. Microsoft Entra Workload ID support was added in Red Hat OpenShift 4.14, which provides customers a way to create and manage Red Hat OpenShift clusters with temporary, limited privilege credentials. Now you can adopt Microsoft Entra Workload ID without having to start over with a new cluster. See Configuring OpenShift with Microsoft Entra Workload ID for details.

Optimize cluster performance with etcd tuning parameters

You can now update etcd to allow your cluster to tolerate decreased latency between etcd members. To do this, you set the latency parameters for the heartbeat interval and leader election timeouts to values that optimize performance and decreased latency.

This allows you to accommodate scenarios where you may have slower but acceptable disks, or stretched clusters that fall within the OpenShift performance and scalability best practices.

Optimize cluster autoscaling according to workload needs

The cluster autoscaler now uses the LeastWaste, Priority, and Random expander strategies. You configure these expanders to influence the selection of machine sets when scaling your cluster.

Random: Recommended for distributing workloads evenly across a homogenous cluster where the node groups offer similar resources

LeastWaste: For clusters where efficiency and minimizing resource waste are priorities, particularly with dynamic workloads where rapid scaling and flexibility are more important

Priority: For sophisticated scaling decisions based on user-defined priorities, and it is suitable for complex clusters with diverse node groups

Bring your own load balancer for on-premises deployment

With Red Hat OpenShift 4.16, you can use your own user-managed load balancer in conjunction with a cluster on any on-premises infrastructure (bare metal, VMware vSphere, Red Hat OpenStack Platform, Nutanix, and more). For this configuration, you specify loadBalancer.type:UserManaged in your cluster’s install-config.yaml file. See services for a user-managed load balancer to learn more about this feature.

Boost your cluster observability with advanced monitoring and troubleshooting

Red Hat OpenShift 4.16 introduces significant enhancements to its observability capabilities, providing improved tools for monitoring, troubleshooting, and optimizing a cluster. There have been updates to in-cluster monitoring stack components such as Prometheus, Thanos, and new alerting rules. A new Metrics Server simplifies metrics collection, and the new monitoring-alertmanager-view role enhances security and collaboration. These features are included in the Cluster Observability Operator version 0.3.0, which serves as a single entry point operator for installing and managing observability. This release also adds improvements to OpenTelemetry and increased Cluster Logging API functionality.

Cluster Observability Operator introduces a new version of Observability Signal Correlation for correlating observability signals, Incident Detection for prioritizing critical alerts, and enhancements to distributed tracing with Tempo Operator support for the monolithic deployment. Distributed tracing visualizations are now displayed in the OpenShift console.

Observability Signal Correlation and Incident Detection are both available for developer preview. Power monitoring, which is available for technology preview, now provides a developer user interface (UI) integration and improves data accuracy.

Red Hat OpenShift Virtualization

On the Red Hat OpenShift Virtualization front,  the general availability of metro disaster recovery for virtual machines (VMs) is here which use storage deployed on Red Hat OpenShift Data Foundation in conjunction with Red Hat Advanced Cluster Management for Kubernetes (RHACM) for management.

Red Hat added a number of VM enhancements. You now have the ability to add additional vCPU resources to a running VM in a declarative manner. There’s improved memory density with safe memory overcommit, and that made it easier to scale up VMs with CPU hotplug.

Using RHACM, you’re now able to monitor multi-cluster VMs. From a RHACM Hub, you’re able to view all VMs across multiple OpenShift clusters. You can collect and quickly build reports for all VMs. At a RHACM Global Hub using Global Hub Search, you’re able to view all VMs across multiple hubs.

The ecosystem continues to grow with hardware partners, storage and network infrastructure partners, as well as third-party data protection providers. In addition to Veeam Kasten, Trilio, and Storaware, there are upcoming capabilities from Cohesity, Commvault, Rubrik, and Veritas.

Image-based update for single-node OpenShift clusters using Lifecycle Agent

Red Hat’s telecommunication partners are shifting to use containers for Radio Access Networks (RAN), deploying solutions on single node OpenShift. Red Hat OpenShift 4.16 features a „shift left“ approach with image-based updates (IBU). IBU provides an alternative way to update a single node OpenShift cluster, whereby single node OpenShift users shift a large portion of the update process to a pre-production environment to reduce the time spent updating at the production site.

IBU allows you to perform z-stream updates, minor version updates, as well as direct EUS-to-EUS update, where the interim version is skipped. This update method utilizes the Lifecycle Agent to generate an OCI image from a dedicated seed cluster that is installed on the target single node OpenShift cluster as a new ostree stateroot. A seed cluster is a single node OpenShift cluster deployed with the target OpenShift Container Platform version, deployed operators, and configurations that are common to all target clusters. You then use the seed image to update the platform version on any single node OpenShift cluster that has the same combination of hardware, operators, and cluster configuration as the seed cluster.

In addition, if an update fails or the application does not return to a functioning state, it can be rolled back to the pre-update state – note: this applies only to single node OpenShift clusters. This ensures service is restored as quickly as possible in either an update success or failure scenario. IBU is seamlessly integrated into the Zero Touch Provisioning flows that use Red Hat OpenShift GitOps and Red Hat Advanced Cluster Management.

Build self-contained OpenShift appliance at scale

Partners who want to build customized turnkey appliances with self-contained OpenShift and added services on their prescribed hardware at scale can now do so using the OpenShift-based Appliance Builder, which is available for Technology Preview. The OpenShift-based Appliance Builder is a container-based utility that builds a disk image that includes the Agent-based Installer, which is used to install multiple OpenShift clusters. Refer to the OpenShift-based Appliance Builder User Guide for more information.

OpenShift Appliance Builder Workflow

Enhanced networking, GitOps management, and seamless EUS Updates for MicroShift

For the Red Hat build of MicroShift, the latest release introduces three updates to enhance edge management:

Attach multiple network interfaces to pods Multus CNI for MicroShift: Multus enables Kubernetes pods to attach to multiple networks, which is useful when you use SR-IOV or have complex VLAN configurations. With Multus enabled on MicroShift, you can easily add multiple interfaces to pods using CNI plugins bridge, macvlan, or ipvlan

Automate infrastructure and application management with GitOps for MicroShift: With GitOps for MicroShift, you can consistently configure and deploy Kubernetes-based infrastructure and applications across clusters and development lifecycles. GitOps with Argo CD for MicroShift is a lightweight, optional add-on controller derived from the Red Hat OpenShift GitOps Operator. GitOps for MicroShift uses the Argo CD command-line interface to interact with the GitOps controller that acts as the declarative GitOps engine

Direct EUS updates for MicroShift: MicroShift now directly updates from Extended User Support (EUS) version 4.14 to version 4.16 in a single reboot (Red Hat Enterprise Linux 9.4 is required for version 4.16).