Freigeben über

Funktionsweise von Bridge to Kubernetes

  • Artikel

Hinweis

Microsoft plant, die Brücke zum Kubernetes-Projekt nicht mehr aktiv aufrechtzuerhalten. In den nächsten Monaten werden wir das Projekt in einen Archivierungszustand umstellen. In der Zwischenzeit steht das Projekt weiterhin zum Verwenden und Herunterladen zur Verfügung. In diesem Zeitraum hoffen wir, Community-Projekte zu erkunden und zu empfehlen, die ähnliche Vorteile wie Bridge to Kubernetes für Ihre zukünftige Nutzung bieten. Wenn Sie Fragen haben, wenden Sie sich bitte an uns in unserem Issues-Board auf GitHub.

Bridge to Kubernetes ist ein iteratives Entwicklungstool zum Erstellen von Microserviceanwendungen für Kubernetes. Die Bridge to Kubernetes-Erweiterung ist für Visual Studio und Visual Studio Code (VS Code) verfügbar.

Mit Bridge to Kubernetes können Sie Code auf Ihrem Entwicklungscomputer ausführen und debuggen. Dieser Computer ist weiterhin zusammen mit Ihren übrigen Anwendungen oder Diensten mit dem Kubernetes-Cluster verbunden. Wenn Sie über eine große Microservicearchitektur mit vielen voneinander abhängigen Diensten und Datenbanken verfügen, kann es schwierig sein, diese Abhängigkeiten auf Ihrem Entwicklungscomputer zu replizieren. Das Erstellen und Bereitstellen von Code für jede Codeänderung in Ihrem Kubernetes-Cluster kann langsam, zeitaufwändig und schwierig sein.

Bridge to Kubernetes erstellt eine Verbindung zwischen Ihrem Entwicklungscomputer und Ihrem Cluster. Dieser Ansatz vermeidet, dass Sie Ihren Code in Ihrem Cluster erstellen und bereitstellen müssen. Sie können Ihren Dienst im Kontext testen und entwickeln, verbunden mit Ihrem Cluster. Mit diesem Ansatz können Sie debuggen, ohne eine weitere Docker- oder Kubernetes-Konfiguration zu erstellen.

Wenn Sie Bridge to Kubernetes verwenden, wird der Datenverkehr zwischen Ihrem verbundenen Kubernetes-Cluster und Ihrem Entwicklungscomputer umgeleitet. Lokaler Code und Dienste in Ihrem Kubernetes-Cluster können so kommunizieren, als ob sie sich im selben Kubernetes-Cluster befänden.

Mit Bridge to Kubernetes können Sie Umgebungsvariablen und eingebundene Volumes in Ihrem Kubernetes-Cluster auf Ihrem Entwicklungscomputer replizieren. Mit dem Zugriff auf Umgebungsvariablen und eingebundene Volumes können Sie an Ihrem Code arbeiten, ohne diese Abhängigkeiten replizieren zu müssen.

Anforderungen

Hinweis

Bridge to Kubernetes ist nicht mit Docker for Desktop-Kubernetes-Clustern kompatibel. Um Bridge to Kubernetes verwenden zu können, benötigen Sie eine der folgenden Konfigurationen:

Sie können mit Bridge to Kubernetes eine Verbindung mit Ihrem Kubernetes-Cluster herstellen. Diese Verbindung leitet Datenverkehr zu und von einem vorhandenen Pod im Cluster an Ihren Entwicklungscomputer um.

Hinweis

Wenn Sie Bridge to Kubernetes verwenden, werden Sie aufgefordert, den Namen des Diensts einzugeben, der auf Ihren Entwicklungscomputer umgeleitet werden soll. Diese Option ist eine bequeme Möglichkeit, einen Pod für die Umleitung zu identifizieren. Alle Umleitungen zwischen Ihrem Kubernetes-Cluster und dem Entwicklungscomputer sind für einen Pod vorgesehen. Weitere Informationen finden Sie unter Verfügbarmachen eines Diensts.

In VS Code unterstützt Bridge to Kubernetes alle Sprachen, sofern sie lokal ausgeführt werden können. In Visual Studio unterstützt Bridge to Kubernetes .NET Core. Bridge to Kubernetes unterstützt .NET Framework in Visual Studio nicht, da dies die Unterstützung von Windows-Knoten erfordert.

Achtung

Bridge to Kubernetes ist nur für die Verwendung in Entwicklungs- und Testszenarios vorgesehen. Er ist nicht für den Einsatz in Produktionsclustern oder Livediensten konzipiert und wird dort nicht unterstützt.

