Azure Kubernetes Service

Azure Kubernetes Service è un servizio Kubernetes completamente gestito per la distribuzione per applicazioni containerizzate offerto da Microsoft Azure, il quale offre una sui suite completa di strumenti per portare le proprie applicazioni verso un’architettura serverless.

Un’infarinatura di Kubernetes

Kubernetes, il cui nome deriva dal greco “kubernḗtēs” (capitano / timoniere), è una piattaforma open-source per la gestione di servizi containerizzati che ha l’obiettivo di semplificare e automatizzare il processo di deploy e gestione delle applicazioni.

Kubernetes (d’ora in avanti K8s) fornisce una vasta gamma di servizi: load balancing, orchestrazione dello storage, rollout e rollback automatizzati, self-healing e gestione di informazioni sensibili e configurazioni.

Con la giusta configurazione K8s può automatizzare al 100% tutto il processo di distribuzione delle proprie applicazioni, ma non è tutto oro quello che luccica. Chi ha configurato – o provato – K8s da zero, sa benissimo quanto può essere complesso orchestrare, e successivamente gestire, tutti i servizi che offre senza incappare in qualche problema, talvolta annullando completamente i vantaggi che se ne possono ottenere.

AKS cerca di semplificare la gestione di K8s astraendo la sua complessità.

Servizio gestito Kubernetes

AKS si preoccupa di spostare su di sé la responsabilità delle operazioni di configurazione, gestione e monitoraggio di K8s, garantendo l’utilizzo di best-practice in tema di sicurezza, governance e high-availability.

Cercando di riassumere in tre concetti cardine un servizio gestito offre quanto segue:

  1. Riduzione della complessità operativa astraendo la complessità dei servizi K8s, dando la possibilità ai team di sviluppo di aumentare la propria agilità senza incrementare il rischio, abbattendo la curva di apprendimento necessaria dello strumento in sé;
  2. Governance e sicurezza a livello enterprise garantendo costantemente i requisiti di conformità e sicurezza compatibili con il Conformance Program of Cloud Native Computing Foundation;
  3. Processi automatizzati e standardizzati tramite l’automazione di processi di aggiornamento, scaling, load-balancing e monitoraggio;

A questi si aggiungono anche i servizi offerti parallelamente da Azure; è infatti possibile integrare con Azure DevOps, Active Directory, servizi di storing e altro ancora.

Nel servizio vengono inclusi gratuitamente sia il Master Node che un load balancer, mentre tutti gli altri servizi hanno il loro listino prezzi “predefinito” (lo stesso che si avrebbe comprandoli per scopi al di fuori di AKS) siano essi siano obbligatori, come le VM per i nodi o lo storage, sia facoltativi come il log analytic workspace o SLA.

AKS fornisce e gestisce il control plane di K8s che consiste nei componenti core di K8s, come kube-apiserver, etcd, kube-scheduler e kube-controller-manager. Viene autonomamente gestito anche il ciclo vitale dei componenti, l’HA e gli aggiornamenti, mentre viene lasciato il controllo all’utente del pool dei nodi e il loro numero.

L’interazione con il servizio può avvenire in diversi modi: dal portale Azure, tramite l’Azure CLI, PowerShell, ARM Template, Terraform e via dicendo, rendendo possibile l’automazione dei task per garantire un’integrazione semplice e rapida con processi e strumenti di DevOps già esistenti.

A favore di un servizio gestito

Come abbiamo già detto, e come non ci stancheremo mai di ripetere, comprendere tutta l’infrastruttura di K8s può essere un processo lungo e difficile, quindi quali vantaggi ci offre un servizio gestito come AKS?

  • Cluster multi-master, ovvero un’infrastruttura in alta affidabilità che comprende  server etcd ridondati;
  •  Astrazione della complessità dei servizi distribuiti;
  • Semplifica i processi di scaling, i quali potrebbero risultare particolarmente ostici via via che il cluster aumenta di dimensione;
  • SLA e supporto forniti direttamente a Azure;

AKS si occupa quindi di effettuare tutto il lavoro pesante relativo alla gestione del cluster permettendo una distribuzione semplice e veloce di soluzioni K8s enterprise.

Il rovescio della medaglia

