🥇 Preparazione dell'applicazione per Istio

Istio è uno strumento pratico per connettere, proteggere e monitorare applicazioni distribuite. Istio utilizza diverse tecnologie per il lancio e la gestione su larga scala del software, inclusi i container per imballare il codice dell'applicazione e le dipendenze per il deployment, e Kubernetes per gestire questi container. Pertanto, per lavorare con Istio, è necessario comprendere come funziona un'applicazione con più servizi basata su queste tecnologie. di Istio. Se questi strumenti e concetti ti sono già familiari, sentiti libero di saltare questa guida e andare direttamente alla sezione Installazione di Istio su Google Kubernetes Engine (GKE) o all'installazione dell'estensione Istio su GKE.

Questa è una guida passo passo in cui esamineremo l'intero processo dal codice sorgente al container su GKE, per farti avere una comprensione di base di queste tecnologie attraverso un esempio. Vedrai anche come Istio sfrutta le potenzialità di queste tecnologie. Si presume che tu non sappia nulla di container, Kubernetes, service mesh o Istio.

Attività

In questa guida, completerai le seguenti attività:

Esplora una semplice applicazione hello world con più servizi.
Avvio dell'applicazione dal codice sorgente.
Imballaggio dell'applicazione in contenitori.
Creazione di un cluster Kubernetes.
Distribuzione dei contenitori nel cluster.

Prima di iniziare

Segui le istruzioni per abilitare l'API di Kubernetes Engine:

Visita la pagina di Kubernetes Engine nel Google Cloud Platform console.
Crea o seleziona un progetto.
Attendere che l'API e i servizi correlati vengano abilitati. Questo potrebbe richiedere alcuni minuti.
Assicurati che la fatturazione sia attivata per il progetto Google Cloud Platform. Scopri come abilitare la fatturazione.

In questa guida puoi utilizzare Cloud Shell, che prepara una macchina virtuale g1-small in Google Compute Engine con Linux basato su Debian, oppure un computer con Linux o macOS.

Opzione A: utilizzo di Cloud Shell

Vantaggi dell'utilizzo di Cloud Shell:

Ambienti di sviluppo Python 2 e Python 3 (incluso virtualenv) completamente configurati.
Strumenti da riga di comando gcloud, docker, git e kubectl, che utilizzeremo, sono già installati.
Hai diverse opzioni di editor di testo:
1. Editor di codice, che si apre con l'icona di modifica nella parte superiore della finestra di Cloud Shell.
2. Emacs, Vim o Nano, che si aprono dalla riga di comando in Cloud Shell.

Per utilizzare Cloud Shell:

Vai alla console GCP.
Clicca sul pulsante Attiva Cloud Shell (Attiva Cloud Shell) nella parte superiore della finestra della console GCP.

Nella parte inferiore della console GCP si aprirà una sessione Cloud Shell con il prompt dei comandi in una nuova finestra.

Opzione B: utilizzo degli strumenti della riga di comando localmente

Se stai lavorando su un computer con Linux o macOS, devi configurare e installare i seguenti componenti:

Configura l'ambiente di sviluppo Python 3 e Python 2.
Installa il Cloud SDK con l'interfaccia della riga di comando gcloud.
Installa kubectl — strumento della riga di comando per lavorare con Kubernetes.
```
gcloud components install kubectl
```
Installa Docker Community Edition (CE). Utilizzerai l'interfaccia della riga di comando docker, per creare immagini dei container per l'esempio dell'applicazione.
Installa lo strumento di controllo versione Git, per ottenere l'esempio dell'applicazione da GitHub.

Download dell'esempio di codice

Scarica il codice sorgente helloserver:

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

Vai alla cartella dell'esempio di codice:
```
cd istio-samples/sample-apps/helloserver
```

Esplora l'applicazione con più servizi

L'esempio dell'applicazione è scritto in Python e consiste di due componenti che interagiscono tramite REST:

server: un server semplice con un unico endpoint GET, /, che restituisce "hello world" sulla console.
loadgen: uno script che invia traffico a server, con un numero configurabile di richieste al secondo.

Avviare l'applicazione dal codice sorgente

Per studiare un esempio di applicazione, avvialo in Cloud Shell o sul tuo computer.
1) Nella directory istio-samples/sample-apps/helloserver esegui server:

python3 server/server.py

All'avvio server viene visualizzato quanto segue:

INFO:root:Starting server...

2) Apri un'altra finestra del terminale per inviare richieste a server. Se usi Cloud Shell, fai clic sull'icona di aggiunta per aprire un'altra sessione.
3) Invia una richiesta a server:

curl http://localhost:8080

il server risponde:

Hello World!

4) Dalla directory in cui hai caricato l'esempio di codice, passa alla directory contenente loadgen:

cd YOUR_WORKING_DIRECTORY/istio-samples/sample-apps/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 genera un messaggio simile a questo:

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

In un'altra finestra del terminale server mostra sulla console messaggi simili a questi:

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

Dal punto di vista della rete, tutta l'applicazione funziona su un unico host (computer locale o macchina virtuale Cloud Shell). Pertanto è possibile utilizzare localhost, per inviare richieste a server.
10) Per fermare loadgen e server, digitare Ctrl-c in ogni finestrino del terminale.
11) Nella finestra del terminale loadgen disattivare l'ambiente virtuale:

deactivate

Imballaggio dell'applicazione nei container

Per eseguire l'applicazione su GKE, è necessario impacchettare l'esempio dell'applicazione — server e loadgen — in container. Un container è un modo per imballare l'applicazione per isolarla dall'ambiente.

Per imballare l'applicazione in un container, è necessario Dockerfile. Dockerfile — è un file di testo che definisce i comandi per costruire il codice sorgente dell'applicazione e le sue dipendenze in un'immagine Docker. Dopo la raccolta, carichi l'immagine nel registro dei container, ad esempio Docker Hub o Container Registry.

L'esempio contiene già Dockerfile per server e loadgen con tutti i comandi necessari per costruire le immagini. Di seguito — Dockerfile per server:

DA python:3-slim come base
DA base come builder
RUN apt-get -qq update 
    && apt-get install -y --no-install-recommends 
        g++ 
    && rm -rf /var/lib/apt/lists/*

# Abilita il logging in modo non bufferizzato
DA base come finale
ENV PYTHONUNBUFFERED=1

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

WORKDIR /helloserver

# Preleva i pacchetti dal builder
COPY --from=builder /usr/local/lib/python3.7/ /usr/local/lib/python3.7/

# Aggiungi l'applicazione
COPY . .

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

Team DA python:3-slim come base richiede a Docker di utilizzare l'ultimo immagine Python 3 come base.
Team COPY . . copia i file sorgente nella cartella di lavoro corrente (in questo caso solo server.py) nel file system del contenitore.
ENTRYPOINT definisce il comando utilizzato per avviare il contenitore. In questo caso, questo comando è quasi identico a quello che hai utilizzato per avviare server.py dal codice sorgente.
Team EXPOSE indica che server si aspetta dati attraverso la porta 8080. Questo comando non fornisce porte. È qualcosa come una documentazione necessaria per aprire la porta 8080 quando si avvia il contenitore.

Preparazione per la containerizzazione dell'applicazione

1) Imposta le seguenti variabili ambientali. Sostituisci PROJECT_ID con l'identificativo del tuo progetto GCP.

export PROJECT_ID="PROJECT_ID"

export GCR_REPO="preparing-istio"

Utilizzando i valori PROJECT_ID e GCR_REPO Contrassegni l'immagine Docker quando la costruisci e la invii al registro di container privato.

2) Imposta il progetto GCP predefinito per lo strumento da riga di comando. gcloud.

gcloud config set project $PROJECT_ID

3) Imposta la zona predefinita per lo strumento da riga di comando. gcloud.

gcloud config set compute/zone us-central1-b

4) Assicurati che il servizio Container Registry sia abilitato nel progetto GCP.

gcloud services enable containerregistry.googleapis.com

Containerizzazione server

Vai nella directory dove si trova l'esempio. server:

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

Costruisci l'immagine con Dockerfile e le variabili d'ambiente che hai definito in precedenza:
```
docker build -t gcr.io/$PROJECT_ID/$GCR_REPO/helloserver:v0.0.1 .
```

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

Invia l'immagine al Container Registry:

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

Containerizzazione loadgen

1) Vai nella directory dove si trova l'esempio. loadgen:

cd ../loadgen

2) Costruisci l'immagine:

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

3) Invia l'immagine al Container Registry:

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

Visualizza l'elenco delle immagini

Controlla l'elenco delle immagini nel repository e assicurati che le immagini siano state caricate:

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

Il comando restituisce i nomi delle immagini appena caricate:

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

Creazione di un cluster GKE.

Questi contenitori potrebbero essere eseguiti su una macchina virtuale di Cloud Shell o sul computer utilizzando il comando docker run. Tuttavia, in un ambiente di produzione è necessaria una soluzione per orchestrare i contenitori in modo centralizzato. Ad esempio, serve un sistema che monitori costantemente i contenitori affinché funzionino sempre, e serve un modo per scalare e avviare ulteriori istanze dei contenitori se cresce il traffico.

Per eseguire applicazioni containerizzate, puoi utilizzare GKE. GKE è una piattaforma di orchestrazione dei contenitori che raggruppa le macchine virtuali in un cluster. Ogni macchina virtuale è chiamata nodo. I cluster GKE si basano sul sistema open source di gestione dei cluster Kubernetes. Kubernetes fornisce meccanismi per interagire con il cluster.

Creazione di un cluster GKE:

1) Crea un cluster:

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

Team gcloud crea un cluster istioready nel progetto GCP e nella zona predefinita che hai specificato. Per avviare Istio, si consiglia di avere almeno 4 nodi e una macchina virtuale n1-standard-2.

Il team crea un cluster in pochi minuti. Quando il cluster è pronto, il team restituisce un messaggio simile messaggio.

2) Inserisci le credenziali nello strumento da riga di comando kubectl, per gestire il cluster:

gcloud container clusters get-credentials istioready

3) Ora puoi comunicare con Kubernetes tramite kubectl. Ad esempio, puoi controllare lo stato dei nodi con il seguente comando:

kubectl get nodes

Il comando restituisce un elenco dei nodi:

NOME                                       STATO   RUOLO     ETÀ    VERSIONE
gke-istoready-default-pool-dbeb23dc-1vg0   Pronto    <nessuno>   99s    v1.13.6-gke.13
gke-istoready-default-pool-dbeb23dc-36z5   Pronto    <nessuno>   100s   v1.13.6-gke.13
gke-istoready-default-pool-dbeb23dc-fj7s   Pronto    <nessuno>   99s    v1.13.6-gke.13
gke-istoready-default-pool-dbeb23dc-wbjw   Pronto    <nessuno>   99s    v1.13.6-gke.13

Concetti chiave di Kubernetes

Il diagramma mostra un'applicazione su GKE:

Prima di distribuire contenitori in GKE, studia i concetti chiave di Kubernetes. Alla fine ci sono link se desideri saperne di più.

Nodi e cluster. In GKE un nodo è una macchina virtuale. Su altre piattaforme, un nodo Kubernetes può essere un computer o una macchina virtuale. Un cluster è un insieme di nodi che si può considerare come un'entità unica dove distribuisci un'applicazione containerizzata.
Pod. In Kubernetes, i container vengono eseguiti nei pod. Un pod in Kubernetes è un'unità indivisibile. Un pod contiene uno o più container. Distribuite i container del server e loadgen in pod separati. Quando ci sono più container in un pod (ad esempio, il server dell'applicazione e un proxy server), i container sono gestiti come un unico oggetto e condividono le risorse del pod.
Distribuzioni. In Kubernetes, una distribuzione è un oggetto che rappresenta un insieme di pod identici. La distribuzione avvia più repliche di pod distribuite sui nodi del cluster. La distribuzione sostituisce automaticamente i pod che hanno fallito o che non rispondono.
Servizio Kubernetes. Quando esegui il codice dell'applicazione in GKE, cambia la connessione tra loadgen e server. Quando hai avviato i servizi su una macchina virtuale di Cloud Shell o sul computer, inviavi richieste a server all'indirizzo localhost:8080. Dopo il deployment in GKE, i pod vengono eseguiti sui nodi disponibili. Di default, non puoi gestire su quale nodo viene eseguito un pod, quindi i pod non hanno indirizzi IP permanenti.
Per ottenere un indirizzo IP per server, è necessario definire un'astrazione di rete sopra ai pod. Questo è il servizio Kubernetes. Il servizio Kubernetes fornisce un endpoint permanente per un insieme di pod. Ci sono diversi tipi di servizi. server utilizza LoadBalancer, che fornisce un indirizzo IP esterno per comunicare con server al di fuori del cluster.
Inoltre, Kubernetes dispone di un sistema DNS integrato che assegna nomi DNS (ad esempio, helloserver.default.cluster.local) ai servizi. Grazie a ciò, i pod all'interno del cluster si collegano ad altri pod nel cluster tramite un indirizzo permanente. Il nome DNS non può essere utilizzato al di fuori del cluster, ad esempio in Cloud Shell o sul computer.

Manifesti Kubernetes

Quando hai avviato un'applicazione dal codice sorgente, hai utilizzato un comando imperativo python3

server.py

L'imperatività implica un verbo: "fai questo".

Kubernetes utilizza un modello dichiarativo. Ciò significa che non diciamo a Kubernetes cosa deve fare esattamente, ma descriviamo lo stato desiderato. Ad esempio, Kubernetes avvia e ferma i pod secondo necessità per garantire che lo stato attuale del sistema corrisponda a quello desiderato.

Lo stato desiderato è specificato nei manifesti, o nei file YAML. Il file YAML contiene le specifiche per uno o più oggetti Kubernetes.

L'esempio include un file YAML per server e loadgen. Ogni file YAML specifica lo stato desiderato di un oggetto di deployment e del servizio 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

kind indica il tipo di oggetto.
metadata.name indica il nome del deployment.
Il primo campo spec contiene la descrizione dello stato desiderato.
spec.replicas indica il numero desiderato di pod.
Sezione spec.template definisce il modello del pod. Nella specifica dei pod è presente il campo image, dove si specifica il nome dell'immagine da estrarre dal Container Registry.

Il servizio è definito come segue:

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

LoadBalancer: i clienti inviano richieste all'indirizzo IP del bilanciatore di carico, che ha un indirizzo IP permanente ed è accessibile dall'esterno del cluster.
targetPort: come ricorderete, il comando EXPOSE 8080 in Dockerfile non ha fornito porte. Si fornisce la porta 8080, in modo da poter comunicare con il contenitore server dall'esterno del cluster. Nel nostro caso hellosvc.default.cluster.local:80 (nome breve: hellosvc) corrisponde alla porta 8080 Indirizzo IP del pod helloserver.
port: è il numero di porta a cui gli altri servizi nel cluster invieranno le richieste.

loadgen.yaml

L'oggetto di distribuzione in loadgen.yaml sembra simile a server.yaml. La differenza è che l'oggetto di distribuzione contiene la sezione env. Definisce le variabili di ambiente necessarie loadgen e che hai impostato durante l'avvio dell'applicazione dal codice sorgente.

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

Se loadgen non accetta richieste in ingresso, per il campo type è specificato ClusterIP. Questo tipo fornisce un indirizzo IP statico che può essere utilizzato dai servizi nel cluster, ma questo indirizzo IP non è fornito ai clienti esterni.

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

Distribuzione di contenitori in GKE

1) Vai nella directory dove si trova l'esempio. server:

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

2) Apri server.yaml in un editor di testo.
3) Sostituisci il nome nel campo image con il nome della tua immagine Docker.

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

Sostituisci PROJECT_ID con l'identificatore del tuo progetto GCP.
4) Salva e chiudi server.yaml.
5) Distribuisci il file YAML in Kubernetes:

kubectl apply -f server.yaml

Una volta completato con successo, il comando restituisce il seguente codice:

deployment.apps/helloserver creato
service/hellosvc creato

6) Vai 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/preparing-istio/loadgenv0.0.1

Sostituisci PROJECT_ID con l'identificatore del tuo progetto GCP.
9) Salva e chiudi loadgen.yaml, chiudi l'editor di testo.
10) Distribuisci il file YAML in Kubernetes:

kubectl apply -f loadgen.yaml

Una volta completato con successo, il comando restituisce il seguente codice:

deployment.apps/loadgenerator creato
service/loadgensvc creato

11) Controlla lo stato dei pod:

kubectl get pods

Il comando mostra lo stato:

NAME                             READY   STATUS    RESTARTS   AGE
helloserver-69b9576d96-mwtcj     1/1     Running   0          58s
loadgenerator-774dbc46fb-gpbrz   1/1     Running   0          57s

12) Estrai i log dell'applicazione dal pod loadgen. Sostituisci POD_ID con l'identificatore della risposta precedente.

kubectl logs loadgenerator-POD_ID

13) Ottieni gli indirizzi IP esterni hellosvc:

kubectl get service

La risposta del comando appare più o meno così:

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) Invia una richiesta a hellosvc: sostituisci EXTERNAL_IP all'indirizzo IP esterno hellosvc.

curl http://EXTERNAL_IP

Iniziamo con Istio

Hai già un'applicazione distribuita in GKE. loadgen può utilizzare il DNS di Kubernetes (hellosvc:80), per inviare richieste a server, e puoi inviare richieste a server all'indirizzo IP esterno. Anche se Kubernetes ha molte funzionalità, alcune informazioni sui servizi mancano:

Come interagiscono i servizi? Quali relazioni ci sono tra i servizi? Come scorre il traffico tra i servizi? Sei a conoscenza del fatto che loadgen inviano richieste a server, ma immagina di non sapere nulla sull'applicazione. Per rispondere a queste domande, guardiamo l'elenco dei pod in esecuzione in GKE.
Metriche. Quanto tempo impiega server a rispondere a una richiesta in arrivo? Quante richieste al secondo riceve il server? Genera messaggi di errore?
Informazioni sulla sicurezza. Il traffico tra loadgen e server scorre semplicemente tramite HTTP o tramite mTLS?

Istio risponde a tutte queste domande. Per fare ciò, Istio posiziona un proxy sidecar Envoy in ogni pod. Il proxy Envoy intercetta tutto il traffico in ingresso e in uscita dai contenitori dell'applicazione. Ciò significa che server e loadgen ricevono tramite il proxy sidecar Envoy, e tutto il traffico da loadgen a server passa attraverso il proxy Envoy.

Le connessioni tra i proxy Envoy formano una service mesh. L'architettura della service mesh offre un livello di controllo sopra Kubernetes.

Poiché i proxy Envoy vengono eseguiti nei propri contenitori, Istio può essere installato sopra un cluster GKE, apportando quasi nessuna modifica al codice dell'applicazione. Ma hai fatto qualche lavoro per preparare l'applicazione a essere gestita tramite Istio:

Servizi per tutti i contenitori. Alle distribuzioni server e loadgen è associato un servizio Kubernetes. Anche a loadgen, a cui non vengono inviati richieste in entrata, è associato un servizio.
Le porte nei servizi devono avere un nome. Anche se in GKE le porte dei servizi possono essere lasciate senza nome, Istio richiede di specificare il nome della porta in base al suo protocollo. Nel file YAML, la porta per server è chiamata http, perché il server utilizza il protocollo HTTP. Se avesse utilizzato service , avresti chiamato la porta gRPCgrpc Le distribuzioni vengono etichettate. Pertanto, puoi utilizzare le funzionalità di gestione del traffico di Istio, ad esempio per suddividere il traffico tra le versioni di un servizio..
Installazione di Istio

Istio può essere installato in due modi. Puoi

abilitare l'estensione Istio on GKE installare la versione open source di Istio o installare la versione open source di Istio nel cluster. Con Istio su GKE è possibile gestire facilmente l'installazione e l'aggiornamento di Istio durante il ciclo di vita del cluster GKE. Se hai bisogno della versione più recente di Istio o di maggiore controllo sulla configurazione della dashboard di Istio, installa la versione open source invece dell'estensione Istio su GKE. Per decidere quale approccio seguire, leggi l'articolo Ho bisogno di Istio su GKE?.

Scegli un'opzione, consulta la guida pertinente e segui le istruzioni per installare Istio sul cluster. Se desideri utilizzare Istio con un'applicazione appena distribuita, attiva l'inserimento dei sidecar per lo spazio dei nomi default.

Pulizia

Per evitare addebiti sul tuo account Google Cloud Platform per le risorse utilizzate in questa guida, elimina il cluster di contenitori una volta installato Istio e dopo aver sperimentato l'applicazione di esempio. Questo comporterà la rimozione di tutte le risorse del cluster, inclusi istanze computazionali, dischi e risorse di rete.