Kubernetes-tjänstmiljövariabler

När du kommunicerar med en annan tjänst i samma Kubernetes-kluster, till exempel med en HTTP-begäran, använder du vanligtvis det hårdkodade tjänstnamnet i URL:en för begäran, men det fungerar inte i vissa scenarier med Bridge to Kubernetes. Den här artikeln beskriver hur du använder Kubernetes-tjänstmiljövariablerna för att ange anslutnings-URL:en.

Undvik omdirigeringsfel

Bridge to Kubernetes omdirigerar trafik genom att ändra värdnamnsmatchningen för att omdirigera nätverkstrafik till sin egen version av tjänsterna. Omdirigeringen fungerar i de flesta scenarier, men misslyckas om bridge-till-Kubernetes-processen har begränsad behörighet, till exempel när begäran kommer från ett icke-förhöjt användarkonto eller när du använder VS Code Remote SSH. Detta beror på att Bridge to Kubernetes måste ändra värdfilen för att aktivera namnuppslagningen för omdirigerade tjänster, men det är inte möjligt när Bridge to Kubernetes körs från ett icke-förhöjt användarkonto. För att undvika det här problemet kan du skriva din kod för att använda Kubernetes-tjänstmiljövariablerna i stället för ett hårdkodat tjänstnamn.

Tabell med miljövariabler

Följande tabell visar kubernetes-tjänstmiljövariablerna som är tillgängliga från alla tjänster i klustret, till exempel en tjänst som använder TCP-protokollet på en port. Det tjänstnamnet är namnet på tjänsten, konverteras till versaler och med bindestreck konverterade till understreck, så till exempel ger en tjänst med namnet web-api en miljövariabel med namnet WEB_API_SERVICE_HOST.

Så om tjänsten heter web-api är variablerna WEB_API_SERVICE_HOST och WEB_API_SERVICE_PORT och så vidare. Standardmiljövariablerna som skapats av Kubernetes beskrivs i Kubernetes-dokumentationen. Information om stödda protokoll finns i .

Miljövariabler i källkod

Om du vill att dina tjänster ska kunna köras i Bridge till Kubernetes utan utökade privilegier ersätter du alla hårdkodade referenser till värdnamnet med miljövariabeln. I följande exempel visas detta i en .NET-tjänst med namnet mywebapi som skrivits i 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);

Ett exempel i Node.js ser ut så här:

    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();
    });

Om du vill uppdatera koden så att den använder miljövariablerna letar du efter förekomster av värdnamnet och uppdaterar för att använda värdet som hämtas från miljövariabeln servicename_SERVICE_HOST.

Även om du vanligtvis inte anger den port som används av måltjänsten när du anropar den, måste du använda miljövariabeln servicename_SERVICE_PORT. Om du anger porten kan Bridge to Kubernetes undvika konflikter när en specifik port inte är tillgänglig på utvecklingsdatorn. Du behöver inte ändra porten som tjänsten lyssnar på för att det ska fungera: du behöver bara se till att när tjänsten anropar andra tjänster anropas de med både servicename_SERVICE_HOST och servicename_SERVICE_PORT miljövariabler.

Om du återanvänder samma kod någon annanstans i klustret är det bra eftersom dessa miljövariabler är tillgängliga i varje podd i klustret. Om du återanvänder samma kod utanför ett Kubernetes-kluster måste du antingen konfigurera motsvarande miljövariabler eller ändra koden på rätt sätt för den nya plattformen eller värdtjänsten.

Ange ATT VS Code ska använda Kubernetes-tjänstmiljövariabler

Om du använder VS Code med en fjärrdator eller kör VS Code som en icke-administratörsanvändare måste du också konfigurera VS Code för att använda Kubernetes-tjänstmiljövariablerna. Öppna tasks.json, leta upp uppgiften med etiketten bridge-to-kubernetes.service och lägg till egenskapen usekubernetesServiceEnvironmentVariables med värdet true, enligt följande kod:

    "tasks": [
        {
            "label": "bridge-to-kubernetes.service",
            "type": "bridge-to-kubernetes.service",
            "service": "bikes",
            "ports": [
                3000
            ],
            "useKubernetesServiceEnvironmentVariables": true
        }
    ]

Ange att Visual Studio ska använda Kubernetes-tjänstmiljövariabler

Om du kör Visual Studio som icke-administratörsanvändare måste du också konfigurera Visual Studio för att använda Kubernetes-tjänstmiljövariablerna. Öppna launchSettings.json, leta reda på profilen med etiketten Bridge to Kubernetes och lägg till egenskapen useKubeServiceEnvironmentVariables med värdet true, enligt följande kod:

   "Bridge to Kubernetes": {
      "commandName": "AzureDevSpacesLocal",
      "launchBrowser": true,
      "useKubeServiceEnvironmentVariables": true
    }

Inställningen behövs bara om du kör VS Code eller Visual Studio som en icke-administratörsanvändare, eller om du använder en fjärrsession, men om du har ändrat koden enligt beskrivningen i den här artikeln är det ingen skada att ange den här egenskapen.

Nästa steg

Läs mer om Bridge to Kubernetes-konfiguration på Så här konfigurerar du Bridge to Kubernetes.