🥇Förberedelse av applikationen för Istio

Istio är ett användarvänligt verktyg för att koppla samman, skydda och övervaka distribuerade applikationer. Istio använder olika teknologier för att driftsätta och hantera programvara i stor skala, inklusive containrar för att paketera applikationskod och dess beroenden för driftsättning samt Kubernetes för att hantera dessa containrar. Därför, för att arbeta med Istio bör du känna till hur en applikation med flera tjänster baserat på dessa teknologier fungerar. utan Istio. Om dessa verktyg och begrepp redan är bekanta för dig, kan du gärna hoppa över denna guide och gå direkt till avsnittet. Installation av Istio på Google Kubernetes Engine (GKE) eller installation av tillägg Istio på GKE.

Detta är en steg-för-steg-guide där vi går igenom hela processen från källkod till container på GKE, så att du får en grundläggande förståelse för dessa teknologier genom ett exempel. Du kommer också att se hur Istio utnyttjar möjligheterna med dessa teknologier. Det förutsätts att du inte har någon kunskap om containrar, Kubernetes, service mesh eller Istio.

Uppgifter

I denna guide kommer du att utföra följande uppgifter:

Utforska en enkel hello world-applikation med flera tjänster.
Köra applikationen från källkoden.
Packa applikationen i containrar.
Skapa en Kubernetes-kluster.
Distribuera containrar till klustret.

Innan du börjar

Följ instruktionerna för att aktivera Kubernetes Engine API:

Gå till Kubernetes Engine-sidan i Google Cloud Platform-konsolen.
Skapa eller välj ett projekt.
Vänta tills API och relaterade tjänster aktiveras. Det kan ta några minuter.
Se till att fakturering är aktiverad för Google Cloud Platform-projektet. Lär dig hur du aktiverar fakturering.

I denna guide kan du använda Cloud Shell, som förbereder en virtuell maskin g1-small i Google Compute Engine med Linux baserat på Debian, eller en dator med Linux eller macOS.

Alternativ A: använda Cloud Shell

Fördelar med att använda Cloud Shell:

Utvecklingsmiljöer för Python 2 och Python 3 (inklusive virtualenv) är helt konfigurerade.
Kommandoradsverktyg gcloud, docker, git och kubectl, som vi kommer att använda, är redan installerade.
Du har flera val av textredigerare.:
1. Kodredigeraren, som öppnas med redigeringsikonen högst upp i Cloud Shell-fönstret.
2. Emacs, Vim eller Nano, som öppnas från kommandoraden i Cloud Shell.

För att använda Cloud Shell:

Gå till GCP-konsolen.
Klicka på knappen Aktivera Cloud Shell (Aktivera Cloud Shell) högst upp i GCP konsolfönster.

I den nedre delen av GCP-konsolen öppnas en Cloud Shell-session med kommandoraden i ett nytt fönster.

Alternativ B: använda kommandoradsverktyg lokalt

Om du arbetar på en dator med Linux eller macOS måste du konfigurera och installera följande komponenter:

Konfigurera Python 3- och Python 2-utvecklingsmiljö.
Installera Cloud SDK med kommandoradsverktyget gcloud.
Installera kubectl — kommandoradsverktyget för att arbeta med Kubernetes.
```
gcloud components install kubectl
```
Installera Docker Community Edition (CE). Du kommer att använda kommandoradsverktyget docker, för att skapa containerbilder för exempelapplikationen.
Installera verktyget versionskontrollsystemet Git, för att hämta exempelapplikationen från GitHub.

Nedladdning av exempel på kod

Ladda ner källkoden helloserver:

git clone https://github.com/GoogleCloudPlatform/istio-samples

Navigera till katalogen för exempel på kod:
```
cd istio-samples/sample-apps/helloserver
```

Utforska en applikation med flera tjänster

Exempelapplikationen är skriven i Python och består av två komponenter som interagerar med hjälp av REST:

