SSH-ServerContainer für die Entwicklung auf Kubernetes

Letztes Jahr haben wir über Laufen gesprochen Gehostete Jupyter-Notebooks und VS Code (Codeserver) auf Ihren Kubernetes-Clustern. Wir haben verschiedene Anwendungen und bestehende Lösungen verglichen, einschließlich der Vermietung und Verwaltung von VMs. Desweiteren haben wir unsere Ansätze zur Behebung von Usability-Problemen beschrieben, um das Erlebnis angenehmer zu gestalten und Kubernetes-Details abzuheben.

Seitdem haben wir viele Rückmeldungen von unseren Kunden erhalten, vor allem fehlt eine bessere Entwicklungserfahrung für vollwertige Apps. Jupyter Lab eignet sich zwar hervorragend für interaktive Notebooks und einfache Bearbeitung, aber um die vollen IDE-Funktionen auszudehnen, muss möglicherweise viel mit Jupyter-Erweiterungen gespielt werden, und für Codebasen, die keine Python-Version sind, ist es möglicherweise immer noch keine großartige Erfahrung. Um diese Mängel zu beheben, haben wir Folgendes gestartet Codeserver Support, der mehr oder weniger VS-Code befindet sich im Browser. Obwohl es eine Null-Setup-Lösung funktioniert und viele Probleme mit der Entwicklererfahrung mit Jupyter Lab löst, berichteten Benutzer von Problemen bei der Arbeit mit VS Code-Erweiterungen.

Zum Beispiel Pylance, die Erweiterung, die die großartige Python-Sprachunterstützung in VS Code bietet, kann installiert werden, da eine proprietäre Microsoft-Lizenz nicht auf Code Server installiert werden muss. Stattdessen müssen Benutzer auf eine Kombination von verlassen Jedi-Ritter und Coptrights die bei Pylance immer noch nicht auf dem neuesten Stand sind. Ein weiteres Beispiel ist Github CoPilot - Obwohl es möglich ist, es auf dem Code Server zu installieren, müssen Sie die Erweiterungsdatei manuell ausführen und die Code Server-Version aktualisieren.

Die Codeserver-Bearbeitung ist nicht schlecht, aber manchmal gibt es eine merkliche Verzögerung und verwirrter Text im Terminal, was nervig sein kann. Wir wussten immer, dass es eine bessere Erfahrung wäre, lokalen VS-Code via SSH oder Tunnel mit dem Remote-VS Code Server zu verbinden.

Tiel ist es, Benutzern zu ermöglichen, ein Deployment zu erstellen, auf dem OpenSSH-Server wird in einem Ubuntu-basierten Container-Image mit derselben Festplattenpersistenz wie Jupyter Lab ausgeführt, und die Benutzer müssen eine Verbindung wiederherstellen.

Es sieht auch auf der Plattform aus (Dokumente):

In diesem Beitrag werden wir erläutern, wie wir die Verbindung zu Containern über SSH implementiert haben, ohne direkten Zugriff auf den Cluster zu gewähren und ohne Datenverkehr außerhalb der VPC zu senden.

Istio und Routing

Wenn wir Anwendungen bereitstellen, konfigurieren wir normalerweise einen Domainnamen, um diese Dienste zu erreichen, aber der Kauf einer Domain für jede Anwendung ist unerschwinglich teuer. Dann kaufen wir eine einzelne Domain (z. B. acmecorp.com), konfigurieren Subdomains (docs.acmecorp.com) und/oder Pfadpräfixe (acmecorp.com/blog/) und verwenden dann einen Router, um Regeln abzugleichen und den Traffic an verschiedene Anwendungen weiterzuleiten.

Wir verwenden Istio für all unser Ingress-Routing. Istio bietet neben vielen Funktionen auch praktische Abstraktionen zur Konfiguration des zugrunde liegenden Gesandter Proxy, der tatsächlich das gesamte Routing abwickelt.

Laß uns verstehen, wie eine HTTP-Anfrage weitergeleitet wird

Im obigen Beispiel, wenn ein Benutzer versucht, https://myapp.acmecorp.com/api/v1 aufzurufen

1. zuerst wird*.acmecorp.com per DNS aufgelöst auf die öffentliche IP des externen Load Balancers. Der Port wird aufgrund des HTTPS-Protokolls als 443 abgeleitet.
2. Eine TCP-Verbindung zum Load Balancer wird hergestellt und die zuletzt verwendete HTTP-Anfrage wird gesendet.
3. Load Balancer leitet die Anforderungslast an Istio Ingress Pods weiter
4. Istio Ingress sieht überhaupt aus Virtuelle DiensteKonfigurationen (und Gateway), die dem Hostnamen (für die gesamte Subdomain myapp) und dem Pfadpräfix entsprechen und zum entsprechenden Kubernetes Service weiter leiten
5. Kubernetes leitet die Anfrage an einen der Endpunkte (Pod) für den Service weiter

