Verfügbare Versionen IBM Cloud Kubernetes Service

IBM Cloud Kubernetes Service unterstützt momentan mehrere Versionen von Kubernetes. Wenn eine aktualisierte Version (n) freigegeben wird, werden bis zu 2 Vorgängerversionen (n-2) unterstützt. Versionen, die mehr als zwei Versionen von der neuesten Version (n-3) abweichen, werden zunächst nicht mehr verwendet (veraltet) und dann nicht mehr unterstützt. Um weiterhin wichtige Aktualisierungen für Sicherheitspatches zu erhalten, stellen Sie sicher, dass in Ihren Clustern stets eine unterstützte Kubernetes-Version ausgeführt wird. Veraltete Cluster erhalten möglicherweise keine Sicherheitsupdates. Weitere Informationen finden Sie unter Release-Lebenszyklus.

Datumsangaben mit einem Kreuzzeichen (†) sind vorläufig und können sich ändern. Betriebssysteme, die mit einem Sternchen (*) gekennzeichnet sind, sind veraltet. Migrieren Sie alle Arbeitsknoten, die ein veraltetes Betriebssystem verwenden, auf eine neuere Version des Betriebssystems.

Aktualisierungstypen

Für Ihre Kubernetes-Cluster gibt es drei Typen von Aktualisierungen: Hauptversionsaktualisierungen, Nebenversionsaktualisierungen und Patchaktualisierungen. Sobald Aktualisierungen verfügbar sind, werden Sie benachrichtigt, wenn Sie Informationen zum Cluster-Master oder den Workerknoten anzeigen, beispielsweise mit den Befehlen ibmcloud ks cluster ls, cluster get, worker ls und worker get.

IBM stellt Fixpacks für Workerknoten zweiwöchentlich bereit. IBM ziel ist es, aufgedeckte, legitime Schwachstellen innerhalb einer dem Risiko angemessenen Zeit zu beheben. Um die Qualität und Stabilität des Release sicherzustellen, können Fixpacks verzögert werden.

Fixpacks werden auf die neueste stabile Upstream-Kernelversion angewendet, die von Canonical bereitgestellt wird.

Um Ihre Knoten zu schützen, müssen die Fixpacks für Workerknoten so schnell wie möglich installiert werden. Sie können Benachrichtigungen abonnieren, um benachrichtigt zu werden, wenn ein neues Update verfügbar ist.

Aktualisierungen von Haupt- und Nebenversionen (1.x)

Zuerst aktualisieren Sie Ihren Masterknoten und anschließend aktualisieren Sie die Workerknoten.

• Sie können für einen Kubernetes-Master kein Update über zwei oder mehr nachfolgende Nebenversionen hinweg durchführen (n+2). Wenn Ihr aktueller Master beispielsweise die Version 1.34 hat und Sie auf 1.36 aktualisieren möchten, müssen Sie zunächst auf 1.35 aktualisieren.
• Auf Workerknoten kann keine Haupt- oder Nebenversion von Kubernetes ausgeführt werden, die höher ist als die Version auf dem Master. Darüber hinaus können Ihre Workerknoten nur bis zu zwei Versionen älter sein als die Masterversion (n-2).
• Wenn Sie eine kubectl-CLI-Version verwenden, die nicht wenigstens mit der Version major.minor Ihrer Cluster übereinstimmt, kann dies zu unerwarteten Ergebnissen führen. Stellen Sie sicher, dass Ihre Kubernetes-Cluster- und Ihre CLI-Version auf dem neuesten Stand bleiben.

Patchaktualisierungen (x.x.4_1510)

Patchübergreifende Änderungen werden im Änderungsprotokoll jeder Version dokumentiert. Master-Patches werden automatisch angewendet. Patches und Aktualisierungen für Workerknoten müssen jedoch von Ihnen eingeleitet werden. Workerknoten können außerdem Patchversionen ausführen, die höher als die des Masters sind. Sobald Aktualisierungen verfügbar sind, werden Sie benachrichtigt, wenn Sie Informationen zum Masterknoten und den Workerknoten in der IBM Cloud-Konsole oder -CLI anzeigen, beispielsweise mit den folgenden Befehlen: ibmcloud ks cluster ls, cluster get, worker ls und worker get.

Patches können für Workerknoten und/oder Master gelten.

• Patches für Worker-Knoten: Überprüfen Sie monatlich, ob ein Update verfügbar ist. Der zu verwendende Befehl hängt von der Art Ihrer Cluster-Infrastruktur und der Ausführung des Worker-Knotens ab.
  • Klassische Cluster: Verwenden Sie den Befehl ibmcloud ks worker reload ibmcloud ks worker update oder. Während eines Updates oder Neuladens wird der Worker-Knoten neu installiert, und Daten werden gelöscht, sofern sie nicht außerhalb des Worker-Knotens gespeichert sind.
  • VPC Virtual Server Instance (VSI)-Worker: Verwenden Sie den Befehl ibmcloud ks worker replace. Der alte Worker-Knoten wird gelöscht und an seiner Stelle wird ein neuer bereitgestellt. Daten werden gelöscht, sofern sie nicht außerhalb des Worker-Knotens gespeichert werden.
  • VPC-Bare-Metal-Mitarbeiter: Verwenden Sie den Befehl ibmcloud ks worker reload. Der Knoten wird an Ort und Stelle neu geladen und behält seine IP-Adresse bei. Daten auf lokalen Festplatten werden gelöscht, wenn sie nicht außerhalb des Worker-Knotens gespeichert sind.
