Verwendung von GitOps mit Amazon Elastic Kubernetes Service mit Landbay

In der sich entwickelnden Landschaft der digitalen Kreditvergabe revolutioniert Landbay, ein preisgekrönter Hypothekengeber auf dem britischen Markt für Mietkredite, seine digitale Infrastruktur. Die Plattform von Landbay basiert auf AWS-Services und umfasst etwa 60 Microservices, die einer dreistufigen Architektur folgen, welche Webserver, Amazon Elastic Kubernetes Service (Amazon EKS) und eine mehrschichtige Datenebene kombiniert. Durch die Kombination der Leistung von AWS Cloud Services mit Open-Source-Projekten war Landbay in der Lage, diesen neuen Ansatz zu nutzen, um eine erstklassige Architektur auf der Grundlage von Amazon Elastic Kubernetes Service zu entwickeln.

Der GitOps-Vorteil

Mit der zunehmenden Bedeutung von Microservices-Architekturen hat sich GitOps zu einem neuen Standard für diesen Bereitstellungsmechanismus entwickelt. Im Rahmen der Cloud Native Computing Foundation (CNCF) sind zwei bemerkenswerte Produkte entstanden: Flux und ArgoCD. Landbay entschied sich für Flux, weil es eine native Integration mit Kubernetes bietet, indem es benutzerdefinierte Ressourcendefinitionen (CRDs) zur Definition von Bereitstellungen, Helm-Releases, Kustomizations und mehr bereitstellt. Dies wiederum ermöglichte es den Softwareingenieuren, Kubernetes zu beherrschen und so besser zu verstehen, wie Flux in das Ökosystem passt.

Lösung im Überblick

Um ein umfassendes Verständnis der GitOps-Implementierung von Landbay zu vermitteln, schauen wir uns die wichtigsten Architekturkomponenten und ihre Beziehungen innerhalb des AWS-Ökosystems an:

• Amazon Elastic Container Registry (ECR): Landbay nutzt Amazon ECR zum Speichern von Helm-Charts sowie Docker-Images.
• Externe DNS- und AWS Elastic Load Balancing Controller: Diese Controller werden zur Konfiguration von Route53 und Load Balancern verwendet, um den externen Zugriff auf Kubernetes-Eingänge sicherzustellen.
  
• Integration mit AWS Secrets Manager: Aus Architektur- und Sicherheitsgründen hat sich Landbay für eine direkte Integration mit AWS Secrets Manager entschieden, anstatt externe Tools wie den externen Secrets Controller zu verwenden, was dem AWS Shared Responsibility Model (AWS-Modell der geteilten Verantwortung) entspricht und die allgemeine Sicherheitslage der Lösung verbessert.
  
• Terraform-Konfigurationsmanagement: Terraform kann verwendet werden, um die Lücke zu schließen, indem eine ConfigMap bereitgestellt und wichtige Konfigurationselemente (Endpunkte, Subnetz-CIDRs usw.) zusammengefasst werden. Flux kann die Config-Map dann über sein Post-Build-Feature verwenden (siehe Abbildung 2).
  

Die Kubernetes-Umgebung und Datenarchitektur von Landbay

Landbay ist ein begeisterter Anwender von Terraform und seine gesamte Infrastruktur ist mit Infrastructure-as-Code (IAC) kodiert. Dadurch wird die Synchronität zwischen Test- und Produktionsumgebungen gewährleistet und sichergestellt, dass alle Änderungen an der Infrastruktur den Standardprozess des Softwareentwicklungszyklus durchlaufen.

Um sicherzustellen, dass es bei Amazon EKS-Upgrades keine Ausfallzeiten gibt, setzt Landbay verwaltete EKS-Knotengruppen mit drei verwalteten Knotengruppen ein, die jeweils auf eine bestimmte Availability Zone ausgerichtet sind. Diese Konfiguration ermöglicht die Nutzung von persistenten Volumes, die durch den Amazon Elastic Block Store (EBS) CSI-Treiber unterstützt werden. Darüber hinaus verwendet Landbay topologySpreadConstraints (DoNotSchedule), um sicherzustellen, dass StatefulSets über Availability Zones verteilt sind.