Aktuelle Features und zukünftige Pläne finden Sie in der Bridge to Kubernetes Roadmap.

Herstellen einer Verbindung

Wenn Bridge to Kubernetes eine Verbindung mit Ihrem Cluster herstellt, werden folgende Aktionen ausgeführt:

  • Fordert Sie auf, den auf Ihrem Cluster zu ersetzenden Dienst, den für Ihren Code zu verwendenden Port auf Ihrem Entwicklungscomputer und die Startaufgabe für Ihren Code als einmalige Aktion zu konfigurieren.
  • Der Container im Pod im Cluster wird durch einen Remote-Agent-Container ersetzt, der Datenverkehr an Ihren Entwicklungscomputer umleitet.
  • kubectl port-forward wird auf dem Entwicklungscomputer ausgeführt, um Datenverkehr vom Entwicklungscomputer an den Remote-Agent weiterzuleiten, der im Cluster ausgeführt wird.
  • Es werden Umgebungsinformationen von Ihrem Cluster mithilfe des Remote-Agents erfasst. Zu diesen Umgebungsinformationen zählen Umgebungsvariablen, sichtbare Dienste, Volumeeinbindungen und Geheimniseinbindungen.
  • Richten Sie die Umgebung in Visual Studio so ein, dass der Dienst auf Ihrem Entwicklungscomputer auf dieselben Variablen zugreifen kann, wie wenn er auf dem Cluster ausgeführt werden würde.
  • Ihre hosts-Datei wird aktualisiert, um Dienste auf Ihrem Cluster lokalen IP-Adressen auf Ihrem Entwicklungscomputer zuzuordnen. Diese Einträge in der hosts-Datei ermöglichen, dass auf dem Entwicklungscomputer ausgeführter Code Anforderungen an andere Dienste senden kann, die in Ihrem Cluster ausgeführt werden. Zum Aktualisieren der hosts-Datei benötigt Bridge to Kubernetes auf Ihrem Entwicklungscomputer Administratorzugriff.
  • Startet die Ausführung und das Debuggen Ihres Codes auf Ihrem Entwicklungscomputer. Bei Bedarf gibt Bridge to Kubernetes erforderliche Ports auf Ihrem Entwicklungscomputer frei, indem Dienste oder Prozesse beendet werden, die diese Ports derzeit verwenden.

Verwenden von Bridge to Kubernetes

Nachdem Sie eine Verbindung mit Ihrem Cluster hergestellt haben, führen Sie Code nativ auf Ihrem Computer aus und debuggen ihn nativ, ohne Containerisierung. Der Code interagiert mit Ihrem Cluster. Jeglicher Netzwerkdatenverkehr, den der Remote-Agent empfängt, wird an den lokalen Port umgeleitet, der während der Verbindung angegeben wird. Ihr nativ ausgeführter Code kann diesen Datenverkehr akzeptieren und verarbeiten. Die Umgebungsvariablen, Volumes und Geheimnisse aus dem Cluster werden für Code zur Verfügung gestellt, der auf dem Entwicklungscomputer ausgeführt wird.

Bridge to Kubernetes hostet Dateieinträge und Portweiterleitung zu Ihrem Entwicklercomputer. Ihr Code kann Netzwerkdatenverkehr mithilfe der Dienstnamen aus Ihrem Cluster an Dienste senden, die in Ihrem Cluster ausgeführt werden. Dieser Datenverkehr wird an die Dienste weitergeleitet, die in Ihrem Cluster ausgeführt werden. Der Datenverkehr wird zwischen dem Entwicklungscomputer und Ihrem Cluster weitergeleitet, solange die Verbindung besteht.

Darüber hinaus bietet Bridge to Kubernetes eine Möglichkeit, Umgebungsvariablen und eingebundene Dateien, die für Pods in Ihrem Cluster auf Ihrem Entwicklungscomputer verfügbar sind, mithilfe der Datei KubernetesLocalProcessConfig.yaml zu replizieren. Sie können diese Datei auch verwenden, um neue Umgebungsvariablen und Volumeeinbindungen zu erstellen.

Hinweis

Für die Dauer der Verbindung mit dem Cluster plus 15 Minuten führt Bridge to Kubernetes auf Ihrem lokalen Computer einen Prozess namens EndpointManager mit Administratorrechten aus.

Sie können parallel mit mehreren Diensten debuggen. Starten Sie so viele Instanzen von Visual Studio wie Dienste, die Sie debuggen möchten. Stellen Sie sicher, dass Ihre Dienste lokal an verschiedenen Ports lauschen. Konfigurieren und debuggen Sie sie separat. Eine Isolation wird in diesem Szenario nicht unterstützt.

Zusätzliche Konfiguration

Mit der Datei KubernetesLocalProcessConfig.yaml können Sie Umgebungsvariablen und eingebundene Dateien replizieren, die für Pods in Ihrem Cluster verfügbar sind. Wenn Sie Visual Studio verwenden, muss sich die Datei KubernetesLocalConfig.yaml im selbern Verzeichnis wie die Projektdatei für den Dienst befinden. Weitere Informationen hierzu finden Sie im Abschnitt zur Konfiguration von Bridge to Kubernetes.

Verwenden von Routingfunktionen für die isolierte Entwicklung

Bridge to Kubernetes leitet den gesamten Datenverkehr für einen Dienst standardmäßig an Ihren Entwicklungscomputer um. Stattdessen können Sie Routingfunktionen verwenden, um nur Anforderungen von einer Unterdomäne an Ihren Entwicklungscomputer umzuleiten. Mithilfe dieser Routingfunktionen können Sie Bridge to Kubernetes verwenden, um Ihre Entwicklung isoliert durchzuführen und Unterbrechungen des anderen Datenverkehrs in Ihrem Cluster zu vermeiden.

In der folgenden Animation werden zwei Entwickler veranschaulicht, die isoliert auf demselben Cluster arbeiten:

Die Animation zeigt Isolation, bei der zwei Entwickler mit demselben Cluster arbeiten.

Wenn Sie die isolierte Entwicklung ermöglichen, führt Bridge to Kubernetes zusätzlich zum Herstellen einer Verbindung mit Ihrem Kubernetes-Cluster folgende Aktionen durch:

  • Es wird überprüft, ob Azure Dev Spaces nicht für den Kubernetes-Cluster aktiviert ist.
  • Repliziert Ihren ausgewählten Dienst im Cluster in demselben Namespace und fügt die Bezeichnung routing.visualstudio.io/route-from=SERVICE_NAME und die Anmerkung routing.visualstudio.io/route-on-header=kubernetes-route-as=GENERATED_NAME hinzu.
  • Er konfiguriert und startet den Routing-Manager im gleichen Namespace auf dem Kubernetes-Cluster. Der Routing-Manager verwendet eine Bezeichnungsauswahl, um bei der Routingkonfiguration in Ihrem Namespace nach der Bezeichnung routing.visualstudio.io/route-from=SERVICE_NAME und der Anmerkung routing.visualstudio.io/route-on-header=kubernetes-route-as=GENERATED_NAME zu suchen.

Hinweis

Bridge to Kubernetes überprüft, ob Azure Dev Spaces in Ihrem Kubernetes-Cluster aktiviert ist. Sie werden aufgefordert, Azure Dev Spaces zu deaktivieren, bevor Sie Bridge to Kubernetes verwenden können.

Der Routing-Manager führt folgende Aktionen durch, wenn er gestartet wird:

  • Er dupliziert alle im Namespace gefundenen eingehenden Daten einschließlich der beim Lastenausgleich mit GENERATED_NAME als Unterdomäne.
  • Er erstellt einen Envoy-Pod für jeden Dienst, der einem duplizierten Eingang mit der Unterdomäne GENERATED_NAME zugeordnet ist.
  • Er erstellt einen anderen Envoy-Pod für den Dienst, an dem Sie isoliert arbeiten. Diese Konfiguration ermöglicht das Weiterleiten von Anforderungen mit der Unterdomäne an Ihren Entwicklungscomputer.
  • Er konfiguriert Routingregeln für jeden Envoy-Pod, um das Routing für Dienste mit der Unterdomäne zu verarbeiten.

Im folgenden Diagramm wird ein Kubernetes-Cluster veranschaulicht, bevor Bridge to Kubernetes eine Verbindung mit Ihrem Cluster herstellt:

Diagramm eines Clusters ohne Bridge to Kubernetes.

Im folgenden Diagramm wird derselbe Cluster mit Bridge to Kubernetes im Isolationsmodus veranschaulicht. Hier sehen Sie den duplizierten Dienst und die Envoy-Pods, die das Routing in der Isolation unterstützen.

Diagramm eines Clusters mit aktiviertem Bridge to Kubernetes.