• Master-Patches: Master-Patches werden automatisch über mehrere Tage hinweg angewendet, sodass eine Master-Patch-Version möglicherweise als verfügbar angezeigt wird, bevor sie auf den Master angewendet wird. Die Aktualisierungsautomatisierung überspringt auch Cluster, die sich in einem nicht einwandfreien Zustand befinden oder in denen derzeit Operationen ausgeführt werden. Gelegentlich kann es vorkommen, dass IBM automatische Updates für ein bestimmtes Master-Fix-Pack deaktiviert, wie im Änderungsprotokoll vermerkt, beispielsweise bei einem Patch, der nur benötigt wird, wenn ein Master von einer Minor-Version auf eine andere aktualisiert wird. In jedem dieser Fälle können Sie den Befehl ibmcloud ks cluster master update selbst sicher ausführen, ohne abzuwarten, bis die automatische Aktualisierung wirksam wird.

Release-Lebenszyklus

Jede unterstützt Version von IBM Cloud Kubernetes Service durchläuft einen Lebenszyklus, der Test, Entwicklung, allgemeine Freigabe, Unterstützung, Einstellung der Unterstützung und Nichtunterstützung umfasst. Lesen Sie die Beschreibungen der einzelnen Phasen im Lebenszyklus einer Version.

Zum besseren Verständnis werden Schätzwerte für Tage und die Versionen angegeben. Die tatsächliche Verfügbarkeit und die Freigabetermine können Änderungen unterliegen und sind abhängig von verschiedenen Faktoren wie Community-Aktualisierungen, Sicherheitspatches und Technologieänderungen zwischen Versionen.

1. Community-Release: Die Community gibt die neue Version frei. IBM-Ingenieure beginnen mit dem Testen und der Absicherung der Community-Version, um die Veröffentlichung einer unterstützten IBM Cloud Kubernetes Service-Version vorzubereiten.

2. Lebenszyklus der unterstützten Version:

   Entwicklungsrelease

   Release befindet sich in der Entwicklung und ist möglicherweise als Betaversion für ausgewählte Kunden verfügbar. IBM bietet für diese Version Support nach bestem Bemühen.

   Allgemeine Verfügbarkeit

   Das Release ist allgemein verfügbar (GA). IBM bietet umfassenden Support für die Version und gibt einen vorläufigen Termin an, ab dem der Support für die Version ausläuft. Die Version wird zur Standardversion bei der Clustererstellung, sobald nur noch minimale Einschränkungen bestehen und eine angemessene Akzeptanzrate erreicht ist.

   Wartung

   Das Release hat Wartungsunterstützung gemäß der Definition durch die Kubernetes-Community erhalten. IBM bietet Wartungsunterstützung für Kubernetes basierend auf Community-Richtlinie. Andernfalls bietet IBM vollständige Unterstützung.

3. Veraltete Version: Die Version ist veraltet. IBM stellt ein aktualisiertes nicht unterstütztes Zieldatum für das Release bereit. Ein nicht unterstützter Countdown bis zu diesem Datum wird mindestens 45 Tage vor dem Release bereitgestellt. IBM bietet in dieser Phase Support für die Version in Übereinstimmung mit den Richtlinien der Kubernetes-Community. Diese Supportphase ist die letzte Phase, bevor die Version nicht mehr unterstützt wird, und hat Vorrang vor der Wartungs- und der erweiterten Supportphase, falls es zu Überschneidungen kommt. Es werden möglicherweise keine Sicherheitspatches bereitgestellt. Während der Auslaufphase wird die Version weiterhin unterstützt und Ihr Cluster ist weiterhin funktionsfähig. Sie müssen jedoch Ihre Cluster-Steuerungsebene und Ihre Worker-Knoten auf eine unterstützte Version aktualisieren, um Sicherheitslücken zu beheben.

