Bei unserem Meetup mit Erfahrungsberichten zu Kubernetes im Projekteinsatz blieben einige Fragen unbeantwortet. Wir haben sie hier zusammengetragen und von unseren Expert:innen beantworten lassen.
Wie geht ihr in Projekten üblicherweise mit Staging-Umgebungen um? Viele eigenständige Cluster vs. Shared für dev/test/preprod? (Reproduzierbarkeit, Monitoring)
In meiner idealen Welt möchte ich viel testen und auch bei den Lasttests volles Rohr geben. In der realen Welt ist das dann leider auch eine Kostenfrage und da muss man hin und wieder mal aufs Geld schauen. Meiner Erfahrung nach bewegen sich die meisten KMU zwischen 2-4 Clustern. In der Enterprise-Welt können viele Cluster schnell zum Problem werden (wegen Maintenance).
Wie nutzt ihr einen Development Workflow (Dev Environment) – Best Practices?
Das kommt immer auf den Kontext an. Ich persönlich nutze kind und minikube zum testen. Das reicht, wenn man nur gegen einen API-Server entwickeln will. Sobald man viele andere microservices anbinden will wird’s damit schwierig.
Habt ihr Best Practices, bzw. Dinge, die man unbedingt bei dem Betrieb von K8s in der Cloud beachten sollte?
- e2e Tests für die Plattform schreiben: Ingress, TLS, Monitoring, Autoscaling, IAM für die Cloud, NetworkPolicies etc. Darin enthalten sollten auch Maintenance-Prozesse sein: node cordon und drain, Backups einspielen etc.
- Sich Zeit nehmen für das Cluster Design: Workloads und Blast-Radius analysieren und das Cluster richtig segmentieren um Noisy Neighbours zu vermeiden
- Security by Default: CIS Benchmark regelmäßig machen und mit policies die Workloads kontrollieren (z.B. mit OPA oder PSP)
- Disaster Recovery Plan machen: Backups, Re-Provisionierung des Clusters, Migration der Workloads auf neue Cluster für den Ernstfall testen!
Welche k8s-Distribution ist für On-Premise empfehlenswert? Welche Lösungen bieten sich dann für Persistent Storage an?
Christian: Installer bzw. Deployment Tools gibt es viele. Unabhängig davon wieviel Arbeit hier bereits vermeintlich erledigt wird, sollte man unbedingt die Komponenten eines Kubernetes Clusters und ihr Zusammenspiel verstehen. Auch die Add-Ons, wie automatisches DNS Management, Cloud Controller, Monitoring oder auch Storage per CSI gehören zur Installation mehr oder weniger dazu. Einige Tools unterstützen auch hierbei etwas – dennoch muss man unbedingt jede Komponente bewusst dem Cluster hinzufügen und die Schnittstellen verstehen.
On-Premise, also mit bereits vorhandenen virtuellen Maschinen oder auch physischen Servern, sollte man auf eine unterstützte und einem vor allem vertraute Linux-Distribution setzen. Ob nun eher Debian-basierte oder RedHat, Ubuntu oder CentOS ist der persönlichen Vorliebe überlassen.
Wie setzt ihr Cluster meistens auf? RKE, kubeadm, kubespray? Immer anders?
It depends 😉 RKE hab ich (Maximilian) noch nicht gesehen. Für On-Premises hatten wir schon eine custom Installation gebaut, als es kubeadm noch nicht gab, mittlerweile setzen wir meistens auf kubeadm auf. In der Cloud bieten sich die managed Lösungen an, insbesondere wenn man kein dedizierte Ops Team hat. Man sollte eben immer die Lösung wählen mit der man umgehen kann und die die eigenen Anforderungen erfüllt.
Das kommt immer auf den Kontext an: Welche Technologien sind in $Company oder $Team bekannt? Was soll den überhaupt gebaut werden? Und wie soll der Cluster in die restliche Landschaft eingebettet werden? Wer und wie sollen der Cluster und die darauf laufenden Anwendungen betrieben werden? Damit reduziert sich schnell die Anzahl an Tools.
Mit welchem Cloud Provider habt ihr die besten Kubernetes-Erfahrungen gemacht?
An Managed.Lösungen hatte ich schon AKS und GKE zwischen den Fingern, die geben sich meiner Meinung nach nicht viel. Viel wichtiger ist meiner Meinung nach, welche anderen Lösungen man vom Cloud Provider will und welcher dann besser dasteht.
Habt ihr Erfahrungen mit Azure AKS oder Redhat OpenShift? Welche Vor-/Nachteile seht ihr da?
AKS haben wir in meinem aktuellen Projekt im Einsatz. Der Hauptvorteil ist, dass man sich um die darunter liegende Infrastruktur nicht groß kümmern muss, so ein Cluster kann man recht schnell hochfahren, auch ohne Vorwissen. Man verliert dadurch aber natürlich auch etwas Kontrolle, könnte z.B. nicht eine andere Container Runtime wählen oder bei Problemen mit der Control Plane selbst Hand anlegen.
Könnt ihr mal Beispiele geben, was ihr genau customizen musstet und wieso?
- Kontext AWS Enterprise: Unterstützung von Cross-Account IAM-Rollen für Cert-Manager, external-dns, kubernetes-external-secrets
- Caching von Forward-Authentication Requests im nginx-ingress Controller
- Wir nutzen kubebuilder für eigene Controller und müssen da immer mal wieder in der controller-runtime ran
Wie betreibt ihr Kubernetes in euren Projekten? Managed in einer Public Cloud oder self-hosted?
Max: Über unsere Projekte hinweg haben wir alle Lösungen schon einmal gehabt. Ich persönlich war schon on-premises, bei GKE und neuerdings auch bei AKS unterwegs.
Moritz: Ich bin fast ausschließlich auf AWS unterwegs. Zur Zeit nutzen wird dort kops und re-evaluieren EKS immer mal wieder. Wirklich managed gibts Kubernetes nur bei GCP. Bei EKS bekommt man nur die Control Plane und EKS-Fargate hatte für unsere bisherigen use-cases zu viele Einschränkungen.
Welchen News, Blogs und anderen Quellen folgt ihr, um am Ball zu bleiben?
Wir haben bei uns intern ein gutes Netzwerk, da bekommt man die Breaking News immer direkt mit; ansonsten reddit.
Habt ihr Erfahrung mit Hybrid Cloud – also Ausfallsicherheit von Kubernetes bei Bereitstellung On-Prem und bei Ausfall Failover in die Cloud?
Keine direkte Betriebserfahrung. Die Frage kommt immer mal wieder und ich habe Konzepte erstellt und durchdacht. Aber aufgrund der sehr hohen Komplexität durch die Vielzahl an Integrationsmöglichkeiten ist das ganze schwer zu managen. Ob die Ausfallsicherheit dann tatsächlich steigt sollte man wirklich prüfen
Gibt es eine einheitliche API bzw. einheitliches Tooling für Build Pipelines?
Kubernetes bringt an sich keine API oder Tooling für Build Pipelines. Es gibt allerdings Projekte, die auf Kubernetes basieren und sich diesem Thema widmen, z.B. argo, tekton und prow. Unser Kollege Simon Kienzler hat ein paar davon hier im inovex Blog betrachtet.
Welche Regeln sollte Ops Dev vorgeben, bevor man sie auf ein self managed Cluster los lässt? Zum Beispiel wie wird man am Ende die Geister wieder los die man rief wenn sie nicht mehr gebraucht werden?
Es sollten Leitplanken eingebaut werden: Labels und Annotations durchsetzen, PodSecurityPolicies, Resource Limits, keine :latest tags usw.
Wie habt ihr in Clustern die API-Versionswechsel von 1.18 nach 1.19 gemanaged?
Christian: Breaking changes in K8s gibt es immer wieder, siehe die Frage dazu weiter unten. Auch bei Version 1.16 gab es einige Deprecations – siehe hier.
Mit Tools wie z.B. Popeye oder Kubepug lässt sich bereits vorab identifizieren, wo man Hand anlegen muss bzw. sollte.
Ist die Übergabe einer K8s-Komponente an die CNCF ein Garant für Long Term Support?
CNCF-Projekte gibt es in verschiedenen Maturity Levels, für die unterschiedliche Anforderungen bestehen. Die Sandbox-Projekte sind noch in einer frühen Phase, hier ist erst einmal kein Support zu erwarten (auch wenn einzelne Projekte diesen bestimmt geben können). Bei Incubating-Projekten muss eine aktivere Community an Commitern und End Usern vorliegen, Graduating Projekte werden noch einmal enger unter die Lupe genommen. Trotzdem ist Long Term Support keine direkte Voraussetzung, garantiert wird also nichts.
Habt ihr Erfahrungen mit Kubernetes als HPC-Plattform?
Leider (noch) nicht, die Engineers beim CERN haben aber eine Case-Study, ein Paper und einen Vortrag auf einer KubeCon gemacht, wenn ich mich richtig erinnere.
Stabilität der API Wie lange bleibt die API stabil?Einiges klingt sehr nach Wildwuchs, wie läuft die Organistion von Kubernetes? Wer entscheidet was?
Größere Änderungen werden seit Kubernetes 1.14 über Kubernetes Enhancement Proposals (KEPs) initiiert. Organisatorisch teilt sich die Kubernetes Community in sogenannte Special Interest Groups (SIGs). Von den SIG Chairs werden dann die KEPs approved, bevor sie implementiert werden dürfen.
Christian: Die Kubernetes API, ihre Versionierung bzw. die Vorgaben für deren Änderungen sind sehr gut dokumentiert:
- https://kubernetes.io/docs/concepts/overview/kubernetes-api/#api-groups-and-versioning
- https://kubernetes.io/docs/reference/using-api/deprecation-policy/
- https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api_changes.md#readme
Weiterlesen
Weitere Infos zu Kubernetes, unsere Offerings und ausführliche Projektberichte in Form von Case Studies findet ihr auf unserer Themenseite!
