Kubernetes-Versionsinformationen

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.22 hat und Sie auf 1.24 aktualisieren möchten, müssen Sie zunächst auf 1.23 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 Workerknoten: Prüfen Sie jeden Monat, ob eine Aktualisierung verfügbar ist, und verwenden Sie den Befehl ibmcloud ks worker update oder den Befehl ibmcloud ks worker reload, um verfügbare Sicherheits- und Betriebssystempatches anzuwenden. Während einer Aktualisierung oder eines erneuten Ladens wird von Ihrer Workerknotenmaschine ein neues Image erstellt und dabei werden Daten gelöscht, die nicht außerhalb des Workerknotens 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 „ IBM “ automatische Updates für ein bestimmtes Master-Fix-Pack deaktivieren, wie im Änderungsprotokoll vermerkt, beispielsweise bei einem Patch, der nur benötigt wird, wenn ein Master von einer Nebenversion auf eine andere aktualisiert wird. In jedem dieser Fälle können Sie den Befehl ibmcloud ks cluster master update Befehl selbst sicher ausführen, ohne darauf zu warten, dass 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 Die Entwickler beginnen mit dem Testen und der Stabilisierung 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 bestmögliche Unterstützung für das Release.

   Allgemeine Verfügbarkeit

   Das Release ist allgemein verfügbar (GA). IBM bietet vollständige Unterstützung für das Release. IBM stellt ein vermutliches Zieldatum für das Release bereit, das nicht unterstützt wird. Release wird zur Standardversion, die während der Clustererstellung verwendet wird, sobald es minimale Einschränkungen und eine angemessene Übernahmerate für das Release gibt.

   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 minimale Unterstützung für das Release in Übereinstimmung mit der Kubernetes. Diese Unterstützungsphase ist im Allgemeinen die letzte Phase, bevor das Release nicht mehr unterstützt wird, und überschreibt die Wartungs-und erweiterten Unterstützungsphasen, falls es Überschneidungen gibt. Es werden möglicherweise keine Sicherheitspatches bereitgestellt. Während der Auslaufphase wird die Version weiterhin unterstützt und Ihr Cluster ist nach wie vor funktionsfähig; möglicherweise ist jedoch ein Update auf eine unterstützte Version erforderlich, um Sicherheitslücken zu beheben. Zum Beispiel durch Hinzufügen oder erneutes Laden von Workerknoten.

4. Nicht unterstützte Version: Die Version wird nicht unterstützt. IBM bietet nur Unterstützung für ein Upgrade auf ein unterstütztes Release. Die Version wird nicht mehr unterstützt. 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 der Cluster-Master zwei oder mehr Versionen hinter der ältesten unterstützten Version ausführt, können Sie keine Aktualisierungen mehr anwenden und müssen den Cluster löschen und eine neue 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: Die Version wird ohne Upgradepfad nicht unterstützt. IBM bietet keine Unterstützung. IBM behält sich das Recht vor, die Steuerebenen für solche Cluster herunterzufahren.

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. Vermeiden Sie dieses Problem, indem Sie veraltete Cluster auf eine unterstützte Version aktualisieren, die weniger als zwei Versionen von der aktuellen Version abweicht (z. B. 1.21 oder 1.22) und nehmen Sie anschließend eine Aktualisierung auf die neueste Version 1.23 vor. Wenn auf den Workerknoten eine Version ausgeführt wird, die im Vergleich zur Masterversion zwei oder mehr Versionen zurückliegt, schlagen Ihre Pods möglicherweise mit einem Status wie beispielsweise MatchNodeSelector, CrashLoopBackOff oder ContainerCreating fehl, bis Sie die Workerknoten auf die Version des Masters aktualisieren. Nicht unterstützte Versionen werden zwar nicht vom IBM Cloud Support unterstützt, aber IBM Technology Expert Labs verfügt über Build-Services, die Ihnen bei der Lösung von Problemen mit nicht unterstützten Versionen helfen können. Wählen Sie im Katalog IBM Cloud die Option "Partner mit IBM Technology Expert Labs", um deren Dienste in Anspruch zu nehmen. 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 Konsole unter IBM Cloud Kubernetes Service ü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.