prepara un'applicazione per Cloud Service Mesh


Cloud Service Mesh è un potente strumento per la gestione e il monitoraggio diverse applicazioni. Per ottenere il massimo da Cloud Service Mesh, è utile comprendere le sue astrazioni sottostanti, inclusi i container e Kubernetes. Questo tutorial spiega come preparare un'applicazione per Cloud Service Mesh dal codice sorgente a un contenitore in esecuzione su GKE, fino al punto immediatamente precedente all'installazione di Cloud Service Mesh.

Se hai già familiarità con i concetti di Kubernetes e service mesh, puoi saltare questo tutorial e andare direttamente alla guida all'installazione di Cloud Service Mesh.

Obiettivi

  1. Esplora una semplice applicazione "Hello World" multiservizio.
  2. Esegui l'applicazione dall'origine
  3. Containerizza l'applicazione.
  4. Creare un cluster Kubernetes.
  5. Esegui il deployment dei container nel cluster.

Prima di iniziare

Per abilitare l'API Cloud Service Mesh, segui questi passaggi:
  1. Visita la pagina di Kubernetes Engine nella console Google Cloud.
  2. Crea o seleziona un progetto.
  3. Attendi che l'API e i relativi servizi siano abilitati. L'operazione può richiedere diversi minuti.
  4. Make sure that billing is enabled for your Google Cloud project.

Questo tutorial utilizza Cloud Shell, che esegue il provisioning di una Macchina virtuale g1-small Compute Engine (VM) che esegue un sistema operativo Linux basato su Debian.

Prepara Cloud Shell

I vantaggi dell'utilizzo di Cloud Shell sono:

  • Gli ambienti di sviluppo Python 2 e Python 3 (inclusovirtualenv) sono configurati.
  • Gli strumenti a riga di comando gcloud, docker, git e kubectl utilizzati in questa tutorial sono già installati.
  • Puoi scegliere tra diversi editor di testo:

    • Editor di codice, a cui puoi accedere facendo clic su nella parte superiore della finestra di Cloud Shell.

    • Emacs, Vim o Nano, a cui si accede dalla riga di comando in Cloud Shell.

In the Google Cloud console, activate Cloud Shell.

Activate Cloud Shell

At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

Scarica il codice campione

  1. Scarica il codice sorgente di helloserver:

    git clone https://github.com/GoogleCloudPlatform/anthos-service-mesh-samples
    
  2. Passa alla directory del codice di esempio:

    cd anthos-service-mesh-samples/docs/helloserver
    

Esplora l'applicazione multiservizio

L'applicazione di esempio è scritta in Python e ha due componenti comunicare tramite REST:

  • server: un semplice server con un endpoint GET, /, che stampa "hello world" nella console.
  • loadgen: uno script che invia traffico a server, con un numero configurabile di richieste al secondo (RPS).

applicazione di esempio

Esegui l'applicazione dall'origine

Per acquisire familiarità con l'applicazione di esempio, eseguila in Cloud Shell.

  1. Dalla directory sample-apps/helloserver, esegui server:

    python3 server/server.py
    

    All'avvio, server mostra quanto segue:

    INFO:root:Starting server...
    
  2. Apri un'altra finestra del terminale per inviare richieste al dispositivo server. Fai clic su per aprire un'altra sessione.

  3. Invia una richiesta a server:

    curl http://localhost:8080
    

    server risponde:

    Hello World!
    
  4. Dalla directory in cui hai scaricato il codice di esempio, vai alla directory che contiene il file loadgen:

    cd YOUR_WORKING_DIRECTORY/anthos-service-mesh-samples/docs/helloserver/loadgen
  5. Crea le seguenti variabili di ambiente:

    export SERVER_ADDR=http://localhost:8080
    export REQUESTS_PER_SECOND=5
    
  6. Avvia virtualenv:

    virtualenv --python python3 env
    
  7. Attiva l'ambiente virtuale:

    source env/bin/activate
    
  8. Installa i requisiti per loadgen:

    pip3 install -r requirements.txt
    
  9. Esegui loadgen:

    python3 loadgen.py
    

    All'avvio, loadgen restituisce un messaggio simile al seguente:

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

    Nell'altra finestra del terminale, server scrive messaggi nella console simili ai seguenti:

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

    Dal punto di vista del networking, l'intera applicazione è ora in esecuzione lo stesso host. Per questo motivo, puoi utilizzare localhost per inviare richieste al server.

  10. Per interrompere loadgen e server, inserisci Ctrl-c in ogni finestra del terminale.

  11. Nella finestra del terminale loadgen, disattiva l'ambiente virtuale:

    deactivate
    

