Platform Engineer Sebastian Nickel spricht im Interview mit CEO und Gründer Thomas Hug über die Arbeit im Team, Kubernetes, Container, Google Cloud, Standort Schweiz und Cloud Migration.
Seit über 5 Jahren Mitarbeiter bei nine mit Fokus auf Automatisierung bei Container-Platform
Sebastian Nickel ist schon seit über fünf Jahren bei nine und hat die nine Managed GKE Plattform massgeblich mitentwickelt. Dieses Produkt ist das Hauptprodukt vom Team Platform, bei welchem Sebastian Nickel zusammen mit vier weiteren Platform Engineers hilfreiche Tools und Admin Dienste auf der Google Kubernetes Engine verfügbar macht. Sie achten auf einen hohen Automatisierungsgrad und haben das Ziel, das Kubernetes Erlebnis für unsere Kunden zu verbessern. Sie haben eine CI/CD Pipeline gebaut, welche aus Gitlab, Terraform und Helm besteht. Diese sorgt für das vollautomatische Deployment von neuen Kunden Clustern. Durch Merge Requests - welche mit dem Vier-Augen-Prinzip überprüft werden - stellen sie einerseits sicher, dass keine ungeprüften Requests nach Production gehen, aber auch, dass sich das Knowledge im Team verbreitet. Das Software Development als Basis für die Automatisierung der Plattform, macht das Team hauptsächlich mit GoLang.
Warum Google Kubernetes Engine (GKE) nicht direkt bei Google beziehen?
Direktlink zur Antwort im Video: https://youtu.be/t0tcp4_vQEY?t=125
Google managed die Kubernetes Plattform (GKE) unterhalb dem Service Layer von nine, was die Engineers von nine zu schätzen wissen, da es doch ziemlich viel Arbeit bedeutet, einen Kubernetes Cluster zu unterhalten. Das Team Platform sieht seinen Dienst darin, dass Software on top installiert wird wie z.B. Monitoring und Logging mit Datenhaltung in der Schweiz oder eine eigene Variante von einem verteilten Filesystem mittels Network File System (NFS). Google bietet diese Dienste auch an, sie sind aber entweder teurer und/oder nicht ausschliesslich in der Schweiz. Bei der installierten Software wird darauf geachtet, dass diese nach bewährten Vorgehensweisen installiert ist. Das bedeutet auch, dass z.B. für Tools wie dem Argo CD ein zusätzlicher Namespace Controller geschrieben wurde um für Kunden die Möglichkeit zu schaffen, den Zugriff von Argo CD auf einzelne Namespaces einzuschränken. Ein weiterer Vorteil einer Zusammenarbeit mit nine ist, einen Ansprechpartner für die komplizierten Pfade von Kubernetes zu haben. Typische Fragen sind z.B. wie ein Deployment auf Kubernetes erstellt wird, wie Einstellungen gewählt werden sollen und wo z.B. Secrets abgespeichert werden.
Woher kommen die Ideen, was als nächstes bei nine Managed GKE integriert wird?
Direktlink zur Antwort im Video: https://youtu.be/t0tcp4_vQEY?t=276
Diese kommen gemäss Sebastian Nickel von mehreren Seiten. Als erstes natürlich von den Kunden selber. Die Engineers stehen im engen Kontakt mit unseren Kunden, da sie Support anbieten. Je nach Fragestellung sind auch schon Verbesserungen entstanden, welche die Handhabung kundenfreundlicher gestaltet haben, indem z.B. Komplexität für den Kunden reduziert wurde. Da nine für die eigene Infrastruktur auch nine Managed GKE verwendet, kommen natürlich auch interne Fragen und Verbesserungsvorschläge. Weiter ist die Lokalisierung ein grosser Faktor. Damit alle Daten in der Schweiz bleiben, müssen oft spezielle Lösungen geschaffen werden, welche dies ermöglichen.
Was sind die Vorteile der Variante von Kubernetes, welche mit der Google Kubernetes Engine (GKE) angeboten werden?
Direktlink zur Antwort im Video: https://youtu.be/t0tcp4_vQEY?t=358
Das Team Platform war massgeblich an der Evaluation einer Nachfolgelösung für unsere OpenShift Infrastruktur beteiligt. Bei dieser Evaluation wurden diverse Cloud-Anbieter evaluiert und es ist von Anfang an aufgefallen, dass die Google Variante dem Team am besten gefällt, da diese ziemlich unverändert daherkommt, d.h. vanilla. Dazu gibt es sehr viel Dokumentation und Problemstellungen im Netz. Google setzt eine Software namens Borg, auf welcher Kubernetes basiert, zudem schon seit längerem in ihrer eigenen Infrastruktur ein. Dadurch haben sie entsprechende Erfahrungen und das schafft Vertrauen. Während der Evaluation wurde auch der Support getestet. Bei Google fiel auf, dass man schnell zu Engineers durchkommt und dadurch kompetente Antworten erhält, was natürlich sehr hilfreich ist. Ein zusätzliches Entscheidungskriterium waren weitere Cloud-Dienste, welche zusätzlich angeboten werden. Zudem war ein gewichtiger Aspekt der Entscheidung, dass Google der erste grosse Anbieter war, der ein Rechencenter in der Schweiz eröffnet hatte.
Welches sind die Hauptvorteile, wenn eine Applikation in Containern läuft?
Direktlink zur Antwort im Video: https://youtu.be/t0tcp4_vQEY?t=464
In einem Container ist das Betriebssystem (OS) und die Applikation abgekapselt vom Rest. Das bedeutet, alle Abhängigkeiten wie eine starke Integration von OS und Software Libraries kommen nicht mehr vor, was das Deployment vereinfacht und somit natürlich die Erstellung von mehreren Umgebungen wie z.B. Testing, Staging und Production ermöglicht. Weiterhin ist die Skalierung einfacher wenn Kubernetes bei höherer Last zusätzliche Container starten muss. Diese Skalierung funktioniert aber natürlich nur, wenn die Applikation dies auch unterstützt. Oft haben Applikationen Abhängigkeiten auf Komponenten, welche die Skalierung in grossem Masse noch nicht so vereinfacht oder sogar verhindert.
Wo soll man anfangen wenn eine Baremetal Installation auf Container migriert werden muss?
Direktlink zur Antwort im Video: https://youtu.be/t0tcp4_vQEY?t=540
Das Wichtigste aus der Sicht von Platform Engineer Sebastian Nickel ist, dass man seine Applikation kennt. Dazu gehören Antworten auf die Fragen wie z.B. wie wird die Applikation konfiguriert? Was hat sie für Abhängigkeiten? Muss noch irgendwo auf shared Storage geschrieben werden? Letzteres ist in der Kubernetes Welt immer noch öfters eine Herausforderung bezüglich der Skalierung. Weiter muss gesagt werden, dass nicht unbedingt jede Applikation zwingend containerisierbar ist. Wenn eine Applikation überhaupt nicht mit dem Hintergrund der Containerisierung gebaut wurde, sollte versucht werden, diesen Teil out zu sourcen und nicht im Kubernetes Cluster laufen zu lassen. Wenn man weiss, wie seine Applikation zusammenhängt und aus welchen Teilen sie besteht, wäre der erste Schritt meistens, Dockerfiles zu bauen. Darin werden Instruktionen festgehalten wie es zum ersten Image kommt. Der Schritt von einem normalen Container auf Kubernetes ist aber immer nochmal ein grösserer, weil Kubernetes noch wesentlich mehr Konzepte zusammenhält. Nine berät gerne, was die bewährten Vorgehensweisen sind und wie die Einstellungen konfiguriert werden können.
Keinen Blogpost mehr verpassen?
