Funzionamento di Bridge to Kubernetes

Nota

Bridge to Kubernetes verrà ritirato il 30 aprile 2025. Per informazioni dettagliate sul ritiro e sulle alternative open source, vedere il problema di GitHub .

Bridge to Kubernetes è uno strumento di sviluppo iterativo per la creazione di applicazioni di microservizi destinate a Kubernetes. L'estensione Bridge to Kubernetes è disponibile per Visual Studio e Visual Studio Code (VS Code).

Bridge to Kubernetes consente di eseguire e fare il debug del codice sul computer di sviluppo. Il computer è ancora connesso al cluster Kubernetes con il resto dell'applicazione o dei servizi. Se si dispone di un'architettura di microservizi di grandi dimensioni con molti servizi e database interdipendenti, la replica di tali dipendenze nel computer di sviluppo può essere difficile. La compilazione e la distribuzione di codice nel cluster Kubernetes per ogni modifica del codice possono risultare lente, dispendiose in termini di tempo e difficoltà.

Bridge to Kubernetes crea una connessione tra il tuo computer di sviluppo e il tuo cluster. Questo approccio evita di dover compilare e distribuire il codice nel cluster. È possibile testare e sviluppare il servizio nel contesto, connesso al cluster. Questo approccio consente di eseguire il debug senza creare altre configurazioni di Docker o Kubernetes.

Bridge a Kubernetes reindirizza il traffico tra il cluster Kubernetes connesso e il computer di sviluppo. Il codice locale e i servizi nel cluster Kubernetes possono comunicare come se fossero nello stesso cluster Kubernetes.

Bridge a Kubernetes consente di replicare le variabili di ambiente e i volumi montati nel cluster Kubernetes nel computer di sviluppo. L'accesso alle variabili di ambiente e ai volumi montati consente di lavorare sul codice senza dover replicare tali dipendenze.

Requisiti

Nota

Bridge to Kubernetes non funziona con i cluster Kubernetes di Docker per Desktop. Per usare Bridge to Kubernetes, sono necessarie una delle configurazioni seguenti:

• VS Code con l'estensione Bridge to Kubernetes installata.
• Visual Studio 2019 versione 16.7 o successiva in esecuzione in Windows 10 o versione successiva. Assicurarsi che il workload ASP.NET e sviluppo Web sia installato. Installare l'estensione Bridge to Kubernetes .

È possibile usare Bridge per Kubernetes per stabilire una connessione al cluster Kubernetes. Questa connessione reindirizza il traffico da e verso un pod esistente nel cluster al computer di sviluppo.

Nota

Quando si usa Bridge to Kubernetes, viene richiesto il nome del servizio per il reindirizzamento al computer di sviluppo. Questa opzione è un modo pratico per identificare un pod per il reindirizzamento. Il reindirizzamento tra il cluster Kubernetes e il computer di sviluppo avviene per un pod. Per altre informazioni, vedere Rendere disponibile un servizio.

In VS Code Bridge to Kubernetes supporta tutti i linguaggi purché sia possibile eseguirli in locale. Il Bridge to Kubernetes in Visual Studio supporta .NET Core. Bridge a Kubernetes non supporta .NET Framework in Visual Studio perché richiede il supporto dei nodi Windows.

Cautela

Bridge to Kubernetes è destinato solo agli scenari di sviluppo e test. Non è progettato o supportato per l'uso con cluster di produzione o servizi attivi in uso.

Per le funzionalità correnti e i piani futuri, vedere la roadmap di Bridge to Kubernetes.

Stabilire una connessione

Quando Bridge a Kubernetes stabilisce una connessione al cluster, esegue le azioni seguenti:

• Richiede di configurare il servizio da configurare nel tuo cluster, la porta sul tuo computer di sviluppo da usare per il tuo codice e l'attività di avvio del codice come azione eseguita una sola volta.
• Sostituisce il container nel pod del cluster con un container agente remoto che reindirizza il traffico al computer di sviluppo.
• Esegui kubectl port-forward sul computer di sviluppo per inoltrare il traffico dal computer di sviluppo all'agente remoto in esecuzione nel cluster.
• Raccoglie informazioni sull'ambiente dal cluster usando l'agente remoto. Queste informazioni sull'ambiente includono variabili di ambiente, servizi visibili, montaggi di volumi e montaggi segreti.
• Configura l'ambiente in Visual Studio in modo che il servizio nel computer di sviluppo possa accedere alle stesse variabili come se fosse in esecuzione nel cluster.
• Aggiorna il file hosts per mappare i servizi sul tuo cluster agli indirizzi IP locali sul computer di sviluppo. Queste voci nei file host consentono al codice che gira sul computer di sviluppo di fare richieste ad altri servizi presenti nel cluster. Per aggiornare il file hosts , Bridge to Kubernetes richiede l'accesso da amministratore sul computer di sviluppo.
• Avvia l'esecuzione e il debug del codice nel computer di sviluppo. Se necessario, Bridge to Kubernetes libera le porte necessarie nel computer di sviluppo arrestando i servizi o i processi che attualmente usano tali porte.