Containerizza l'applicazione

Per eseguire l'applicazione su GKE, devi pacchettizzare l'esempio server e loadgen in container. R container è un modo per pacchettizzare un'applicazione in modo che sia isolata dal dell'ambiente sottostante.

Per eseguire il containerizzazione dell'applicazione, devi avere un Dockerfile. Un Dockerfile è un messaggio di testo file che definisce i comandi necessari per assemblare il codice sorgente dell'applicazione e le sue dipendenze Immagine Docker . Dopo aver creato l'immagine, la carichi in un registry dei container, ad esempio Docker Hub o Container Registry.

Il sample è dotato di un Dockerfile sia per server che per loadgen con tutti i comandi necessari per creare le immagini. Di seguito è riportato il Dockerfile per il server:

FROM python:3.12-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.* /usr/local/lib/

# Add the application
COPY . .

EXPOSE 8080
ENTRYPOINT [ "python", "server.py" ]
  • Il comando FROM python:3-slim as base indica a Docker di utilizzare l'ultima immagine Python 3 come l'immagine di base.
  • Il comando COPY . . copia i file di origine nell'ambiente di lavoro attuale (in questo caso, solo server.py) nel file del container di un sistema operativo completo.
  • ENTRYPOINT definisce il comando utilizzato per eseguire il container. In questo caso, il comando è quasi uguale a quello che hai utilizzato per eseguire server.py dal codice sorgente.
  • Il comando EXPOSE specifica che server è in ascolto sulla porta 8080. Questo comando non espone porte, ma serve come documentazione per indicare che devi aprire la porta 8080 quando esegui il contenitore.

Preparati a containerizzare l'applicazione

  1. Imposta le seguenti variabili di ambiente. Sostituisci PROJECT_ID con l'ID del tuo progetto Google Cloud.

    export PROJECT_ID="PROJECT_ID"
    export GCR_REPO="asm-ready"

    Utilizza il valore di PROJECT_ID e GCR_REPO per taggare l'immagine Docker durante la compilazione ed eseguine il push nel tuo Container Registry privato.

  2. Imposta il progetto Google Cloud predefinito per Google Cloud CLI.

    gcloud config set project $PROJECT_ID
  3. Imposta la zona predefinita per Google Cloud CLI.

    gcloud config set compute/zone us-central1-b
    
  4. Assicurati che il servizio Container Registry sia abilitato nel progetto Google Cloud.

    gcloud services enable containerregistry.googleapis.com
    

Containerizza server

  1. Passa alla directory in cui si trova l'esempio server:

    cd YOUR_WORKING_DIRECTORY/anthos-service-mesh-samples/docs/helloserver/server/
  2. Crea l'immagine utilizzando Dockerfile e le variabili di ambiente che definiti in precedenza:

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

    Il flag -t rappresenta il tag Docker. Questo è il nome dell'immagine che utilizzi per il deployment del container.

  3. Esegui il push dell'immagine a Container Registry:

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

Containerizza loadgen

  1. Passa alla directory in cui si trova il campione loadgen:

    cd ../loadgen
    
  2. Crea l'immagine:

    docker build -t gcr.io/$PROJECT_ID/$GCR_REPO/loadgen:v0.0.1 .
    
  3. Esegui il push dell'immagine a Container Registry:

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

Elenca le immagini

Recupera un elenco delle immagini nel repository per verificare che siano state inviato:

gcloud container images list --repository gcr.io/$PROJECT_ID/asm-ready

Il comando risponde con i nomi delle immagini che hai appena eseguito il push:

NAME
gcr.io/PROJECT_ID/asm-ready/helloserver
gcr.io/PROJECT_ID/asm-ready/loadgen

Crea un cluster GKE

Puoi eseguire questi container sulla VM Cloud Shell utilizzando il comando docker run. In fase di produzione, però, devi orchestrare i container in modo più unificato. Ad esempio, hai bisogno di un sistema che garantisca i container sono sempre in esecuzione e ti serve un modo per fare lo scale up di istanze aggiuntive di un container per gestire l'aumento del traffico.

Puoi utilizzare la modalità GKE per eseguire applicazioni containerizzate. GKE è un servizio di orchestrazione che funziona collegando le VM a un cluster. Ogni VM chiamato nodo. I cluster GKE sono basati sul sistema di gestione dei cluster open source Kubernetes. Kubernetes fornisce meccanismi attraverso i quali interagisci con il cluster.

