Ankündigung von zusätzlichem Extended Update Support für OpenShift 4.14 und höher!

Red Hat kündigt eine optionale zusätzliche 12-monatige EUS-Laufzeit für OpenShift 4.14 und nachfolgende Red Hat OpenShift Releases mit gerader Nummerierung der 4.x-Reihe an. Damit beträgt der vollständige Lifecycle, der für diese EUS-Releases von OpenShift zur Verfügung steht, drei (3) Jahre.

Zum Auftakt des Red Hat Summit hier in Denver mit dem OpenShift Commons Gathering werden wir von Ihnen, unseren Kunden, hören, die täglich auf Red Hat OpenShift setzen. In den vergangenen Jahren haben Kunden die Technologie von OpenShift für Use Cases in spezialisierten Märkten eingesetzt, die längere Lebenszyklen erfordern.Unsere Kunden setzen auf Red Hat, um die Lebensdauer unserer Open Source-Komponenten zu verlängern, und zwar sowohl aufgrund von vielschichtigen Compliance-Anforderungen als auch aufgrund der Tatsache, dass OpenShift grundlegende Services bereitstellt, die von Regierungen und Unternehmen unterschiedlich behandelt werden.Red Hat untersucht jedes Jahr längere Lifecycles anhand einer Reihe von Kriterien. In diesem Jahr haben wir den passenden Mix von Bedingungen gefunden, der es uns ermöglicht, etwas zu tun, um unsere Kunden in diesen Situationen zu unterstützen.

Angesichts der komplexen Anforderungen unserer Kunden erweitern wir unser Extended Update Support (EUS)-Angebot für Red Hat OpenShift und bieten Ihnen die Möglichkeit, den unterstützten Lifecycle von OpenShift-Deployments erheblich zu verlängern.

Der Support wird über die bestehende 6-monatige EUS-Laufzeit, die mit der Veröffentlichung von OpenShift 4.12 eingeführt wurde, erweitert. Diese neue, zusätzliche EUS-Laufzeit von 12 Monaten ist als Add-On-Subskription erhältlich und verlängert den Lifecycle von OpenShift auf insgesamt 3 Jahre.

Mit der zusätzlichen EUS-Laufzeit wird OpenShift 4.14 nun bis zum 31. Oktober 2026 unterstützt:

Die nächste Version mit Extended Update Support ist die kommende Version von OpenShift 4.16. Die Auswirkungen auf den Lifecycle von EUS-Releases werden ebenfalls im Folgenden visualisiert:

Die zusätzliche EUS-Laufzeit umfasst Rückportierungen von Sicherheitsupdates mit kritischen und wichtigen Auswirkungen sowie Fehlerbehebungen mit dringender Priorität. Die formale Formulierung wird auf der Seite Red Hat OpenShift Container Platform Lifecycle Policy veröffentlicht, die weiterhin die zentrale Quelle für aktuelle Informationen zum OpenShift Lifecycle ist.

Das während der zusätzlichen EUS-Phase angebotene Support-SLA wird aus dem erworbenen Basisangebot (Premium oder Standard) übernommen.

Welche Komponenten sind enthalten?

Die zusätzliche EUS-Laufzeit gilt für alle plattformorientierten Operatoren, die in OpenShift Kubernetes Engine enthalten sind. Andere Operatoren werden nicht automatisch einbezogen und unterliegen weiterhin ihren eigenen Lifecycles.

Kunden, die OpenShift Platform Plus oder OpenShift Container Platform als Basissubskription kaufen, können trotzdem die entsprechende zusätzliche Laufzeit für erweiterten Update-Support für dieses Angebot erwerben. Sie erhalten aber nur die zusätzliche EUS-Laufzeit für diejenigen Komponenten, für die sie verfügbar ist.

Wir gehen davon aus, diese zusätzliche EUS-Laufzeit in Zukunft für weitere Red Hat Operatoren anbieten zu können. Überprüfen Sie immer die Lifecycle-Seite für den relevanten Operator, um die neuesten Lifecycle-Informationen zu erhalten.

Wie wirkt sich das auf Upgrades aus?

OpenShift 4.14 unterstützt weiterhin eine N-2-Versionsabweichung zwischen Control Plane-Services und Workerknoten, wobei N das relevante Neben-Release von OpenShift ist. Dies bedeutet beispielsweise, dass eine Control Plane, die zu OpenShift 4.14 migriert wurde, mit Workerknoten auf 4.13 und/oder 4.12 als Teil einer Upgrade-Sequenz interagieren kann.

Für die Control Plane-Knoten selbst bleiben Upgrades sequenziell. Für die Workerknoten gibt es jedoch eine Möglichkeit, Workerpools anzuhalten, um jede zweite Version – und den damit verbundenen Neustart – zu überspringen. Dies ermöglicht in Kombination mit der Versionsabweichungs-Unterstützung die Minderung der zusätzlichen Auswirkungen mehrerer Upgrades auf laufende Workloads.

Beispielhafter Upgrade-Ablauf für Control Plane- und Workerknoten von 4.14 auf ein zukünftiges Release von 4.18.

Vorbehaltlich weiterer Tests wird diese Funktion in zukünftigen Releases in Übereinstimmung mit der Erweiterung der Upstream-Versionsabweichung von Kubernetes ausgebaut. Diese geht in eine Richtlinie zur Unterstützung einer N-3-Versionsabweichung über.

Da der Zeitraum zwischen der Quell- und Zielversion im Laufe der Zeit wächst, wächst auch die Anzahl der sequenziellen Upgrades, die erforderlich sind, um die neueste EUS-Version zu erhalten. Mit der Anzahl der erforderlichen sequenziellen Upgrades wächst auch die Komplexität des Upgrades, das Ausmaß der Workload-Unterbrechung und die erforderliche Zeit. Wenn die Kapazität dies zulässt, ist es daher möglicherweise wünschenswerter, ein Upgrade über einen Blue-/Green-Upgrade-Prozess durchzuführen, bei dem ein neuer Cluster vertikal skaliert, Workloads verschoben und der alte Cluster außer Betrieb genommen wird.

Jeder Cluster ist anders und daher benötigt jeder Cluster seinen eigenen Pfad zum Upgrade. Wenn Sie sich für die Nutzung dieser OpenShift EUS-Laufzeiten für einen Cluster entscheiden, empfehlen wir, dass Sie gleichzeitig einen Upgrade-Plan auswählen.

Mehr erfahren

Red Hat ist der Long Term Support (LTS) Working Group innerhalb des Kubernetes-Partnernetzwerks beigetreten, um Ideen zu fördern, wie die Lebensdauer von Kubernetes und den zugehörigen Technologien verlängert werden kann. Wir laden alle Nutzer, die sich für diese Themen interessieren, ein, dieser Community beizutreten.

Mehr erfahren Sie auf dem virtuellen Event „What's New in OpenShift 4.16“. Folgen Sie uns auf YouTube oder Twitch, um über das Übertragungsdatum informiert zu werden.

Und wenn Sie OpenShift noch nicht nutzen und wir Ihr Interesse geweckt haben: Testen Sie es!