Jak działa Mostek na platformę Kubernetes

Uwaga

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 użycia i pobrania. W tym okresie mamy nadzieję zapoznać się z projektami społeczności, które zapewniają podobne korzyści, jak bridge to Kubernetes w przyszłości. Jeśli masz pytania, skontaktuj się z nami na tablicy problemów w witrynie GitHub.

Mostek do platformy 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

Uwaga

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.
• Program Visual Studio 2019 w wersji 16.7 lub nowszej działa w systemie Windows 10 lub nowszym. Upewnij się, że zainstalowano obciążenie ASP.NET i tworzenie aplikacji internetowych. Zainstaluj rozszerzenie Bridge to Kubernetes.

Aby nawiązać połączenie z klastrem Kubernetes, możesz użyć narzędzia Bridge to Kubernetes. To połączenie przekierowuje ruch do i z istniejącego zasobnika w klastrze do komputera programistycznego.

Uwaga

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 zasobnika na potrzeby przekierowania. Wszystkie przekierowania między klastrem Kubernetes a komputerem deweloperskim są przeznaczone dla zasobnika. Aby uzyskać więcej informacji, zobacz Udostępnianie 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.

Uwaga

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 plan mostu na platformę Kubernetes.

Nawiązywanie połączenia

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

• Monituje o skonfigurowanie usługi w celu zastąpienia w klastrze, portu na komputerze dewelopera do użycia w kodzie oraz zadania uruchamiania kodu jako jednorazowej akcji.
• Zastępuje kontener w zasobniku w klastrze kontenerem agenta zdalnego, który przekierowuje ruch do komputera deweloperskiego.
• Uruchamia polecenie kubectl port-forward na komputerze dewelopera, aby przekazać ruch z komputera deweloperskiego do agenta zdalnego uruchomionego w klastrze.
• Zbiera informacje o środowisku z klastra przy użyciu agenta zdalnego. Te informacje o środowisku obejmują zmienne środowiskowe, widoczne usługi, instalowanie woluminów i instalowanie wpisów tajnych.
• 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 plik hostów w celu mapowania usług w klastrze na lokalne adresy IP na komputerze dewelopera. Te wpisy plików hostów umożliwiają uruchamianie kodu na komputerze dewelopera w celu wysłania żądań do innych usług uruchomionych w klastrze. Aby zaktualizować plik hostów , rozwiązanie Bridge to Kubernetes wymaga dostępu administratora na komputerze deweloperskim.
• Rozpoczyna uruchamianie i debugowanie kodu na komputerze dewelopera. W razie potrzeby mostek do platformy Kubernetes zwalnia wymagane porty na komputerze deweloperskim, zatrzymując usługi lub 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 do kodu uruchomionego na komputerze dewelopera.

Mostek do platformy Kubernetes dodaje wpisy plików hostów i 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 komputerem dewelopera a klastrem przez cały czas, w którym masz połączenie.

Ponadto rozwiązanie Bridge to Kubernetes umożliwia replikowanie zmiennych środowiskowych i zainstalowanych plików dostępnych dla zasobników w klastrze na komputerze deweloperskim KubernetesLocalProcessConfig.yaml za pośrednictwem pliku . Możesz również użyć tego pliku do utworzenia nowych zmiennych środowiskowych i instalacji woluminów.

Uwaga

Przez czas trwania połączenia z klastrem oraz 15 minut mostek do platformy 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. Izolacja nie jest obsługiwana w tym scenariuszu.

Dodatkowa konfiguracja

Plik KubernetesLocalProcessConfig.yaml umożliwia replikowanie zmiennych środowiskowych i zainstalowanych plików dostępnych dla zasobników w 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 Konfigurowanie mostka na platformie Kubernetes.

Korzystanie z funkcji routingu do opracowywania w izolacji

Domyślnie platforma Bridge to Kubernetes przekierowuje cały ruch dla usługi do komputera deweloperskiego. 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 i 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.

Uwaga

Rozwiązanie Bridge to Kubernetes sprawdza, czy usługa Azure Dev Spaces jest włączona w klastrze Kubernetes. Spowoduje to wyświetlenie monitu o wyłączenie usługi Azure Dev Spaces przed użyciem mostka do platformy 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, znalezione w przestrzeni nazw przy użyciu GENERATED_NAME dla poddomeny.
• Tworzy zasobnik wysłannika dla każdej usługi skojarzonej ze zduplikowanymi ruchami przychodzącymi z poddomeną GENERATED_NAME .
• Tworzy kolejny zasobnik wysłannika dla usługi, nad którą pracujesz w izolacji. Ta konfiguracja umożliwia kierowanie żądań z poddomeną do komputera dewelopera.
• Konfiguruje reguły routingu dla każdego zasobnika wysłannika do obsługi routingu dla usług za pomocą poddomeny.

Na poniższym diagramie przedstawiono klaster Kubernetes przed połączeniem mostka z klastrem Kubernetes:

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ć zduplikowaną usługę i zasobniki wysłanników, które obsługują routing w izolacji.

Gdy klaster odbiera żądanie z poddomeną GENERATED_NAME , dodaje do żądania nagłówek kubernetes-route-as=GENERATED_NAME . Zasobniki wysłanników obsługują routing żądania do odpowiedniej usługi w klastrze. W przypadku żądania do usługi, która jest wykonywana w izolacji, klaster przekierowuje żądanie do komputera dewelopera przez agenta zdalnego.

Gdy klaster odbiera żądanie bez poddomeny GENERATED_NAME , nie dodaje nagłówka do żądania. Zasobniki wysłanników obsługują routing żądania do odpowiedniej usługi w klastrze. W przypadku żądania usługi, która jest zastępowana, zasobniki kierują ją do oryginalnej usługi zamiast agenta zdalnego.

Ważne

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 usługa ServiceA odbiera żądanie, następnie wysyła żądanie do usługi B przed zwróceniem odpowiedzi. W tym przykładzie usługa ServiceA musi przekazać nagłówek kubernetes-route-as=GENERATED_NAME w żądaniu do usługi 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 program Bridge to Kubernetes usunie wszystkie zasobniki wysłannika i zduplikowaną usługę.

Uwaga

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 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ć informacje, 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 polecenia 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> 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 mostka do platformy Kubernetes w celu nawiązania połączenia z lokalnym komputerem deweloperskim z klastrem, zobacz Use Bridge to Kubernetes (VS) or Use Bridge to Kubernetes (VS Code) (Używanie mostka do platformy Kubernetes (VS Code) lub Używanie mostu do platformy Kubernetes (VS Code).