Bei kritischen Diensten werden benutzerdefinierte Prioritätsklassen verwendet, um Bereitstellungen mit niedrigerer Priorität zu verhindern.

Um die Kosten in der Testumgebung zu senken, nutzt Landbay die Leistung von Amazon EC2 Spot Instances über von Terraform und Amazon EKS verwaltete Knotengruppen.

Landbay hat sich schließlich Bottlerocket zu eigen gemacht, indem es eine stark reduzierte Angriffsfläche bietet.  Der Kubernetes-Operator wird verwendet, um die Knoten in einem Cluster schrittweise zu aktualisieren, indem das Konzept der Wellen verwendet wird. Während der Zugriff auf das Root-Dateisystem gesperrt ist, erfüllt die Integration mit IAM und Systems Manager (SSM) die grundlegenden Anforderungen von Landbay.

Amazon EKS-Erweiterungen

Zusätzlich zum Amazon Virtual Private Cloud (Amazon VPC) CNI-Plugin führt Landbay die folgenden Erweiterungen aus:

1. CoreDNS: Stellt die Auflösung des DNS-Dienstes innerhalb des Clusters sicher
2. KubeProxy: Unterstützt die Serviceerkennung und Vernetzung in Kubernetes.
   
3. Amazon VPC CNI mit enableNetworkPolicy: Ermöglicht die Durchsetzung von Netzwerkrichtlinien und hilft Landbay dabei, verschiedene Zugriffe auf Namespaces und Pods abzusichern.
   
4. Amazon EBS CSI-Treiber: Ermöglicht die Verwendung persistenter Volumes.
   

Konfiguration der Zugriffsverwaltung

Landbay verwendet AWS IAM Identity Center, um den gesamten Zugriff auf AWS APIs zu kontrollieren. Amazon EKS ermöglicht die Zuordnung von SSO-Rollen zu Kubernetes-Gruppen und damit eine indirekte Zuordnung zu Azure Entra ID-Gruppen durch das IT-Admin-Team. Dieser Ansatz gewährleistet eine Trennung der Belange zwischen dem IT-Admin-Team und dem Rest der Organisation.

Das obige Fragment kann dann verwendet werden, um eine kubernetes_config_map_v1-data aws_auth-Ressource festzulegen:

Um eine Vielzahl von Rollen zu vermeiden, bietet Kubernetes einen Mechanismus, mit dem Berechtigungen aus anderen Helm-Releases mithilfe von „aggregate-to-admin“ auf bestehende Gruppen übertragen werden können:

AWS Load Balancer Controller

Um die Integration zwischen Diensten zu verbessern, hat Landbay den AWS Load Balancer Controller (LBC) und den externen DNS-Controller genutzt.

Mit dem AWS Load Balancer Controller können Sie Load Balancers direkt von Ingresses aus bereitstellen sowie extern verwaltete Load Balancers wiederverwenden und Ziel-Pods zuweisen. Durch die Ausgliederung der Bereitstellung von Load Balancern in ein separates Projekt können DevOps-Teams mehr Rechte an einem Quellcode-Repository haben und gleichzeitig den Ingenieuren, die die Ziele verwalten, Tools für die Arbeit zur Verfügung stellen.

Der Controller verwaltet bei Bedarf auch Sicherheitsgruppen im Backend zwischen dem Load Balancer und seinen Zielen. Durch die Verwendung der Anmerkung group.name kann derselbe Load Balancer hinter den Kulissen für mehrere Zielgruppen freigegeben werden.

Landbay verwendet außerdem AWS Load Balancer Controller zur Bereitstellung von Netzwerk-Load-Balancern, um den Eintritt von AWS Lambda-Funktionen, die innerhalb der VPC laufen, in die EKS-Infrastruktur zu ermöglichen.