Per creare un cluster GKE:

  1. Crea il cluster:

    gcloud container clusters create asm-ready \
      --cluster-version latest \
      --machine-type=n1-standard-4 \
      --num-nodes 4
    

    Il comando gcloud crea un cluster nel progetto e nella zona Google Cloud impostati in precedenza. Per eseguire Cloud Service Mesh, consigliamo almeno 4 nodi e il tipo di macchina n1-standard-4.

    Il completamento del comando per la creazione del cluster richiede alcuni minuti. Quando il cluster è pronto, il comando restituisce un messaggio simile al seguente:

    NAME        LOCATION       MASTER_VERSION  MASTER_IP      MACHINE_TYPE   NODE_VERSION   NUM_NODES  STATUS
    asm-ready  us-central1-b  1.13.5-gke.10   203.0.113.1    n1-standard-2  1.13.5-gke.10  4          RUNNING
    
  2. Fornisci le credenziali allo strumento a riga di comando kubectl in modo da poterlo utilizzare per gestire il cluster:

    gcloud container clusters get-credentials asm-ready
    
  3. Ora puoi utilizzare kubectl per comunicare con Kubernetes. Ad esempio, puoi eseguire il seguente comando per ottenere lo stato dei nodi:

    kubectl get nodes
    

    Il comando risponde con un elenco di nodi, simile al seguente:

    NAME                                       STATUS   ROLES    AGE    VERSION
    gke-asm-ready-default-pool-dbeb23dc-1vg0   Ready    <none>   99s    v1.13.6-gke.13
    gke-asm-ready-default-pool-dbeb23dc-36z5   Ready    <none>   100s   v1.13.6-gke.13
    gke-asm-ready-default-pool-dbeb23dc-fj7s   Ready    <none>   99s    v1.13.6-gke.13
    gke-asm-ready-default-pool-dbeb23dc-wbjw   Ready    <none>   99s    v1.13.6-gke.13
    

Comprendere i concetti chiave di Kubernetes

Il seguente diagramma illustra l'applicazione in esecuzione su GKE:

applicazione containerizzata

Prima di eseguire il deployment dei container in GKE, ti consigliamo di esaminare alcuni concetti chiave di Kubernetes. Alla fine di questo tutorial sono disponibili link per approfondire ciascun concetto.

  • Nodi e cluster: in GKE, un nodo è una VM. Su altro su piattaforme Kubernetes, un nodo può essere sia una macchina fisica che una macchina virtuale. Un cluster è un insieme di nodi che possono essere trattati insieme come una singola macchina su cui esegui il deployment di un'applicazione containerizzata.

  • Pod: in Kubernetes, i container vengono eseguiti all'interno di un pod. Un pod è l'unità atomica di Kubernetes. Un pod contiene uno o più container. Esegui il deployment dei container server e loadgen ciascuno nel proprio pod. Quando viene eseguito un pod in più container (ad esempio, un server delle applicazioni server proxy), i container sono gestiti come una singola entità e condividono le risorse del pod.

  • Deployment: un deployment è un oggetto Kubernetes che rappresenta un insieme di di pod identici. Un deployment esegue più repliche dei pod distribuiti tra i nodi di un cluster. Un deployment sostituisce automaticamente i pod che si arrestano in modo anomalo o non rispondono.

  • Servizio Kubernetes: esecuzione del codice dell'applicazione nelle modifiche GKE il networking tra loadgen e server. Quando hai eseguito in una VM Cloud Shell, potresti inviare richieste a server utilizzando l'indirizzo localhost:8080. Dopo il deployment in GKE, i pod sono pianificati per essere eseguiti sui nodi disponibili. Per impostazione predefinita, non puoi controllare su quale nodo è in esecuzione, I pod non hanno indirizzi IP stabili.

    Per ottenere un indirizzo IP per server, devi definire un'astrazione di rete sopra i pod chiamata servizio Kubernetes. Un servizio Kubernetes fornisce un endpoint di networking stabile per un insieme di pod. Esistono diversi tipi di servizi. server utilizza un LoadBalancer, che espone un indirizzo IP esterno in modo da poter raggiungere server dall'esterno del cluster.

    Kubernetes ha anche un sistema DNS integrato, che assegna i nomi DNS (ad esempio helloserver.default.cluster.local) ai servizi. In questo modo i pod all'interno del cluster possono raggiungere altri pod del cluster con un indirizzo stabile. Non puoi utilizzare questo nome DNS all'esterno del cluster, ad esempio da Cloud Shell.