Ovviamente non ci sono solo aspetti positivi in un servizio K8s gestito, ma anche svariati svantaggi che potrebbero portare a preferire un ambiente completamente autogestito.

  • Dato che K8s viene aggiornato frequentemente (circa una minor ogni tre mesi) sarà praticamente impossibile lavorare costantemente usando l’ultima versione disponibile;
  • Container Network Interface predefinito per i container del cluster;
  • Immagine predefinita per l’OS, il quale verrà utilizzato dai vari nodi senza alcuna possibilità di personalizzazioni;
  • Control Plane con accesso e personalizzazioni limitate, rendendo impossibile entrare in un nodo Master tramite SSH o server etcd;
  • Non tutte le funzionalità potrebbero essere disponibili in tutte le regioni;
  • Limiti generici del servizio, come ad esempio il dimensionamento di un nodo o la banda disponibile;

Come si potrebbe aver già capito il compromesso principale nell’utilizzare un servizio completamente gestito è, in generale, la personalizzazione. Che si parli di nodi o del control plane utilizzando un servizio come AKS si è, ovviamente, limitati da ciò che viene direttamente offerto.

Di contro, però, abbiamo un servizio che si occupa in autonomia di utilizzare costantemente il miglior approccio possibile per quanto riguarda sicurezza, automazione e alta affidabilità, cosa non scontata quando invece si gestisce tutto il cluster “manualmente”.

Demo

Proviamo ad effettuare un esempio pratico di deploy su un cluster AKS.

Prerequisiti

I seguenti passaggi presuppongono che sia stato:

  1. Creato un “Service Principal” per accedere alle risorse desiderate (come il registry delle immagini);
  2. Creato il cluster AKS, al quale è stato associato il service principal, e con un solo nodo. Nessun’altra configurazione è necessaria per questa piccola dimostrazione;
  3. Configurato il proprio kubectl per accedere all’istanza AKS;

Configurazione

Come prima cosa è necessario creare un file yaml di deploy:

Come si può vedere il file è composto principalmente da due sezioni separate da “—”.

La prima rappresenta un oggetto di K8s di tipo Deployment che definisce cosa vogliamo rilasciare. In questo caso verranno create tre istanze (replicas: 3) con il nome base “aks-mabo” dall’immagine base “mattiabonanni.aks.giuneco:v1” recuperata direttamente dal registry Azure.

La seconda invece rappresenta un oggetto di tipo Service che andrà a configurare un load-balancer davanti alla nostra applicazione, e che si occuperà di direzionare il traffico verso una delle tre istanze agendo come punto di ingresso.

Deployment

Creato il file è sufficiente usare il comando “kubectl apply -f ./mabo.yaml”.

Usando “kubectl get service” si dovrebbe vedere il load balancer attivo

Collegandosi all’IP mostrato nella colonna “EXTERNAL-IP” si dovrebbe vedere la propria applicazione, che in questo esempio è semplicemente una pagina bianca con un titolo

Scaling e HA

All’inizio della dimostrazione ho specificato la necessità di avere un solo nodo nel cluster AKS, questo vuol dire che, al momento, l’applicazione è ridondata sì tre volte ma sullo stesso nodo, questo ovviamente vuol dire che nel caso in cui sul nodo si verifichi un problema di una certa entità l’applicazione non sarà più raggiungibile.

Non solo, anche il load balancer al momento è piuttosto inutile dato che tutto il traffico sarà comunque direzionato verso lo stesso nodo.

Per ovviare al problema possiamo affidarci ad AKS per scalare il numero di nodi necessari alle nostre esigenze.

Con un singolo comando possiamo dire ad AKS di creare altri due nodi uguali a quello precedentemente creato

Effettuando un nuovo deploy K8s si occuperà direttamente di rilasciare l’applicazione distribuendo sui tre nodi il carico.

Update

Se volessimo rilasciare una nuova versione dell’applicazione non dovremmo fare altro che ripetere lo step precedente di “Deploy” limitandosi a modificare la versione dell’immagine stessa.

Applicare le modifiche con il solito “kubectl apply -f ./mabo.yaml”

A questo punto K8s si occuperà di aggiornare le tre repliche preoccupandosi di mantenere l’HA e anche di effettuare un eventuale rollback alla precedente versione se dovesse verificarsi un errore.

Collegandosi nuovamente all’IP precedente si dovrebbe vedere l’applicazione aggiornata, che in questo caso consiste nella solita pagina bianca ma con un nuovo titolo.

In conclusione

Come abbiamo visto le operazioni di rilascio su AKS sono piuttosto semplici, tuttavia, considerando la banalità della demo, in ambiente di produzione a livello enterprise potrebbe non esserlo allo stesso modo.

Azure Kubernetes Service e Kubernetes forniscono gli strumenti per gestire un’applicazione enterprise serverless, e per questo sono senza dubbio utili. Spostare applicazioni monolitiche e/o non pensate per essere containerizzate potrebbe provocare più danni che benefici, soprattutto nel caso in cui non sia nativamente stateless.

Da usare con cura.