Handreichungen Managed Kubernetes

Best Practices

Um verbreitete Probleme zu verhindern, die die Verfügbarkeit Ihrer Anwendung beinträchtigen, haben wir hier eine Liste an “Best Practices” erstellt, die Sie für Ihre Anwendungen umsetzen sollten.

Replicas anstatt einfacher Pods benutzen

Um sicherzustellen, dass Pods an anderer Stelle neugestartet werden, sollten keine Pod Ressourcen direkt erstellt werden. Stattdessen sollten Deployments, StatefulSets oder andere Workload Ressourcen verwendet werden.

Aufgrund der Flüchtigkeit einzelner Nodes ist es wichtig, dass Ihre Anwendungen resilient gegenüber diesem Verhalten sind. teuto.net empfiehlt dafür, die Best Practices zu befolgen.

Bitte prüfen Sie dies besonders vor den Updates, um einen reibungslosen Ablauf zu ermöglichen.

Ressourcen Requests und Limits

Damit der Kubernetes Scheduler abschätzen kann, ob ein Pod auf einen Node passt, vergleicht er die Ressourcen Requests und Limits mit den anderen Pods auf dem Node, sowie mit den verfügbaren Ressourcen des Nodes.

Um sicherzustellen, dass alle Anwendungen wie erwartet laufen, sollten die Requests und Limits für jede Workload Resource konfiguriert sein. Mehr Details gibt es in der Kubernetes Dokumentation “Managing Resources for Containers”.

PodDisruptionBudget

Mit Hilfe von PodDisruptionBudgets kann für eine Anwendung konfiguriert werden, wie viele Replicas zu jedem Zeitpunkt mindestens verfügbar sein müssen. Damit wird sichergestellt, dass z.B. während eines Kubernetes Upgrades, wenn alle Nodes einmal ausgetauscht werden, dauerhaft genügend Instanzen der Anwendung laufen.

Falls es nicht möglich ist, ein PodDisruptionBudget sinnvoll zu erfüllen, zum Beispiel wenn im PodDisruptionBudget maxUnavailable: 0 angegeben ist, wird die betreffende Anwendung nach einem Timeout trotzdem gestoppt. Dies kann zu Ausfällen führen.

Provider-Details

Cloud Integration

teuto.net verwendet OpenStack als Cloud-Basis für Managed Kubernetes Cluster. Dies erlaubt die Integration und einfache Nutzung einiger Funktionen, welche Ihnen in Ihrem Kubernetes-Cluster zur Verfügung stehen.

Netzwerk

Die Cluster werden von uns mit funktionierendem Networking (CNI) und DNS per CoreDNS ausgestattet. So können Ihre Anwendungen mühelos nach außen, sowie innerhalb des Clusters kommunizieren..

Loadbalancer

Wir installieren den openstack-cloud-controller-manager der auf Wunsch Services mit type: Loadbalancer mit einem Octavia Loadbalancer ausstattet. Diese LoadBalancer bekommen automatisch jeweils eine dedizierte, extern erreichbare Floating-IP zugewiesen.

Volumes

Wir installieren das cinder-csi-plugin und erstellen folgende passende StorageClasses:

• teutostack-ssd (default)
• teutostack-hdd

Damit ist es möglich, PersistentVolumes über die Verwendung von PersistentVolumeClaims anzulegen und zu nutzen.

Nähere Informationen zur Verwendung von PersistentVolumeClaims entnehmen sie bitte der offiziellen Dokumentation.

Proxy-Cache

Um den Netzwerk-Traffic zu oft verwendeten Container-Registries zu reduzieren, setzt teuto.net einen Proxy-Cache ein. Dies hilft auch, um ein Rate-Limiting durch die einzelnen Registries zu vermeiden. Dieser Proxy-Cache wird automatisch konfiguriert und funktioniert völlig transparent. Es brauchen keine Image-URLs angepasst werden.

Es wird ein Proxy-Cache für Container-Images der folgenden (öffentlichen) Image-Repositories eingerichtet:

• docker.io
• gcr.io
• ghcr.io
• hub.docker.com
• index.docker.io
• k8s.gcr.io
• quay.io
• registry.gitlab.com
• registry.opensource.zalan.do
• registry.teuto.io
• registry.k8s.io

Flüchtigkeit einzelner Nodes

Einzelne Nodes (Control- und Computeplane) können jederzeit durch uns ausgetauscht werden. Dies passiert zum Beispiel, um Updates des Betriebssystems oder der verwendeten Kubernetes Software einzuspielen, oder damit wir Wartungsarbeiten an der unterliegenden Cloud-Infrastruktur (Hypervisor) durchführen können.

Wir verwenden dabei den normalen Node drain Prozess, welcher darauf achtet, dass die Pods wie konfiguriert gestoppt werden, und alle PodDisruptionBudgets weiterhin beachtet werden. Dieser Prozess ist mit einem Timeout versehen, welcher verhindern soll, dass ein Rotieren der Nodes auf Grund von fehlerhaften PodDisruptionBudgets in eine unendliche Warteschleife gerät.

MachineHealthChecks

Um die Verfügbarkeit des Clusters und Ihrer Anwendungen sicher zu stellen, verwendet teuto.net sogenannte MachineHealthChecks. Diese überprüfen kontinuierlich die Verfügbarkeit und Funktion der Nodes eines Clusters. Sollte ein Node ausfallen und sich nicht binnen eines gewissen Zeitrahmens wieder selbst erholen, wird das Management-System den fehlerhaften Node automatisch durch einen neuen ersetzen.

Update-Verfahren

teuto.net installiert regelmäßig Updates auf den Managed Kubernetes-Clustern. Für das Update auf den neuste Minor-Release warten wir mindestens den zweiten Patch-Release der neuesten Minor-Release ab.

Während der Updates werden die Nodes der Reihe nach ausgetauscht. Dazu wird immer erst ein neuer Node zum Cluster hinzugefügt, bevor einer der bestehenden Nodes ausgetauscht wird. Auf diese Weise stehen Ihnen stets die vollen Ressourcen zur Verfügung. teuto.net verwendet dabei den normalen Node drain Prozess.

Um die Updates reibungslos durchführen zu können, sollten unsere Best Practices, insbesondere die Konfiguration von PodDisruptionBudgets, eingehalten werden. Andernfalls kann es zu Ausfällen bzw. zu einem Non-Graceful Shutdown der betreffenden Anwendung kommen.

Die Kommunikation zu den Updates findet über tickets.teuto.net unter dem Label kubernetes-updatestatt. Dieses muss vom Kunden abonniert werden, damit die entsprechenden Informationen zugestellt werden können. Dazu gehen Sie in Ihrem Projekt bitte auf das Feld Project informationund wählen in dem Menü Labelsaus. Es öffnet sich eine Seite, in der alle Labels aus dem Projekt aufgelistet sind. Dort suchen Sie nun das Label kubernetes-update. Rechts davon befindet sich der Button Subscribe. Wenn Sie diesen anklicken, sind Sie auf dem Projekt Level auf das Label subscribed. Sollte sich ein Menü öffnen, in welchem Sie wählen können ob Sie das Issue auf Group oder Project Level subscriben wollen, wählen Sie project level.

Limitierung

Reservierte Resourcen

Für den stabilen Betrieb des Kubernetes Clusters ist es nötig, dass teuto.net auf jedem Node weitere Software laufen lässt, zum Beispiel um Storage-Volumes anbinden zu können (siehe Volumes). Für diese Zwecke steht nur ein Teil der Resourcen der Nodes zur freien Verfügung.