Configurare Bridge per Kubernetes

Articolo
05/31/2024

È possibile configurare il processo bridge locale in Kubernetes usando due metodi. È possibile annotare i servizi nel cluster ed è possibile specificare la configurazione locale.

Configurazione di Kubernetes

Il file di configurazione kubernetes (kubeconfig) è archiviato per impostazione predefinita in ~/.kube/config, ma è possibile impostarlo usando la variabile di ambiente KUBECONFIG.

Se si usa Visual Studio, è possibile modificare il profilo di avvio di Bridge in Kubernetes nell'IDE usando l'interfaccia utente dei profili di avvio debug nelle proprietà Debug. Vedere Modificare il profilo di avvio.

Da qui è possibile aprire la schermata seguente, che consente di modificare alcune delle proprietà di configurazione più comuni.

Impedire a Bridge a Kubernetes di inoltrare porte specifiche

Configurare Bridge in Kubernetes per ignorare il mapping di porte specifiche in un servizio Kubernetes al computer aggiungendo l'annotazione bridgetokubernetes/ignore-ports nel servizio.

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

Configurazione locale con (KubernetesLocalProcessConfig.yaml)

Il KubernetesLocalProcessConfig.yaml file consente di replicare le variabili di ambiente e i file montati disponibili per i pod nel cluster. È possibile specificare le azioni seguenti in un KubernetesLocalProcessConfig.yaml file:

Scaricare un volume e impostare il percorso di tale volume come variabile di ambiente.
Rendere disponibile un servizio in esecuzione nel cluster per i processi in esecuzione nel computer di sviluppo.
Creare una variabile di ambiente con un valore costante.

Un file predefinito KubernetesLocalProcessConfig.yaml non viene creato automaticamente, quindi è necessario creare manualmente il file nella radice del progetto.

Scaricare un volume

In env specificare un nome e un valore per ogni volume da scaricare. Il nome è la variabile di ambiente che verrà usata nel computer di sviluppo. Il valore è il nome del volume e un percorso nel computer di sviluppo. Il valore per il valore accetta il formato $(volumeMounts:VOLUME_NAME)/PATH/TO/FILES.

Ad esempio:

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

L'esempio precedente scarica il volume allow-list dal contenitore e imposta tale percorso più il percorso della variabile di ambiente ALLOW_LIST_PATH. Il comportamento predefinito consiste nel scaricare i file nel percorso specificato in una directory temporanea nel computer di sviluppo. Nell'esempio precedente ALLOW_LIST_PATH è impostato su /TEMPORARY_DIR/allow-list.

Nota

Il download di un volume scaricherà l'intero contenuto del volume indipendentemente dal percorso impostato. Il percorso viene usato solo per impostare la variabile di ambiente da utilizzare nel computer di sviluppo. L'aggiunta di /allow-list o /path/to/files alla fine del token non influisce effettivamente sulla posizione in cui il volume viene salvato in modo permanente. La variabile di ambiente è solo una comodità nel caso in cui l'app richieda un riferimento a un file specifico all'interno di tale volume.

È anche possibile specificare un percorso per scaricare il montaggio del volume nel computer di sviluppo anziché usare una directory temporanea. In volumeMounts specificare un nome e un localPath per ogni posizione specifica. Il nome è il nome del volume che si vuole trovare e localPath è il percorso assoluto nel computer di sviluppo. Ad esempio:

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-*)

L'esempio precedente usa la voce in env per scaricare un volume corrispondente a default-token-*, ad esempio default-token-1111 o default-token-1234-5678-90abcdef. Nei casi in cui più volumi corrispondono, viene usato il primo volume corrispondente. Tutti i file vengono scaricati /var/run/secrets/kubernetes.io/serviceaccount nel computer di sviluppo usando la voce in volumeMounts. La variabile di ambiente KUBERNETES_IN_CLUSTER_CONFIG_OVERRIDE è impostata su /var/run/secrets/kubernetes.io/serviceaccount.

Rendere disponibile un servizio

In env specificare un nome e un valore per ogni servizio che si vuole rendere disponibile nel computer di sviluppo. Il nome è la variabile di ambiente che verrà usata nel computer di sviluppo. Il valore è il nome del servizio dal cluster e un percorso. Il valore per value accetta il formato $(services:edizione Standard RVICE_NAME)/PATH.

Ad esempio:

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

L'esempio precedente rende disponibile il servizio myapp1 per il computer di sviluppo e la variabile di ambiente MYAPP1_edizione Standard RVICE_HOST è impostata sull'indirizzo IP locale del servizio myapp1 con il /api/v1 percorso ( ovvero 127.1.1.4/api/v1). Il servizio myapp1 è accessibile usando la variabile di ambiente myapp1 o myapp1.svc.cluster.local.

Nota

Rendere disponibile un servizio nel computer di sviluppo renderà disponibile l'intero servizio indipendentemente dal percorso impostato. Il percorso viene usato solo per impostare la variabile di ambiente da utilizzare nel computer di sviluppo. È anche possibile rendere disponibile un servizio da uno spazio dei nomi Kubernetes specifico usando $(services:edizione Standard RVICE_NAME. NAMESPACE_NAME). Ad esempio:

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

L'esempio precedente rende disponibile myapp2 dallo spazio dei nomi mynamespace nel computer di sviluppo e imposta la variabile di ambiente MYAPP2_edizione Standard RVICE_HOST sull'indirizzo IP locale di myapp2 dallo spazio dei nomi mynamespace.

Creare una variabile di ambiente con un valore costante

In env specificare un nome e un valore per ogni variabile di ambiente che si vuole creare nel computer di sviluppo. Il nome è la variabile di ambiente che verrà usata nel computer di sviluppo e il valore è il valore . Ad esempio:

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

Nell'esempio precedente viene creata una variabile di ambiente denominata DEBUG_MODE con un valore true.

Aggiungere una dipendenza del servizio

È possibile specificare una dipendenza del servizio, ad esempio un database o una cache, usando un campo di dipendenze generico, in modo analogo alla modalità di dichiarazione dei servizi. Specificare una dipendenza qui quando il servizio di cui si esegue il debug deve connettersi alle risorse che non sono in esecuzione nel cluster. Dichiarare una dipendenza come nell'esempio seguente:

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

Specificare il nome DNS host (server-bridgetest13.database.windows.net nell'esempio) e la porta (1433 nell'esempio) per la dipendenza.

Quando si specificano dipendenze come i database, i modelli di autenticazione di reindirizzamento non funzioneranno. Ad esempio, per database SQL di Azure, è necessario impostare i criteri di connessione su "Proxy" (anziché "Reindirizzamento" o "Predefinito").

Esempio di KubernetesLocalProcessConfig.yaml

Di seguito è riportato un esempio di file completo 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"

Passaggi successivi

Per iniziare a usare Bridge to Kubernetes per connettersi al computer di sviluppo locale al cluster, vedere Usare Bridge to Kubernetes con Visual Studio Code e Usare Bridge to Kubernetes con Visual Studio.

Condividi tramite