Manifest di Kubernetes

Quando hai eseguito l'applicazione dal codice sorgente, hai utilizzato un modello comando: python3 server.py

Il linguaggio imperativo è basato sui verbi: "fai questo".

Al contrario, Kubernetes si basa su un modello dichiarativo. Ciò significa che, invece di dire esattamente a Kubernetes cosa fare, Kubernetes con lo stato desiderato. Ad esempio, Kubernetes avvia e termina i pod secondo necessità, in modo che lo stato effettivo del sistema corrisponda a quello desiderato.

Puoi specificare lo stato desiderato in un insieme di manifest. YAML. Un file YAML contiene la specifica per uno o più oggetti Kubernetes.

Il sample contiene un file YAML per server e loadgen. Ogni file YAML specifica lo stato desiderato per l'oggetto e il servizio Kubernetes Deployment.

Server

apiVersion: apps/v1
kind: Deployment
metadata:
  name: helloserver
spec:
  replicas: 1
  selector:
    matchLabels:
      app: helloserver
  template:
    metadata:
      labels:
        app: helloserver
    spec:
      containers:
      - image: gcr.io/google-samples/istio/helloserver:v0.0.1
        imagePullPolicy: Always
        name: main
      restartPolicy: Always
      terminationGracePeriodSeconds: 5
  • kind indica il tipo di oggetto.
  • metadata.name specifica il nome del deployment.
  • Il primo campo spec contiene una descrizione dello stato desiderato.
  • spec.replicas specifica il numero di pod desiderati.
  • La sezione spec.template definisce un modello di pod. Incluso nel specifica per i pod è il campo image, ovvero il nome l'immagine di cui eseguire il pull da Container Registry.

Il Servizio è definito come segue:

apiVersion: v1
kind: Service
metadata:
  name: hellosvc
spec:
  ports:
  - name: http
    port: 80
    targetPort: 8080
  selector:
    app: helloserver
  type: LoadBalancer
  • LoadBalancer: i client inviano richieste all'indirizzo IP di un carico di rete di servizio, che ha un indirizzo IP stabile ed è raggiungibile all'esterno in un cluster Kubernetes.
  • targetPort: ricorda che il comando EXPOSE 8080 in Dockerfile non espone effettivamente alcuna porta. Esponi la porta 8080 in modo da poter raggiungere il contenitore server all'esterno del cluster. In questo caso, hellosvc.default.cluster.local:80 (nome breve: hellosvc) viene mappato allo helloserver Porta dell'IP del pod 8080.
  • port: si tratta del numero di porta utilizzato da altri servizi nel cluster durante l'invio delle richieste.

Generatore di carico

L'oggetto Deployment in loadgen.yaml è simile a server.yaml. Un elemento degno di nota è che l'oggetto Deployment contiene una sezione denominata env. Questo definisce le variabili di ambiente richieste da loadgen, che imposti in precedenza, quando eseguivi l'applicazione dall'origine.

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

Poiché loadgen non accetta richieste in entrata, il campo type è impostato a ClusterIP. Questo tipo fornisce un indirizzo IP stabile che fornisce utilizzabile dal cluster, ma l'indirizzo IP non è esposto ai client esterni.

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

Esegui il deployment dei container in GKE

  1. Passa alla directory in cui si trova l'esempio server:

    cd YOUR_WORKING_DIRECTORY/anthos-service-mesh-samples/docs/helloserver/server/
  2. Apri server.yaml in un editor di testo.

  3. Sostituisci il nome nel campo image con il nome dell'immagine Docker.

    image: gcr.io/PROJECT_ID/asm-ready/helloserver:v0.0.1
    

    Sostituisci PROJECT_ID con il tuo progetto Google Cloud ID.

  4. Salva e chiudi server.yaml.

  5. Esegui il deployment del file YAML in Kubernetes:

    kubectl apply -f server.yaml
    

    In caso di esito positivo, il comando risponde con quanto segue:

    deployment.apps/helloserver created
    service/hellosvc created
    

  6. Passa alla directory in cui si trova loadgen.

    cd ../loadgen
    
  7. Apri loadgen.yaml in un editor di testo.

  8. Sostituisci il nome nel campo image con il nome della tua immagine Docker.

    image: gcr.io/PROJECT_ID/asm-ready/loadgen:v0.0.1
    

    Sostituisci PROJECT_ID con l'ID del tuo progetto Google Cloud.

  9. Salva e chiudi loadgen.yaml, quindi chiudi l'editor di testo.

  10. Esegui il deployment del file YAML in Kubernetes:

    kubectl apply -f loadgen.yaml
    

    In caso di esito positivo, il comando risponde con quanto segue:

    deployment.apps/loadgenerator created
    service/loadgensvc created
    

  11. Controlla lo stato dei pod:

    kubectl get pods
    

    Il comando risponde con lo stato simile al seguente:

    NAME                             READY   STATUS    RESTARTS   AGE
    helloserver-69b9576d96-mwtcj     1/1     Running   0          58s
    loadgenerator-774dbc46fb-gpbrz   1/1     Running   0          57s
    
  12. Recupera i log dell'applicazione dal pod loadgen. Sostituisci POD_ID con l'identificatore dell'output precedente.

    kubectl logs loadgenerator-POD_ID
    
  13. Recupera gli indirizzi IP esterni di hellosvc:

    kubectl get service
    

    La risposta del comando è simile alla seguente:

    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. Invia una richiesta a hellosvc. Sostituisci EXTERNAL_IP con l'indirizzo IP esterno del tuo hellosvc.

    curl http://EXTERNAL_IP
    