Dies wird Layer-7-Routing genannt, das wir für das Routing der http-Spezifikation verwenden.

Routing im Kontext von SSH

SSH verwendete ein benutzerdefiniertes Protokoll, das TCP für den Transport verwendet. Eine einfache SSH-Verbindung sieht ungefähr wie folgt‍

ssh user@somemachine.acmecorp.com -p 22


Hier versuche über Port 22 eine Verbindung zu somemachine.acmecorp.com herzustellen. Hier muss somemachine.acmecorp.com:22 zu einer eindeutigen Kombination aus IP-Adresse und Port aufgelöst werden, um das Ziel zu erreichen. Aber denk dran, dass in unserem Setup alle Subdomains so konfiguriert sind, dass sie auf den gleichen Load Balancer verweisen - das heißt, abc.acmecorp.com, xyz.acmecorp.com, somemachine.acmecorp.com, somemachine.acmecorp.com werden alle auf dieselbe IP-Adresse aufgelöst, und Istio/Envoy muss die Subdomain überprüfen und entscheiden, wohin weitergeleitet werden soll. Im Herbst von SSH ist das aber nicht möglich, Istio sieht nach der Auflösung der IP-Adresse nur die Load Balancer-IP und die Portnummer und baut dann eine TCP-Verbindung auf. Der wahre Inhalt der Pakete wird mit SSH verschlüsselt. Wie können wir auch mehrere verschiedene SSH-Ziele im Cluster weiterleiten?

Option 1: Verwenden Sie eindeutige Ports auf demselben LoadBalancer

Da wir nur eindeutige Kombinationen von IP-Adresse und Ports sicherstellen müssen, können wir einzelnen SSH-Containern einfach verschiedene Ports auf dem Load Balancer zuweisen

Wir können dann konfigurieren TCP-Routen-Port-Übereinstimmung mit Istio

Hier erreichte der gesamte TCP-Verkehr, der Port 22 der Load Balancer, Service A und der gesamte TCP-Verkehr auf Port 23 erreichte Service B.

Das funktioniert zwar gut, aber es gibt ein paar Einschränkungen.

• Maximal 65.535 SSH-Container können hinter einem einzigen Load Balancer erreicht werden. Das ist keine große Sache, da wir realistischerweise nicht erwarten, dass diese vielen SSH-Container gleichzeitig eingesetzt werden.
• Das schwierigere Problem besteht darin, Ports auf dem externen Load Balancer präzise dynamisch zu öffnen und freizugeben, ohne jemals den anderen normalen Verkehr zu stören. Das ist sicherlich möglich, aber jeder Bug oder jede Rennbedingung kann zu schwerwiegenden Ausfällen bei anderen Anwendungen führen. Ganz zu schweigen davon, dass das Öffnen beliebiger Ports für viele unserer Kunden ein großes Sicherheitsrisiko darstellt.

Option 2: Verwenden Sie einen neuen LoadBalancer für jeden SSH-Container

In diesem Fall haben wir abc.acmecorp.com und xyz.acmecorp.com explizit auf zwei verschiedene externe Load Balancer weitergeleitet, anstatt auf den Platzhalter *.acmecorp.com. Jetzt verweisen sie jeweils auf eine eindeutige IP-Adresse und können von zwei verschiedenen weitergeleitet werden Istio-Gateway (eins zu eins verknüpft mit einem externen Load Balancer). Die offensichtliche Einschränkung besteht darin, dass die Bereitstellung eines neuen Load Balancers pro SSH-Container unerschwinglich teuer wird.

Gibt es eine Möglichkeit, Routing auf HTTP-Ebene zu nutzen und trotzdem nur mit TCP-Verkehr zu arbeiten? Gib HTTP CONNECT!

Proxy mit HTTP CONNECT

Das HTTP-VERBINDUNG Die Methode ermöglicht den Aufbau eines Tunnels zwischen zwei Zielen über einen Proxy. Sie stellen die alten Zeiten von Telefonzentralen vor - Sie möchten eine Nummer anrufen, haben aber keine direkte Leitung, um sie zu erreichen, stattdessen stellt ein Operator zwischen der Verbindung in ihrem Namen ein und geht dann aus dem Weg, um die beiden Parteien miteinander zu kommunizieren.

