SaaS-Modernisierung mit Amazon EKS, Teil 3 GitOps-Prozess mit Flux-Werkzeugen aufsetzen

GitOps steht sinnbildlich für einen hohen Automatisierungsgrad, wie er im Software-as-a-Service-, kurz SaaS-Kontext angestrebt wird. Dieser Beitrag zeigt, wie Flux dabei hilft, einen GitOps-Prozess für Änderungen im laufenden Betrieb aufzusetzen.

Dies ist der dritte Teil einer Blog-Post-Reihe zum Thema Software-as-a-Service (SaaS) in Amazon Elastic Kubernetes Service (EKS). In den vorigen Teilen haben wir …

• das Kubernetes Cluster provisioniert,

• ein erstes Container Repository in AWS Elastic Container Registry (ECR) angelegt,

• die SaaS Identität eingeführt, und

• mit Amazon Cognito einen Identity Provider mit OIDC und JWT Unterstützung eingerichtet.

In der Einführung dieser Reihe haben wir festgestellt, dass ein hoher Automatisierungsgrad und eine Standardisierung der Anwendung über alle Mandanten hinweg für einen effizienten SaaS-Betrieb notwendig ist. GitOps ist in den letzten Jahren im Umfeld von Cloud Native zu einem beliebten Prozess zur Automatisierung von Deployments in Container-Plattformen geworden.

Der Vorteil von GitOps ist dabei, die Stabilität und Verlässlichkeit im Betrieb zu maximieren. Änderungen werden ausschließlich über die Versionskontrolle durchgeführt. Dadurch erhalten wir nicht nur einen Audit-Trail aller Änderungen, wir erhalten auch eine sehr einfache Roll-Back-Funktionalität zur Minimierung der Mean-Time-to-Recovery (MTTR). Wir werden in diesem Beispiel GitOps nur für Änderungen der Anwendung innerhalb eines produktiven Kubernetes-Clusters verwenden.

Weaveworks hat den Begriff GitOps 2017 geprägt. Dabei hat Weaveworks auf der Art aufgebaut, wie Änderungen in Kubernetes durchgeführt werden. Der Zustand des Clusters wird durch die Control-Plane verwaltet. Gewünschte Zustandsänderungen (entweder von außerhalb des Clusters durch Anweisungen über die Kubernetes API oder von innerhalb wie zum Beispiel bei Skalierungs-Events) werden im Key-Value Store etcd persistiert; Controller im Cluster führen kontinuierlich eine Reconciliation durch.

Reconcilation bedeutet, dass der Controller den aktuellen Zustand der von ihm überwachten Objekte mit dem gewünschten Zustand in etcd vergleicht und die nötigen Schritte einleitet, um diesen zu erreichen. Dabei ist die Zustandsbeschreibung deklarativ. Im Gegensatz zu einer imperativen Beschreibung wird nicht beschrieben, wie dieser Zustand zu erreichen ist. GitOps für Kubernetes führt eine weitere Reconciliation-Schleife ein: zwischen der Versionskontrolle (in der Regel Git) und dem Key-Value-Store etcd.

Flux v2

Um diese Reconciliation-Schleife zu implementieren, werden wir im Folgenden Flux v2 von Weaveworks verwenden. Flux ist hierbei kein alleinstehendes Werkzeug, das von außen mit der Kubernetes API kommuniziert. Es nutzt viel mehr das Kubernetes-Konzept von Custom Resource Definitions (CRDs).

Eine CRD erweitert die Kubernetes API und ermöglicht es so, den Cluster um Funktionalitäten zu erweitern. Typische Beispiele hierfür sind beispielweise die AWS Controllers for Kubernetes, die AWS Services wie Datenbanken oder Message Broker als native Objekte in den Kubernetes Templates verwalten können. Flux definiert vier Arten von Controllern als CRD:

• Source Controller überwachen externe Quellen (beispielweise Git oder Helm-Repositories) und erzeugen von anderen Controllern konsumierbare Artefakte im Kubernetes Cluster.

• Reconciler prüfen die von Source Controllern erzeugten Artefakte und erzeugen bei Bedarf Änderungen im Desired State in etcd, auf den dann wiederum die Runtime Controller von Kubernetes selbst reagieren und den Zustand der Anwendung entsprechend anpassen.

• Image Automation Controller überwachen den Zustand von Image Repositories, schreiben bei Bedarf neue Image Versionen in die Kubernetes Templates, committen diese an Git Repositories und lösen somit wieder Reconciliation-Schleifen über Source Controllers und Reconcilers aus.