Uso di Bridge to Kubernetes

Dopo aver stabilito una connessione al cluster, eseguire e fare il debug del codice in modo nativo sul tuo computer, senza containerizzazione. Il codice interagisce con il cluster. Qualsiasi traffico di rete ricevuto dall'agente remoto viene reindirizzato alla porta locale specificata durante la connessione. Il codice in esecuzione in modo nativo può accettare ed elaborare tale traffico. Le variabili di ambiente, i volumi e i segreti del cluster vengono resi disponibili per il codice in esecuzione nel computer di sviluppo.

Bridge a Kubernetes aggiunge host voci di file e port forwarding al computer per sviluppatori. Il codice può inviare il traffico di rete ai servizi in esecuzione nel cluster usando i nomi dei servizi del cluster. Il traffico viene inoltrato ai servizi in esecuzione nel cluster. Il traffico viene instradato tra il computer di sviluppo e il cluster durante l'intera connessione.

Bridge to Kubernetes offre inoltre un modo per replicare le variabili di ambiente e i file montati disponibili per i pod nel cluster sul computer di sviluppo attraverso il file KubernetesLocalProcessConfig.yaml. È anche possibile usare questo file per creare nuove variabili di ambiente e montaggi di volumi.

Nota

Per la durata della connessione al cluster, più 15 minuti, Bridge to Kubernetes esegue un processo denominato EndpointManager con autorizzazioni di amministratore nel computer locale.

È possibile eseguire il debug in parallelo, con più servizi. Avvia tante istanze di Visual Studio quanti sono i servizi che vuoi eseguire il debug. Assicurati che i tuoi servizi siano in ascolto su porte diverse localmente. Configurarli ed eseguirne il debug separatamente. L'isolamento non è supportato in questo scenario.

Configurazione aggiuntiva

Il file KubernetesLocalProcessConfig.yaml consente di replicare le variabili di ambiente e i file montati disponibili per i pod nel cluster. Quando si usa Visual Studio, il file KubernetesLocalConfig.yaml deve trovarsi nella stessa directory del file di progetto per il servizio. Per altre informazioni, vedere Configure Bridge to Kubernetes.

Uso delle funzionalità di routing per lo sviluppo in isolamento

Per impostazione predefinita, Bridge to Kubernetes reindirizza tutto il traffico per un servizio al computer di sviluppo. È invece possibile usare le funzionalità di routing per reindirizzare solo le richieste da un sottodominio al computer di sviluppo. Queste funzionalità di routing consentono di usare Bridge to Kubernetes per sviluppare in isolamento ed evitare l'interruzione di altro traffico nel cluster.

L'animazione seguente mostra due sviluppatori che lavorano sullo stesso cluster in isolamento:

Quando si abilita l'isolamento, Bridge to Kubernetes esegue le azioni seguenti oltre a connettersi al cluster Kubernetes:

• Verifica che il cluster Kubernetes non abbia Azure Dev Spaces abilitato.
• Replica il servizio scelto nel cluster nello stesso namespace e aggiunge un'etichetta routing.visualstudio.io/route-from=SERVICE_NAME e un'annotazione routing.visualstudio.io/route-on-header=kubernetes-route-as=GENERATED_NAME.
• Configura e avvia il manager di instradamento nello stesso spazio dei nomi nel cluster Kubernetes. Il gestore del routing usa un selettore di etichette per cercare l'etichetta routing.visualstudio.io/route-from=SERVICE_NAME e l'annotazione routing.visualstudio.io/route-on-header=kubernetes-route-as=GENERATED_NAME quando si configura il routing nel tuo spazio dei nomi.

Nota

Bridge a Kubernetes verifica se Azure Dev Spaces è abilitato nel cluster Kubernetes. Viene richiesto di disabilitare Azure Dev Spaces prima di poter usare Bridge per Kubernetes.

