Förbereder en ansökan för Istio

Förbereder en ansökan för Istio

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:

  1. Lär dig en enkel hej världen-applikation med flera tjänster.
  2. Kör programmet från källkoden.
  3. Förpackning av applikationen i behållare.
  4. Skapa ett Kubernetes-kluster.
  5. Distribuera behållare i ett kluster.

Innan du börjar

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

  1. Gå till Kubernetes Engine-sida i Google Cloud Platform-konsolen.
  2. Skapa eller välj ett projekt.
  3. Vänta tills API och relaterade tjänster är aktiverade. Detta kan ta några minuter.
  4. Se till att fakturering är inställd för ditt Google Cloud Platform-projekt. Läs om hur du aktiverar fakturering.

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, и kubectl, som vi kommer att använda är redan installerade.
  • Du har flera att välja mellan textredigerare:
    1. Kodredigerare, 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.

Att använda Molnskal:

  1. Gå till GCP-konsolen.
  2. tryck Aktivera Cloud Shell (Aktivera Cloud Shell) överst i GCP-konsolfönstret.

Förbereder en ansökan för Istio

I nedre delen GCP-konsol En Cloud Shell-session med en kommandorad öppnas i ett nytt fönster.

Förbereder en ansökan för Istio

Alternativ B: Använda kommandoradsverktyg lokalt

Om du ska arbeta på en dator som kör Linux eller macOS måste du konfigurera och installera följande komponenter:

  1. Anpassa Python 3 och Python 2 utvecklingsmiljö.

  2. Installera Cloud SDK med kommandoradsverktyget gmoln.

  3. Ställ kubectl - kommandoradsverktyg för att arbeta med Kubernetes.

    gcloud components install kubectl

  4. Ställ Docker Community Edition (CE). Du kommer att använda kommandoradsverktyget hamnarbetareför att skapa behållarbilder för exempelapplikationen.

  5. Installera verktyget Git versionskontrollför att få provapplikationen från GitHub.

Ladda ner exempelkod

  1. Ladda ner källkoden hej server:

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

  2. Gå till exempelkodkatalogen:

    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: 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.

Förbereder en ansökan för Istio

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

5) Skapa följande miljövariabler:

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

6) Kör virtualenv:

virtualenv --python python3 env

7) Aktivera den virtuella miljön:

source env/bin/activate

8) Ställ krav på loadgen:

pip3 install -r requirements.txt

9) Kör loadgen:

python3 loadgen.py

Vid start loadgen visar något i stil med följande meddelande:

Starting loadgen: 2019-05-20 10:44:12.448415
5 request(s) complete to http://localhost:8080

I ett annat terminalfönster server skickar ut följande meddelanden till konsolen:

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: */*

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.

gcloud services enable containerregistry.googleapis.com

Containeriseringsserver

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

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

  2. Sätt ihop bilden med hjälp av Dockerfile och miljövariablerna du definierade tidigare:

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

Parameter -t representerar Docker-taggen. Detta är namnet på bilden du använder när du distribuerar behållaren.

  1. Ladda upp bilden till containerregistret:
    docker push gcr.io/$PROJECT_ID/$GCR_REPO/helloserver:v0.0.1

Containerisering av lasten

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

cd ../loadgen

2) Samla bilden:

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

3) Ladda upp bilden till containerregistret:

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

Visa en lista med bilder

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.

Skapa ett GKE-kluster:

1) Skapa ett kluster:

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

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:

gcloud container clusters get-credentials istioready

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:

Förbereder en ansökan för Istio

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.

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

  • slag anger typen av objekt.
  • metadata.name anger distributionsnamnet.
  • 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.

Tjänsten definieras enligt följande:

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

  • 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.

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

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.

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

Distribuera behållare i GKE

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

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

2) Öppen server.yaml i en textredigerare.
3) Byt ut namnet i fältet bild till namnet på din Docker-bild.

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

Byta ut PROJECT_ID till ditt GCP-projekt-ID.
4) Spara och stäng server.yaml.
5) Distribuera YAML-filen till Kubernetes:

kubectl apply -f server.yaml

Efter framgångsrikt slutförande producerar kommandot följande kod:

deployment.apps/helloserver created
service/hellosvc created

6) Gå till katalogen där loadgen:

cd ../loadgen

7) Öppen loadgen.yaml i en textredigerare.
8) Byt ut namnet i fältet bild till namnet på din Docker-bild.

image: gcr.io/PROJECT_ID/preparing-istio/loadgenv0.0.1

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.

Förbereder en ansökan för Istio

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.

Vad händer nu?

Källa: will.com

Lägg en kommentar