Jak działa rozwiązanie Bridge to Kubernetes

Notatka

Firma Microsoft planuje już nie obsługiwać projektu Bridge to Kubernetes. W ciągu najbliższych kilku miesięcy przeniesiemy projekt do stanu archiwalnego. W międzyczasie projekt jest nadal dostępny do korzystania oraz pobrania. W tym okresie mamy nadzieję zapoznać się z projektami społeczności, które zapewniają podobne korzyści do „Bridge to Kubernetes” dla przyszłych zastosowań. Jeśli masz pytania, skontaktuj się z nami na tablicy problemów w witrynie GitHub.

Bridge to Kubernetes to iteracyjne narzędzie programistyczne do tworzenia aplikacji mikrousług przeznaczonych dla platformy Kubernetes. Rozszerzenie Bridge to Kubernetes jest dostępne dla programów Visual Studio i Visual Studio Code (VS Code).

Rozwiązanie Bridge to Kubernetes umożliwia uruchamianie i debugowanie kodu na komputerze deweloperskim. Ten komputer jest nadal połączony z klastrem Kubernetes z pozostałą częścią aplikacji lub usług. Jeśli masz dużą architekturę mikrousług z wieloma usługami i bazami danych, replikowanie tych zależności na komputerze deweloperów może być trudne. Kompilowanie i wdrażanie kodu w klastrze Kubernetes dla każdej zmiany kodu może być powolne, czasochłonne i trudne.

Rozwiązanie Bridge to Kubernetes tworzy połączenie między komputerem deweloperskim a klastrem. Takie podejście pozwala uniknąć konieczności kompilowania i wdrażania kodu w klastrze. Usługę można przetestować i opracować w kontekście połączonym z klastrem. Takie podejście umożliwia debugowanie bez tworzenia konfiguracji platformy Docker lub Kubernetes.

Mostek do platformy Kubernetes przekierowuje ruch między połączonym klastrem Kubernetes a komputerem deweloperskim. Lokalny kod i usługi w klastrze Kubernetes mogą komunikować się tak, jakby były w tym samym klastrze Kubernetes.

Rozwiązanie Bridge to Kubernetes umożliwia replikowanie zmiennych środowiskowych i zainstalowanych woluminów w klastrze Kubernetes na komputer deweloperski. Dostęp do zmiennych środowiskowych i zainstalowanych woluminów umożliwia pracę nad kodem bez konieczności replikowania tych zależności.

Wymagania

Notatka

Rozwiązanie Bridge to Kubernetes nie działa z klastrami Platformy Docker for Desktop Kubernetes. Aby użyć narzędzia Bridge to Kubernetes, potrzebujesz jednej z następujących konfiguracji:

• Program VS Code z zainstalowanym rozszerzeniem Bridge to Kubernetes.
• programu Visual Studio 2019 w wersji 16.7 lub nowszej z systemem Windows 10 lub nowszym. Upewnij się, że zainstalowano zestaw narzędzi ASP.NET i do tworzenia aplikacji internetowych. Zainstaluj Bridge to Kubernetes Extension.

Aby nawiązać połączenie z klastrem Kubernetes, możesz użyć narzędzia Bridge to Kubernetes. To połączenie przekierowuje ruch między istniejącym podem w klastrze a Twoim komputerem programistycznym.

Notatka

W przypadku korzystania z rozwiązania Bridge to Kubernetes zostanie wyświetlony monit o podanie nazwy usługi w celu przekierowania do komputera deweloperskiego. Ta opcja jest wygodnym sposobem identyfikowania poda na potrzeby przekierowania. Wszystkie przekierowania między klastrem Kubernetes a komputerem do pracy deweloperskiej dotyczą zasobnika. Aby uzyskać więcej informacji, zobacz Udostępnienie usługi.

