Best Practices für Upgrades

Best Practice: Die neueste Version von Kubernetes verwenden

Neue Kubernetes-Releases umfassen in der Regel viele Updates, zusätzliche Features und vor allem Patches zur Behebung von Sicherheitsproblemen in früheren Versionen. Kubernetes Engine unterstützt drei kleinere Kubernetes-Versionen mit der neuesten Patchversion für jede dieser Versionen.

Wir empfehlen Ihnen daher Folgendes:

• Produktionscluster führen immer die neueste stabile Version von Kubernetes aus.
• Sie geben die letzte untergeordnete unterstützte Version von Kubernetes an, wenn Sie Cluster mit der Kubernetes-Engine erstellen.
• Sie aktualisieren vorhandene Cluster, wenn Oracle die Kubernetes Engine-Unterstützung für eine Kubernetes-Hauptversion, eine Nebenversion oder eine Patchversion ankündigt. Durch das regelmäßige Upgrade von Clustern können Sie Situationen vermeiden, in denen Cluster ältere Kubernetes-Versionen ausführen, die nicht die neuesten Features und Fixes enthalten.

Siehe Kubernetes-Versionen und Kubernetes Engine (OKE), Cluster auf neuere Kubernetes-Versionen upgraden.

Best Practice: Test- und Produktionsumgebungen einrichten

Es wird empfohlen, mehrere Kubernetes Engine-Umgebungen als Teil eines Workflows zum Bereitstellen und Freigeben von Anwendungen zu verwenden. Durch die Verwendung mehrerer Umgebungen können Sie Risiken und unerwünschte Ausfallzeiten minimieren, indem Sie Software- und Infrastrukturupdates in einer von der Produktionsumgebung getrennten Umgebung testen. Es wird mindestens empfohlen, eine Produktionsumgebung und eine Vorproduktions- oder Testumgebung zu verwenden.

Außerdem wird empfohlen, dass Sie vor dem Upgrade eines Clusters auf eine neue Version von Kubernetes alle auf dem Cluster bereitgestellten Anwendungen testen, um zu bestätigen, dass die Anwendungen mit der neuen Kubernetes-Version kompatibel sind. Nach dem Upgrade der Control-Plane-Knoten auf eine neuere Version von Kubernetes können Sie kein Downgrade der Control-Plane-Knoten auf eine frühere Kubernetes-Version ausführen. Daher ist es wichtig, Anwendungen zu testen, bevor das Cluster auf eine neue Kubernetes-Version upgegradet wird. Beispiel: Vor dem Upgrade eines Clusters können Sie ein separates Cluster erstellen, in dem die neue Kubernetes-Version ausgeführt und Anwendungen in diesem Cluster getestet werden.

Siehe Upgrade von Clustern auf neuere Kubernetes-Versionen.

Best Practice: Blue-Green-Deployment-Strategie verwenden

Wir empfehlen, beim Upgrade von Kubernetes-Clustern eine blaugrüne Bereitstellungsstrategie zu verwenden, um Risiken zu reduzieren und Ausfallzeiten zu minimieren. Blue-Green-Deployments verwenden zwei Produktionsumgebungen, die als "blau" und "grün" bezeichnet werden, um zuverlässige Tests, kontinuierliche Upgrades ohne Ausfall und sofortige Rollbacks bereitzustellen. Durch die Verwendung einer Blue/Green-Deployment-Strategie wird sichergestellt, dass Benutzer Zugriff auf eine Produktionsumgebung haben, während die andere Produktionsumgebung aktualisiert wird.

Best Practice: Wartungsfenster planen

Es wird empfohlen, Wartungsaktivitäten außerhalb der Spitzenzeiten zu planen, um die Auswirkungen auf Anwendungen zu begrenzen, die Podunterbrechungen aufgrund von Cluster-/Knotenupgrades und -wartungen nicht ordnungsgemäß verarbeiten.

Beispiel: Bei Upgrades kann es zu vorübergehenden Unterbrechungen kommen, wenn Workloads verschoben werden, um Knoten neu zu erstellen. Um sicherzustellen, dass solche Störungen minimale Auswirkungen haben, wenn möglich:

• Upgrades außerhalb der Spitzenzeiten planen
• Anwendungsbereitstellungen entwerfen, um Teilunterbrechungen nahtlos zu bewältigen

Best Practice: Worker-Knoten als unveränderlich behandeln

Es wird empfohlen, vorhandene Worker-Knoten als unveränderliche Entitys zu behandeln.

Änderungen, die Sie an den Worker-Knoteneigenschaften eines Knotenpools vornehmen, gelten nur für neue Worker-Knoten, die anschließend erstellt werden. Sie können die Eigenschaften vorhandener Worker-Knoten nicht ändern.

Beispiel: Anstatt das BS-Image zu aktualisieren, das auf vorhandenen Worker-Knoten ausgeführt wird, sollten Sie einen neuen Knotenpool mit Worker-Knoten erstellen, die das aktualisierte BS-Image aufweisen. Nachdem Sie Cordon- und Drain-Optionen für den ursprünglichen Knotenpool angegeben haben, um das Starten neuer Pods zu verhindern und vorhandene Pods zu löschen, können Sie die Arbeit vom ursprünglichen Knotenpool in den neuen Knotenpool verschieben. Anschließend können Sie den ursprünglichen Knotenpool löschen.

Siehe Worker-Knoten mit aktualisierten Attributen erstellen.

Best Practice: Cordon und Drain Worker-Knoten in Vorbereitung auf die Wartung

Es wird empfohlen, einen Worker-Knoten vor der geplanten Wartung auf diesem Knoten zu binden und zu entleeren.

Beim Cordoning wird ein Worker-Knoten als nicht planbar markiert. Dadurch wird verhindert, dass der Kube-Scheduler neue Pods auf diesen Knoten platziert. Beim Draining werden Pods sicher von einem Worker-Knoten entfernt. Dadurch wird sichergestellt, dass Container ordnungsgemäß beendet werden und alle erforderlichen Bereinigungen ausgeführt werden.

Weitere Informationen finden Sie unter Verwaltete Knoten vor dem Herunterfahren oder Beenden cordoning und draining. Siehe auch Manuelle Knotenadministration und Knoten sicher entleeren in der Kubernetes-Dokumentation.