Produktübersicht Managed Kubernetes

Produktübersicht

Das teuto.net Managed Kubernetes Produkt basiert auf der eigens entwickelten “t8s-engine” auf Basis der Kubernetes Cluster API.

Verantwortungen

teuto.net

Die t8s-engine/teuto.net ist für folgende Komponenten verantwortlich und garantiert die Funktionalität/Verfügbarkeit:

• Control Plane
  • Wir stellen die Control Plane der Workload Cluster (kube-apiserver, etcd, kube-scheduler, kube-controller-manager) und sind für die Verfügbarkeit dieser Komponenten verantwortlich.
• Worker/Compute Plane
  • Wir betreiben eine Anzahl von OpenStack Servern, die als Worker/Compute Plane fungieren.
  • Wir behalten uns vor diese Server, z.b. bei Updates, auszutauschen. Dabei werden wir PodDisruptionBudgets beachten und nicht die konfigurierte Anzahl an Servern unterschreiten.
• Networking
  • Die Cluster werden mit funktionierendem Networking (CNI) ausgestattet. Wir sind dafür verantwortlich, dass dieses funktioniert.
  • Der Cluster wird mit funktionierendem DNS per CoreDNS ausgestattet. Wir sind dafür verantwortlich, dass dieses verfügbar ist.
• OpenStack / Cloud Integration
  • Loadbalancer
    • Wir installieren den openstack-cloud-controller-manager der auf Wunsch Services mit type: Loadbalancer mit einem Octavia Loadbalancer austattet. Wir sind dafür verantwortlich, dass die Loadbalancer funktionieren und der Service die Requests empfängt.
    • Siehe Abschnitt Ingress für mehr Infos.
  • Volumes
    • Wir installieren das cinder-csi-plugin und erstellen passende StorageClasses. Damit ist es möglich Persistent Volumes anzulegen. Wir sind für die Verfügbarkeit dieser Persistent Volumes und des cinder-csi-plugin verantwortlich.
• Ingress
  • Wenn nicht anders gewünscht, wird in den Cluster ein nginx-ingress und cert-manager installiert, um das Onboarding zu erleichtern. Wir sind dabei für die Verfügbarkeit dieser beiden Komponenten verantwortlich. Wir sind explizit nicht für die Verfügbarkeit des cert-manager Issuers (Let’s Encrypt) verantwortlich.
• Updates
  • Wir sind dafür verantwortlich neue Kubernetes Versionen und gepatchte OS Images bereitzustellen. Wir werden uns an die offizielle Support Period von Kubernetes halten.
• Monitoring
  • Um unsere Verantwortungen umsetzen zu können, werden wir die Workload Cluster überwachen. Dieses Monitoring gilt explizit nur für unsere Verantwortungen.

Kunden

• Worker/Compute Plane
  • Aufgrund der Flüchtigkeit einzelner Nodes ist es wichtig, dass Ihre Anwendungen resilient gegenüber diesem Verhalten sind. Sie sind dafür verantwortlich diese Resilienz sicherzustellen. teuto.net empfiehlt dafür, die Best Practices zu befolgen.

    Wenn Sie überprüfen möchten, ob Ihre Anwendungen den Anforderungen an die Resilienz entspricht, können Sie mit teuto.net einen Test vereinbaren, bei dem wir einzelne oder alle Nodes gemäß unseres Update Prozesses austauschen.

• Updates
  • Patch Releases (z.b. Kubernetes 1.23.3 -> 1.23.4)
    • Für Kubernetes Patch Releases und andere kleinere Updates, wie zum Beispiel neue Kernel Versionen, wird teuto.net Sie über geplante Wartungstermine informieren. Sie haben an der Stelle eine Mitwirkungspflicht, können aber den Zeitpunkt in Abstimmung mit teuto.net verschieben.
  • Feature Releases (z.b. Kubernetes 1.22.x -> 1.23.y)
    • Feature Releases enthalten oft Breaking Changes in der Kubernetes API, zum Beispiel werden bestimmte API Resourcen nicht mehr angeboten. teuto.net wird Ihnen diese Updates anbieten und Sie müssen dem Update explizit zustimmen, bevor es durchgeführt wird.
    • Falls Sie dem Update nicht zustimmen, bevor die von Ihnen verwendete Kubernetes Version nicht mehr von teuto.net unterstützt wird (siehe “Updates” im Abschnitt “Verantwortungen > teuto.net”), enden die oben aufgezählten Verantwortungen von teuto.net und Unterstützung kann nur noch auf einer Best-Effort Basis gewährt werden.
• Monitoring
  • Sie sind für die Überwachung Ihrer eigenen Anwendungen verantwortlich.

Limitierung

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.

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 Monitoring Daten zu erheben. Für diese Zwecke steht nur ein Teil der Resourcen der Nodes zur freien Verfügung.

Best Practices

Um übliche 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 Resourcen direkt erstellt werden. Stattdessen sollten Deployments, StatefulSets oder andere Workload Resourcen verwendet werden.

Resourcen Requests und Limits

Damit der Kubernetes Scheduler abschätzen kann, ob ein Pod auf einen Node passt, vergleicht er die Resourcen Requests und Limits mit den anderen Pods auf dem Node, sowie mit den verfügbaren Resourcen 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, kann es sein, dass teuto.net dieses PodDisruptionBudget bei einem Rollout nicht beachtet.

Sonstiges

Proxy-Cache

Um das Netzwerk-Volumen zu viel 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