W programie VS Code mostek do platformy Kubernetes obsługuje wszystkie języki, o ile można je uruchamiać lokalnie. W programie Visual Studio platforma Bridge to Kubernetes obsługuje platformę .NET Core. Rozwiązanie Bridge to Kubernetes nie obsługuje programu .NET Framework w programie Visual Studio, ponieważ wymaga obsługi węzłów systemu Windows.

Ostrożność

Rozwiązanie Bridge to Kubernetes jest przeznaczone tylko do użycia w scenariuszach programowania i testowania. Nie jest ona przeznaczona ani obsługiwana do użytku z klastrami produkcyjnymi ani usługami na żywo w aktywnym użyciu.

Aby zapoznać się z bieżącymi funkcjami i przyszłymi planami, zobacz harmonogram Bridge to Kubernetes.

Nawiązywanie połączenia

Gdy platforma Bridge to Kubernetes nawiązuje połączenie z klastrem, wykonuje następujące akcje:

• Prosi cię o skonfigurowanie usługi, aby zastąpić w klastrze port na komputerze dewelopera do użycia przez kod oraz jednorazowo skonfigurować zadanie uruchamiania kodu.
• Zastępuje kontener w zasobniku w klastrze kontenerem agenta zdalnego, który przekierowuje ruch do komputera deweloperskiego.
• Uruchom na komputerze deweloperskim polecenie #"kubectl port-forward" , aby przekazać ruch z komputera deweloperskiego do agenta zdalnego uruchomionego w klastrze.
• Zbiera informacje o środowisku z klastra przy użyciu agenta zdalnego. Informacje o tym środowisku obejmują zmienne środowiskowe, widoczne usługi, zamontowane woluminy oraz zamontowane sekrety.
• Konfiguruje środowisko w programie Visual Studio, aby usługa na komputerze dewelopera mogła uzyskiwać dostęp do tych samych zmiennych, co w przypadku, gdy była uruchomiona w klastrze.
• Aktualizuje hosty , aby mapować usługi w klastrze na lokalne adresy IP na komputerze dewelopera. Te hosty wpisy plików pozwalają kodowi uruchomionemu na komputerze deweloperskim wysyłać żądania do innych usług działających w klastrze. Aby zaktualizować hosty pliku, narzędzie Bridge to Kubernetes wymaga dostępu administratora na komputerze deweloperskim.
• Rozpoczyna uruchamianie i debugowanie kodu na komputerze dewelopera. W razie potrzeby Bridge to Kubernetes zwalnia wymagane porty na komputerze deweloperskim, zatrzymując usługi i procesy, które obecnie korzystają z tych portów.

Korzystanie z rozwiązania Bridge to Kubernetes

Po nawiązaniu połączenia z klastrem uruchom i debuguj kod natywnie na komputerze bez konteneryzacji. Kod współdziała z klastrem. Dowolny ruch sieciowy odbierany przez agenta zdalnego jest przekierowywany do portu lokalnego określonego podczas połączenia. Natywnie uruchomiony kod może akceptować i przetwarzać ten ruch. Zmienne środowiskowe, woluminy i wpisy tajne z klastra są udostępniane kodowi uruchomionemu na komputerze do tworzenia oprogramowania.

Rozwiązanie Bridge to Kubernetes dodaje wpisy plików hostów oraz przekazywanie portów do komputera deweloperskiego. Kod może wysyłać ruch sieciowy do usług uruchomionych w klastrze przy użyciu nazw usług z klastra. Ten ruch jest przekazywany do usług uruchomionych w klastrze. Ruch jest kierowany między twoim komputerem deweloperskim a klastrem przez cały czas, gdy jesteś podłączony.

Ponadto rozwiązanie Bridge to Kubernetes umożliwia replikowanie zmiennych środowiskowych i zamontowanych plików, które są dostępne dla podów w klastrze, na komputerze deweloperskim za pośrednictwem pliku KubernetesLocalProcessConfig.yaml. Możesz również użyć tego pliku do utworzenia nowych zmiennych środowiskowych i montowań woluminów.