Als Ergänzung dazu ermöglicht der External DNS Controller Kubernetes-Pods einen begrenzten Schreibzugriff auf Route53. Dieses Feature erleichtert die automatische Freigabe von externen Diensten mit freundlichen DNS-Namen und verbessert so die allgemeine Benutzerfreundlichkeit.

Aus Sicherheitsgründen benötigen der Application Load Balancer (ALB)-Controller und der externe DNS-Controller nur eine begrenzte Anzahl von IAM-Berechtigungen, die eng gefasst werden können. Der DNS-Controller benötigt zum Beispiel lediglich Schreibzugriff auf bestimmte Route 53-Zonen (route53:ChangeResourceRecordSets) sowie eine Handvoll Listenberechtigungen.

Verwaltung von Geheimnissen in Kubernetes

Während die meisten Lösungen Probleme im Zusammenhang mit der Verwaltung von Geheimnissen angehen, wie z. B. die Rotation von Geheimnissen und die Integration, führt die Verwendung der Kubernetes-Geheimnisspeicherung oder die Synchronisierung externer Geheimnisse mit Kubernetes dazu, dass Geheimnisse im Klartext im zugrunde liegenden etcd von Kubernetes gespeichert werden.  Obwohl die Verwendung von ‚verschlüsselten Geheimnissen in EKS‘ dazu beiträgt, physische Angriffsvektoren abzuschwächen, werden beim Zugriff über die Kubernetes-API die Rohwerte des Geheimnisses gemäß dem AWS Shared Responsibility Model (AWS-Modell der geteilten Verantwortung) offengelegt

Die Verwendung des von AWS bereitgestellten Container Storage Interface (CSI)-Treibers bietet Vorteile, entfernt die Architektur aber auch vom nativen Kubernetes-Management. In Anbetracht der Tatsache, dass sowohl der CSI-Treiber als auch eine externe Provider-Lösung eine direkte Integration mit dem externen Secrets-Provider erfordern, beschloss Landbay, seine Microservices direkt in AWS Secret Manager zu integrieren.

Die direkte Integration vermeidet die Einführung von mehr Komplexität in der Umgebung, die sonst zu höheren Wartungs- und Supportkosten führen könnte. Außerdem werden Geheimnisse im Klartext in Container-Volumes vermieden, was die Sicherheit weiter erhöht.

Provisioning Flux in der AWS-Umgebung

Flux, die von Landbay gewählte GitOps-Lösung, bietet einen Terraform-Anbieter für das Bootstrapping von EKS-Clustern. In regelmäßigen, konfigurierbaren Abständen stellt Flux sicher, dass alle im Git Repository definierten Kubernetes-Manifeste mit den vorhandenen, auf Kubernetes bereitgestellten Ressourcen abgeglichen werden, und korrigiert jede festgestellte Abweichung. Sobald Flux gebootet ist, kann es seinen ersten Abgleich durchführen und konfigurierte Dienste, Pods, Stateful Sets und mehr auf dem Kubernetes-Cluster installieren, wie in der Abbildung unten dargestellt.

Flux kann AWS Elastic Container Registry (ECR) als Helm Repository nutzen, da ECR eine erstklassige Unterstützung für OCI-Artefakte bietet. Dadurch kann Flux als Bindeglied zwischen ECR und EKS fungieren und mithilfe von Kustomizations umfeldspezifische Konfigurationen anwenden.

Ein entscheidender Vorteil dieses Ansatzes ist die logische Trennung zwischen dem Continuous Integration (CI)-Teil der Bereitstellungspipeline (Build, Test & Paketierung) und dem Continuous Deployment (CD)-Teil (Bereitstellung in der Umgebung). Aus der Sicherheitsperspektive zieht Flux die Änderungen, so dass die Zugriffsberechtigungen für die tägliche Bereitstellung deutlich eingeschränkt werden können. Um Verzögerungen bei der Bereitstellung zu vermeiden, ist die einzige erforderliche Berechtigung, dass das Build-Tool Flux über eine frühzeitige Abstimmung ‚benachrichtigt‘, was über eine gesperrte kubeconfigmit einem eingeschränkten Benutzer erfolgen kann.