• Notification Controller interagieren mit externen Systemen via Events und sind beispielweise das Bindeglied zu Slack und somit ChatOps.

Neben den Controllern in Kubernetes benötigen wir noch eine Möglichkeit, den Cluster-Zustand unter Versionskontrolle zu halten. Wie bereits erwähnt, verwenden wir Git – und Flux gibt hier ein paar Konventionen vor. Diese Konventionen sind jedoch nicht starr und erlauben es die Struktur der Repositories auf den jeweiligen Workflow zwischen Development und Betriebsteam anzupassen. Eine Übersicht findet sich in der offiziellen Doku.

Ein häufiges Team-Setup von SaaS Anbietern ist, eine Plattform-Mannschaft für die Entwicklung und Verwaltung des Clusters zu haben, welches das Produktteams dazu befähigt, ihre Anwendung in dieser Plattform zu betreiben. Um die Trennung der Verantwortlichkeiten auch technisch zu gewährleisten, besitzen beide Teams ihre eigenen Git-Repositories. Wir wollen daran angelehnt in diesem Beispiel den vorne zu sehenden Workflow abbilden.

Das Plattformteam verwaltet einen oder mehrere Cluster in seinem Infrastruktur-Repository. Es führt die notwendigen Konfigurationen durch, wie beispielweise die Installation von Flux. Dieser Schritt wird Bootstrapping genannt. Anschließend ist das Team für das Onboarding neuer Mandanten zuständig. Hierzu werden die notwendigen Kubernetes-Templates im Infrastruktur-Repository angelegt.

Im Onboarding-Prozess werden ebenfalls Kubernetes Namespaces und Service Accounts zur Isolierung der Mandanten erzeugt. Außerdem bestimmt der Onboarding-Prozess, welche SaaS-Anwendungen für einen Mandanten provisioniert werden sollen.

Die eigentliche Provisionierung erfolgt dann aber durch Links in die Produkt-Repositories der Produktteams. Hier liegen die Deployment-Manifeste, wie beispielweise Kubernetes Templates oder Helm-Charts. Die Mandanten- oder umgebungsspezifische Konfiguration liegt in unserem Beispiel ebenfalls im Produkt-Repository.

Die Repository Struktur

Für diese Artikelreihe werden wir mit zwei Repositories arbeiten. Das Plattform-Team verwaltet das Infrastruktur-Repository, das den Infrastrukturcode und die Konfiguration des Clusters enthält. Es beinhaltet darüber hinaus noch Konfiguration für die Tenant-Namespaces, in welche die SaaS-Mandanten deployed werden. Hier findet sich der Link zum Produkt Repository des Produkt-Teams. Es enthält das Deployment-Manifest und die App-Konfiguration, auf die im Infrastruktur-Repository verwiesen wird.

Die für diesen Blog Post relevanten Komponenten im Infrastruktur Repository sind:

Das Produkt-Repository hingegen enthält das Deployment Manifest, das im Infrastruktur Repository innerhalb des Tenant Unterordners verlinkt ist:

Wir verwalten beide Repositories in GitHub und erzeugen uns ein GitHub Token für den Account. Das Token ist eine Alternative zur Passwort-Authentifizierung gegenüber der GitHub API. Wir werden das Token verwenden, um Flux Zugriff auf die Repositories zu geben. Eine detaillierte Anleitung beinhaltet die GitHub-Dokumentation. Das Token muss – wie in der Abbildung zu sehen – alle Berechtigungen des Scope repo enthalten.

Eine Demo App

Unser Beispiel für ein Produkt Repository ist das in der offiziellen Flux Dokumentation verwendete podinfo-Repository von Stefan Prodan von Weaveworks. Im kustomize-Ordner des Repositories ist ein Manifest bestehend aus einem Deployment, einem Service und Konfigurationen zum Skalieren der Pods enthalten:

Boostrapping des Kubernetes-Cluster

Wir benötigen zwei Kommandozeilen-Tools in unserer lokalen Entwicklungsumgebung, um den oben beschriebenen Workflow mit Flux aufzusetzen. Zunächst muss Flux in Version 2 selbst installiert werden. Das zweite Tool werden wir für das Konfigurationsmanagement einsetzen. Es erzeugt Kubernetes Templates und heißt Kustomize, eine Installationsanleitung findet sich hier.

Nach der Installation exportieren wir unsere GitHub Zugangsdaten in der Kommandozeilen-Session, die wir für das Bootstrapping mit Flux verwenden wollen:

Flux verwendet die kubeconfig zur Authentifizierung am Kubernetes Cluster. Damit dort aktuelle Zugangsinformationen für den EKS Cluster gefunden werden, müssen wir die kubeconfig mit der AWS CLI aktualisieren:

Wir können nun prüfen, ob alle Voraussetzungen erfüllt sind, den Boostrap-Prozess für das Cluster zu starten:

Der Bootstrap-Prozess führt eine Reihe von Schritten im Kubernetes-Cluster und im Infrastruktur-Repository durch:

• Das Repository wird in GitHub angelegt, falls es nicht bereits existiert.

• Ein Manifest für die Komponenten von Flux wird im Infrastruktur Repository angelegt.

• Das Manifest wird verwendet, um die Flux-Komponenten in den Kubernetes Cluster zu deployen.

• Flux im Kubernetes Cluster wird so konfiguriert, dass der Cluster-Ordner im Infrastruktur Repository auf Änderungen überwacht wird.

Wir starten den Bootstrap-Prozess über die Kommandozeile, in der wir die GitHub Zugangsdaten exportiert haben:

Im Kubernetes-Cluster existiert nun ein neuer Namespace flux-system, in dem die Controller laufen. Die erste Reconciliation-Schleife wurde ebenfalls eingerichtet. Im neuen Unterordner clusters/prod-eu/flux-system ist in der gotk-sync.yaml-Datei der Cluster-Unterordner im Infrastruktur-Repository registriert:

Hinzufügen neuer Tenants

Diese erste Reconciliation-Schleife ermöglicht es uns nun, über einen Git-Commit neue Mandanten im Cluster zu erzeugen. Dazu arbeiten wir im lokal ausgecheckten Infrastruktur-Repository:

Damit weisen wir Flux an, eine Reconciliation-Schleife für das Produkt-Repository im Namespace des neuen Mandanten anzulegen und das Deployment-Manifest aus dem Unterordner kustomize anzuwenden:

Der Reconciler nutzt dafür den neu erzeugten Service Account. Dieser erhält über ein RoleBinding administrative Rechte im Namespace:

Es werden keine Änderungen im Produkt Repository durchgeführt. Der Reconciler benötigt hier lediglich lesenden Zugriff, um die referenzierten Manifestdateien in den Kubernetes Cluster zu übertragen.

Die Reconciliation-Schleife für das Infrastruktur Repository zeigt nach kurzer Zeit die neue Revision. Die mit Flux und Kustomize angelegten Manifeste enthalten die Anweisungen, die App für den neuen Mandanten in einem eigenen Namespace anzulegen:

In diesem Namespace wurde ein zusätzlicher Service Account angelegt, der ein cluster-admin RoleBinding nur in diesem Namespace hat:

Der Reconciler verwendet diesen Service-Account, um Änderungen im Deployment-Manifest ausrollen und sämtliche Kubernetes-Objekte in diesem Namespace manipulieren zu können. Außerhalb des eigenen Namensbereichs hat der Reconciler keine Zugriffsrechte. Service-Accounts für Pods zur Laufzeit sind davon nicht betroffen. Sie können weiterhin beliebige Service-Accounts wie zum Beispiel default verwenden.

In diesem Teil der Serie haben wir gesehen, wie ein GitOps-Prozess mit Flux aufgesetzt werden kann. SaaS-Apps für Mandanten werden in dedizierte Namespaces deployed. Die Definition der Deployment-Manifeste liegt in der Hand der Produktteams, das autark vom Plattformteam eine Wartung über Git-Commits betreiben kann.

Das Plattform-Team ist weiterhin für die Kubernetes-Infrastruktur zuständig und hat alle Möglichkeiten zur Isolation der Mandanten. So können zum Beispiel Network Policies verwendet werden, um den Datentransfer zu kontrollieren. Durch die Integration von AWS Identity and Access Management (IAM) in AWS und die Role Based Access Control (RBAC) in Kubernetes kann das Plattform Team auch zentral Zugriffsrechte auf Ressourcen wie zum Beispiel Datenbanken außerhalb des Clusters verwalten.

Im nächsten Teil der Reihe zeigen wir, wie sich das Onboarding und damit die Provisionierung neuer Mandanten automatisieren lässt.

* Markus Kokott arbeitet als Solutions Architect bei Amazon Web Services. Er hilft Softwareherstellern dabei ihre Prozesse und Produkte zu modernisieren und damit fit für die Cloud zu machen. Technologisch interessiert sich Markus insbesondere für die Bereiche DevOps und Container.

(ID:47826686)