server: en enkel server med en slutpunkt GET, /, som skriver ut "hello world" på konsolen.
loadgen: ett skript som skickar trafik till server, med ett anpassningsbart antal förfrågningar per sekund.

Kör applikationen 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 kör server:

python3 server/server.py

När den körs visas följande: server INFO:root:Startar servern...

2) Öppna ett annat terminalfönster för att skicka förfrågningar till

. Om du använder Cloud Shell, klicka på plustecknet för att öppna en annan session. server3) Skicka en förfrågning till
curl http://localhost:8080 server:

servern svarar:

4) Från katalogen där du laddade exempel på kod, navigera till katalogen som innehåller

Hello World!

cd YOUR_WORKING_DIRECTORY/istio-samples/sample-apps/helloserver/loadgen loadgen:

5) Skapa följande miljövariabler:

export SERVER_ADDR=http://localhost:8080 export REQUESTS_PER_SECOND=5

6) Kör

virtualenv --python python3 env virtualenv:

7) Aktivera den virtuella miljön:

source env/bin/activate

8) Installera kraven för

pip3 install -r requirements.txt loadgen:

9) Kör

python3 loadgen.py loadgen:

genererar ungefär följande meddelande:

När den körs visas följande: loadgen Startar loadgen: 2019-05-20 10:44:12.448415 5 begäran(er) fullständiga till http://localhost:8080

I ett annat terminalfönster

visar ungefär följande meddelanden på konsolen: server 127.0.0.1 - - [21/Jun/2019 14:22:01] "GET / HTTP/1.1" 200 - INFO:root:GET-begäran, Sökväg: / Rubriker: Host: localhost:8080 User-Agent: python-requests/2.22.0 Accept-Encoding: gzip, deflate Accept: */*

127.0.0.1 - - [21/Jun/2019 14:22:01] "GET / HTTP/1.1" 200 -
INFO:root:GET request,
Path: /
Headers:
Host: localhost:8080
User-Agent: python-requests/2.22.0
Accept-Encoding: gzip, deflate
Accept: */*

Från ett nätverksperspektiv kör hela applikationen på en enda värd (lokal dator eller virtuell maskin Cloud Shell). Så du kan använda localhost, för att skicka förfrågningar till server.
10) För att stoppa loadgen och server, skriv in Ctrl-c i varje terminalfönster.
11) I terminalfönstret loadgen inaktivera den virtuella miljön:

deactivate

Förpackning av applikationen i containrar

För att köra applikationen på GKE måste du paketera exempelapplikationen — server och loadgen — i containrar. En container är ett sätt att paketera en applikation för att isolera den från miljön.

För att paketera applikationen i en container behövs en Dockerfile. Dockerfile — det är en textfil där kommandon definieras för att bygga källkoden för applikationen och dess beroenden i en Docker-image. Efter byggandet laddar du upp bilden till en containertjänst, exempelvis Docker Hub eller Container Registry.