Dadurch wird die Bereitstellung, Rückgängigmachung oder Förderung eines neuen Mikrodienstes so einfach wie die Aktualisierung eines semantischen Versionsverwaltungsfragments (semver) in einer YAML-Datei oder die Rückgängigmachung eines Commits. Sobald eine Git-Änderung festgestellt wird, löst Flux einen Abgleich mit Kubernetes aus und aktualisiert den betreffenden Dienst entsprechend.

Flux Repository-Struktur und gemeinsame Komponenten

Flux bietet eine umfassende Dokumentation über empfohlene Repository-Strukturen. Der Ansatz von Landbay ist relativ geradlinig und folgt diesen Best Practices.

Cluster-Konfigurationen werden in eigenen Ordnern definiert, die jeweils auf gemeinsame Komponenten verweisen. Innerhalb dieser Cluster-Ordner sorgt die umfassende Verwendung von Kustomizations für die Isolierung zwischen Clustern. Dies ermöglicht umgebungsspezifische Konfigurationen, wie Versionsverwaltung und Speicher.

Die oben dargestellte Struktur schafft ein Gleichgewicht zwischen der gemeinsamen Nutzung von Code und der Beibehaltung des deklarativen und expliziten Charakters des GitOps-Paradigmas, sodass ein Ingenieur ein Git-Repository lesen und feststellen kann, welche Komponenten, Versionen oder Pakete auf dem Cluster installiert wurden.

Durch die Trennung der Komponenten kann Landbay den Prozess des Aufbaus neuer Cluster rationalisieren. Ab hier wird die Cluster-Konfiguration zu einer Frage der Auswahl von „LEGO-Steinen“ und deren Zusammenbau mit einer umgebungsspezifischen Konfiguration.

Während einige Cluster in der Cloud betrieben werden und zusätzliche Komponenten benötigen, können sich andere Cluster an DevOps-Ingenieure richten, die lokal arbeiten. Dieser lokale Entwicklungsansatz bietet eine schnellere Feedback-Schleife und beinhaltet keine Komponenten, die in direktem Zusammenhang mit AWS-Services stehen.

Lokale Entwicklung als Sprungbrett

Dieser lokale Entwicklungsansatz ist auch das Sprungbrett für die schnelle Bereitstellung cloudbasierter, kurzlebiger Entwicklungsumgebungen. Durch die Verwendung von Kubernetes-Namespaces und das Entfernen von Abhängigkeiten von AWS-verwalteten Diensten ist Landbay in der Lage, Flux für das schnelle Bootstrapping neuer eigenständiger Umgebungen zu verwenden.

In diesem Fall könnte die Entwicklungsumgebung von Landbay den Amazon Relational Database Service (RDS) durch einen einfachen MariaDB-Container und den Amazon OpenSearch Service durch den entsprechenden OpenSearch-Container ersetzen. Während dieser Ansatz die Entwicklungsumgebungen architektonisch "im Gleichschritt" hält (z.B. ähnliches Namespacing, Serviceerkennung, Networking), besteht der Nachteil in einem Mangel an betrieblicher Ausfallsicherheit - was für einige Entwicklungsumgebungen akzeptabel sein mag.

Integration von EKS-, GitOps- und AWS-Services

Bei Landbay wird die AWS-Infrastruktur vollständig von Terraform verwaltet. Daher ist es unerlässlich, die Lücke zwischen den von Terraform bereitgestellten Elementen (RDS, OpenSearch usw.) und anderen Pods, die innerhalb des Clusters laufen, zu schließen. Der native Weg zum Zugriff auf die Konfiguration in Kubernetes in Microservices ist über ConfigMaps.

