Konfigurowanie mostka na platformie Kubernetes

Notatka

Most do Kubernetes zostanie wycofany 30 kwietnia 2025 roku. Aby uzyskać szczegółowe informacje o wycofaniu i alternatywach typu open source, zobacz zgłoszenie GitHub .

Proces lokalnego mostka na platformę Kubernetes można skonfigurować przy użyciu dwóch metod. Możesz dodawać adnotacje do usług w klastrze i dostarczać konfigurację lokalną.

Konfiguracja rozwiązania Kubernetes

Plik konfiguracji kubernetes (kubeconfig) jest domyślnie przechowywany w ~/.kube/config, ale można go ustawić przy użyciu zmiennej środowiskowej KUBECONFIG.

Jeśli używasz programu Visual Studio, możesz edytować profil uruchamiania bridge to Kubernetes w środowisku IDE przy użyciu interfejsu użytkownika profilów uruchamiania debugowania debugowania we właściwościach debugowania. Zobacz Edytuj profil uruchamiania.

Z tego miejsca możesz otworzyć następujący ekran, który umożliwia edytowanie niektórych typowych właściwości konfiguracji.

Zapobieganie przekazywaniu określonych portów przez Bridge to Kubernetes

Skonfiguruj Bridge to Kubernetes, aby ignorowało mapowanie określonych portów usługi Kubernetes na twoją maszynę przez dodanie adnotacji bridgetokubernetes/ignore-ports do usługi.

apiVersion: v1
kind: Service
metadata:
  annotations:
    bridgetokubernetes/ignore-ports:445,23

Konfiguracja lokalna przy użyciu (KubernetesLocalProcessConfig.yaml)

Plik KubernetesLocalProcessConfig.yaml umożliwia odtwarzanie zmiennych środowiskowych i zamontowanych plików dostępnych dla podów w klastrze. W pliku KubernetesLocalProcessConfig.yaml można określić następujące akcje:

• Pobierz wolumin i ustaw ścieżkę do tego woluminu jako zmienną środowiskową.
• Udostępnij usługę uruchomioną w klastrze procesom uruchomionym na komputerze dewelopera.
• Utwórz zmienną środowiskową z wartością stałą.

Domyślny plik KubernetesLocalProcessConfig.yaml nie jest tworzony automatycznie, dlatego należy ręcznie utworzyć plik w katalogu głównym projektu.

Pobieranie woluminu

W obszarze envokreśl nazwę i wartość dla każdego woluminu, który chcesz pobrać. Nazwa to zmienna środowiskowa, która będzie używana na komputerze dewelopera. Wartość jest nazwą woluminu i ścieżką na komputerze dewelopera. Wartość dla wartość przyjmuje formę $(volumeMounts:VOLUME_NAME)/PATH/TO/FILES.

Na przykład:

version: 0.1
env:
  - name: ALLOW_LIST_PATH
    value: $(volumeMounts:allow-list)/allow-list

Powyższy przykład pobiera woluminu listy dozwolonych z kontenera i ustawia lokalizację oraz ścieżkę do zmiennej środowiskowej ALLOW_LIST_PATH. Domyślnym zachowaniem jest pobranie plików do ścieżki określonej w katalogu tymczasowym na komputerze dewelopera. W powyższym przykładzie ALLOW_LIST_PATH jest ustawiony na wartość /TEMPORARY_DIR/allow-list.

Notatka

Pobranie woluminu spowoduje pobranie całej zawartości tego woluminu niezależnie od ustawionej ścieżki. Ścieżka jest używana tylko do ustawiania zmiennej środowiskowej do użycia na komputerze dewelopera. Dodanie /allow-list lub /path/to/files na końcu tokenu nie ma wpływu na miejsce utrwalania woluminu. Zmienna środowiskowa jest po prostu wygodą, jeśli aplikacja potrzebuje odwołania do określonego pliku w tym woluminie.

Istnieje również możliwość określenia folderu na komputerze deweloperskim, gdzie wolumin ma zostać zamontowany, zamiast używać katalogu tymczasowego. W obszarze volumeMountsokreśl nazwę i localPath dla każdej konkretnej lokalizacji. Nazwa to nazwa woluminu, którą chcesz dopasować, a localPath jest ścieżką bezwzględną na komputerze deweloperskim. Na przykład:

version: 0.1
volumeMounts:
  - name: default-token-*
    localPath: /var/run/secrets/kubernetes.io/serviceaccount
env:
  - name: KUBERNETES_IN_CLUSTER_CONFIG_OVERRIDE
    value: $(volumeMounts:default-token-*)