Für eine gute Aussage empfehlen wir das folgende Video: https://www.youtube.com/watch?v=PAJ5kK50qp8

Zum Glück verwenden wir in unserem Fall bereits einen Proxy, der CONNECT - Envoy Proxy verwenden kann. Schauen wir uns an, wie es in unserem Anwendungsfall funktionieren würde:

1. Der Client öffnet eine Verbindung zu acmecorp.com:80 — dem externen Load Balancer, der den Datenverkehr zu Envoy weiterleitet.
2. Der Client sendet eine HTTP CONNECT-Anfrage

VERBINDE svc-a.ns.cluster.svc.local:80 HTTP/1.1
Veranstalter: svc-a.ns.cluster.svc.local

was Envoy anweist, in ihrem Namen eine TCP-Verbindung zu svc-a.ns.cluster.svc.local:80 herzustellen

3. Sobald eine Verbindung hergestellt ist, wird A 200 OK an den Client zurückgegeben.
4. Ab diesem Zeitpunkt kümmert sich der Mitarbeiter nicht mehr um den Verkehrsinhalt und funktioniert als „Tunnel“, da der Verkehr zwischen den Kunden und dem Pod fließen kann. Es kann alles sein, was zusätzlich zu TCP funktioniert, einschließlich, aber nicht beschränkt auf SSH.

Beachten Sie, dass svc-a.ns.cluster.svc.local:80 ein Kubernetes-Dienst ist und nicht auf eine öffentliche IP-Adresse verweist, sondern nur innerhalb des Kubernetes-Clusters aufgelöst werden kann. Da Envoy innerhalb des Clusters lebt, können wir ihn so konfigurieren, dass die Pods zusammenkommen.

Sie müssen Envoy nur noch so konfigurieren, dass es ein solches Routing durchführt. Leider hat Istio keine Abstraktionen auf hoher Ebene, um es einfach zu konfigurieren, stattdessen müssen wir Patches auf die Envoy-Konfiguration anwenden Filter senden

Filter senden

Das Verständnis der Envoy-Funktionen und des Envoy-Filters wird den Rahmen dieser Blogbeiträge bekommen, aber ich betrachte es als einfach wie möglich, die Istio-Routing-Regeln mit Small-Patches zu ändern. Um das Connect-based Routing zu verwenden, müssen wir aktivieren

1. Habe einen öffentlich zugänglichen Port an Load Balancer um TCP-Verkehr zu akzeptieren (zum Beispiel 2222) und das entsprechende zu konfigurieren Istio-Gateway um HTTP-Verkehr zu akzeptieren. Wir haben uns für Port 80 entschieden, weil wir ihn bereits für normalen HTTP-Verkehr verwenden und der SSH-Verkehr sowieso verschlüsselt wird.
2. Konfigurieren Sie den öffentlich zugänglichen Port auf dem Gateway für diese Anfrage, indem Sie den Verbindungstyp akzeptiert haben. Wir haben festgestellt, dass dies bereits für Anfragen an Port 80 aktiviert ist. Für jeden anderen Port können Sie einen Envoy-Filter anwenden, wie folgt:

Aktiviere zum Beispiel CONNECT auf Port 2222apiVersion: networking.istio.io/v1alpha3
Art: EnvoyFilter
spezifikation:
Patches konfigurieren:
- Bewerben Sie sich auf: NETWORK_FILTER
Spiel:
Kontext: GATEWAY
Zuhörer:
Filterkette:
filtern:
Name: envoy.filters.network.http_connection_manager
Portnummer: 2222
Aufnäher:
Bedienung: MERGE
wert:
typ_config:
'@type': ->
Geben Sie sie.googleapis.com/envoy.extensions.filters.network.Http_Connection_Manager.v3.httpConnectionManager
http2_protocol_options:
allow_connect: wahr
upgrade_configs:
- Upgrade-Typ: VERBINDEN
Workload-Selektor:
Beschriftungen:
Anwendung: tfy-istio-ingress


3. Konfigurieren Sie das verbindungsbasierte Routing für jeden SSH-Container:

API-Version: networking.istio.io/v1alpha3
Art: EnvoyFilter
Metadaten:
Name: svc-a-ns-ssh-senvoy-filter
Namespace: istio-system
spezifikation:
Patches konfigurieren:
- Bewerben Sie sich auf: NETWORK_FILTER
Spiel:
Kontext: GATEWAY
Zuhörer:
Filterkette:
filtern:
Name: envoy.filters.network.http_connection_manager
Portnummer: 80
Aufnäher:
Bedienung: MERGE
wert:
typ_config:
'@type': ->
Geben Sie sie.googleapis.com/envoy.extensions.filters.network.Http_Connection_Manager.v3.httpConnectionManager
Route_Config:
Name: local_route
Virtuelle_Hosts:
- Domänen:
- svc-a.ns.svc.cluster.local:80
Name: svc-a-ns-ssh-vh
Strecken:
- Spiel:
connect_matcher: {}
Reiseroute:
Cluster: ->
ausgehend|80||svc-a.ns.svc.cluster.local
upgrade_configs:
- Verbindungskonfiguration: {}
aktiviert: wahr
upgrade_type: VERBINDEN
Workload-Selektor:
Beschriftungen:
Page: tfy-istio-ingress

Das ist ein sehr weiter nach oben gerichtetes YAML, aber alles, was wir tun, ist der Listener auf Port 80 auf dem Gateway zu ändern, dass er mit der CONNECT-Anfrage an svc-a.ns.svc.cluster.local:80 verbunden ist und in outbound|80||svc-a.ns.svc.cluster.local weiterleiten, d. h. den Port 80 des Kubernetes-Dienstes svc-a.ns.ns.ns.svs.svs.svs.svc. c.cluster.local, also wartet unser OpenSSH-Server auf SSH-Verbindungen innerhalb der Container.

CONNECT auf der SSH-Clientseite initiieren

Alleine weiß der SSH-Client nichts über HTTP CONNECT. Stattdessen bietet es eine Proxy-Befehl Option, die es anderen Programmen ermöglicht, die SSH-Verbindung zu erleichtern. Benutze hier die Proxy-Tunnel Projekt, das einfach macht. Die Konfiguration ist ~/.ssh/config sieht wie folgt aus

Gastgeberin svc-a-ns
Benutzer jovyan
Hostname svc-a.ns.svc.cluster.local
Anschluss 80
ServerAlive-Intervall 100
Identitätsdatei ~/.ssh/my-private-key
ProxyCommand proxytunnel -v -p ssh.acmecorp.com:80 -o %h -d %h: %p

Wenn all dies abgeschlossen ist, können Benutzer jetzt einfach eine Verbindung und ihren ausgewählten Entwicklungsworkflow wiederherstellen — seien es Neovim, VS Code, JetBrains IDE usw.

EINSCHRÄNKUNGEN UND MÖGLICHE LÖSUNGEN

Diese Funktion verbessert das Entwicklererlebnis in der Codebearbeitung und -ausführung erheblich, es gelten jedoch immer noch einige Einschränkungen, da wir immer noch in einem Container ausgeführt werden.

• Docker funktioniert nicht, weil wir uns bereits in einem Container befinden. Theoretisch ist es möglich, ein paar Dinge zum Laufen zu bringen FINDEN, aber es bringt seine Herausforderungen mit sich.
• Änderungen am Root-Datensystem der Container / sind bei Container-Neustarts nicht persistent. Wir bieten eine Möglichkeit, unser SSH-Server-Image zu erweitern und mit diesen User-Images zu beginnen.
• Kubernetes-Pods sollen kurzlebig sein und können verschoben werden, aber das ist für eine Entwicklungsumgebung unerwünscht. Wir konfigurieren Budgets für Pod-Pausen, um zu verhindern, dass der Pod verloren geht.
• Obgleich das Proxying transparent ist, fließt der Traffic immer noch durch den Load Balancer und die Istio Envoy-Pods. Das bedeutet, dass etwas Seltsames während der Entwicklung, wie das Hochladen/Herunterladen riesiger Dateien, Bandbreite und Ressourcen verbrauchen und den anderen Datenverkehr beeinträchtigen kann. Sie verwenden am besten einen separaten Satz von LoadBalancer-, Gateway- und Envoy-Pods für die Verbindung zu SSH-Containern.

SSH-Servercontainer auf Kubernetes bei TrueFoundry

Wahre Giesserei ist eine ML/LLM-Implementierung PaaS über Kubernetes, um den Arbeitsablauf des Entwicklers zu ermöglichen. Sie ermöglicht die volle Flexibilität beim Testen und Bereitstellen von Modellen und während der vollen Sicherheit und Kontrolle für das Infra-Team. Apropos unsere Plattform, wir Teams bereitstellen und überwachen Modelle innerhalb von 15 Minuten mit 100% iger Zuverlässigkeit, Skalierbarkeit und dem Möglichen, kehren innerhalb von weniger Sekunden zurück. So lassen sich Kosten sparen und Modelle schneller für die Produktion freigeben, wodurch ein echter Geschäftswert erzielt wird.