Variabili di ambiente del servizio 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 .
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 questo non funziona in alcuni scenari con Bridge to Kubernetes. Questo articolo descrive come usare le variabili di ambiente del servizio Kubernetes per specificare l'URL di connessione.
Evitare errori di reindirizzamento
Bridge to Kubernetes reindirizza il traffico modificando la risoluzione dei nomi host per dirigere il traffico di rete alla propria versione dei servizi. Il reindirizzamento funziona nella maggior parte degli scenari, ma non riesce nel caso in cui il processo da Bridge a Kubernetes abbia privilegi limitati, ad esempio quando la richiesta ha origine da un account utente non con privilegi elevati o quando si usa VS Code Remote SSH. Ciò è dovuto al fatto che per abilitare la risoluzione dei nomi per i servizi reindirizzati, Bridge a Kubernetes deve modificare il file host, ma ciò non è possibile quando Bridge to Kubernetes viene eseguito da un account utente non con privilegi elevati. Per risolvere questo problema, è possibile scrivere il codice per usare le variabili di ambiente del servizio Kubernetes anziché un nome di servizio hardcoded.
Tabella delle variabili di ambiente
La tabella seguente illustra le variabili di ambiente del servizio Kubernetes disponibili da qualsiasi servizio nel cluster, per un servizio di esempio che usa il protocollo TCP su una porta. Il nomeservizio è il nome del servizio, convertito in maiuscolo e con trattini convertiti in caratteri di sottolineatura, quindi, ad esempio, un servizio denominato web-api restituisce una variabile di ambiente denominata WEB_API_SERVICE_HOST.
Nome | Esempio | Descrizione |
---|---|---|
nomeservizio_SERVICE_HOST | 10.0.0.11 | Nome dell'host del servizio |
nomeservizio_SERVICE_PORT | 6379 | Porta per il servizio |
nomeservizio_PORT | tcp://10.0.0.11:6379 | URL con protocollo, indirizzo IP e porta. |
nomeservizio_PORT_numeroporta_protocollo | tcp://10.0.0.11:6379 | URL con protocollo, indirizzo IP e porta. |
nomeservizio_PORT_portnumber_protocollo_PROTO | TCP | Identificatore del protocollo. |
nomeservizio_PORT_portnumber_protocollo_PORT | 6379 | Numero di porta per TCP. |
nomeservizio_PORT_numeroporta_protocollo_ADDR | 10.0.0.11 | Indirizzo IP per TCP. |
Quindi, se il servizio è denominato web-api, le variabili vengono WEB_API_SERVICE_HOST e WEB_API_SERVICE_PORT e così via. Le variabili di ambiente predefinite create da Kubernetes sono descritte nella documentazione di Kubernetes . Per informazioni sui protocolli supportati, vedere Protocolli supportati.
Variabili di ambiente nel codice sorgente
Per consentire l'esecuzione dei servizi in Bridge a Kubernetes senza privilegi elevati, sostituire eventuali riferimenti hardcoded al nome host con la variabile di ambiente. L'esempio seguente illustra questa operazione in un servizio .NET denominato mywebapi scritto in C#:
using var client = new HttpClient();
var host = Environment.GetEnvironmentVariable("MYWEBAPI_SERVICE_HOST");
var port = Environment.GetEnvironmentVariable("MYWEBAPI_SERVICE_PORT");
var request = new HttpRequestMessage();
request.RequestUri = new Uri($"http://{host}:{port}/api/data");
var response = await client.SendAsync(request);
Un esempio in Node.js è simile al seguente:
server.get("/api/data", function (req, res) {
var options = {
host: process.env.MYWEBAPI_SERVICE_HOST,
port: process.env.MYWEBAPI_SERVICE_PORT,
path: '/api/data',
method: 'GET'
};
var req = http.request(options, function(response) {
res.setHeader('Content-Type', 'application/json');
var responseString = '';
//another chunk of data has been received, so append it to `responseString`
response.on('data', function (chunk) {
responseString += chunk;
});
response.on('end', function () {
res.send(responseString);
});
});
req.on('error', function(e) {
console.log('problem with request: ' + e.message);
});
req.end();
});
Per aggiornare il codice in modo da usare le variabili di ambiente, cercare eventuali occorrenze del nome host e aggiornare per usare il valore ottenuto dalla variabile di ambiente nomeservizio_SERVICE_HOST.
Anche se in genere non si specifica la porta usata dal servizio di destinazione durante la chiamata, sarà necessario usare la variabile di ambiente _SERVICE_PORT nomeservizio. La specifica della porta consente a Bridge to Kubernetes di evitare i conflitti che si verificano quando una porta specifica non è disponibile nel computer di sviluppo. Non è necessario modificare la porta su cui il tuo servizio è in ascolto affinché funzioni: devi solo assicurarti che, quando il tuo servizio chiama altri servizi, li chiami utilizzando sia le variabili di ambiente nomeservizio_SERVICE_HOST che nomeservizio_SERVICE_PORT.
Se si riutilizza lo stesso codice altrove nel cluster, ciò è corretto perché queste variabili di ambiente sono disponibili in ogni pod del cluster. Se si riutilizza lo stesso codice all'esterno di un cluster Kubernetes, è necessario configurare le variabili di ambiente equivalenti o modificare il codice in modo appropriato per la nuova piattaforma o il servizio di hosting.
Impostare VS Code per usare le variabili di ambiente del servizio Kubernetes
Se si usa VS Code con un computer remoto o si esegue VS Code come utente non amministratore, è anche necessario configurare VS Code per usare le variabili di ambiente del servizio Kubernetes. Aprire tasks.json, trovare l'attività con l'etichetta bridge-to-kubernetes.service
e aggiungere la proprietà usekubernetesServiceEnvironmentVariables
con il valore true
, come illustrato nel codice seguente:
"tasks": [
{
"label": "bridge-to-kubernetes.service",
"type": "bridge-to-kubernetes.service",
"service": "bikes",
"ports": [
3000
],
"useKubernetesServiceEnvironmentVariables": true
}
]
Impostare Visual Studio per usare le variabili di ambiente del servizio Kubernetes
Se si esegue Visual Studio come utente non amministratore, è anche necessario configurare Visual Studio per usare le variabili di ambiente del servizio Kubernetes. Aprire launchSettings.json, trovare il profilo con l'etichetta Bridge to Kubernetes
e aggiungere la proprietà useKubeServiceEnvironmentVariables
con il valore true
, come illustrato nel codice seguente:
"Bridge to Kubernetes": {
"commandName": "AzureDevSpacesLocal",
"launchBrowser": true,
"useKubeServiceEnvironmentVariables": true
}
L'impostazione è necessaria solo se si esegue VS Code o Visual Studio come utente non amministratore o se si usa una sessione remota, ma se il codice è stato modificato come descritto in questo articolo, non c'è alcun danno nell'impostazione di questa proprietà.
Passaggi successivi
Per ulteriori informazioni sulla configurazione di Bridge a Kubernetes, consultare Come configurare Bridge a Kubernetes.