Google Kubernetes Engine: App di esempio

Avviamo la nostra prima applicazione Kubernetes su Google Cloud e, per farlo, definiamo bene i passi da seguire:

• creiamo un cluster secondo la modalità Autopilot di GKE;
• scegliamo le immagini Docker da porre come basi dei nodi operativi dell'applicazione. Possiamo utilizzare immagini provenienti da un registry esterno come DockerHub o quelle predisposte da noi o da altri sul registry interno di GCP che prende il nome di Artifact Registry (ne esiste un altro, di prima generazione, chiamato Google Container Registry). In questo esempio, per semplicità, seguiremo la prima via ma si tenga presente che, andando avanti con gli studi di GCP e GKE, è assolutamente fondamentale saper containerizzare le proprie applicazioni ed usare Artifact Registry;
• utilizziamo il comando gcloud per autenticarci presso il cluster;
• interagiamo con il cluster mediante kubectl proprio come abbiamo sempre fatto con minikube. Questo è un aspetto molto interessante in quanto proietta direttamente nel Cloud tutta la conoscenza su Kubernetes che abbiamo accumulato sinora;
• alla fine dell'utilizzo dell'applicazione chiudiamo tutte le risorse che abbiamo avviato con una tipica operazione di clean up. Questo è un aspetto fondamentale in quanto nel Cloud si paga solo ciò che si utilizza pertanto ogni risorsa non più necessaria va immediatamente chiusa.

Creazione del cluster

Supponiamo di avere un progetto Google già pronto a cui faremo riferimento mediante PROJECT ID (nel nostro caso, faremo finta sia my-cloud-1234). Apriamo la Cloud Shell e impostiamo il progetto di default:

$ gcloud config set project my-cloud-1234
Updated property [core/project].

Il messaggio di risposta ci conferma l'avvenuto aggiornamento della configurazione.

Qualora non lo siano, attiviamo le API container.googleapis.com sul progetto Google che stiamo usando con:

$ gcloud services enable container.googleapis.com

A questo punto creiamo un cluster di nome my-first-cluster in Autopilot nella regione us-central1. (questi aspetti possono essere personalizzati in base alle nostre esigenze):

$ gcloud container clusters create-auto my-first-cluster --location=us-central1
...
Creating cluster my-first-cluster in us-central1... Cluster is being health-checked...working.
Creating cluster my-first-cluster in us-central1... Cluster is being health-checked (master is healthy)
...done.
...
...
NAME: my-first-cluster
LOCATION: us-central1
MASTER_VERSION: 1.27.3-gke.100
MASTER_IP: <l'indirizzo IP pubblico assegnato al vostro cluster>
MACHINE_TYPE: e2-medium
NODE_VERSION: 1.27.3-gke.100
NUM_NODES: 3
STATUS: RUNNING

Dopo alcuni secondi di attesa, il nostro cluster sarà pronto ed i messaggi in output ne mostreranno le caratteristiche principali. Tra l'altro avremo anche l'informazione dell'identificativo univoco del cluster che avrà un formato tipo

https://container.googleapis.com/v1/projects/PROJECT-ID/zones/REGIONE-CLUSTER/clusters/NOME-CLUSTER

dove, al posto delle parole che abbiamo indicato in maiuscolo, appariranno gli identificativi specifici del vostro cluster: ciò dimostra come ogni risorsa creata (non vale solo per i cluster Kubernetes) sia congenitamente legata non solo al nome da noi assegnato ma anche a regione e progetto Google di appartenenza. Potremo verificare l'attuale stato del cluster con il comando:

$ gcloud container clusters create-auto my-first-cluster --location=us-central1

o passando dal pannello di controllo di GKE nella console di Google Cloud seguendo questo link.

Il simbolo verde indica che il cluster è running ma, non avendo ancora avviato applicazioni, le risorse che Autopilot gli assegna sono nulle. In alternativa, possiamo chiedere l'elenco dei cluster a nostra disposizione con:

gcloud container clusters list

Ora che il cluster è pronto potremo chiedere le credenziali di accesso in modo che qualsiasi comando successivo di kubectl sia autorizzato ad agire al suo interno. Il comando di cui abbiamo bisogno è il seguente:

$ gcloud container clusters get-credentials my-first-cluster \
    --location us-central1

Ricordiamo che il simbolo \ si usa per andare a capo nei comandi al fine di migliorarne la leggibilità. Fatto ciò potremo lanciare la nostra applicazione.

L'applicazione: Deployment e Service

Per provare il nostro cluster, lanceremo un'applicazione che, in questo caso, consisterà semplicemente in un server Web Apache la cui immagine sarà reperita su DockerHub. Come abbiamo imparato sinora, creare un'applicazione su Kubernetes e, aprirla alle connessioni, consiste nel lanciare un Deployment ed esporlo con un Service: tutto il resto sottostante (Pod, repliche, etc.) sarà mantenuto in autonomia da Kubernetes.

Anche nel Cloud, a maggior ragione, è fondamentale l'uso della configurazione dichiarativa di un'applicazione ma in questo caso, per semplicità di approccio, utilizzeremo la configurazione imperativa. Ecco il lancio del Deployment:

$ kubectl create deployment my-server-web \
    --image=httpd

Autopilot adatterà le risorse e lancerà il necessario sul cluster (ricordiamo che ci siamo autenticati quindi ogni comando è rivolto al cluster). Facciamo alcune verifiche di routine:

$ kubectl get deploy
NAME            READY   UP-TO-DATE   AVAILABLE   AGE
my-server-web   1/1     1            1           2m57s
$ kubectl get pods
NAME                             READY   STATUS    RESTARTS   AGE
my-server-web-7f79d67824-pkqfk   1/1     Running   0          3m

Essendo tutto perfettamente operativo, esponiamo il Deployment con un Service che offre un LoadBalancer:

$ kubectl expose deployment my-server-web \
    --type LoadBalancer \
    --port 80 \
    --target-port 80
service/my-server-web exposed

Quando il Service sarà stato lanciato potremo verificarne l'operatività, in primis, con kubectl:

$ kubectl get svc

che ci mostrerà il nostro indirizzo IP pubblico etichettato come LoadBalancer. Successivamente potremo aprire la console di gestione di GKE alla pagina dedicata a Service e Ingress seguendo il link https://console.cloud.google.com/kubernetes/discovery. Soprattutto però potremo invocare l'indirizzo IP che ci è stato assegnato verificando che appaia il messaggio di benvenuto con cui Apache presenta sempre le sue nuove installazioni: "It works!".

In tutto questo, intanto, il cluster è stato dotato delle risorse necessarie al suo funzionamento secondo le politiche di gestione autonome di Autopilot:

Pulizia finale e chiusura del cluster

Eccoci infine ad una parte estremamente importante: la messa a riposo delle risorse e la chiusura del cluster. Potremo innanzitutto spegnere il nostro Service Kubernetes con il comando:

$ kubectl delete service my-server-web

applicando, come immaginabile, il nome del nostro esempio e poi, se non più necessario, chiudere anche il cluster con:

$ gcloud container clusters delete my-first-cluster --location us-central1