Istio er et praktisk verktøy for å koble til, sikre og overvåke distribuerte applikasjoner. Istio bruker en rekke teknologier for å kjøre og administrere programvare i stor skala, inkludert containere for å pakke applikasjonskode og avhengigheter for distribusjon, og Kubernetes for å administrere disse containerne. For å jobbe med Istio må du derfor vite hvordan en applikasjon med flere tjenester basert på disse teknologiene fungerer без Istio. Hvis disse verktøyene og konseptene allerede er kjent for deg, kan du gjerne hoppe over denne opplæringen og gå rett til delen Installere Istio på Google Kubernetes Engine (GKE) eller installere en utvidelse Istio på GKE.
Dette er en trinn-for-trinn-guide hvor vi vil gå gjennom hele prosessen fra kildekode til GKE-beholder for å gi deg en grunnleggende forståelse av disse teknologiene gjennom et eksempel. Du vil også se hvordan Istio utnytter kraften til disse teknologiene. Dette forutsetter at du ikke vet noe om containere, Kubernetes, servicemasker eller Istio.
oppgaver
I denne opplæringen skal du fullføre følgende oppgaver:
Lær en enkel hei verden-applikasjon med flere tjenester.
Kjør programmet fra kildekoden.
Pakke søknaden i beholdere.
Opprette en Kubernetes-klynge.
Utplassering av containere i en klynge.
Før du begynner
Følg instruksjonene for å aktivere Kubernetes Engine API:
I denne opplæringen kan du bruke Cloud Shell, som forbereder den virtuelle maskinen g1-small i Google Compute Engine med Debian-basert Linux, eller en Linux- eller macOS-datamaskin.
Alternativ A: Bruke Cloud Shell
Fordeler med å bruke Cloud Shell:
Python 2 og Python 3 utviklingsmiljøer (inkludert virtualenv) er fullt konfigurert.
Kommandolinjeverktøy gcloud, Docker, git и kubectl, som vi skal bruke, er allerede installert.
Eksempelapplikasjonen er skrevet i Python og består av to komponenter som samhandler vha REST:
server: enkel server med ett endepunkt FÅ, /, som skriver ut "hello world" til konsollen.
loadgen: skript som sender trafikk til server, med et konfigurerbart antall forespørsler per sekund.
Kjøre et program fra kildekoden
For å utforske eksempelapplikasjonen, kjør den i Cloud Shell eller på datamaskinen din.
1) I katalogen istio-samples/sample-apps/helloserver løpe server:
python3 server/server.py
Ved oppstart server følgende vises:
INFO:root:Starting server...
2) Åpne et annet terminalvindu for å sende forespørsler til server. Hvis du bruker Cloud Shell, klikker du på legg til-ikonet for å åpne en ny økt.
3) Send en forespørsel til server:
curl http://localhost:8080
server svarer:
Hello World!
4) Fra katalogen der du lastet ned eksempelkoden, gå til katalogen som inneholder loadgen:
cd YOUR_WORKING_DIRECTORY/istio-samples/sample-apps/helloserver/loadgen
Fra et nettverksperspektiv kjører hele applikasjonen på en enkelt vert (lokal datamaskin eller Cloud Shell virtuell maskin). Derfor kan du bruke localhostå sende forespørsler til server.
10) Å stoppe loadgen и server, Tast inn Ctrl-c i hvert terminalvindu.
11) I terminalvinduet loadgen deaktiver det virtuelle miljøet:
deactivate
Pakke en applikasjon i containere
For å kjøre applikasjonen på GKE, må du pakke eksempelapplikasjonen − server и loadgen - inn Containere. En beholder er en måte å pakke en applikasjon for å isolere den fra miljøet.
For å pakke en applikasjon inn i en beholder, trenger du Dockerfile. Dockerfile er en tekstfil som definerer kommandoer for å bygge applikasjonens kildekode og dens avhengigheter inn i Docker-bilde. Når det er bygget, laster du opp bildet til et containerregister som Docker Hub eller Beholderregister.
Eksemplet har allerede Dockerfile for server и loadgen med alle nødvendige kommandoer for å samle bilder. Nedenfor - Dockerfile 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" ]
Lag FRA python:3-slank som base ber Docker om å bruke det siste Python 3 bilde som en base.
Lag KOPIERE. . kopierer kildefilene til gjeldende arbeidskatalog (bare i vårt tilfelle server.py) til beholderens filsystem.
INNGANGSPUNKT definerer kommandoen som brukes til å starte beholderen. I vårt tilfelle er denne kommandoen nesten den samme som den du pleide å kjøre server.py fra kildekoden.
Lag AVDEKKE indikerer det server venter på data gjennom porten 8080. Dette laget er ikke gir havner. Dette er en slags dokumentasjon som trengs for å åpne porten 8080 når du starter beholderen.
Forbereder på å containerisere søknaden din
1) Angi følgende miljøvariabler. Erstatte PROJECT_ID til GCP-prosjekt-ID-en din.
export PROJECT_ID="PROJECT_ID"
export GCR_REPO="preparing-istio"
Bruke verdier PROJECT_ID и GCR_REPO du merker Docker-bildet når du bygger det og skyver det til et privat containerregister.
2) Angi standard GCP-prosjekt for kommandolinjeverktøyet gcloud.
gcloud config set project $PROJECT_ID
3) Angi standardsonen for kommandolinjeverktøyet gcloud.
gcloud config set compute/zone us-central1-b
4) Sørg for at Container Registry-tjenesten er aktivert i GCP-prosjektet.
Se gjennom listen over bilder i depotet og kontroller at bildene er lastet opp:
gcloud container images list --repository gcr.io/$PROJECT_ID/preparing-istio
Kommandoen viser navnene på de nylig opplastede bildene:
NAME
gcr.io/PROJECT_ID/preparing-istio/helloserver
gcr.io/PROJECT_ID/preparing-istio/loadgen
Opprette en GKE-klynge.
Disse beholderne kan kjøres på en Cloud Shell virtuell maskin eller på en datamaskin med kommandoen docker kjøre. Men i et produksjonsmiljø trenger du en måte å sentralt orkestrere containere. Du trenger for eksempel et system som sørger for at containere alltid kjører, og du trenger en måte å skalere opp og spinne opp flere containerforekomster på hvis trafikken øker.
For å kjøre containeriserte applikasjoner kan du bruke G.K.E.. GKE er en containerorkestreringsplattform som samler virtuelle maskiner til en klynge. Hver virtuell maskin kalles en node. GKE-klynger er basert på åpen kildekode Kubernetes klyngestyringssystem. Kubernetes gir mekanismer for å samhandle med klyngen.
Lag gcloud oppretter en istioready-klynge i GCP-prosjektet og standardsonen du spesifiserte. For å kjøre Istio anbefaler vi å ha minst 4 noder og en virtuell maskin n1-standard-2.
Teamet oppretter klyngen på noen få minutter. Når klyngen er klar, vil kommandoen gi noe sånt som dette сообщение.
2) Oppgi legitimasjon i kommandolinjeverktøyet kubectlfor å bruke den til å administrere klyngen:
3) Nå kan du kommunisere med Kubernetes via kubectl. For eksempel kan følgende kommando finne ut statusen til noder:
kubectl get nodes
Kommandoen produserer 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økkelkonsepter
Diagrammet viser en applikasjon på GKE:
Før du distribuerer containere i GKE, lær deg nøkkelkonseptene til Kubernetes. Det er lenker helt på slutten hvis du vil lære mer.
Noder og klynger. I GKE er en node en virtuell maskin. På andre Kubernetes-plattformer kan en node være en datamaskin eller en virtuell maskin. En klynge er en samling av noder som kan betraktes som en enkelt enhet der du distribuerer en containerisert applikasjon.
Pods. I Kubernetes kjører containere i belg. En Pod i Kubernetes er en udelelig enhet. En Pod har en eller flere beholdere. Du distribuerer servercontainere og loadgen i separate belg. Når det er flere beholdere i en pod (for eksempel en applikasjonsserver og proxy-server), beholdere administreres som en enkelt enhet og deler pod-ressurser.
Implementeringer. I Kubernetes er en distribusjon et objekt som er en samling av identiske pods. Implementering lanserer flere replikaer av pods fordelt på klyngenoder. Implementering erstatter automatisk pods som har mislyktes eller ikke svarer.
Kubernetes tjeneste. Når du kjører applikasjonskode i GKE, er forbindelsen mellom loadgen и server. Når du startet tjenester på en Cloud Shell virtuell maskin eller skrivebord, sendte du forespørsler til server ved localhost: 8080. Når de er distribuert til GKE, kjøres pods på tilgjengelige noder. Som standard har du ingen kontroll over hvilken node poden kjører på, så du belger ingen permanente IP-adresser.
For å få en IP-adresse for server, må du definere en nettverksabstraksjon på toppen av podene. Det er det det er Kubernetes tjeneste. Kubernetes-tjenesten gir et vedvarende endepunkt for et sett med pods. Det er noen få typer tjenester. server bruker LoadBalancer, som gir en ekstern IP-adresse å kontakte server fra utenfor klyngen.
Kubernetes har også et innebygd DNS-system som tildeler DNS-navn (f.eks. helloserver.default.cluster.local) tjenester. Takket være dette kommuniserer poder i klyngen med andre poder i klyngen på en permanent adresse. DNS-navnet kan ikke brukes utenfor klyngen, for eksempel i Cloud Shell eller på en datamaskin.
Kubernetes manifesterer seg
Når du kjørte programmet fra kilden, brukte du imperative kommandoen python3
server.py
Imperativ innebærer et verb: "gjør dette."
Kubernetes bruker deklarativ modell. Dette betyr at vi ikke forteller Kubernetes nøyaktig hva de skal gjøre, men heller beskriver ønsket tilstand. For eksempel starter og stopper Kubernetes pods etter behov for å sikre at den faktiske tilstanden til systemet samsvarer med ønsket tilstand.
Du angir ønsket tilstand i manifester eller filer YAML. En YAML-fil inneholder spesifikasjoner for ett eller flere Kubernetes-objekter.
Eksemplet inneholder en YAML-fil for server и loadgen. Hver YAML-fil spesifiserer ønsket tilstand for distribusjonsobjektet og Kubernetes-tjenesten.
Første felt spec inneholder en beskrivelse av ønsket tilstand.
spes.replikaer indikerer ønsket antall pods.
Seksjon spec.mal definerer en pod-mal. Det er et felt i pod-spesifikasjonen bilde, som spesifiserer navnet på bildet som må trekkes ut fra containerregisteret.
LoadBalancer: Klienter sender forespørsler til IP-adressen til lastbalanseren, som har en vedvarende IP-adresse og er tilgjengelig fra utenfor klyngen.
targetPort: som du husker, laget UTSTILL 8080 в Dockerfile ga ikke porter. Du oppgir porten 8080slik at du kan kontakte containeren server utenfor klyngen. I vårt tilfelle hellosvc.default.cluster.local:80 (kort navn: hellosvc) tilsvarer porten 8080 Pod IP-adresser hei server.
havn: Dette er portnummeret der andre tjenester i klyngen vil sende forespørsler.
loadgen.yaml
Distribusjonsobjekt til loadgen.yaml ser ut som server.yaml. Forskjellen er at distribusjonsobjektet inneholder en seksjon env. Den definerer miljøvariablene som er nødvendige loadgen og som du installerte når du kjørte programmet fra kilden.
En gang loadgen godtar ikke innkommende forespørsler for feltet typen ukjent ClusterIP. Denne typen gir en vedvarende IP-adresse som tjenester i klyngen kan bruke, men denne IP-adressen er ikke eksponert for eksterne klienter.
Erstatte PROJECT_ID til GCP-prosjekt-ID-en din.
9) Lagre og lukk loadgen.yaml, lukk tekstredigeringsprogrammet.
10) Distribuer YAML-filen til Kubernetes:
kubectl apply -f loadgen.yaml
Etter vellykket fullføring produserer kommandoen følgende kode:
deployment.apps/loadgenerator created
service/loadgensvc created
11) Sjekk statusen til podene:
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) Trekk ut applikasjonslogger fra poden loadgen. Erstatte POD_ID til identifikatoren fra forrige svar.
kubectl logs loadgenerator-POD_ID
13) Skaff eksterne IP-adresser hellosvc:
kubectl get service
Kommandoresponsen ser omtrent slik ut:
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 forespørsel til hellosvc: erstatte EXTERNAL_IP til ekstern IP-adresse hellosvc.
curl http://EXTERNAL_IP
La oss ta på Istio
Du har allerede en applikasjon distribuert til GKE. loadgen kan bruke Kubernetes DNS (hellosvc:80) for å sende forespørsler til serverog du kan sende forespørsler til server etter ekstern IP-adresse. Selv om Kubernetes har mange funksjoner, mangler det noe informasjon om tjenestene:
Hvordan samhandler tjenester? Hva er relasjonene mellom tjenestene? Hvordan flyter trafikken mellom tjenestene? Er du klar over det loadgen sender forespørsler til server, men tenk deg at du ikke vet noe om applikasjonen. For å svare på disse spørsmålene, la oss se på listen over løpende pods i GKE.
Beregninger. Hvor lenge server svarer på en innkommende forespørsel? Hvor mange forespørsler per sekund mottas av serveren? Gir den feilmeldinger?
Sikkerhetsinformasjon. Trafikk mellom loadgen и server bare går gjennom HTTP eller av mTLS?
Istio svarer på alle disse spørsmålene. For å gjøre dette, plasserer Istio en sidevogn-proxy Envoy i hver pod. Envoy-proxyen fanger opp all innkommende og utgående trafikk til applikasjonsbeholdere. Det betyr at server и loadgen motta via sidevogn proxy Envoy, og all trafikk fra loadgen к server går gjennom envoy proxy.
Forbindelser mellom envoy-fullmakter danner et servicenettverk. Tjenestenett-arkitekturen gir et lag med kontroll på toppen av Kubernetes.
Siden Envoy-proxyer kjører i sine egne containere, kan Istio installeres på toppen av en GKE-klynge med nesten ingen endringer i applikasjonskoden. Men du har gjort litt arbeid for å gjøre applikasjonen klar til å bli administrert av Istio:
Tjenester for alle containere. Til utplasseringer server и loadgen knyttet til Kubernetes-tjenesten. Til og med loadgen, som ikke mottar innkommende forespørsler, er det en tjeneste.
Porter i tjenester må ha navn. Selv om tjenesteporter kan stå uten navn i GKE, krever Istio at du spesifiserer portnavn i samsvar med hans protokoll. I YAML-filen porten for server kalt httpfordi serveren bruker protokollen HTTP. Hvis tjeneste brukt gRPC, vil du navngi porten grpc.
Implementeringer er flagget. Derfor kan du bruke Istios trafikkstyringsfunksjoner, som å dele trafikk mellom versjoner av samme tjeneste.
Installerer Istio
Det er to måter å installere Istio på. Kan aktiver Istio på GKE-utvidelsen eller installer åpen kildekode-versjon av Istio på klyngen. Med Istio på GKE kan du enkelt administrere Istio-installasjoner og oppgraderinger gjennom hele GKE-klyngens livssyklus. Hvis du vil ha den nyeste versjonen av Istio eller mer kontroll over konfigurasjonen av Istio-kontrollpanelet, installer åpen kildekode-versjonen i stedet for Istio on GKE-utvidelsen. For å bestemme tilnærmingen, les artikkelen Trenger jeg Istio på GKE?.
Velg et alternativ, se gjennom den aktuelle veiledningen og følg instruksjonene for å installere Istio på klyngen din. Hvis du ønsker å bruke Istio med din nylig distribuerte applikasjon, aktiver sidevognimplementering for navneområde standard~~POS=TRUNC.
rengjøring
For å unngå å bli belastet Google Cloud Platform-kontoen din for ressursene du brukte i denne opplæringen, slett containerklyngen når du har installert Istio og spilt med eksempelapplikasjonen. Dette vil fjerne alle klyngeressurser, for eksempel dataforekomster, disker og nettverksressurser.