Cloud Service Mesh è un potente strumento per la gestione e il monitoraggio di applicazioni distribuite. Per ottenere il massimo da Cloud Service Mesh, è utile comprendere le astrazioni sottostanti, tra cui container e Kubernetes. Questo tutorial spiega come preparare un'applicazione per Cloud Service Mesh dal codice sorgente a un container in esecuzione su GKE, fino al punto appena prima di installare Cloud Service Mesh.
Se hai già familiarità con i concetti di Kubernetes e del mesh di servizi, puoi saltare questo tutorial e passare direttamente alla guida all'installazione di Cloud Service Mesh.
Obiettivi
- Esplora una semplice applicazione "Hello World" multi-servizio.
- Esegui l'applicazione dall'origine
- Containerizza l'applicazione.
- Creare un cluster Kubernetes.
- Eseguire il deployment dei container nel cluster.
Prima di iniziare
Segui questi passaggi per abilitare l'API Cloud Service Mesh:- Visita la pagina di Kubernetes Engine nella console Google Cloud.
- Crea o seleziona un progetto.
- Attendi che l'API e i servizi correlati siano abilitati. Questa operazione può richiedere diversi minuti.
-
Assicurati che la fatturazione sia attivata per il tuo progetto Google Cloud.
Questo tutorial utilizza Cloud Shell, che esegue il provisioning di una macchina virtuale (VM) g1-small Compute Engine che esegue un sistema operativo Linux basato su Debian.
Prepara Cloud Shell
I vantaggi dell'utilizzo di Cloud Shell sono:
- Entrambi gli ambienti di sviluppo Python 2 e Python 3 (incluso
virtualenv
) sono tutti configurati. - Gli strumenti a riga di comando
gcloud
,docker
,git
ekubectl
utilizzati in questo tutorial sono già installati. Puoi scegliere tra 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.
Nella console Google Cloud, attiva Cloud Shell.
Nella parte inferiore della console Google Cloud viene avviata una sessione di Cloud Shell che mostra un prompt della riga di comando. Cloud Shell è un ambiente shell con Google Cloud CLI già installato e con valori già impostati per il progetto attuale. L'inizializzazione della sessione può richiedere alcuni secondi.
Scarica il codice campione
Scarica il codice sorgente di
helloserver
:git clone https://github.com/GoogleCloudPlatform/anthos-service-mesh-samples
Passa alla directory codice campione:
cd anthos-service-mesh-samples/docs/helloserver
Esplora l'applicazione multiservizio
L'applicazione di esempio è scritta in Python e ha due componenti che comunicano utilizzando REST:
server
: un semplice server con un endpointGET
,/
, che stampa "hello world" nella console.loadgen
: uno script che invia traffico aserver
, con un numero configurabile di richieste al secondo (RPS).
Esegui l'applicazione dall'origine
Per acquisire familiarità con l'applicazione di esempio, eseguila in Cloud Shell.
Dalla directory
sample-apps/helloserver
, eseguiserver
:python3 server/server.py
All'avvio,
server
mostra quanto segue:INFO:root:Starting server...
Apri un'altra finestra del terminale per inviare richieste al dispositivo
server
. Fai clic su per aprire un'altra sessione.Invia una richiesta a
server
:curl http://localhost:8080
L'
server
risponde:Hello World!
Dalla directory in cui hai scaricato il codice campione, passa alla directory che contiene
loadgen
:cd YOUR_WORKING_DIRECTORY/anthos-service-mesh-samples/docs/helloserver/loadgen
Crea le seguenti variabili di ambiente:
export SERVER_ADDR=http://localhost:8080 export REQUESTS_PER_SECOND=5
Avvia
virtualenv
:virtualenv --python python3 env
Attiva l'ambiente virtuale:
source env/bin/activate
Installa i requisiti per
loadgen
:pip3 install -r requirements.txt
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 nella console messaggi 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 sullo stesso host. Per questo motivo puoi utilizzare
localhost
per inviare richieste aserver
.Per arrestare
loadgen
eserver
, inserisciCtrl-c
in ogni finestra del terminale.Nella finestra del terminale
loadgen
, disattiva l'ambiente virtuale:deactivate
Containerizza l'applicazione
Per eseguire l'applicazione su GKE, devi pacchettizzare l'applicazione di esempio, server
e loadgen
, in containers. Un container è un modo per pacchettizzare un'applicazione in modo che sia isolata dall'ambiente sottostante.
Per containerizzare l'applicazione, è necessario un Dockerfile
. Un Dockerfile
è un file di testo che definisce i comandi necessari per assemblare il codice sorgente dell'applicazione e le sue dipendenze in unDockerimmagine. Dopo aver creato l'immagine, caricala in un Container Registry, come Docker Hub o Container Registry.
L'esempio include un valore Dockerfile
sia per server
che per loadgen
con tutti i comandi necessari per creare le immagini. Di seguito è riportato il
Dockerfile
di server
:
- Il comando
FROM python:3-slim as base
indica a Docker di utilizzare l'immagine Python 3 più recente come immagine di base. - Il comando
COPY . .
copia i file di origine presenti nella directory di lavoro corrente (in questo caso, soloserver.py
) nel file system del container. ENTRYPOINT
definisce il comando utilizzato per eseguire il container. In questo caso, il comando è quasi uguale a quello utilizzato per eseguireserver.py
dal codice sorgente.- Il comando
EXPOSE
specifica cheserver
è in ascolto sulla porta8080
. Questo comando non espone alcuna porta, ma funge da documentazione per aprire la porta8080
quando esegui il container.
Preparati a containerizzare l'applicazione
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"
Puoi usare i valori
PROJECT_ID
eGCR_REPO
per taggare l'immagine Docker quando crei la build e ne esegui il push nel Container Registry privato.Imposta il progetto Google Cloud predefinito per Google Cloud CLI.
gcloud config set project $PROJECT_ID
Imposta la zona predefinita per Google Cloud CLI.
gcloud config set compute/zone us-central1-b
Assicurati che il servizio Container Registry sia abilitato nel tuo progetto Google Cloud.
gcloud services enable containerregistry.googleapis.com
Containerizza server
Passa alla directory in cui si trova l'esempio
server
:cd YOUR_WORKING_DIRECTORY/anthos-service-mesh-samples/docs/helloserver/server/
Crea l'immagine utilizzando
Dockerfile
e le variabili di ambiente definite 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 quando esegui il deployment del container.Esegui il push dell'immagine a Container Registry:
docker push gcr.io/$PROJECT_ID/$GCR_REPO/helloserver:v0.0.1
Containerizza loadgen
Passa alla directory in cui si trova l'esempio
loadgen
:cd ../loadgen
Crea l'immagine:
docker build -t gcr.io/$PROJECT_ID/$GCR_REPO/loadgen:v0.0.1 .
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 confermare che sia stato eseguito il push:
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 che i container siano sempre in esecuzione, nonché di un modo per fare lo scale up e avviare altre istanze di un container per gestire l'aumento del traffico.
Puoi utilizzare GKE per eseguire applicazioni containerizzate. GKE è una piattaforma di orchestrazione dei container che funziona connettendo le VM in un cluster. Ogni VM è detta nodo. I cluster GKE sono basati sul sistema open source di gestione dei cluster Kubernetes. Kubernetes fornisce i meccanismi che consentono di interagire con il cluster.
Per creare un cluster GKE:
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 nella zona e nel progetto Google Cloud impostati in precedenza. Per eseguire Cloud Service Mesh, consigliamo almeno quattro nodi e il tipo di macchina n1-standard-4.Il completamento del comando per creare il 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
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
Ora puoi utilizzare
kubectl
per comunicare con Kubernetes. Ad esempio, puoi eseguire questo 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:
Prima di eseguire il deployment dei container in GKE, rivedi alcuni concetti chiave di Kubernetes. Alla fine di questo tutorial troverai dei link che ti consentiranno di scoprire di più su ciascun concetto.
Nodi e cluster: in GKE, un nodo è una VM. Su altre piattaforme Kubernetes, un nodo può essere una macchina fisica o virtuale. Un cluster è un insieme di nodi che possono essere trattati insieme come una singola macchina, su cui viene eseguito il deployment di un'applicazione containerizzata.
Pod: in Kubernetes, i container vengono eseguiti all'interno di un pod. Un pod è l'unità atomica in Kubernetes. Un pod contiene uno o più container. Puoi eseguire il deployment di
server
eloadgen
container ciascuno nel proprio pod. Quando un pod esegue più container (ad esempio, un server applicazioni e un server proxy), i container vengono gestiti come una singola entità e condividono le risorse del pod.Deployment: un deployment è un oggetto Kubernetes che rappresenta un insieme di pod identici. Un oggetto Deployment esegue più repliche dei pod distribuiti tra i nodi di un cluster. Un deployment sostituisce automaticamente i pod che non rispondono o non rispondono.
Servizio Kubernetes: l'esecuzione del codice dell'applicazione in GKE cambia il networking tra
loadgen
eserver
. Quando eseguivi i servizi in una VM Cloud Shell, potevi inviare richieste aserver
utilizzando l'indirizzolocalhost:8080
. Dopo il deployment in GKE, i pod vengono pianificati per l'esecuzione sui nodi disponibili. Per impostazione predefinita, non puoi controllare su quale nodo è in esecuzione il pod, per cui i pod non hanno indirizzi IP stabili.Per ottenere un indirizzo IP per
server
, devi definire un'astrazione di networking nella parte superiore dei pod denominata servizio Kubernetes. Un servizio Kubernetes fornisce un endpoint di networking stabile per un insieme di pod. Esistono diversi tipi di servizi.server
utilizza unLoadBalancer
, che espone un indirizzo IP esterno in modo che tu possa raggiungereserver
dall'esterno del cluster.Kubernetes dispone inoltre di un sistema DNS integrato, che assegna nomi DNS (ad esempio,
helloserver.default.cluster.local
) ai servizi. Ciò consente ai pod all'interno del cluster di raggiungere altri pod nel 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 comando imperativo: python3 server.py
Imperativo significa basato sui verbi: "fai questo".
Kubernetes opera invece secondo un modello dichiarativo. Ciò significa che, anziché dire a Kubernetes esattamente cosa fare, fornisci a Kubernetes lo stato desiderato. Ad esempio, Kubernetes avvia e termina i pod in base alle esigenze in modo che lo stato effettivo del sistema corrisponda a quello desiderato.
Puoi specificare lo stato desiderato in un insieme di manifest o file YAML. Un file YAML contiene le specifiche di uno o più oggetti Kubernetes.
L'esempio contiene un file YAML per server
e loadgen
. Ogni file YAML specifica lo stato desiderato per l'oggetto Deployment Kubernetes e il servizio.
Server
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. Nella specifica dei pod è incluso il campoimage
, ovvero il nome dell'immagine da estrarre da Container Registry.
Il Servizio è definito come segue:
LoadBalancer
: i client inviano richieste all'indirizzo IP di un bilanciatore del carico di rete, che dispone di un indirizzo IP stabile ed è raggiungibile all'esterno del cluster.targetPort
: ricorda che il comandoEXPOSE 8080
inDockerfile
non espone effettivamente alcuna porta. Esponi la porta8080
in modo da poter raggiungere il containerserver
all'esterno del cluster. In questo caso,hellosvc.default.cluster.local:80
(shortname:hellosvc
) viene mappato alla porta8080
dell'IP del podhelloserver
.port
: il numero di porta utilizzato da altri servizi nel cluster per l'invio delle richieste.
Generatore di carico
L'oggetto Deployment in loadgen.yaml
è simile a server.yaml
. Una differenza notevole è che l'oggetto Deployment contiene una sezione denominata env
. Questa sezione definisce le variabili di ambiente richieste da loadgen
, che hai impostato in precedenza quando hai eseguito l'applicazione dall'origine.
Poiché loadgen
non accetta richieste in entrata, il campo type
è impostato su ClusterIP
. Questo tipo fornisce un indirizzo IP stabile che i servizi nel cluster possono utilizzare, ma l'indirizzo IP non è esposto ai client esterni.
Esegui il deployment dei container in GKE
Passa alla directory in cui si trova l'esempio
server
:cd YOUR_WORKING_DIRECTORY/anthos-service-mesh-samples/docs/helloserver/server/
Apri
server.yaml
in un editor di testo.Sostituisci il nome nel campo
image
con il nome della tua immagine Docker.image: gcr.io/PROJECT_ID/asm-ready/helloserver:v0.0.1
Sostituisci
PROJECT_ID
con l'ID del tuo progetto Google Cloud.Salva e chiudi
server.yaml
.Esegui il deployment del file YAML in Kubernetes:
kubectl apply -f server.yaml
Se l'operazione riesce, il comando risponde con quanto segue:
deployment.apps/helloserver created service/hellosvc created
Passa alla directory in cui si trova
loadgen
.cd ../loadgen
Apri
loadgen.yaml
in un editor di testo.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.Salva e chiudi
loadgen.yaml
, quindi chiudi l'editor di testo.Esegui il deployment del file YAML in Kubernetes:
kubectl apply -f loadgen.yaml
Se l'operazione riesce, il comando risponde con quanto segue:
deployment.apps/loadgenerator created service/loadgensvc created
Controlla lo stato dei pod:
kubectl get pods
Il comando risponde con uno 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
Recupera i log dell'applicazione dal pod
loadgen
. SostituisciPOD_ID
con l'identificatore dell'output precedente.kubectl logs loadgenerator-POD_ID
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
Invia una richiesta a
hellosvc
. SostituisciEXTERNAL_IP
con l'indirizzo IP esterno del tuohellosvc
.curl http://EXTERNAL_IP
Pronto per Cloud Service Mesh
A questo punto hai eseguito il deployment dell'applicazione su GKE. loadgen
può utilizzare il DNS Kubernetes (hellosvc:80
) per inviare richieste a server
e
puoi inviare richieste a server
con un indirizzo IP esterno. Sebbene Kubernetes offra molte funzionalità, mancano alcune informazioni sui servizi:
- Come interagiscono i servizi? Qual è il rapporto tra i servizi? Come scorre il traffico tra i servizi? Sai che
loadgen
invia richieste alserver
, ma immagina di non avere familiarità con l'applicazione. Non puoi rispondere a queste domande guardando l'elenco di pod in esecuzione su GKE. - Metriche: quanto tempo impiega
server
per rispondere alle richieste in arrivo? Quante richieste al secondo (RPS) sono in entrata nell'server
? Sono presenti risposte di errore? - Informazioni di sicurezza: il traffico tra
loadgen
eserver
è normaleHTTP
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 inserendo un proxy sidecar Envoy in ogni pod. Il proxy Envoy
intercetta tutto il traffico in entrata e in uscita verso i container dell'applicazione. Questo
significa che server
e loadgen
ricevono ciascuno un proxy sidecar Envoy e tutto
il traffico dal loadgen
al server
è mediato dai proxy Envoy. Le connessioni tra questi proxy Envoy costituiscono il mesh di servizi. Questa architettura
mesh di servizio fornisce un livello di controllo superiore a Kubernetes.
Poiché i proxy Envoy vengono eseguiti nei propri container, puoi installare Cloud Service Mesh su un cluster GKE senza apportare modifiche sostanziali al codice dell'applicazione. Tuttavia, esistono alcuni modi chiave in cui hai preparato l'applicazione per l'instrumentazione con Cloud Service Mesh:
- Servizi per tutti i container: i deployment
server
eloadgen
hanno un servizio Kubernetes collegato. Ancheloadgen
, che non riceve richieste in entrata, ha un servizio. - Le porte nei servizi devono avere un nome: sebbene GKE consenta di definire porte di servizio senza nome, Cloud Service Mesh richiede di fornire un nome per una porta che corrisponda al protocollo della porta. Nel file YAML, la porta per
server
è denominatahttp
perchéserver
utilizza il protocollo di comunicazioneHTTP
. Seservice
utilizzavagRPC
, il nome della porta saràgrpc
. - I deployment sono etichettati: questo 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 comporta l'eliminazione di tutte le risorse che compongono il cluster di container, ad esempio istanze di calcolo, dischi e risorse di rete.
gcloud container clusters delete asm-ready
Passaggi successivi
Scopri di più sulle tecnologie utilizzate in questo tutorial:
Scopri di più sugli strumenti:
Scopri di più sui concetti di base di Kubernetes: