Istio er et praktisk værktøj til at forbinde, sikre og overvåge distribuerede applikationer. Istio bruger en række teknologier til at køre og administrere software i stor skala, herunder containere til at pakke applikationskode og afhængigheder til implementering, og Kubernetes til at administrere disse containere. For at arbejde med Istio skal du derfor vide, hvordan en applikation med flere tjenester baseret på disse teknologier fungerer без Istio. Hvis disse værktøjer og koncepter allerede er bekendt for dig, er du velkommen til at springe denne tutorial over og gå direkte til afsnittet Installation af Istio på Google Kubernetes Engine (GKE) eller installere en udvidelse Istio på GKE.
Dette er en trin-for-trin guide, hvor vi vil gennemgå hele processen fra kildekode til GKE container, så du får en grundlæggende forståelse af disse teknologier med et eksempel. Du vil også se, hvordan Istio udnytter kraften i disse teknologier. Dette forudsætter, at du ikke ved noget om containere, Kubernetes, servicemasker eller Istio.
opgaver
I denne øvelse skal du udføre følgende opgaver:
Lær en simpel hej verden-applikation med flere tjenester.
Kør programmet fra kildekoden.
Emballering af applikationen i beholdere.
Oprettelse af en Kubernetes-klynge.
Implementering af containere i en klynge.
Før du starter
Følg instruktionerne for at aktivere Kubernetes Engine API:
I denne vejledning kan du bruge Cloud Shell, som forbereder den virtuelle maskine g1-small i Google Compute Engine med Debian-baseret Linux eller en Linux- eller macOS-computer.
Mulighed A: Brug af Cloud Shell
Fordele ved at bruge Cloud Shell:
Python 2 og Python 3 udviklingsmiljøer (inklusive virtualenv) er fuldt konfigureret.
Kommandolinjeværktøjer gcloud, havnearbejder, git и kubectl, som vi vil bruge, er allerede installeret.
Eksempelapplikationen er skrevet i Python og består af to komponenter, der interagerer vha REST:
server: simpel server med ét slutpunkt FÅ, /, som udskriver "hello world" til konsollen.
loadgen: script, der sender trafik til server, med et konfigurerbart antal anmodninger pr. sekund.
Kører et program fra kildekoden
For at udforske eksempelapplikationen skal du køre den i Cloud Shell eller på din computer.
1) I kataloget istio-samples/sample-apps/helloserver løb server:
python3 server/server.py
Ved opstart server følgende vises:
INFO:root:Starting server...
2) Åbn et andet terminalvindue for at sende anmodninger til server. Hvis du bruger Cloud Shell, skal du klikke på tilføjelsesikonet for at åbne en anden session.
3) Send en anmodning til server:
curl http://localhost:8080
server svarer:
Hello World!
4) Fra den mappe, hvor du downloadede prøvekoden, skal du gå til den mappe, der indeholder loadgen:
cd YOUR_WORKING_DIRECTORY/istio-samples/sample-apps/helloserver/loadgen
Fra et netværksperspektiv kører hele applikationen på en enkelt vært (lokal computer eller Cloud Shell virtuel maskine). Derfor kan du bruge localhostat sende anmodninger til server.
10) At stoppe loadgen и server, gå ind Ctrl-c i hvert terminalvindue.
11) I terminalvinduet loadgen deaktiver det virtuelle miljø:
deactivate
Emballering af en applikation i containere
For at køre applikationen på GKE skal du pakke eksempelapplikationen − server и loadgen - ind containere. En container er en måde at pakke et program på for at isolere det fra dets miljø.
For at pakke en applikation ind i en container, skal du bruge Dockerfil. Dockerfil er en tekstfil, der definerer kommandoer til indbygning af applikationens kildekode og dens afhængigheder Docker billede. Når det er bygget, uploader du billedet til et containerregister såsom Docker Hub eller Containerregister.
Eksemplet har allerede Dockerfil for server и loadgen med alle de nødvendige kommandoer til at indsamle billeder. Nedenfor - Dockerfil for 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 FRA python:3-slank som base fortæller Docker at bruge den nyeste Python 3 billede som base.
Team KOPI. . kopierer kildefilerne til den aktuelle arbejdsmappe (kun i vores tilfælde server.py) til containerens filsystem.
INDGANG definerer den kommando, der bruges til at starte containeren. I vores tilfælde er denne kommando næsten den samme som den, du plejede at køre server.py fra kildekoden.
Team UDSÆTTE indikerer det server venter på data gennem porten 8080. Dette hold er ikke giver havne. Dette er en form for dokumentation, der er nødvendig for at åbne porten 8080 ved start af beholderen.
Forbereder på at containerisere din ansøgning
1) Indstil følgende miljøvariabler. Erstatte PROJECT_ID til dit GCP-projekt-id.
export PROJECT_ID="PROJECT_ID"
export GCR_REPO="preparing-istio"
Brug af værdier PROJECT_ID и GCR_REPO du mærker Docker-billedet, når du bygger det, og skubber det til et privat containerregister.
2) Indstil standard GCP-projektet for kommandolinjeværktøjet gcloud.
gcloud config set project $PROJECT_ID
3) Indstil standardzonen for kommandolinjeværktøjet gcloud.
gcloud config set compute/zone us-central1-b
4) Sørg for, at Container Registry-tjenesten er aktiveret i GCP-projektet.
Gennemgå listen over billeder i depotet, og bekræft, at billederne er blevet uploadet:
gcloud container images list --repository gcr.io/$PROJECT_ID/preparing-istio
Kommandoen viser navnene på de nyligt uploadede billeder:
NAME
gcr.io/PROJECT_ID/preparing-istio/helloserver
gcr.io/PROJECT_ID/preparing-istio/loadgen
Oprettelse af en GKE-klynge.
Disse containere kunne køres på en Cloud Shell virtuel maskine eller på en computer med kommandoen docker løb. Men i et produktionsmiljø har du brug for en måde at orkestrere containere centralt på. For eksempel har du brug for et system, der sørger for, at containere altid kører, og du har brug for en måde at opskalere og spinne op på yderligere containerforekomster, hvis trafikken stiger.
For at køre containeriserede applikationer kan du bruge G.K.E.. GKE er en container-orkestreringsplatform, der samler virtuelle maskiner i en klynge. Hver virtuel maskine kaldes en node. GKE-klynger er baseret på open source Kubernetes klyngestyringssystem. Kubernetes leverer mekanismer til at interagere med klyngen.
Team gcloud opretter en istioready-klynge i det GCP-projekt og standardzone, du har angivet. For at køre Istio anbefaler vi at have mindst 4 noder og en virtuel maskine n1-standard-2.
Holdet opretter klyngen på få minutter. Når klyngen er klar, udsender kommandoen noget som dette сообщение.
2) Angiv legitimationsoplysninger i kommandolinjeværktøjet kubectlfor at bruge det til at administrere klyngen:
3) Nu kan du kommunikere med Kubernetes via kubectl. For eksempel kan følgende kommando finde ud af status for noder:
kubectl get nodes
Kommandoen producerer en liste over 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 nøglebegreber
Diagrammet viser en applikation på GKE:
Før du implementerer containere i GKE, skal du lære nøglebegreberne i Kubernetes. Der er links til allersidst, hvis du vil vide mere.
Noder og klynger. I GKE er en node en virtuel maskine. På andre Kubernetes-platforme kan en node være en computer eller en virtuel maskine. En klynge er en samling af noder, der kan betragtes som en enkelt enhed, hvor du implementerer en containeriseret applikation.
Bælge. I Kubernetes kører containere i bælg. En Pod i Kubernetes er en udelelig enhed. En Pod rummer en eller flere beholdere. Du implementerer servercontainere og loadgen i separate bælg. Når der er flere beholdere i en pod (for eksempel en applikationsserver og proxyserver), administreres containere som en enkelt enhed og deler pod-ressourcer.
Implementeringer. I Kubernetes er en implementering et objekt, der er en samling af identiske pods. Implementering lancerer flere replikaer af pods fordelt på tværs af klynge noder. Implementering erstatter automatisk pods, der har fejlet eller ikke reagerer.
Kubernetes tjeneste. Når du kører applikationskode i GKE, er forbindelsen mellem loadgen и server. Da du startede tjenester på en Cloud Shell virtuel maskine eller desktop, sendte du anmodninger til server ved localhost: 8080. Når de er installeret til GKE, udføres pods på tilgængelige noder. Som standard har du ingen kontrol over, hvilken node poden kører på, så du bælg ingen permanente IP-adresser.
For at få en IP-adresse til server, skal du definere en netværksabstraktion oven på bælgerne. Det er, hvad det er Kubernetes tjeneste. Kubernetes-tjenesten giver et vedvarende slutpunkt for et sæt pods. Der er et par stykker typer af tjenester. server bruger LoadBalancer, som giver en ekstern IP-adresse at kontakte server uden for klyngen.
Kubernetes har også et indbygget DNS-system, der tildeler DNS-navne (f.eks. helloserver.default.cluster.local) tjenester. Takket være dette kommunikerer pods i klyngen med andre pods i klyngen på en konstant adresse. DNS-navnet kan ikke bruges uden for klyngen, f.eks. i Cloud Shell eller på en computer.
Kubernetes manifesterer sig
Når du kørte programmet fra kilden, brugte du den imperative kommando python3
server.py
Imperativ indebærer et verbum: "gør dette."
Kubernetes bruger deklarativ model. Det betyder, at vi ikke fortæller Kubernetes præcist, hvad de skal gøre, men beskriver snarere den ønskede tilstand. For eksempel starter og stopper Kubernetes pods efter behov for at holde systemets faktiske tilstand i overensstemmelse med den ønskede tilstand.
Du angiver den ønskede tilstand i manifester eller filer YAML. En YAML-fil indeholder specifikationer for et eller flere Kubernetes-objekter.
Eksemplet indeholder en YAML-fil til server и loadgen. Hver YAML-fil angiver den ønskede tilstand for installationsobjektet og Kubernetes-tjenesten.
Første felt spec indeholder en beskrivelse af den ønskede tilstand.
spec.replikaer angiver det ønskede antal pods.
Sektion spec.skabelon definerer en pod-skabelon. Der er et felt i pod-specifikationen billede, som angiver navnet på det billede, der skal udtrækkes fra containerregistret.
LoadBalancer: Klienter sender anmodninger til IP-adressen på belastningsbalanceren, som har en vedvarende IP-adresse og er tilgængelig uden for klyngen.
targetPort: som du husker, holdet UDSÆT 8080 в Dockerfil leverede ikke havne. Du leverer havnen 8080så du kan kontakte containeren server uden for klyngen. I vores tilfælde hellosvc.default.cluster.local:80 (kort navn: hellosvc) svarer til porten 8080 Pods IP-adresser hej server.
port: Dette er portnummeret, hvor andre tjenester i klyngen sender anmodninger.
loadgen.yaml
Implementeringsobjekt til loadgen.yaml ligner server.yaml. Forskellen er, at implementeringsobjektet indeholder en sektion env. Den definerer de miljøvariabler, der er nødvendige loadgen og som du installerede, da du kørte programmet fra kilden.
tid loadgen accepterer ikke indgående forespørgsler for feltet typen ukendt ClusterIP. Denne type giver en vedvarende IP-adresse, som tjenester i klyngen kan bruge, men denne IP-adresse er ikke eksponeret for eksterne klienter.
Erstatte PROJECT_ID til dit GCP-projekt-id.
9) Gem og luk loadgen.yaml, luk teksteditoren.
10) Implementer YAML-filen til Kubernetes:
kubectl apply -f loadgen.yaml
Efter vellykket afslutning producerer kommandoen følgende kode:
deployment.apps/loadgenerator created
service/loadgensvc created
11) Tjek status for pods:
kubectl get pods
Kommandoen viser status:
NAME READY STATUS RESTARTS AGE
helloserver-69b9576d96-mwtcj 1/1 Running 0 58s
loadgenerator-774dbc46fb-gpbrz 1/1 Running 0 57s
12) Udtræk applikationslogfiler fra poden loadgen. Erstatte POD_ID til identifikatoren fra det forrige svar.
kubectl logs loadgenerator-POD_ID
13) Få eksterne IP-adresser hellosvc:
kubectl get service
Kommandosvaret ser nogenlunde sådan ud:
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) Send en anmodning til hellosvc: udskift EKSTERN_IP til ekstern IP-adresse hellosvc.
curl http://EXTERNAL_IP
Lad os tage imod Istio
Du har allerede en applikation implementeret til GKE. loadgen kan bruge Kubernetes DNS (hellosvc:80) for at sende anmodninger til serverog du kan sende anmodninger til server ved ekstern IP-adresse. Selvom Kubernetes har mange funktioner, mangler der nogle oplysninger om tjenesterne:
Hvordan interagerer tjenester? Hvad er relationerne mellem tjenester? Hvordan flyder trafikken mellem tjenesterne? Er du klar over det loadgen sender anmodninger til server, men forestil dig, at du ikke ved noget om applikationen. For at besvare disse spørgsmål, lad os se på listen over kørende pods i GKE.
Metrics. Hvor længe server svarer på en indgående anmodning? Hvor mange anmodninger per sekund modtages af serveren? Giver den fejlmeddelelser?
Sikkerhedsoplysninger. Trafik mellem loadgen и server bare passerer igennem HTTP eller ved mTLS?
Istio besvarer alle disse spørgsmål. For at gøre dette placerer Istio en sidevognsproxy udsending i hver pod. Envoy-proxyen opsnapper al indgående og udgående trafik til applikationscontainere. Det betyder at server и loadgen modtage via sidevogn proxy Envoy, og al trafik fra loadgen к server går gennem envoy proxy.
Forbindelser mellem envoy fuldmagter danner et servicenet. Servicemesh-arkitekturen giver et lag af kontrol oven på Kubernetes.
Da Envoy proxyer kører i deres egne containere, kan Istio installeres oven på en GKE-klynge næsten uden ændringer i applikationskoden. Men du har gjort noget arbejde for at gøre din ansøgning klar til at blive administreret af Istio:
Service til alle containere. Til udrulninger server и loadgen knyttet til Kubernetes-tjenesten. Også selvom loadgen, som ikke modtager indgående forespørgsler, er der en service.
Havne i tjenester skal have navne. Selvom serviceporte kan efterlades unavngivne i GKE, kræver Istio, at du specificerer portnavn i overensstemmelse med hans protokol. I YAML-filen porten for server kaldet httpfordi serveren bruger protokollen HTTP. Hvis tjeneste Brugt gRPC, ville du navngive havnen grpc.
Implementeringer er markeret. Derfor kan du bruge Istios trafikstyringsfunktioner, såsom at opdele trafik mellem versioner af samme tjeneste.
Installation
Der er to måder at installere Istio på. Kan aktiver Istio på GKE-udvidelsen eller installer open source-versionen af Istio på klyngen. Med Istio på GKE kan du nemt administrere Istio-installationer og opgraderinger gennem hele GKE-klyngens livscyklus. Hvis du vil have den nyeste version af Istio eller mere kontrol over din Istio-kontrolpanelkonfiguration, skal du installere open source-versionen i stedet for Istio på GKE-udvidelsen. For at beslutte dig for tilgangen, læs artiklen Har jeg brug for Istio på GKE?.
Vælg en mulighed, gennemgå den relevante vejledning, og følg instruktionerne for at installere Istio på din klynge. Hvis du vil bruge Istio med din nyligt implementerede applikation, muliggør implementering af sidevogn til navneområde standard.
Очистка
For at undgå at blive debiteret din Google Cloud Platform-konto for de ressourcer, du brugte i dette selvstudie, skal du slette containerklyngen, når du har installeret Istio og spillet med eksempelapplikationen. Dette vil fjerne alle klyngresourcer, såsom computerforekomster, diske og netværksressourcer.