Handreichungen Managed Kubernetes
API-Dokumentation
Dem Kunden wird Zugriff auf die standard Kubernetes-API gegeben. Die Dokumentation dafür kann in der offiziellen Kubernetesdokumentation unter der entsprechend installierten Version nachgelesen werden. Außerdem stehen dem Nutzer die APIs des CloudControllerManagers, des CSIs und CNIs (cillium) zur Verfügung.
Best Practices
Um verbreitete Probleme zu verhindern, die die Verfügbarkeit Ihrer Anwendung beeinträ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 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 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)
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 unter anderem für Container-Images der folgenden (öffentlichen) Image-Repositories eingerichtet:
docker.iogcr.ioghcr.iok8s.gcr.ionvcr.ioquay.ioregistry.gitlab.comregistry.k8s.ioregistry.opensource.zalan.doregistry.teuto.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.
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 Ressourcen der Nodes zur freien Verfügung.
Bekannte Fehlermeldungen
Quota überschritten
Disk-Quota
Ein überschrittenes Disk-Quota äußert sich in der Regel dadurch, dass ein PersistentVolumeClaim im Status Pending hängen bleibt und gleichzeitig bei einem describe auf das PersistentVolumeClaim den Hinweis auf einen ExceedsAvailableQuota enthält.
$ kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
disk-quota-example Pending teutostack-hdd 25s
$ kubectl describe pvc disk-quota-example
Name: disk-quota-example
Namespace: default
StorageClass: teutostack-hdd
Status: Pending
...
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning ProvisioningFailed 70s (x6 over 102s) cinder.csi.openstack.org_openstack-cinder-csi-controllerplugin-dbc57c7b9-mtczf_ca72589f-2cce-4f2d-b7b2-fc556d0b740e failed to provision volume with StorageClass "teutostack-hdd": rpc error: code = Internal desc = CreateVolume failed with error Expected HTTP response code [202] when accessing [POST https://api.ffm3.teutostack.de:8776/v3/613bec9239ad4973accbfb252cb53725/volumes], but got 413 instead
{"overLimit": {"code": 413, "message": "VolumeSizeExceedsAvailableQuota: Requested volume or snapshot exceeds allowed gigabytes_Ceph-HDD quota. Requested 500G, quota is 1000G and 1000G has been consumed.", "retryAfter": "0"}}
Sollten Sie an ein Quota Limit stoßen, wenden Sie sich bitte an uns, wir helfen Ihnen gerne.