4. Nicht unterstützte Version: Die Version wird nicht unterstützt. IBM-Support wird ausschließlich bereitgestellt, um Sie beim Upgrade auf eine unterstützte Version zu unterstützen. Für nicht unterstützte Cluster werden keine Sicherheits- oder Patch-Updates bereitgestellt, und sie werden vom IBM Cloud-Support nicht unterstützt. Auch wenn Ihr Cluster und Ihre Anwendungen möglicherweise noch eine Zeit lang weiterlaufen, können Sie bei Auftreten eines Problems keine Cluster-Control-Plane- oder Worker-Knoten mehr erstellen, neu laden oder andere Korrekturmaßnahmen daran vornehmen. Sie können die Cluster- oder Workerknoten immer noch löschen oder den Cluster auf die nächste Version aktualisieren. Überprüfen Sie die potenziellen Auswirkungen und aktualisieren Sie den Cluster, um weiterhin wichtige Sicherheitsaktualisierungen und -unterstützung zu erhalten. Wenn die Cluster-Steuerungsebene zwei oder mehr Versionen hinter der ältesten unterstützten Version zurückliegt, können Sie keine Updates mehr anwenden und müssen den Cluster löschen und einen neuen erstellen.

   Cluster, die eine nicht unterstützte Version verwenden, werden irgendwann ausfallen, weil Cluster-Zertifikate ablaufen. Zu den Fehlern können unter anderem eine nicht verfügbare Cluster-Steuerungsebene, NotReady-Arbeitsknoten oder ein fehlerhafter Ingress gehören.

5. Archiviert: Diese Version wird nicht mehr unterstützt und es ist kein Upgrade-Pfad verfügbar. IBM bietet keinen Support an und behält sich das Recht vor, die Steuerungsebenen für archivierte Cluster abzuschalten.

IBM Cloud Kubernetes Service hat den unterstützten Versatz zwischen Kernknoten und Steuerungskomponenten nicht um eine Nebenversion erweitert. Die unterstützte Abweichung bleibt n-2. Weitere Informationen finden Sie unter „ Änderungen an der unterstützten Skew-Zeit zwischen Control Plane und Node-Versionen “ in den Kubernetes Community-Informationen.

Wenn Sie abwarten, bis Ihr Cluster mindestens zwei Nebenversionen hinter der ältesten unterstützten Version zurück liegt, können Sie den Cluster nicht mehr aktualisieren. Erstellen Sie stattdessen einen neuen Cluster, stellen Sie Ihre Apps in dem neuen Cluster bereit und löschen Sie den nicht unterstützten Cluster. Um dieses Problem zu vermeiden, aktualisieren Sie veraltete Cluster auf eine unterstützte Version, bevor Sie das Update auf die neueste Version durchführen. Wenn die Worker-Knoten eine Version ausführen, die zwei oder mehr Versionen hinter der Control Plane zurückliegt, kann es vorkommen, dass Ihre Pods ausfallen und in einen Zustand wie MatchNodeSelector, CrashLoopBackOff, oder übergehen, ContainerCreating bis Sie die Worker-Knoten auf dieselbe Version wie die Control Plane aktualisieren. IBM Cloud-Support bietet zwar keinen Support für nicht unterstützte Versionen an, jedoch stellt IBM Technology Expert Labs Build-Services zur Verfügung, die Ihnen bei der Behebung von Problemen mit nicht unterstützten Versionen helfen können. Wählen Sie im IBM Cloud-Katalog die Option Partner mit IBM Technology Expert Labs aus, um die Nutzung der Dienste zu starten. Nachdem Sie den Cluster von einer veralteten Version auf eine unterstützte Version aktualisiert haben, kann Ihr Cluster den normalen Betrieb wieder aufnehmen und weiterhin Support erhalten. Sie können feststellen, ob Ihr Cluster nicht unterstützt wird, indem Sie das Feld State in der Ausgabe des Befehls ibmcloud ks cluster ls oder in der IBM Cloud Kubernetes Service-Konsole überprüfen.

Aktualisierung vorbereiten

Die Aktualisierung eines Clusters von der Vorgängerversion auf eine neue Version hat häufig Auswirkungen auf bereitgestellte Apps. Eine vollständige Liste der Änderungen finden Sie in den Änderungsprotokollen Kubernetes der Community, den IBM Versionsänderungsprotokollen und den Kubernetes hilfreichen Warnungen.

Aktionen, die Sie vor und nach der Aktualisierung Ihres Clusters ausführen sollten, finden Sie unter den Versionsinformationslinks unter Verfügbare IBM Cloud® Kubernetes Service-Versionen.

Archivieren

Nicht unterstützte Cluster werden nicht mit Sicherheits- und Patchaktualisierungen bereitgestellt. Sie werden vom IBM Cloud-Kundendienst nicht unterstützt. Auch wenn Ihr Cluster und Ihre Apps eine Zeit lang weiterlaufen, können Sie bei einem Problem auf Ihrem Cluster-Master oder Ihren Workerknoten nicht mehr erstellen, neu laden oder andere Korrekturmaßnahmen ergreifen. Sie können die Cluster- oder Workerknoten immer noch löschen oder den Cluster auf die nächste Version aktualisieren. Überprüfen Sie die potenziellen Auswirkungen und aktualisieren Sie den Cluster, um weiterhin wichtige Sicherheitsaktualisierungen und -unterstützung zu erhalten. Wenn Ihr Cluster-Master zwei oder mehr Versionen hinter der ältesten unterstützten Version liegt, müssen Sie einen neuen Cluster einrichten und Ihre Apps im neuen Cluster bereitstellen.