Pronti per Cloud Service Mesh

Ora l'applicazione è stata dispiata in GKE. loadgen puoi utilizzare il DNS di Kubernetes (hellosvc:80) per inviare richieste a server, e puoi inviare richieste a server con un indirizzo IP esterno. Sebbene Kubernetes offre molte funzionalità. Alcune informazioni sui servizi mancanti:

  • Come interagiscono i servizi? Qual è la relazione tra i servizi? Come scorre il traffico tra i servizi? Sai che loadgen invia richieste a server, ma immagina di non conoscere bene l'applicazione. Non puoi rispondere a queste domande esaminando l'elenco dei pod in esecuzione su GKE.
  • Metriche: quanto tempo impiega server per rispondere alle richieste in arrivo? Quante richieste al secondo (RPS) vengono inviate a server? Ci sono risposte di errore?
  • Informazioni sulla sicurezza: il traffico tra loadgen e server è in testo normale HTTP o mTLS?

Cloud Service Mesh può fornire risposte a queste domande. Cloud Service Mesh è una versione del progetto open source Istio gestita da Google Cloud. Cloud Service Mesh funziona posizionando Proxy sidecar Envoy in ogni pod. Il proxy Envoy intercetta tutto il traffico in entrata e in uscita verso i container dell'applicazione. Ciò significa che server e loadgen ricevono ciascuno un proxy sidecar Envoy e tutto il traffico da loadgen a server è mediato dai proxy Envoy. Le connessioni tra questi proxy Envoy formano il mesh di servizi. Questa architettura mesh dei servizi fornisce un livello di controllo su Kubernetes.

mesh di servizi

Poiché i proxy Envoy vengono eseguiti nei propri container, puoi installare Cloud Service Mesh di un cluster GKE senza modifiche sostanziali il codice dell'applicazione. Tuttavia, hai preparato alcune delle risorse principali da instrumentare con Cloud Service Mesh:

  • Servizi per tutti i container: sia i deployment server sia loadgen hanno un servizio Kubernetes collegato. Anche loadgen, che non riceve richieste in entrata, ha un servizio.
  • Le porte nei servizi devono essere denominate: anche se GKE ti consente di definire porte di servizio senza nome, Cloud Service Mesh richiede che tu fornisca un nome per una porta che corrisponda al protocollo della porta. Nel file YAML, la porta per server è denominato http perché server utilizza il protocollo di comunicazione HTTP. Se service utilizzava gRPC, il nome della porta sarà grpc.
  • I deployment sono etichettati: questo ti consente di utilizzare le funzionalità di gestione del traffico di Cloud Service Mesh, come la suddivisione del traffico tra le versioni dello stesso servizio.

Installa Cloud Service Mesh

Consulta la guida all'installazione di Cloud Service Mesh e segui le istruzioni per installare Cloud Service Mesh sul cluster.

Esegui la pulizia

Per evitare che al tuo account Google Cloud vengano addebitati costi relativi alle risorse utilizzate in questo tutorial, elimina il progetto che contiene le risorse oppure mantieni il progetto ed elimina le singole risorse.

Per eseguire la pulizia, elimina il cluster GKE. L'eliminazione del cluster elimina tutti i alle risorse che compongono il cluster dei container, come le istanze di calcolo, dischi e risorse di rete.

gcloud container clusters delete asm-ready

Passaggi successivi