Wenn der Cluster eine Anforderung mit der Unterdomäne GENERATED_NAME empfängt, fügt er der Anforderung den Header kubernetes-route-as=GENERATED_NAME hinzu. Die Envoy-Pods verarbeiten das Routing der Anforderung an den entsprechenden Dienst im Cluster. Eine Anforderung an den Dienst, die isoliert bearbeitet wird, leitet der Cluster über den Remote-Agent an Ihren Entwicklungscomputer um.

Wenn der Cluster eine Anforderung ohne die Unterdomäne GENERATED_NAME empfängt, wird der Anforderung kein Header hinzugefügt. Die Envoy-Pods verarbeiten das Routing der Anforderung an den entsprechenden Dienst im Cluster. Die Pods leiten eine Anforderung für den Dienst, der ersetzt wird, an den ursprünglichen Dienst und nicht an den Remote-Agent weiter.

Wichtig

Jeder Dienst auf Ihrem Cluster muss den Header kubernetes-route-as=GENERATED_NAME weiterleiten, wenn zusätzliche Anforderungen gestellt werden. Wenn serviceA beispielsweise eine Anforderung empfängt, wird eine Anforderung an serviceB gestellt, bevor eine Antwort zurückgegeben wird. In diesem Beispiel muss serviceA den Header kubernetes-route-as=GENERATED_NAME in der Anforderung an serviceB weiterleiten. Einige Sprachen, z. B. ASP.NET, verfügen möglicherweise über Methoden zum Verarbeiten der Headerweitergabe.

Wenn Sie die Verbindung mit Ihrem Cluster trennen, entfernt Bridge to Kubernetes standardmäßig alle Envoy-Pods und den duplizierten Dienst.

Hinweis

Die Bereitstellung des Routing-Managers und der Dienst werden weiterhin in Ihrem Namespace ausgeführt. Führen Sie die folgenden Befehle für Ihren Namespace aus, um die Bereitstellung und den Dienst zu entfernen.

kubectl delete deployment routingmanager-deployment -n NAMESPACE
kubectl delete service routingmanager-service -n NAMESPACE

Diagnose und Protokollierung

Wenn Sie mit Bridge to Kubernetes eine Verbindung mit Ihrem Cluster herstellen, protokolliert Ihr Computer die Diagnose. Er speichert sie im TEMP-Verzeichnis Ihres Entwicklungscomputers im Ordner Bridge to Kubernetes.

Kubernetes RBAC-Autorisierung

Kubernetes bietet rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) zum Verwalten von Berechtigungen für Benutzer und Gruppen. Weitere Informationen finden Sie in der Kubernetes-Dokumentation. Sie können die Berechtigungen für einen Cluster mit RBAC-Unterstützung festlegen, indem Sie eine YAML-Datei erstellen und kubectl verwenden, um sie auf den Cluster anzuwenden.

Um Berechtigungen für den Cluster festzulegen, erstellen oder ändern Sie eine YAML-Datei wie permissions.yml. Verwenden Sie Ihren Namespace für <namespace> und die Benutzer und Gruppen, die Zugriff benötigen.

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: bridgetokubernetes-<namespace>
  namespace: development
subjects:
  - kind: User
    name: jane.w6wn8.k8s.ginger.eu-central-1.aws.gigantic.io
    apiGroup: rbac.authorization.k8s.io
  - kind: Group
    name: dev-admin
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: admin
  apiGroup: rbac.authorization.k8s.io

Wenden Sie die Berechtigungen mithilfe des folgenden Befehls an:

kubectl -n <namespace> apply -f <yaml file name>

Einschränkungen

Bridge to Kubernetes unterliegt den folgenden Einschränkungen:

  • In einem Pod darf nur ein einzelner Container ausgeführt werden, damit Bridge to Kubernetes erfolgreich eine Verbindung herstellen kann.
  • Derzeit müssen Bridge to Kubernetes-Pods Linux-Container sein. Windows-Container werden nicht unterstützt.
  • Bridge to Kubernetes benötigt erhöhte Rechte, damit die Erweiterung auf Ihrem Entwicklungscomputer ausgeführt werden kann, um Ihre Hostdatei zu bearbeiten.
  • Bridge to Kubernetes kann nicht auf Clustern verwendet werden, auf denen Azure Dev Spaces aktiviert ist.

Nächste Schritte

Informationen zu den ersten Schritten bei der Verwendung von Bridge to Kubernetes zum Herstellen einer Verbindung zwischen Ihrem lokalen Entwicklungscomputer und Ihrem Cluster finden Sie unter Verwenden von Bridge to Kubernetes (VS) oder unter Verwenden von Bridge to Kubernetes (VS Code).