Das folgende Diagramm zeigt die Wechselbeziehung zwischen unseren Terraform- und Flux-Projekten.

Das erste Terraform-Projekt ist für die Einrichtung aller grundlegenden Netzwerke, der dem Internet zugewandten Load Balancer und der von AWS verwalteten Dienste zuständig. Das zweite Projekt richtet den EKS-Cluster ein, bootet Flux in den Cluster, sichert den EKS-Cluster, richtet alle IAM-Rollen ein und verwaltet die unteren Ebenen wie verwaltete Knotengruppen, auf denen Bottlerocket läuft. Dieses Projekt erstellt eine Umgebungs-ConfigMap, die AWS nach allen Umgebungsvariablen abfragt und sie in Kubernetes injiziert.

Das abschließende Projekt ist ein eigenes Flux-Projekt. Dieses definiert die Cluster-Konfiguration für die Umgebung,  verlinkt auf eine Reihe gemeinsam genutzter Komponenten und passt dann Helm-Releases und Kubernetes-Manifeste an die jeweilige Umgebung an. Die Umgebungs -ConfigMap kann dann als Teil von Anpassungen innerhalb des Flux-Repositorys verwendet werden. Flux bietet auch ein Feature zur Ersetzung von Variablennach dem Build, die die Verwendung von Variablenersetzungen mit einer Vielzahl von gut definierten Bash-String-Ersetzungsfunktionen ermöglicht.

In einem Helm-Chart können die Werte beispielsweise nach dem Build die Variablenersetzung verwenden. Wie in der Abbildung unten zu sehen ist, erweitert dieser Ansatz das GitOps-Repository, sodass gemeinsam genutzte Komponenten unabhängig von der Umgebung sein können.

Fazit

Die Entscheidung von Landbay, GitOps über Flux einzuführen, das eng mit Amazon EKS und dem breiteren AWS-Ökosystem integriert ist, hat sich als entscheidender Schritt erwiesen. Durch die Einführung dieses innovativen Ansatzes hat Landbay eine Vielzahl von Vorteilen erschlossen, die den Betrieb rationalisiert und die Sicherheit erhöht haben. Einer der wichtigsten Vorteile ist vielleicht die Realisierung von Effizienzsteigerungen in allen Bereichen der Technik. Von schnelleren Bereitstellungen und kürzeren Wartezeiten bis hin zur nahtlosen Nutzung von Lösungen von Drittanbietern – die Integration von GitOps mit EKS und AWS-Services hat die Entwicklungsprozesse von Landbay revolutioniert.

Außerdem wurde die Sicherheitslandschaft von Landbay gestärkt und ist nun robuster und kostengünstiger in der Wartung. Durch die Nutzung von Bottlerocket, die Trennung von Aufgaben über SCM/Git-Berechtigungen und die Ermöglichung müheloser Upgrades durch Helm hat Landbay sein Engagement für Sicherheit gefestigt und gleichzeitig die Betriebskosten optimiert.

Die tiefgreifendste Auswirkung dieser Umstellung liegt in der verbesserten Sichtbarkeit und Transparenz des Zustands und der Änderungen des EKS-Workloads. Mit GitOps wird die Konfiguration mit YAML deklariert und alle Änderungen werden als Git Commits gespeichert. Dieser Paradigmenwechsel hat den Support-, Risiko-, Compliance- und Audit-Teams von Landbay erhebliche Vorteile verschafft und ihnen einen beispiellosen Einblick und Kontrolle über ihre unternehmenskritischen Systeme ermöglicht.

Wenn Sie bereit sind, Ihr Startup wie Landbay zu transformieren, kommen Sie zu AWS Activate, um Zugang zu bereitstellbaren Vorlagen, AWS-Guthaben und Lernmöglichkeiten zu erhalten.