Il gestore di instradamento esegue le seguenti azioni all'avvio del sistema:

• Duplica tutti gli ingressi, inclusi quelli dei bilanciatori del carico, trovati nello spazio dei nomi usando il GENERATED_NAME per il sottodominio.
• Crea un pod envoy per ogni servizio associato agli ingressi duplicati con il sottodominio GENERATED_NAME.
• Crea un altro pod envoy per il servizio su cui stai lavorando in isolamento. Questa configurazione consente di instradare le richieste con il sottodominio al computer di sviluppo.
• Configura le regole di routing per ogni pod di envoy per gestire il routing dei servizi con il sottodominio.

Il diagramma seguente illustra un cluster Kubernetes prima che Bridge a Kubernetes si connetta al cluster:

Il diagramma seguente illustra lo stesso cluster con Bridge to Kubernetes abilitato in modalità di isolamento. Qui è possibile visualizzare il servizio duplicato e i pod Envoy che supportano il routing in modalità isolata.

Quando il cluster riceve una richiesta con il sottodominio GENERATED_NAME, aggiunge alla richiesta un'intestazione kubernetes-route-as=GENERATED_NAME. I pod Envoy gestiscono l'instradamento delle richieste al servizio appropriato nel cluster. Per una richiesta al servizio su cui si sta lavorando in isolamento, il cluster reindirizza la richiesta al computer di sviluppo dall'agente remoto.

Quando il cluster riceve una richiesta senza il sottodominio GENERATED_NAME, non aggiunge un'intestazione alla richiesta. I pod Envoy gestiscono l'instradamento delle richieste al servizio appropriato nel cluster. Per una richiesta per il servizio che viene sostituito, i pod lo instradano al servizio originale anziché all'agente remoto.

Importante

Ogni servizio nel cluster deve inoltrare l'intestazione kubernetes-route-as=GENERATED_NAME durante l'esecuzione di richieste aggiuntive. Ad esempio, quando serviceA riceve una richiesta, effettua una richiesta per serviceB prima di restituire una risposta. In questo esempio, serviceA deve inoltrare l'intestazione kubernetes-route-as=GENERATED_NAME nella sua richiesta a serviceB. Alcuni linguaggi, ad esempio ASP.NET, possono avere metodi per la gestione della propagazione degli header.

Quando si disconnette dal cluster, per impostazione predefinita, Bridge to Kubernetes rimuove tutti i pod envoy e il servizio duplicato.

Nota

La distribuzione e il servizio del manager del routing rimangono in esecuzione nel tuo spazio dei nomi. Per rimuovere la distribuzione e il servizio, eseguire i comandi seguenti per il namespace.

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

Diagnostica e registrazione

Quando si usa Bridge to Kubernetes per connettersi al cluster, il computer registra la diagnostica. Li archivia nella directory TEMP del computer di sviluppo nella cartella Bridge to Kubernetes.

Autorizzazione Kubernetes RBAC

Kubernetes fornisce il controllo degli accessi in base al ruolo per gestire le autorizzazioni per utenti e gruppi. Per informazioni, vedere la documentazione Kubernetes. È possibile impostare le autorizzazioni per un cluster abilitato RBAC creando un file YAML e usando kubectl per applicarlo al cluster.

Per impostare le autorizzazioni nel cluster, creare o modificare un file YAML, ad esempio permissions.yml. Usa il tuo spazio dei nomi per <namespace> e gli utenti e i gruppi che necessitano dell'accesso.

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

Applicare le autorizzazioni usando il comando seguente:

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

Limitazioni

Bridge to Kubernetes presenta le limitazioni seguenti:

• Un pod può avere un solo contenitore in esecuzione in tale pod affinché Bridge to Kubernetes si connetta con successo.
• Attualmente, i pod di Bridge to Kubernetes devono essere contenitori Linux. I contenitori di Windows non sono supportati.
• Bridge to Kubernetes richiede autorizzazioni elevate per essere eseguito sul tuo computer di sviluppo al fine di modificare il file hosts.
• Il bridge a Kubernetes non può essere usato nei cluster con Azure Dev Spaces abilitato.

Passaggi successivi

Per iniziare a usare Bridge to Kubernetes per connettersi dal computer di sviluppo locale al cluster, vedere Usare Bridge to Kubernetes (VS) o Usare Bridge to Kubernetes (VS Code).