Exemplet innehåller redan Dockerfile för server och loadgen med alla nödvändiga kommandon för att bygga bilder. Här är 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/*

# Aktivera ofiltrerat loggande
FROM base as final
ENV PYTHONUNBUFFERED=1

RUN apt-get -qq update 
    && apt-get install -y --no-install-recommends 
        wget

WORKDIR /helloserver

# Hämta paket från byggaren
COPY --from=builder /usr/local/lib/python3.7/ /usr/local/lib/python3.7/

# Lägg till applikationen
COPY . .

EXPOSE 8080
ENTRYPOINT [ "python", "server.py" ]

Team FROM python:3-slim as base tillåter Docker att använda den senaste Python 3 som bas.
Team COPY. . kopierar källfilerna till den aktuella arbetskatalogen (i vårt fall endast server.py) till containerfilsystemet.
ENTRYPOINT definierar kommandot som används för att köra containern. I vårt fall överensstämmer detta kommando nästan med det som du använde för att köra server.py från källkoden.
Team EXPOSE anger att server väntar på data via port 8080. Detta kommando gör inte tillgängliga portar. Det är lite som dokumentation som behövs för att öppna en port 8080 vid körning av containern.

Förberedelse för containerisering av applikationen

1) Ange följande miljövariabler. Ersätt PROJECT_ID med din GCP-projektidentifierare.

export PROJECT_ID="PROJECT_ID"

export GCR_REPO="preparing-istio"

Med värdena PROJECT_ID och GCR_REPO markerar du Docker-imagen när du bygger och skickar den till det privata Container Registry.

2) Ange standard GCP-projekt för kommandoradsverktyget gcloud.

gcloud config set project $PROJECT_ID

3) Ange standard zon för kommandoradsverktyget gcloud.

gcloud config set compute/zone us-central1-b

4) Se till att Container Registry-tjänsten är aktiverad i GCP-projektet.

gcloud services enable containerregistry.googleapis.com

Containrization av server

Gå till katalogen där exemplet finns server:

cd DIN_ARBETSKATALOG/istio-samples/sample-apps/helloserver/server/

Bygg en bild med hjälp av Dockerfile och miljövariablerna som du definierade tidigare:
```
docker build -t gcr.io/$PROJECT_ID/$GCR_REPO/helloserver:v0.0.1 .
```

Parameter -t representerar Docker-taggen. Det är namnet på bilden som du använder vid distribution av containern.

Skicka bilden till Container Registry:

docker push gcr.io/$PROJECT_ID/$GCR_REPO/helloserver:v0.0.1

Containrization av loadgen

1) Gå till katalogen där exemplet finns loadgen:

cd ../loadgen

2) Bygg en bild:

docker build -t gcr.io/$PROJECT_ID/$GCR_REPO/loadgen:v0.0.1 .

3) Skicka bilden till Container Registry:

docker push gcr.io/$PROJECT_ID/$GCR_REPO/loadgen:v0.0.1

Visa listan över bilder

Titta på listan över bilder i förrådet och kontrollera att bilderna har skickats:

gcloud container images list --repository gcr.io/$PROJECT_ID/preparing-istio

Kommandot ger ut namnen på de nyss skickade bilderna:

NAMN
gcr.io/PROJECT_ID/preparing-istio/helloserver
gcr.io/PROJECT_ID/preparing-istio/loadgen

Skapa en GKE-kluster.

Dessa containrar kan köras på en virtuell maskin Cloud Shell eller på en dator med kommandot docker run. Men i en produktionsmiljö behövs ett sätt att centralt orkestrera containrar. Till exempel behövs ett system som ser till att containrar alltid är igång, och ett sätt att skala upp och starta flera instanser av containrar om trafiken ökar.

För att köra containertillämpningar kan du använda GKE. GKE är en plattform för orkestrering av containrar som sammanför virtuella maskiner i en kluster. Varje virtuell maskin kallas en nod. GKE-kluster är baserade på det öppen källkod systemet för klusterhantering Kubernetes. Kubernetes erbjuder mekanismer för interaktion med klustret.

Skapa ett GKE-kluster:

1) Skapa kluster:

gcloud container clusters create istioready 
  --cluster-version latest 
  --machine-type=n1-standard-2 
  --num-nodes 4

Team gcloud skapar klustret istioready i det GCP-projekt och zon som du angett. För att köra Istio rekommenderar vi att ha minst 4 noder och en virtuell maskin. n1-standard-2.

Kommandot skapar klustret på några minuter. När klustret är klart ger kommandot ett liknande problemet.

2) Ange referenser i kommandoradsverktyget kubectl, så att du kan hantera klustret:

gcloud container clusters get-credentials istioready

3) Nu kan du kommunicera med Kubernetes via kubectl. Till exempel kan du använda följande kommando för att ta reda på statusen för noderna:

kubectl get nodes

Kommandot ger en lista över noder:

NAMN                                       STATUS   ROLER    ÅLDER    VERSION
gke-istoready-default-pool-dbeb23dc-1vg0   Klar    <ingen>   99s    v1.13.6-gke.13
gke-istoready-default-pool-dbeb23dc-36z5   Klar    <ingen>   100s   v1.13.6-gke.13
gke-istoready-default-pool-dbeb23dc-fj7s   Klar    <ingen>   99s    v1.13.6-gke.13
gke-istoready-default-pool-dbeb23dc-wbjw   Klar    <ingen>   99s    v1.13.6-gke.13

Nyckelbegrepp inom Kubernetes

Diagrammet visar en applikation på GKE:

Innan du distribuerar containrar i GKE, studera de nyckelbegreppen inom Kubernetes. I slutet finns länkar om du vill lära dig mer.

Noder och kluster. I GKE är en nod en virtuell maskin. På andra plattformar kan en nod vara en dator eller en virtuell maskin. Ett kluster är en uppsättning noder som kan ses som en enhet där du distribuerar containeriserade applikationer.
Podar. I Kubernetes körs containrar i podar. En pod i Kubernetes är en odelbar enhet. En pod rymmer en eller flera containrar. Du distribuerar containrar server och loadgen i separata podar. När en pod har flera containrar (till exempel en applikationsserver och proxy-server), hanteras containrarna som ett enhetligt objekt och delar resurser inom pod-en.
Distributioner. I Kubernetes är en distribution ett objekt som representerar en uppsättning identiska podar. Distributionen kör flera repliker av podar, fördelade över klusternoder. Distributionen ersätter automatiskt podar som har misslyckats eller inte svarar.
Kubernetes-tjänst. När du kör kod från en applikation i GKE ändras anslutningen mellan loadgen och server. När du körde tjänster på en virtuell maskin i Cloud Shell eller på en dator, skickade du förfrågningar till server på adressen localhost:8080. Efter distributionen i GKE körs podarna på tillgängliga noder. Som standard kan du inte styra vilken nod en pod körs på, så att podar inte har permanenta IP-adresser.
För att få en IP-adress för server, behöver du definiera en nätverksabstraktion ovanpå podarna. Det är här Kubernetes-tjänstenkommer in. Kubernetes-tjänsten tillhandahåller en konstant slutpunkt för en uppsättning podar. Det finns flera typer tjänster. server använder LoadBalancer, som tillhandahåller en extern IP-adress för att ansluta till server utifrån klustret.
Det finns också ett inbyggt DNS-system i Kubernetes som tilldelar DNS-namn (till exempel, helloserver.default.cluster.local) tjänster. Detta gör att poddar inom klustret kopplas ihop med andra poddar i klustret via en konstant adress. DNS-namn kan inte användas utanför klustret, till exempel i Cloud Shell eller på en dator.

Kubernetes-manifest

När du körde applikationen från källkoden använde du ett imperativt kommando python3

server.py

Imperativitet innebär ett verb: 'gör detta'.

Kubernetes använder deklarativ modell. Det innebär att vi inte säger till Kubernetes vad som exakt måste göras, utan beskriver det önskade tillståndet. Till exempel startar och stoppar Kubernetes poddar efter behov för att det faktiska tillståndet i systemet ska överensstämma med det önskade.

Det önskade tillståndet anger du i manifest, eller filer YAML. YAML-filen innehåller specifikationer för en eller flera Kubernetes-objekt.

Exemplet innehåller en YAML-fil för server och loadgen. Varje YAML-fil anger det önskade tillståndet för ett distributions- och serviceobjekt i Kubernetes.

server.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: helloserver
spec:
  selector:
    matchLabels:
      app: helloserver
  replicas: 1
  template:
    metadata:
      labels:
        app: helloserver
    spec:
      terminationGracePeriodSeconds: 5
      restartPolicy: Always
      containers:
      - name: main
        image: gcr.io/google-samples/istio/helloserver:v0.0.1
        imagePullPolicy: Always

typ anger typ av objekt.
metadata.name anger namnet på distributionen.
Det första fältet spec innehåller en beskrivning av det önskade tillståndet.
spec.replicas anger det önskade antalet poddar.
Avsnitt spec.template definierar poddsnablonen. I specifikationen för poddar finns ett fält bild, där namnet på bilden som ska hämtas från Container Registry anges.

En tjänst definieras enligt följande:

apiVersion: v1
kind: Service
metadata:
  name: hellosvc
spec:
  type: LoadBalancer
  selector:
    app: helloserver
  ports:
  - name: http
    port: 80
    targetPort: 8080

LoadBalancer: klienter skickar förfrågningar till IP-adressen för lastbalanseraren, som har en konstant IP-adress och som är tillgänglig utanför klustret.
targetPort: som du kanske minns, gav kommandot EXPOSE 8080 på Dockerfile inte angivet några portar. Du anger en port 8080, så att det går att kommunicera med containern server utanför klustret. I vårt fall hellosvc.default.cluster.local:80 (kort namn: hellosvc) motsvarar porten 8080 IP-adressen till podden helloserver.
port: detta är portnumret dit andra tjänster i klustret kommer att skicka förfrågningar.

loadgen.yaml

Distributionsobjektet i loadgen.yaml liknar server.yaml. Skillnaden är att distributionsobjektet innehåller avsnittet env. Det definierar miljövariablerna som behövs loadgen och som du installerade vid starten av applikationen från källkoden.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: loadgenerator
spec:
  selector:
    matchLabels:
      app: loadgenerator
  replicas: 1
  template:
    metadata:
      labels:
        app: loadgenerator
    spec:
      terminationGracePeriodSeconds: 5
      restartPolicy: Always
      containers:
      - name: main
        image: gcr.io/google-samples/istio/loadgen:v0.0.1
        imagePullPolicy: Always
        env:
        - name: SERVER_ADDR
          value: "http://hellosvc:80/"
        - name: REQUESTS_PER_SECOND
          value: "10"
        resources:
          requests:
            cpu: 300m
            memory: 256Mi
          limits:
            cpu: 500m
            memory: 512Mi

Ett loadgen accepterar inga inkommande förfrågningar för fältet typ som har angetts ClusterIP. Denna typ tillhandahåller en statisk IP-adress som kan användas av tjänster i klustret, men denna IP-adress tillhandahålls inte till externa klienter.

apiVersion: v1
kind: Service
metadata:
  name: loadgensvc
spec:
  type: ClusterIP
  selector:
    app: loadgenerator
  ports:
  - name: http
    port: 80
    targetPort: 8080

Distribution av containrar i GKE

1) Gå till katalogen där exemplet finns server:

cd DIN_ARBETSKATALOG/istio-samples/sample-apps/helloserver/server/

2) Öppna server.yaml i en textredigerare.
3) Ändra namnet i fältet bild till namnet på din Docker-avbildning.

image: gcr.io/PROJECT_ID/preparing-istio/helloserver:v0.0.1

Byt ut PROJECT_ID mot din GCP-projektidentifierare.
4) Spara och stäng server.yaml.
5) Distribuera YAML-filen i Kubernetes:

kubectl apply -f server.yaml

Efter att kommandot har slutförts framgångsrikt returnerar det följande koden:

deployment.apps/helloserver created
service/hellosvc created

6) Gå till katalogen där loadgen:

cd ../loadgen

7) Öppna loadgen.yaml i en textredigerare.
8) Ändra namnet i fältet bild till namnet på din Docker-avbildning.

image: gcr.io/PROJECT_ID/preparing-istio/loadgen:v0.0.1

Byt ut PROJECT_ID mot din GCP-projektidentifierare.
9) Spara och stäng loadgen.yaml, stäng textredigeraren.
10) Distribuera YAML-filen i Kubernetes:

kubectl apply -f loadgen.yaml

Efter att kommandot har slutförts framgångsrikt returnerar det följande koden:

deployment.apps/loadgenerator created
service/loadgensvc created

11) Kontrollera status på poddar:

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) Hämta applikationsloggar från podden loadgen. Byt ut POD_ID från identifieraren i det föregående svaret.

kubectl logs loadgenerator-POD_ID

13) Hämta externa IP-adresser hellosvc:

kubectl get service

Svaret från kommandot ser ungefär ut 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                443/TCP        93m
loadgensvc   ClusterIP      10.81.15.155             80/TCP         4m52s

14) Skicka en förfrågan till hellosvc: byt ut EXTERNAL_IP mot den externa IP-adressen hellosvc.

curl http://EXTERNAL_IP

Vi tar oss an Istio

Du har redan en applikation distribuerad i GKE. loadgen kan använda Kubernetes DNS (hellosvc:80), för att skicka förfrågningar till server, och du kan skicka förfrågningar till server via den externa IP-adressen. Även om Kubernetes har många möjligheter saknas viss information om tjänster:

Hur interagerar tjänster? Vilka relationer finns mellan tjänster? Hur flödar trafiken mellan tjänster? Vet du att loadgen skickar förfrågningar till server, men föreställ dig att du inte vet något om applikationen. För att besvara dessa frågor, ser vi på listan över aktiva pods i GKE.
Mätvärden. Hur länge server svarar på en inkommen förfrågan? Hur många förfrågningar per sekund kommer till servern? Visar den felmeddelanden?
Säkerhetsinformation. Trafiken mellan loadgen och server går helt enkelt genom HTTP eller genom mTLS?

Alla dessa frågor besvaras av Istio. Istio placerar en sidecar-proxy Envoy i varje pod. Proxy Envoy fångar upp all inkommen och utgående trafik till applikationens containrar. Detta innebär att server och loadgen tar emot via sidecar-proxy Envoy, och all trafik från loadgen till server går igenom proxy Envoy.

Anslutningar mellan proxyerna Envoy utgör ett service mesh. Arkitekturen för service mesh erbjuder en kontrollnivå ovanpå Kubernetes.

Eftersom proxyerna Envoy körs i sina containrar kan Istio installeras ovanpå GKE-klustret utan större kodändringar i applikationen. Men du har gjort lite arbete för att förbereda applikationen för att hanteras med Istio:

Tjänster för alla containrar. Varje distribution server och loadgen är kopplad till en Kubernetes-tjänst. Även en loadgen, som inte tar emot inkommande förfrågningar, har en tjänst.
Tjänster har portnamn. Även om portar i GKE kan lämnas namnlösa, kräver Istio att portnamnet anges enligt dess protokoll. I YAML-filen ska porten för server kallas http, eftersom servern använder protokollet HTTP. Om service använde gRPC, skulle du namnge porten grpc.
Distributionerna markeras. Därför kan du använda Istios trafikhanteringsfunktioner, till exempel att dela trafik mellan versioner av en tjänst.

Installera Istio

Istio kan installeras på två sätt. Du kan aktivera tillägget Istio on GKE eller installera den öppen källkods-versionen av Istio på klustret. Med Istio on GKE kan du enkelt hantera installation och uppgradering av Istio inom GKE-klustrets livscykel. Om du behöver den senaste versionen av Istio eller vill ha mer kontroll över Istios kontrollpanelkonfiguration, installera den öppen källkods-versionen istället för Istio on GKE-tillägget. För att bestämma vilken metod som passar, läs artikeln Behöver jag Istio on GKE?.

Välj alternativ, granska den relevanta guiden och följ instruktionerna för att installera Istio på klustret. Om du vill använda Istio med det nyss distribuerade applikationen, aktivera sidecar-integrationer för namnrymden default.

Rensa

För att inga avgifter ska dras från ditt Google Cloud Platform-konto för resurser som du använde i denna guide, ta bort behållarklustret när du har installerat Istio och lekt med exempelapplikationen. Detta kommer att ta bort alla resurser från klustret, inklusive beräkningsinstanser, diskar och nätverksresurser.