Notatka

Przez czas trwania połączenia z klastrem oraz dodatkowe 15 minut, Bridge to Kubernetes uruchamia proces o nazwie EndpointManager z uprawnieniami administratora na komputerze lokalnym.

Możesz debugować równolegle z wieloma usługami. Uruchom dowolną liczbę wystąpień programu Visual Studio jako usług, które chcesz debugować. Upewnij się, że usługi nasłuchują lokalnie na różnych portach. Skonfiguruj je i debuguj oddzielnie. W tym scenariuszu izolacja nie jest wspierana.

Dodatkowa konfiguracja

Plik KubernetesLocalProcessConfig.yaml pozwala na replikację zmiennych środowiskowych i zamontowanych plików dostępnych dla podów w twoim klastrze. W przypadku korzystania z programu Visual Studio plik KubernetesLocalConfig.yaml musi znajdować się w tym samym katalogu co plik projektu dla usługi. Aby uzyskać więcej informacji, zobacz Configure Bridge to Kubernetes.

Korzystanie z funkcji routingu do opracowywania w izolacji

Domyślnie Bridge to Kubernetes przekierowuje cały ruch dla usługi do komputera dewelopera. Zamiast tego możesz użyć funkcji routingu, aby przekierowywać żądania tylko z poddomeny do komputera dewelopera. Te możliwości routingu umożliwiają korzystanie z mostka do platformy Kubernetes w celu opracowywania w izolacji i unikania zakłócania innego ruchu w klastrze.

Poniższa animacja przedstawia dwóch deweloperów pracujących nad tym samym klastrem w izolacji:

Po włączeniu pracy w izolacji narzędzie Bridge to Kubernetes wykonuje następujące akcje oprócz nawiązywania połączenia z klastrem Kubernetes:

• Sprawdza, czy klaster Kubernetes nie ma włączonej usługi Azure Dev Spaces.
• Replikuje wybraną usługę w klastrze w tej samej przestrzeni nazw i dodaje etykietę routing.visualstudio.io/route-from=SERVICE_NAME oraz adnotację routing.visualstudio.io/route-on-header=kubernetes-route-as=GENERATED_NAME.
• Konfiguruje i uruchamia menedżera routingu w tej samej przestrzeni nazw w klastrze Kubernetes. Menedżer routingu używa selektora etykiet do wyszukiwania etykiety routing.visualstudio.io/route-from=SERVICE_NAME i adnotacji routing.visualstudio.io/route-on-header=kubernetes-route-as=GENERATED_NAME podczas konfigurowania routingu w przestrzeni nazw.

Notatka

Rozwiązanie Bridge to Kubernetes sprawdza, czy usługa Azure Dev Spaces jest włączona w klastrze Kubernetes. Zostaniesz poproszony o wyłączenie Azure Dev Spaces przed użyciem Bridge to Kubernetes.

Menedżer routingu wykonuje następujące akcje podczas uruchamiania:

• Duplikuje wszystkie wejścia, w tym ruch przychodzący modułu równoważenia obciążenia, znajdujące się w przestrzeni nazw przy użyciu GENERATED_NAME dla poddomeny.
• Tworzy pod wysłannika dla każdej usługi skojarzonej ze zduplikowanymi ingressami z poddomeną GENERATED_NAME.
• Tworzy kolejny pod wysłannika dla usługi, nad którą pracujesz. Ta konfiguracja umożliwia kierowanie żądań z poddomeną do komputera dewelopera.
• Konfiguruje reguły routingu dla każdego „pod” Envoy do obsługi routingu dla usług z poddomeną.

Na poniższym diagramie przedstawiono klaster Kubernetes, zanim Bridge to Kubernetes połączy się z twoim klastrem.

Na poniższym diagramie przedstawiono ten sam klaster z włączonym rozwiązaniem Bridge to Kubernetes w trybie izolacji. W tym miejscu można zobaczyć usługę duplikat i zasobniki wysłanników, które obsługują izolowane trasowanie.

