Usare Bridge to Kubernetes con VS Code

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 ti consente di eseguire e fare il debug del codice sul computer di sviluppo, mantenendo la connessione al cluster Kubernetes insieme al resto dell'applicazione e dei servizi. In questa guida si apprenderà come usare Bridge to Kubernetes per reindirizzare il traffico tra il cluster Kubernetes e il codice in esecuzione nel computer di sviluppo.

Prima di iniziare

Questo articolo presuppone che tu abbia già il tuo cluster con un'architettura a microservizi e che tu voglia eseguire il debug di uno dei pod nel tuo cluster. Per informazioni su come usare Bridge to Kubernetes con un'applicazione di esempio esistente, vedere Usare Bridge to Kubernetes con un esempio. Se si usa il servizio Azure Kubernetes e si vuole usare un'applicazione di esempio più complessa, vedere Bridge to Kubernetes (AKS).

Prerequisiti

• Un cluster Kubernetes con un'app di cui si vuole eseguire il debug.
• Visual Studio Code in esecuzione in macOS, Windows 10 o versione successiva o Linux.

Connettersi al cluster ed eseguire il debug di un servizio

Esistono due modi diversi per avviare il processo di debug con Bridge to Kubernetes. Se si inizia dall'estensione Kubernetes open source, senza Bridge to Kubernetes installato, passare a Installare e usare il debug del tunnel locale. Se è già installato Bridge to Kubernetes, procedere con la procedura seguente:

1. Sul computer di sviluppo, assicurarsi che il contesto corrente sia impostato sul cluster e nel namespace in cui è in esecuzione l'applicazione.

2. Aprire l'area di lavoro per l'app di cui si vuole eseguire il debug in Visual Studio Code. Nella finestra dell'estensione Kubernetes sotto Clusters, verificare che il cluster e il namespace siano selezionati. Aprire la Palette dei comandi (CTRL+MAIUSC+P o Cmd+Shift+P in un Mac) ed eseguire il comando Bridge to Kubernetes: Configura per avviare il processo di configurazione.

3. Scegliere il servizio Kubernetes da reindirizzare alla versione locale.

   

   Tutto il traffico nel cluster Kubernetes viene reindirizzato per il servizio alla versione dell'applicazione in esecuzione nel computer di sviluppo. Bridge a Kubernetes instrada anche tutto il traffico in uscita dall'applicazione al cluster Kubernetes.

   Importante

   È possibile reindirizzare solo i servizi con un singolo pod.

4. Dopo aver selezionato il servizio, ignorare la sezione successiva e continuare seguendo i passaggi descritti in Configurare il debugger per il debug del tunnel locale con Bridge to Kubernetes.

Installare e usare il debug del tunnel locale

Seguire questa procedura per iniziare a usare il debug del tunnel locale quando è installata l'estensione Kubernetes open source installata e si dispone di un cluster Kubernetes con servizi di cui si vuole eseguire il debug. I passaggi descritti in questa sezione illustrano l'installazione di Bridge to Kubernetes e avviano il processo di configurazione per il debug del tunnel locale.

Nota

L'estensione Kubernetes per VS Code fornisce un punto di ingresso API che consente agli autori di estensioni di contribuire ad altre soluzioni di tunnel locale da VS Code Marketplace. Bridge to Kubernetes è una possibile implementazione della funzionalità di debug del tunnel locale.

Esistono due modi per iniziare a usare il debug del tunnel locale in VS Code. Il primo consiste nell'aprire il riquadro comandi (CTRL+MAIUSC+P o Cmd+Maiusc+P in un Mac) e digitare Kubernetes: Debug (tunnel locale).

In alternativa, naviga verso il tuo esploratore di cluster Kubernetes. Aprire le risorse del cluster attivo e individuare un servizio o un pod di cui si vuole eseguire il debug, quindi fare clic con il pulsante destro del mouse sul servizio e selezionare Debug: Tunnel locale.

A questo punto, se non è installata alcuna estensione di VS Code che offre funzionalità di debug locali, si verrà reindirizzati al Marketplace per selezionare un'estensione che fornisce il debug locale. Selezionare l'estensione Bridge to Kubernetes.

Dopo aver installato l'estensione Bridge to Kubernetes, la volta successiva che si sceglie Debug: Tunnel locale, si ignorerà il passaggio di installazione e si procederà direttamente al passaggio successivo, Configurare il debugger per il debug del tunnel locale con Bridge to Kubernetes.

Configurare il debugger per il debug del tunnel locale con Bridge to Kubernetes

Il primo passaggio per configurare il debugger per il debug del tunnel locale è che viene richiesto di immettere la porta TCP usata dall'applicazione per l'esecuzione in locale:

Scegliere una configurazione di avvio di debug usata normalmente durante l'esecuzione dell'applicazione in locale. Se non si ha una configurazione di avvio, è possibile consentire a Bridge to Kubernetes di crearne uno o di non crearne uno, nel qual caso è necessario avviare manualmente l'applicazione o il servizio. Per altre informazioni, vedere Configurazioni di avvio.

