In der heutigen, sich st\u00e4ndig im Wandel befindenden Technologie-Landschaft werden moderne Systeme wie Kubernetes h\u00e4ufig als neueste Innovation des Infrastruktur- und Applikationsmanagements angesehen. Doch auch in der Welt der Containerisierung und der dynamischen Skalierung gibt es Zeiten, in denen diese fortgeschrittenen Technologien mit traditionellen Systemen und Praktiken interagieren m\u00fcssen.<\/p>\n\n\n\n
Einen solchen Bereich stellt das Sicherstellen einer vorhersehbaren Netzwerkkonnektivit\u00e4t dar \u2013 besonders, wenn es um \u00e4ltere Firewalls und externe Dienste geht, die verlangen, dass die Verbindung von einer bestimmten IP-Adresse ausgeht. Da uns bei Nine solche Anforderungen immer wieder begegnen, haben wir uns eine L\u00f6sung \u00fcberlegen m\u00fcssen: unser neues Feature Static Egress, das wir uns in diesem Artikel n\u00e4her anschauen wollen. <\/p>\n\n\n\n
Als wir unser NKE (Nine Kubernetes Engine) Produkt entwarfen, geh\u00f6rte zu unseren Hauptzielen sowohl die Automatisierung als auch die M\u00f6glichkeit, Self-Service anzubieten. Kubernetes und die dazugeh\u00f6rigen Add-ons bieten bereits eine gute Basis daf\u00fcr. Je nach Ressourcenbedarf des Clusters, auf dem die Workloads laufen, f\u00fcgt der Cluster-Autoscaler zum Beispiel Nodes hinzu oder entfernt sie wieder. Etwas, worum sich Kubernetes jedoch nicht von sich aus k\u00fcmmert, ist die Verwaltung der darunterliegenden Nodes.<\/p>\n\n\n\n
Bei unseren VMs f\u00fchren seit jeher die Updates der installierten Software und der Linux Kernel mithilfe eines Konfigurationssystems und des Package Managers der darunterliegenden Linux-Distribution durch. Das betrifft auch Upgrades von einem grossen Distribution-Release zum n\u00e4chsten (z. B. von Ubuntu 22.04 auf 24.04), f\u00fcr die viel Vorbereitung und Vorarbeit n\u00f6tig sind. Als wir NKE einf\u00fchrten, wollten wir diesen Weg nicht gehen und suchten daher nach anderen L\u00f6sungen.<\/p>\n\n\n\n
Als wir NKE ins Leben riefen, hatten wir gl\u00fccklicherweise bereits Erfahrungen mit der Verwaltung von Google Kubernetes Engine (GKE) Clustern sammeln k\u00f6nnen. Dort waren wir sehr zufrieden damit, wie Node-Upgrades durchgef\u00fchrt werden. In einem GKE Cluster wird die Node-Software selbst nicht in einer bereits laufenden Instanz aktualisiert. Stattdessen werden die Maschinen eine nach der anderen durch neuere, aktualisierte Maschinen ersetzt. Bei der Implementierung dieses Workflows setzen wir auf Flatcar Linux<\/a>, welches eine rollende Linux-Distribution mit fortgeschrittener Sicherheit bietet. Einer der zus\u00e4tzlichen Sicherheitsmechanismen ist ein unver\u00e4nderliches Dateisystem, das eine Ver\u00e4nderung bereits installierter Software nicht zul\u00e4sst. Dadurch werden Versions- und Konfigurationsabweichungen verhindert.<\/p>\n\n\n\n Doch kehren wir zum Upgrade-Mechanismus selbst zur\u00fcck. Da beim sequentiellen Upgrade-Workflow eine neue Maschine hinzugef\u00fcgt wird, bevor die alte entfernt wird, laufen beide einen kurzen Moment lang gleichzeitig. Eine Konsequenz daraus ist, dass beide Nodes unterschiedliche IP-Adressen nutzen m\u00fcssen, was sich wiederum auf die Workloads auswirkt, die auf dem Kubernetes Cluster laufen. Das liegt daran, dass die ausgehende IP-Adresse f\u00fcr den externen Datenverkehr des Clusters von der IP des Nodes selbst abh\u00e4ngt (vom Workload veranlasster Datenverkehr zu externen Adressen nutzt eine Node Source NAT).<\/p>\n\n\n\n Nachdem wir unseren Node Upgrade-Mechanismus implementiert und eingef\u00fchrt hatten, fragten einige unserer Kund*innen nach der IP-Adresse ihrer NKE-Cluster-Nodes, da sie diese auf externen Firewalls konfigurieren wollten. Da sich die IP-Adressen der Nodes jedoch im n\u00e4chsten Wartungsfenster vermutlich wieder \u00e4ndern w\u00fcrden, konnten sie nicht mehr langfristig bestimmt werden. Selbst wenn sie w\u00e4hrend der Wartung gleich blieben, bestand immer noch die M\u00f6glichkeit, dass die Nutzung von Node Pools, die mithilfe des Cluster-Autoscalers skaliert wurden, zu neuen Nodes mit neuen IP-Adressen f\u00fchrte. Es war daher klar, dass die dynamische Welt von Kubernetes nicht wirklich in die vorhandenen, eher statischen Umgebungen passt.<\/p>\n\n\n\n Eine ganze Zeit lang bestand die einzige L\u00f6sung darin, alle NKE Subnetze auf externen Firewalls zuzulassen. Das verringert zwar das Risiko von Angriffen auf externe Dienste, doch meiner Meinung nach ist eindeutig, dass es sich hierbei nicht wirklich um eine zufriedenstellende L\u00f6sung handelt. Das Ganze wird noch zus\u00e4tzlich dadurch kompliziert, dass wir ausserdem mit der Zeit neue NKE Subnetze hinzuf\u00fcgen m\u00fcssen.<\/p>\n\n\n\n Als wir genauer untersuchten, wie dieses Problem gel\u00f6st werden kann, wurden wir darauf aufmerksam, dass unser CNI-Anbieter Cilium bereits ein Feature mit dem Namen Egress Gateway<\/a> anbot. Die dazugeh\u00f6rige Dokumentation beschreibt das Feature wie folgt:<\/p>\n\n\n\n \u00abDas Egress Gateway Feature routet alle IPv4-Verbindungen, die von Pods ausgehen und deren Ziel spezifische CIDRs ausserhalb des Clusters sind, \u00fcber bestimmte Nodes, die ab diesem Zeitpunkt \u2039Gateway Nodes\u203a heissen. Wenn das Egress Gateway Feature eingeschaltet ist und Egress Gateway Regeln vorhanden sind, werden passende Pakete, die den Cluster verlassen, mit ausgew\u00e4hlten, vorhersehbaren IPs maskiert, die mit den Gateway Nodes in Verbindung stehen.\u00bb<\/p>\n\n\n\n Dieses Feature l\u00f6ste zwar unser Problem mehr oder weniger, aber es gab noch weitere Punkte, die wir ebenfalls angehen mussten.<\/p>\n\n\n\n Erstens k\u00f6nnte der \u00abGateway Node\u00bb w\u00e4hrend eines Wartungsfensters einfach verschwinden (da er ersetzt wird), sodass ein anderer Node seine Rolle \u00fcbernehmen muss. Die IP-Adresse dieses neuen \u00abGateway Nodes\u00bb k\u00f6nnte wiederum von einem ganz anderen Subnetz als die des vorherigen \u00abGateway Nodes\u00bb stammen. Daher war uns klar, dass wir die IP-Adressen bereits vorhandener NKE-Subnetze nicht als Static-Egress-IPs nutzen konnten.<\/p>\n\n\n\n Zweitens muss die IP-Adresse, die als Egress-IP genutzt werden soll, \u00fcber einen bestimmten Mechanismus auf dem \u00abGateway Node\u00bb konfiguriert werden. Cilium tut das nicht automatisch, sondern verlangt vielmehr, dass dies bereits voreingestellt ist.<\/p>\n\n\n\n Um das erste Problem zu l\u00f6sen, verwenden wir BGP (Border Gateway Protocol), um unseren Routern die Routen f\u00fcr spezielle, unabh\u00e4ngige Egress-IPs anzuk\u00fcndigen. Den gleichen Mechanismus verwenden wir bereits bei Kubernetes-Services des Loadbalancer-Typen (f\u00fcr eingehenden Datenverkehr) in unseren NKE-Clustern. Daher war es f\u00fcr uns logisch, das gleiche System auch hier anzuwenden. Damit sind die statischen Egress-IPs komplett unabh\u00e4ngig von den Subnetzen, die wir f\u00fcr unsere NKE-Nodes nutzen. <\/p>\n\n\n\n Nachdem wir die Untersuchung dieses Falles abgeschlossen und einige erste Testdurchl\u00e4ufe vorgenommen hatten, wussten wir, was nun zu tun war. Unsere n\u00e4chste Aufgabe bestand darin, einen Cluster Agent zu entwickeln, der auf den Control-Plane Nodes (von denen wir 3 betreiben) jedes NKE-Clusters laufen kann und einen der Nodes als \u00abGateway Node\u00bb ausw\u00e4hlt. Der Agent teilt diesem Node dann ein spezifisches Kubernetes-Label zu, \u00fcbernimmt alle BGP-Arbeiten, um das richtige Routing f\u00fcr eine ausgew\u00e4hlte statische Egress-IP aufzubauen und konfiguriert diese IP auf dem Node selbst. Wenn der ausgew\u00e4hlte Egress-Node dann w\u00e4hrend der Wartung gel\u00f6scht wird (oder auch einfach aus anderen Gr\u00fcnden nicht mehr funktioniert), sucht sich der Agent einen der anderen vorhandenen Nodes aus und f\u00fchrt eine Neukonfiguration durch. Gl\u00fccklicherweise gibt es bereits L\u00f6sungen f\u00fcr die Auswahl dieses sogenannten \u00abLeaders\u00bb (der Leader ist der ausgew\u00e4hlte Egress-Node), die wir bereits in Kubernetes nutzen konnten. Nach einem Monat Arbeit und Tests war der Agent fertiggestellt.<\/p>\n\n\n\n Um die Entwicklung des Static Egress Features abzuschliessen, haben wir dann noch Ciliums \u00abEgress Gateway\u00bb integriert, die Konfiguration unseres Agenten in einen Setup-Workflow vorgenommen und ihn \u00fcber unsere API ver\u00f6ffentlicht. Da Deploio<\/a> bereits auf NKE basiert, konnte das Static Egress Feature dort einfach bereitgestellt werden. Das Gleiche trifft auf vClusters<\/a> zu. Sobald die Dokumentation<\/a> fertig war, konnten wir unseren Kund*innen das Feature anbieten. <\/p>\n\n\n\n Das Feature l\u00e4uft nun seit einiger Zeit in der Produktionsumgebung und hat sich als zuverl\u00e4ssige L\u00f6sung f\u00fcr das Bereitstellen vorhersehbarer Egress-Identit\u00e4ten erwiesen.<\/p>\n\n\n\n <\/p>\n","protected":false},"excerpt":{"rendered":" In der heutigen, sich st\u00e4ndig im Wandel befindenden Technologie-Landschaft werden moderne Systeme wie Kubernetes h\u00e4ufig als neueste Innovation des Infrastruktur- und Applikationsmanagements angesehen. Doch auch in der Welt der Containerisierung und der dynamischen Skalierung gibt es Zeiten, in denen diese fortgeschrittenen Technologien mit traditionellen Systemen und Praktiken interagieren m\u00fcssen.<\/p>\n","protected":false},"author":4,"featured_media":3618,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[405],"tags":[413,398,412],"class_list":["post-3620","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-product-news","tag-deploio-de","tag-managed-kubernetes-de","tag-vcluster-de"],"acf":[],"yoast_head":"\nWie haben wir das Problem gel\u00f6st?<\/h2>\n\n\n\n