Gdy klaster odbiera żądanie z poddomeną GENERATED_NAME, dodaje do żądania nagłówek kubernetes-route-as=GENERATED_NAME. Zasobniki Envoy obsługują przekierowywanie żądań do odpowiedniej usługi w ramach klastra. W przypadku żądania do usługi, nad którą pracuje się w izolacji, klaster przekierowuje to żądanie na komputer dewelopera przez agenta zdalnego.

Gdy klaster odbiera żądanie bez poddomeny GENERATED_NAME, nie dodaje nagłówka do żądania. Kapsuły Envoy obsługują trasowanie żądania do odpowiedniej usługi w klastrze. W przypadku żądania dotyczącego usługi, która jest zastępowana, pody kierują ją do oryginalnej usługi zamiast agenta zdalnego.

Ważny

Każda usługa w klastrze musi przesyłać dalej nagłówek kubernetes-route-as=GENERATED_NAME podczas wykonywania dodatkowych żądań. Na przykład gdy serviceA odbiera żądanie, następnie wysyła żądanie serviceB przed zwróceniem odpowiedzi. W tym przykładzie serviceA musi przekazać nagłówek kubernetes-route-as=GENERATED_NAME w swoim żądaniu do serviceB. Niektóre języki, takie jak ASP.NET, mogą mieć metody obsługi propagacji nagłówka.

Gdy odłączysz się od klastra, domyślnie narzędzie Bridge to Kubernetes usunie wszystkie pody Envoy i zduplikowaną usługę.

Notatka

Wdrożenie i usługa menedżera routingu pozostają uruchomione w przestrzeni nazw. Aby usunąć wdrożenie i usługę, uruchom następujące polecenia dla swojej przestrzeni nazw.

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

Diagnostyka i rejestrowanie

W przypadku nawiązywania połączenia z klastrem przy użyciu narzędzia Bridge to Kubernetes komputer rejestruje diagnostykę. Przechowuje je w katalogu TEMP komputera deweloperskiego w folderze Bridge to Kubernetes.

Autoryzacja RBAC na platformie Kubernetes

Platforma Kubernetes zapewnia kontrolę dostępu opartą na rolach (RBAC) do zarządzania uprawnieniami dla użytkowników i grup. Aby uzyskać więcej informacji, zobacz dokumentację platformy Kubernetes. Uprawnienia dla klastra z włączoną kontrolą dostępu opartej na rolach można ustawić, tworząc plik YAML i używając kubectl, aby zastosować go do klastra.

Aby ustawić uprawnienia w klastrze, utwórz lub zmodyfikuj plik YAML, taki jak permissions.yml. Użyj przestrzeni nazw dla <namespace> oraz dla użytkowników i grup, które potrzebują dostępu.

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

Zastosuj uprawnienia przy użyciu następującego polecenia:

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

Ograniczenia

Rozwiązanie Bridge to Kubernetes ma następujące ograniczenia:

• Zasobnik może mieć uruchomiony tylko jeden kontener w tym zasobniku, aby pomyślnie nawiązać połączenie z rozwiązaniem Bridge to Kubernetes.
• Obecnie zasobniki Bridge to Kubernetes muszą być kontenerami systemu Linux. Kontenery systemu Windows nie są obsługiwane.
• Rozwiązanie Bridge to Kubernetes wymaga podwyższonych uprawnień do uruchamiania na komputerze deweloperskim w celu edytowania pliku hostów.
• Nie można używać mostka do platformy Kubernetes w klastrach z włączoną usługą Azure Dev Spaces.

Następne kroki

Aby rozpocząć korzystanie z Bridge do Kubernetes do nawiązania połączenia z lokalnym komputerem deweloperskim z klastrem, zobacz Use Bridge to Kubernetes (VS) lub Use Bridge to Kubernetes (VS Code).