Hai l'opzione di eseguire in modo isolato o non isolato. Se si esegue isolato, solo le tue richieste vengono instradate al tuo processo locale; altri sviluppatori possono usare il cluster senza subire effetti. Se non esegui in modalità isolata, tutto il traffico viene reindirizzato al tuo processo locale. Per altre informazioni su questa opzione, vedere Uso delle funzionalità di routing per lo sviluppo in isolamento.

Selezionare l'icona Debug a sinistra e selezionare la configurazione di avvio di Kubernetes appena aggiunta, ad esempio Avvia tramite NPM con Kubernetes, nella parte superiore. Questa configurazione di avvio viene creata da Bridge to Kubernetes, se si sceglie tale opzione.

Nota

Verrà richiesto di consentire all'EndpointManager di eseguire con privilegi elevati e modificare il file hosts.

Il computer di sviluppo è connesso quando la barra di stato di VS Code diventa arancione e l'estensione Kubernetes mostra che si è connessi.

Una volta connesso il computer di sviluppo, il traffico inizia a essere reindirizzato verso il computer di sviluppo per il servizio che stai sostituendo.

Nota

Nei lanci successivi non verrà richiesto il nome del servizio, la porta, il task di avvio o se eseguire in modalità isolata. Questi valori vengono salvati in .vscode/tasks.json. Per modificare queste impostazioni in un secondo momento, aprire il riquadro comandi (CTRL+MAIUSC+P o Cmd+Shift+P in un Mac) ed eseguire il comando Bridge to Kubernetes: Configure. È possibile aprire .vscode/launch.json e .vscode/tasks.json per visualizzare le impostazioni di configurazione specifiche aggiunte da Bridge a Kubernetes al profilo di avvio.

Se il cluster usa core gRPC C, un'implementazione di gRPC che usa c-ares, viene aggiunta una variabile di ambiente al profilo di avvio, GRPC_DNS_RESOLVER, con il valore native. Questa variabile specifica di usare una soluzione alternativa per evitare un ritardo di 2 minuti durante la connessione. Per altre informazioni, vedere questo problema gRPC.

Impostare un punto di interruzione

Impostare un punto di interruzione con F9 o selezionando Esegui quindi Attiva/Disattiva punto di interruzione.

Passare all'applicazione di esempio aprendo l'URL pubblico. Quando il codice raggiunge il punto di interruzione, deve essere aperto nel debugger. Per riprendere il servizio, premere CTRL+F5 oppure selezionare Esegui quindi Continua. Tornare al browser e verificare che venga visualizzata un'immagine segnaposto per la bicicletta.

Aggiornare l'applicazione

Quando si apportano modifiche al codice in locale, il fatto che siano visibili o meno ad altri utenti che utilizzano il cluster dipende dal fatto se si stia eseguendo in modalità isolata o meno. Se lavori in modalità isolata, è possibile apportare modifiche che non influiscono sugli altri utenti.

Modificare il codice, salvare le modifiche e premere CTRL+MAIUSC+F5 (⇧⌘F5 in un Mac) oppure selezionare Esegui quindi Riavvia debug. Dopo la riconnessione, aggiornare il browser e convalidare le modifiche.

Selezionare Esegui quindi Arresta debug o premere MAIUSC+F5 per arrestare il debugger.

Nota

Per impostazione predefinita, l'arresto dell'attività di debug disconnette anche il computer di sviluppo dal cluster Kubernetes. È possibile modificare questo comportamento cercando Bridge to Kubernetes: Disconnetti dopo il debug nelle impostazioni di Visual Studio Code e rimuovendo il controllo accanto a Disconnetti automaticamente quando il debug si arresta. Dopo l'aggiornamento di questa impostazione, il computer di sviluppo rimarrà connesso quando si arresta e si avvia il debug. Per disconnettere il computer di sviluppo dal cluster, fare clic sull'estensione Bridge to Kubernetes sulla barra di stato e quindi scegliere Disconnetti sessione corrente.

Configurazione aggiuntiva

Il bridge a Kubernetes può gestire il traffico di routing e replicare le variabili di ambiente senza alcuna configurazione aggiuntiva. Se è necessario scaricare tutti i file montati nel contenitore nel cluster Kubernetes, ad esempio un file ConfigMap, è possibile creare un KubernetesLocalProcessConfig.yaml per scaricare tali file nel computer di sviluppo. Per altre informazioni, vedere Configure Bridge to Kubernetes.

Se si usa un cluster del servizio Azure Kubernetes che usa l'identità gestita, una funzionalità di sicurezza fornita da Microsoft Entra ID, vedere Usare l'identità gestita con Bridge to Kubernetes per informazioni su come configurare Bridge to Kubernetes per questo scenario.

Uso dei log e della diagnostica

L'output del log viene scritto nella finestra Bridge to Kubernetes quando il computer di sviluppo è connesso al cluster Kubernetes.

Fare clic sulla barra di stato Kubernetes e scegliere Mostra informazioni di diagnostica della connessione. Questo comando stampa le variabili di ambiente correnti e le voci DNS nell'output di registrazione.