W powyższym przykładzie użyto wpisu w env do pobrania woluminu pasującego do default-token-*, na przykład default-token-1111 lub default-token-1234-5678-90abcdef. W przypadkach, gdy wiele woluminów jest zgodnych, jest używany pierwszy pasujący wolumin. Wszystkie pliki są pobierane do /var/run/secrets/kubernetes.io/serviceaccount na komputerze deweloperskim za pomocą wpisu w volumeMounts. Zmienna środowiskowa KUBERNETES_IN_CLUSTER_CONFIG_OVERRIDE jest ustawiona na wartość /var/run/secrets/kubernetes.io/serviceaccount.

Udostępnianie usługi

W obszarze envokreśl nazwę i wartość dla każdej usługi, którą chcesz udostępnić na komputerze dewelopera. Nazwa to zmienna środowiskowa, która będzie używana na komputerze dewelopera. Wartość jest nazwą usługi z klastra oraz ścieżką. Wartość dla przyjmuje formę $(services:SERVICE_NAME)/PATH.

Na przykład:

version: 0.1
env:
  - name: MYAPP1_SERVICE_HOST
    value: $(services:myapp1)/api/v1/

W powyższym przykładzie usługa myapp1 jest dostępna dla komputera deweloperskiego, a zmienna środowiskowa MYAPP1_SERVICE_HOST jest ustawiona na lokalny adres IP usługi myapp1 ze ścieżką /api/v1 (czyli 127.1.1.4/api/v1). Usługa myapp1 jest dostępna przy użyciu zmiennej środowiskowej myapp1lub myapp1.svc.cluster.local.

Notatka

Udostępnienie usługi na komputerze dewelopera spowoduje udostępnienie całej usługi niezależnie od ustawionej ścieżki. Ścieżka jest używana tylko do ustawiania zmiennej środowiskowej do użycia na komputerze dewelopera. Możesz również udostępnić usługę z określonej przestrzeni nazw Kubernetes przy użyciu $(services:SERVICE_NAME.NAMESPACE_NAME). Na przykład:

version: 0.1
env:
  - name: MYAPP2_SERVICE_HOST
    value: $(services:myapp2.mynamespace)

W powyższym przykładzie aplikacja myapp2 z przestrzeni nazw mynamespace zostaje udostępniona na komputerze dewelopera oraz ustawia zmienną środowiskową MYAPP2_SERVICE_HOST na lokalny adres IP aplikacji myapp2 z przestrzeni nazw mynamespace.

Tworzenie zmiennej środowiskowej ze stałą wartością

W obszarze envokreśl nazwę i wartość dla każdej zmiennej środowiskowej, którą chcesz utworzyć na komputerze dewelopera. Nazwa to zmienna środowiskowa, która będzie używana na komputerze dewelopera, a wartość jest wartością. Na przykład:

version: 0.1
env:
  - name: DEBUG_MODE
    value: "true"

Powyższy przykład tworzy zmienną środowiskową o nazwie DEBUG_MODE z wartością true.

Dodaj zależność usługi

Można określić zależność usługi, taką jak baza danych lub pamięć podręczna, przy użyciu pola zależności ogólnych, podobnie jak w przypadku deklarowanych usług. Określ zależność w tym miejscu, gdy debugowane usługi muszą łączyć się z zasobami, które nie są uruchomione w klastrze. Zadeklaruj zależność, jak w poniższym przykładzie:

version: 0.1
volumeMounts:
env:
  - name: DB_HOST
    value: $(externalendpoints:server-bridgetest123.database.windows.net:1433)

Podaj nazwę DNS hosta (server-bridgetest13.database.windows.net w przykładzie) i port (1433 w przykładzie) dla zależności.

Po określeniu zależności, takich jak bazy danych, modele uwierzytelniania przekierowania nie będą działać. Na przykład w przypadku usługi Azure SQL Database należy ustawić zasady połączenia na "Serwer proxy" (zamiast "Przekierowanie" lub "Ustawienie domyślne").

Przykład KubernetesLocalProcessConfig.yaml

Oto przykład kompletnego pliku KubernetesLocalProcessConfig.yaml:

version: 0.1
volumeMounts:
  - name: default-token-*
    localPath: /var/run/secrets/kubernetes.io/serviceaccount
env:
  - name: KUBERNETES_IN_CLUSTER_CONFIG_OVERRIDE
    value: $(volumeMounts:default-token-*)
  - name: ALLOW_LIST_PATH
    value: $(volumeMounts:allow-list)/allow-list
  - name: MYAPP1_SERVICE_HOST
    value: $(services:myapp1)/api/v1/
  - name: MYAPP2_SERVICE_HOST
    value: $(services:myapp2.mynamespace)
  - name: DEBUG_MODE 
    value: "true"

Następne kroki

Aby rozpocząć korzystanie z Bridge do Kubernetes w celu połączenia lokalnego komputera deweloperskiego z klastrem, zobacz Use Bridge to Kubernetes with Visual Studio Code oraz Use Bridge to Kubernetes with Visual Studio.