Infrastructure as Code: Kubernetes in der GitOps-Welt verwenden

Inhaltsverzeichnis

Seit vier Jahren setzt die HanseMerkur Versicherung bereits auf Kubernetes für das Deployment von Containerinfrastruktur, von internen Systemen bis zu den öffentlichen Webseiten. Da Kubernetes zur Zeit des ersten Deployments noch sehr jung war, reicherten sich über die Zeit einige Altlasten an, die es zu beseitigen galt. Um nicht die Fehler der ersten Version der Plattform zu wiederholen, sollte strikt das GitOps-Pattern für Infrastruktur, Prozesse und Deployment gelten.

Der Kern der existierenden Infrastruktur bestand aus Foreman-Instanzen. Sie wurden über Jenkins-Pipelines angesprochen, um CoreOS-Instanzen zu starten. Die wiederum setzten bei ihrer Installation durch die mitgelieferte Konfigurationsdatei cloud-init einen Kubernetes-Cluster auf.

2016 war daran nichts auszusetzen. Die Schwächen zeigten sich erst später. Jeder, der schon mal versucht hat, einen Kubernetes-Cluster ohne passende Deployment-Werkzeuge wie kubespray oder kubeadm aufzusetzen, kann bezeugen, dass das nicht leicht ist. Am schwersten wog die fehlende Upgrade-Möglichkeit. Sie war tatsächlich nie vorgesehen. Spätere Versuche, sie nachzureichen, stellten sich als sehr heikel heraus.

Das war die Leseprobe unseres heise-Plus-Artikels "Infrastructure as Code: Kubernetes in der GitOps-Welt verwenden". Mit einem heise-Plus-Abo können sie den ganzen Artikel lesen und anhören.