Inoltre, è possibile trovare i log di diagnostica nella directory Bridge to Kubernetes nella directory TEMP del computer di sviluppo. Su Windows 10, si trova in %TEMP%\Bridge to Kubernetes. In un Mac la directory TEMP è reperibile eseguendo echo $TMPDIR da una finestra del terminale. In Linux è /tmp/Bridge to Kubernetes.

Esecuzione in modalità di isolamento

Con Bridge to Kubernetes, è anche possibile configurare una versione isolata dei servizi su cui si sta lavorando, ovvero gli altri che usano il cluster non saranno interessati dalle modifiche. Questa modalità di isolamento viene attuata instradando le richieste verso la tua copia di ciascun servizio interessato, mentre tutto l'altro traffico viene instradato normalmente. Per accedere all'URL dell'endpoint locale per l'app isolata, avviare il debugger in modalità di isolamento, aprire il menu Kubernetes sulla barra di stato e scegliere la voce dell'endpoint. Per altre informazioni sul funzionamento del routing in modalità di isolamento, vedere Funzionamento di Bridge to Kubernetes.

Propagazione dell'intestazione

Per usare Bridge to Kubernetes nel modo in cui è progettato, è necessario assicurarsi di propagare l'intestazione Bridge to Kubernetes dalle richieste in ingresso a qualsiasi richiesta che i servizi fanno ad altri servizi nel cluster. Tutte le API di richiesta HTTP, indipendentemente dal linguaggio, forniscono un modo specifico del framework per eseguire questa operazione. Ad esempio, per il codice .NET in C#, è possibile usare codice simile al seguente:

var request = new HttpRequestMessage();
request.RequestUri = new Uri("http://mywebapi/api/values/1");
if (this.Request.Headers.ContainsKey("kubernetes-route-as"))
{
    // Propagate the dev space routing header
    request.Headers.Add("kubernetes-route-as", this.Request.Headers["kubernetes-route-as"] as IEnumerable<string>);
}
var response = await client.SendAsync(request);

Nota

Per evitare di influire sul codice a ogni richiesta, è possibile creare una classe che eredita da System.Net.Http.DelegatingHandler ed eseguire l'override del metodo SendAsync con codice simile all'esempio precedente. È possibile trovare codice usando questa tecnica sul Web; un esempio è propagazione corretta di "kubernetes-route-as" in Bridge to Kubernetes.

Per i servizi Node.js, è possibile usare il codice simile al seguente, tratto dall'esempio todo-app nel repository chiamato Bridge to Kubernetes:

    server.get("/api/stats", function (req, res) {
        var options = {
            host: process.env.STATS_API_HOST,
            path: '/stats',
            method: 'GET'
        };
        const val = req.get('kubernetes-route-as');
        if (val) {
            console.log('Forwarding kubernetes-route-as header value - %s', val);
            options.headers = {
                'kubernetes-route-as': val
            }
        }
        var req = http.request(options, function(statResponse) {
            res.setHeader('Content-Type', 'application/json');
            var responseString = '';
            //another chunk of data has been received, so append it to `responseString`
            statResponse.on('data', function (chunk) {
                responseString += chunk;
            });
            statResponse.on('end', function () {
                res.send(responseString);
            });
        });

        req.on('error', function(e) {
            console.log('problem with request: ' + e.message);
          });

          req.end();
    });

Comunicazione con altri servizi

Quando si comunica con un altro servizio nello stesso cluster Kubernetes, ad esempio con una richiesta HTTP, in genere si usa il nome del servizio hardcoded nell'URL per la richiesta, ma non funziona in alcuni scenari, ad esempio quando si usa SSH remoto, WSL e Codespaces. Questo articolo descrive come usare le variabili di ambiente del servizio Kubernetes per specificare l'URL di connessione per questi scenari.

Risoluzione dei problemi

Se viene visualizzato questo errore durante l'attivazione dell'estensione Bridge to Kubernetes:

"Impossibile aggiornare le dipendenze: superato il numero massimo di tentativi"

Prima di tutto, ripetere l'attivazione usando il pulsante . Se ripetutamente non riesce, vedere https://github.com/microsoft/mindaro/issues/32.

Quando si usa Bridge to Kubernetes in una sessione SSH remota, se EndpointManager ha esito negativo, il problema potrebbe essere che Bridge to Kubernetes non può modificare il file hosts a causa di un problema di autorizzazioni. Per abilitare SSH remoto o l'esecuzione come utente non con privilegi elevati, è necessario aggiornare il codice per usare le variabili di ambiente del servizio Kubernetes e configurare VS Code per usarle, come descritto nell'argomento variabili di ambiente del servizio.

Passaggi successivi

Altre informazioni su Bridge to Kubernetes sono disponibili in Funzionamento di Bridge to Kubernetes.

Se è necessario eseguire il debug di più servizi contemporaneamente in parallelo, vedere Eseguire il debug di più servizi contemporaneamente.