Istio är ett bekvämt verktyg för att ansluta, säkra och övervaka distribuerade applikationer. Istio använder en mängd olika tekniker för att köra och hantera programvara i stor skala, inklusive behållare för att paketera programkod och beroenden för distribution, och Kubernetes för att hantera dessa behållare. För att arbeta med Istio måste du därför veta hur en applikation med flera tjänster baserad på dessa teknologier fungerar без Istio. Om dessa verktyg och begrepp redan är bekanta för dig, hoppa gärna över denna handledning och gå direkt till avsnittet Installera Istio på Google Kubernetes Engine (GKE) eller installera ett tillägg Istio på GKE.
Det här är en steg-för-steg-guide där vi går igenom hela processen från källkod till GKE-behållare för att ge dig en grundläggande förståelse för dessa tekniker genom ett exempel. Du kommer också att se hur Istio utnyttjar kraften i dessa teknologier. Detta förutsätter att du inte vet något om behållare, Kubernetes, servicenät eller Istio.
uppgifter
I den här självstudien kommer du att slutföra följande uppgifter:
Lär dig en enkel hej världen-applikation med flera tjänster.
Kör programmet från källkoden.
Förpackning av applikationen i behållare.
Skapa ett Kubernetes-kluster.
Distribuera behållare i ett kluster.
Innan du börjar
Följ instruktionerna för att aktivera Kubernetes Engine API:
I den här handledningen kan du använda Cloud Shell, som förbereder den virtuella maskinen g1-small i Google Compute Engine med Debian-baserat Linux, eller en Linux- eller macOS-dator.
Alternativ A: Använda Cloud Shell
Fördelar med att använda Cloud Shell:
Python 2 och Python 3 utvecklingsmiljöer (inklusive virtualenv) är helt konfigurerade.
Kommandoradsverktyg gmoln, hamnarbetare, gå и kubectl, som vi kommer att använda är redan installerade.
Exempelapplikationen är skriven i Python och består av två komponenter som interagerar med hjälp av REST:
server: enkel server med en slutpunkt SKAFFA SIG, /, som skriver ut "hej världen" till konsolen.
loadgen: skript som skickar trafik till server, med ett konfigurerbart antal förfrågningar per sekund.
Kör ett program från källkoden
För att utforska exempelapplikationen, kör den i Cloud Shell eller på din dator.
1) I katalogen istio-samples/sample-apps/helloserver springa server:
python3 server/server.py
Vid start server följande visas:
INFO:root:Starting server...
2) Öppna ett annat terminalfönster att skicka förfrågningar till server. Om du använder Cloud Shell klickar du på lägg till-ikonen för att öppna en annan session.
3) Skicka en förfrågan till server:
curl http://localhost:8080
servern svarar:
Hello World!
4) Från katalogen där du laddade ner exempelkoden, gå till katalogen som innehåller loadgen:
cd YOUR_WORKING_DIRECTORY/istio-samples/sample-apps/helloserver/loadgen
Ur ett nätverksperspektiv körs hela applikationen på en enda värd (lokal dator eller Cloud Shell virtuell maskin). Därför kan du använda lokalvärdatt skicka förfrågningar till server.
10) Att sluta loadgen и server, stiga på Ctrl-c i varje terminalfönster.
11) I terminalfönstret loadgen avaktivera den virtuella miljön:
deactivate
Förpackning av en applikation i behållare
För att köra applikationen på GKE måste du paketera exempelapplikationen − server и loadgen - kl Behållare. En behållare är ett sätt att paketera en applikation för att isolera den från dess miljö.
För att paketera en applikation i en behållare behöver du Dockerfile. Dockerfile är en textfil som definierar kommandon för att bygga in programmets källkod och dess beroenden i Docker-bild. När den har byggts laddar du upp bilden till ett containerregister som Docker Hub eller Containerregistret.
Exemplet har redan gjort det Dockerfile för server и loadgen med alla nödvändiga kommandon för att samla in bilder. Nedan - Dockerfile för server:
FROM python:3-slim as base
FROM base as builder
RUN apt-get -qq update
&& apt-get install -y --no-install-recommends
g++
&& rm -rf /var/lib/apt/lists/*
# Enable unbuffered logging
FROM base as final
ENV PYTHONUNBUFFERED=1
RUN apt-get -qq update
&& apt-get install -y --no-install-recommends
wget
WORKDIR /helloserver
# Grab packages from builder
COPY --from=builder /usr/local/lib/python3.7/ /usr/local/lib/python3.7/
# Add the application
COPY . .
EXPOSE 8080
ENTRYPOINT [ "python", "server.py" ]
Team FRÅN python:3-smal som bas säger till Docker att använda den senaste Python 3 bild som bas.
Team KOPIERA. . kopierar källfilerna till den aktuella arbetskatalogen (endast i vårt fall server.py) till behållarens filsystem.
INKÖRSPORT definierar kommandot som används för att starta behållaren. I vårt fall är detta kommando nästan detsamma som det du brukade köra server.py från källkoden.
Team ÖVERSIKT indikerar att server väntar på data genom porten 8080. Det här laget är inte tillhandahåller hamnar. Detta är någon form av dokumentation som behövs för att öppna porten 8080 när du startar behållaren.
Förbereder för att behålla din ansökan
1) Ställ in följande miljövariabler. Byta ut PROJECT_ID till ditt GCP-projekt-ID.
export PROJECT_ID="PROJECT_ID"
export GCR_REPO="preparing-istio"
Använda värden PROJECT_ID и GCR_REPO du taggar Docker-bilden när du bygger den och skickar den till ett privat containerregister.
2) Ställ in standard GCP-projekt för kommandoradsverktyget gmoln.
gcloud config set project $PROJECT_ID
3) Ställ in standardzonen för kommandoradsverktyget gmoln.
gcloud config set compute/zone us-central1-b
4) Se till att Container Registry-tjänsten är aktiverad i GCP-projektet.
Granska listan över bilder i arkivet och kontrollera att bilderna har laddats upp:
gcloud container images list --repository gcr.io/$PROJECT_ID/preparing-istio
Kommandot visar namnen på de nyligen uppladdade bilderna:
NAME
gcr.io/PROJECT_ID/preparing-istio/helloserver
gcr.io/PROJECT_ID/preparing-istio/loadgen
Skapa ett GKE-kluster.
Dessa behållare kan köras på en Cloud Shell virtuell maskin eller på en dator med kommandot docker körning. Men i en produktionsmiljö behöver du ett sätt att centralt orkestrera containrar. Till exempel behöver du ett system som ser till att containrar alltid körs, och du behöver ett sätt att skala upp och spinna upp ytterligare containerinstanser om trafiken ökar.
För att köra containeriserade applikationer kan du använda G.K.E.. GKE är en containerorkestreringsplattform som samlar virtuella maskiner till ett kluster. Varje virtuell maskin kallas en nod. GKE-kluster är baserade på Kubernetes klusterhanteringssystem med öppen källkod. Kubernetes tillhandahåller mekanismer för att interagera med klustret.
Team gmoln skapar ett istioready-kluster i GCP-projektet och standardzonen som du angav. För att köra Istio rekommenderar vi att du har minst 4 noder och en virtuell maskin n1-standard-2.
Teamet skapar klustret på några minuter. När klustret är klart matar kommandot ut ungefär så här сообщение.
2) Ange autentiseringsuppgifter i kommandoradsverktyget kubectlför att använda den för att hantera klustret:
3) Nu kan du kommunicera med Kubernetes via kubectl. Till exempel kan följande kommando ta reda på status för noder:
kubectl get nodes
Kommandot producerar en lista med noder:
NAME STATUS ROLES AGE VERSION
gke-istoready-default-pool-dbeb23dc-1vg0 Ready <none> 99s v1.13.6-gke.13
gke-istoready-default-pool-dbeb23dc-36z5 Ready <none> 100s v1.13.6-gke.13
gke-istoready-default-pool-dbeb23dc-fj7s Ready <none> 99s v1.13.6-gke.13
gke-istoready-default-pool-dbeb23dc-wbjw Ready <none> 99s v1.13.6-gke.13
Kubernetes nyckelbegrepp
Diagrammet visar en applikation på GKE:
Innan du distribuerar behållare i GKE, lär dig nyckelkoncepten för Kubernetes. Det finns länkar i slutet om du vill veta mer.
Noder och kluster. I GKE är en nod en virtuell maskin. På andra Kubernetes-plattformar kan en nod vara en dator eller en virtuell maskin. Ett kluster är en samling noder som kan betraktas som en enda enhet där du distribuerar en containeriserad applikation.
Skida. I Kubernetes körs containrar i baljor. En Pod i Kubernetes är en odelbar enhet. En Pod rymmer en eller flera behållare. Du distribuerar servercontainrar och loadgen i separata baljor. När det finns flera behållare i en pod (till exempel en applikationsserver och proxyserver), hanteras behållare som en enda enhet och delar podresurser.
Utplaceringar. I Kubernetes är en distribution ett objekt som är en samling identiska pods. Implementeringen lanserar flera repliker av poddar fördelade över klusternoder. Implementeringen ersätter automatiskt pods som har misslyckats eller inte svarar.
Kubernetes tjänst. Vid körning av applikationskod i GKE är kopplingen mellan loadgen и server. När du startade tjänster på en Cloud Shell virtuell maskin eller skrivbord skickade du förfrågningar till server vid lokalvärd: 8080. När de har distribuerats till GKE, exekveras pods på tillgängliga noder. Som standard har du ingen kontroll över vilken nod podden körs på, så du baljor inga permanenta IP-adresser.
För att få en IP-adress för server, måste du definiera en nätverksabstraktion ovanpå poddarna. Det är vad det är Kubernetes tjänst. Kubernetes-tjänsten tillhandahåller en beständig slutpunkt för en uppsättning pods. Det finns några typer av tjänster. server användningsområden Lastbalanserare, som tillhandahåller en extern IP-adress att kontakta server från utanför klustret.
Kubernetes har också ett inbyggt DNS-system som tilldelar DNS-namn (t.ex. helloserver.default.cluster.local) tjänster. Tack vare detta kommunicerar pods inom klustret med andra pods i klustret på en konstant adress. DNS-namnet kan inte användas utanför klustret, till exempel i Cloud Shell eller på en dator.
Kubernetes manifesterar
När du körde programmet från källan använde du det imperativa kommandot python3
server.py
Imperativ innebär ett verb: "gör detta."
Kubernetes använder deklarativ modell. Det betyder att vi inte talar om för Kubernetes exakt vad de ska göra, utan snarare beskriver det önskade tillståndet. Till exempel startar och stoppar Kubernetes pods efter behov för att hålla systemets faktiska tillstånd överensstämmande med det önskade tillståndet.
Du anger önskat tillstånd i manifest eller filer YAML. En YAML-fil innehåller specifikationer för ett eller flera Kubernetes-objekt.
Exemplet innehåller en YAML-fil för server и loadgen. Varje YAML-fil anger önskat tillstånd för distributionsobjektet och Kubernetes-tjänsten.
Första fältet spec innehåller en beskrivning av önskat tillstånd.
spec.repliker indikerar önskat antal pods.
Avsnitt spec.mall definierar en podmall. Det finns ett fält i podspecifikationen bild, som anger namnet på bilden som måste extraheras från containerregistret.
Lastbalanserare: Klienter skickar förfrågningar till IP-adressen för lastbalanseraren, som har en beständig IP-adress och är tillgänglig utanför klustret.
targetPort: som ni minns, laget EXPONERA 8080 в Dockerfile tillhandahöll inte hamnar. Du tillhandahåller hamnen 8080så att du kan kontakta containern server utanför klustret. I vårat fall hellosvc.default.cluster.local:80 (kort namn: hellosvc) motsvarar porten 8080 Pod IP-adresser hej server.
port: Detta är portnumret dit andra tjänster i klustret kommer att skicka förfrågningar.
loadgen.yaml
Implementeringsobjekt mot loadgen.yaml ser ut som server.yaml. Skillnaden är att distributionsobjektet innehåller en sektion env. Den definierar de miljövariabler som behövs loadgen och som du installerade när du körde programmet från källan.
En gång loadgen accepterar inte inkommande förfrågningar för fältet Typ okänd ClusterIP. Denna typ tillhandahåller en beständig IP-adress som tjänster i klustret kan använda, men denna IP-adress är inte exponerad för externa klienter.
Byta ut PROJECT_ID till ditt GCP-projekt-ID.
9) Spara och stäng loadgen.yaml, stäng textredigeraren.
10) Distribuera YAML-filen till Kubernetes:
kubectl apply -f loadgen.yaml
Efter framgångsrikt slutförande producerar kommandot följande kod:
deployment.apps/loadgenerator created
service/loadgensvc created
11) Kontrollera statusen för poddarna:
kubectl get pods
Kommandot visar status:
NAME READY STATUS RESTARTS AGE
helloserver-69b9576d96-mwtcj 1/1 Running 0 58s
loadgenerator-774dbc46fb-gpbrz 1/1 Running 0 57s
12) Extrahera applikationsloggar från podden loadgen. Byta ut POD_ID till identifieraren från föregående svar.
kubectl logs loadgenerator-POD_ID
13) Skaffa externa IP-adresser hellosvc:
kubectl get service
Kommandosvaret ser ut ungefär så här:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
hellosvc LoadBalancer 10.81.15.158 192.0.2.1 80:31127/TCP 33m
kubernetes ClusterIP 10.81.0.1 <none> 443/TCP 93m
loadgensvc ClusterIP 10.81.15.155 <none> 80/TCP 4m52s
14) Skicka en förfrågan till hellosvc: byta ut EXTERN_IP till extern IP-adress hellosvc.
curl http://EXTERNAL_IP
Låt oss ta oss an Istio
Du har redan en applikation distribuerad till GKE. loadgen kan använda Kubernetes DNS (hellosvc:80) för att skicka förfrågningar till serveroch du kan skicka förfrågningar till server via extern IP-adress. Även om Kubernetes har många funktioner saknas det viss information om tjänsterna:
Hur interagerar tjänster? Vilka är relationerna mellan tjänsterna? Hur flyter trafiken mellan tjänsterna? Är du medveten om det loadgen skickar förfrågningar till server, men tänk dig att du inte vet något om applikationen. För att svara på dessa frågor, låt oss titta på listan över körande pods i GKE.
Metrik. Hur länge server svarar på en inkommande förfrågan? Hur många förfrågningar per sekund tas emot av servern? Ger den felmeddelanden?
Säkerhetsinformation. Trafik mellan loadgen и server bara passerar HTTP eller genom mTLS?
Istio svarar på alla dessa frågor. För att göra detta placerar Istio en sidovagnsproxy Sändebud i varje pod. Envoy-proxyn fångar upp all inkommande och utgående trafik till programbehållare. Det betyder att server и loadgen ta emot via sidovagnsproxy Envoy, och all trafik från loadgen к server går genom envoy proxy.
Anslutningar mellan Envoy-fullmakter bildar ett servicenät. Service mesh-arkitekturen ger ett lager av kontroll ovanpå Kubernetes.
Eftersom Envoy-proxyer körs i sina egna behållare kan Istio installeras ovanpå ett GKE-kluster utan nästan inga ändringar av applikationskoden. Men du har gjort en del arbete för att få din ansökan redo att hanteras av Istio:
Tjänster för alla containrar. Till distributioner server и loadgen knuten till Kubernetes-tjänsten. Även loadgen, som inte tar emot inkommande förfrågningar, det finns en tjänst.
Hamnar i tjänster måste ha namn. Även om serviceportar kan lämnas namnlösa i GKE, kräver Istio att du specificerar portnamn i enlighet med hans protokoll. I YAML-filen porten för server kallas httpeftersom servern använder protokollet HTTP. Om service Begagnade gRPC, skulle du namnge porten grpc.
Implementeringar är flaggade. Därför kan du använda Istios trafikhanteringsfunktioner, som att dela upp trafik mellan versioner av samma tjänst.
Installerar Istio
Det finns två sätt att installera Istio. Burk aktivera Istio på GKE-tillägget eller installera open source-versionen av Istio på klustret. Med Istio på GKE kan du enkelt hantera Istio-installationer och uppgraderingar under hela GKE-klustrets livscykel. Om du vill ha den senaste versionen av Istio eller mer kontroll över din Istio-kontrollpanelkonfiguration installerar du versionen med öppen källkod istället för tillägget Istio på GKE. För att bestämma tillvägagångssättet, läs artikeln Behöver jag Istio på GKE?.
Välj ett alternativ, läs lämplig guide och följ instruktionerna för att installera Istio på ditt kluster. Om du vill använda Istio med din nyligen distribuerade applikation, aktivera sidovagnsimplementering för namnutrymme standard.
rengöring
För att undvika att debiteras ditt Google Cloud Platform-konto för resurserna du använde i den här handledningen, ta bort containerklustret när du har installerat Istio och spelat med exempelapplikationen. Detta tar bort alla klusterresurser, såsom beräkningsinstanser, diskar och nätverksresurser.