Als SaaS-Anbieter haben wir unser Produkt von Beginn an auf Skalierbarkeit ausgelegt: horizontal skalierbare Microservices in Docker-Containern. Zur Automatisierung der bedarfsgesteuerten Skalierung entschieden wir uns – natürlich – für Kubernetes.

Da der Betrieb von Kubernetes-Clustern bekanntermaßen sehr aufwändig ist, entschieden wir uns dafür, ein Kubernetes Managed Service zu nutzen – dafür verließen wir sogar AWS und zogen zu Google Cloud um, damals der einzige Cloud-Anbieter der Managed Kubernetes anbot. Jetzt, drei Jahre später, haben wir die Entscheidung gefällt, Kubernetes nicht weiter zu nutzen. In drei Teilen will ich die Hintergründe dieser Entscheidung beleuchten.

  • Teil 1 beschäftigt sich mit den Kosten der Kubernetes-Nutzung: monetären Kosten, aber vor allem technischen Schwierigkeiten – von der Umstellung von Docker auf containerd, AppArmor-Kompatibilitätsproblemen, Network-Policy-Problemen und ingress-nginx-admission-webhook-Ärger – welche selbst die Nutzung von Kubernetes als Managed Service ressourcenintensiv und aufwändig machen, und die volle Automatisierung des Clusters als “cattle” extrem komplex machen.
  • Teil 2 beschäftigt sich mit dem Mehrwert, den wir durch Kubernetes erwartet haben und was wir tatsächlich realisieren konnten – ernüchternd wenig – und die Gründe dafür: von architektonischen Eigenheiten unserer Infrastruktur über die On-Premise-Präferenz unserer Kunden im DACH-Raum bis zu Herausforderungen in Kostenkontrolle.
  • Im Teil 3 stelle ich Kosten und Nutzen nebeneinander und zeige, wie eindeutig die Entscheidung gegen Kubernetes war – und warum wir sie nicht schon früher getroffen haben.