Distribuire Azure Kubernetes Service (AKS)
Quando lo sviluppo di applicazioni si sposta verso un approccio basato sui containers, è importante la necessità di orchestrare e gestire le risorse. Kubernetes è la piattaforma leader che offre programmazione affidabile di carichi di lavoro applicativi.
È possibile compilare ed eseguire applicazioni basate su microservizi moderne e portabili che sfruttano la capacità di Kubernetes di orchestrare e gestire la disponibilità di tali componenti applicativi.
Azure Kubernetes Service (AKS) è un servizio Kubernetes gestito che riduce la complessità delle attività di distribuzione e delle attività principali di gestione, tra cui il coordinamento degli aggiornamenti.
Architettura del cluster Kubernetes
Un cluster Kubernetes è suddiviso in due componenti:
- I nodi del control plane forniscono i servizi Kubernetes principali e l’orchestrazione dei carichi di lavoro dell’applicazione.
-
I nodi eseguono i carichi di lavoro applicativi.
Figura 1: Azure Kubernetes Service (AKS)
Control plane
Quando si crea un cluster AKS viene creato e configurato automaticamente un Control plane, che viene fornito come una risorsa di Azure gestita (astratta dall’utente) e a cui non è possibile accedere direttamente. Il Control plane non prevede alcun costo, bensì solo i nodi che fanno parte del cluster AKS.
Il Control plane include i seguenti componenti Kubernetes:
- kube-apiserver: Il server API indica il modo in cui le API Kubernetes sono esposte. Questo componente fornisce l’interazione per gli strumenti di gestione, ad esempio kubectl o la dashboard di Kubernetes.
- etcd: È un archivio di valori chiave all’interno di Kubernetes per mantenere lo stato della configurazione e del cluster Kubernetes.
- kube-scheduler: Quando si creano o si ridimensionano applicazioni, l’utilità di pianificazione determina quali nodi possono eseguire il carico di lavoro e li avvia.
- kube-controller-manager: Lo strumento di gestione del controller supervisiona molti controller più piccoli che eseguono azioni, ad esempio la replica di pod e la gestione delle operazioni dei nodi.
Nodi e pool di nodi
Per eseguire le applicazioni e i servizi di supporto, è necessario un nodo Kubernetes. Un cluster Azure Kubernetes Service ha uno o più nodi, ovvero una macchina virtuale (VM) di Azure che esegue i componenti nodo e il runtime del contenitore di Kubernetes:
- Il kubelet è l’agente Kubernetes che elabora le richieste di orchestrazione dal control plane e la pianificazione dell’esecuzione dei contenitori richiesti.
- La rete virtuale è gestita in ogni nodo dal kube-proxy. Il proxy instrada il traffico di rete e gestisce gli indirizzi IP per i servizi e i pod.
- Il container runtime è il componente che consente di eseguire le applicazioni nei container e interagire con risorse aggiuntive, ad esempio la rete virtuale e la risorsa di archiviazione. In AKS viene usato Moby come runtime del contenitore.
Figura 2: Pool di nodi in Azure Kubernetes Service
La dimensione della macchina virtuale di Azure utilizzata dai nodi del cluster AKS definisce il numero di CPU, la quantità di memoria e la dimensione e tipo del disco disponibile, ad esempio unità SSD a prestazioni elevate o HDD normale. Se si prevede di aver bisogno di applicazioni che richiedono grandi quantità di CPU e memoria o dischi a prestazioni elevate, pianificate di conseguenza la dimensione dei nodi. È anche possibile aumentare il numero di nodi del cluster Azure Kubernetes Service in base alle esigenze.
In AKS l’immagine della macchina virtuale per i nodi del cluster è attualmente basata su Ubuntu Linux o Windows Server 2019. Quando si crea un cluster Azure Kubernetes Service o si aumenta il numero di nodi, la piattaforma Azure crea il numero richiesto di macchine virtuali e le configura. Non è necessario eseguire alcuna configurazione manuale.
Pool di nodi
I nodi della stessa configurazione sono raggruppati in pool di nodi. Un cluster Kubernetes contiene uno o più pool di nodi, che verranno utilizzati per far girare le vostre applicazioni. Il numero e la dimensione iniziale dei nodi sono definiti quando si crea un cluster Azure Kubernetes Service; infatti viene creato un pool di nodi predefinito. Questo pool di nodi predefinito in AKS contiene le macchine virtuali che eseguono i nodi agent.
Per garantire il funzionamento affidabile del cluster e l’alta disponibilità è consigliabile eseguire 2 o più nodi nel pool di nodi predefinito.
Pod
Kubernetes usa i pod per eseguire un’istanza dell’applicazione. Un pod rappresenta una singola istanza dell’applicazione. I pod hanno in genere un mapping 1:1 con i container, anche se vi sono scenari avanzati in cui un pod può contenere più contenitori. Un pod è una risorsa logica, i carichi di lavoro applicativi sono eseguiti nei contenitori.
Creazione di un Azure Kubernetes Service
Per creare un Azure Kubernetes Service potete collegarvi al portale di Azure e cercare la risorsa Kubernetes Service.
Figura 3: Creazione della risorsa Azure Kubernetes Service nel portale di Azure
Per creare un Kubernetes Cluster vi verranno richieste diverse informazioni. Inserite il nome del cluster, la regione dove volete distribuirlo, la versione di Kubernetes e il nome DNS che verrà dato all’endpoint pubblico. Scegliete il numero dei nodi da creare durante la prima distribuzione e la dimensione delle macchine virtuali che ospiteranno i nodi del cluster.
Figura 4: Inserimento delle informazioni relative alla creazione dell’Azure Kubernetes Service
Per poter offrire scalabilità alla vostra applicazione è possibile definire un VM scale set e definire i Virtual nodes. Ho già avuto modo di parlare dei Virtual Machine Scale Set (VMSS) nell’articolo Configurare Azure Virtual Machine Scale Set
I nodi virtuali consentono di effettuare rapidamente il provisioning dei pod, senza dover aspettare che la funzionalità di scalabilità automatica crei delle nuove macchine virtuali per eseguire pod aggiuntivi. I nodi virtuali sono supportati solo con i pod e i nodi Linux. Per maggiori informazioni vi rimando alla lettura della guida https://docs.microsoft.com/it-it/azure/aks/virtual-nodes-portal
Figura 5: Configurazione delle scalabilità dell’Azure Kubernetes Service
Nella pagina Authentication configurate il Service principal da utilizzare per le autenticazioni. Si può creare un nuovo Service
principal oppure utilizzarne uno esistente. Nel caso si voglia utilizzare un Service principal esistente sarà necessario specificarne il client ID e il secret.
Per ottenere un controllo più capillare sull’accesso alle risorse Kubernetes distribuite nel cluster di AKS abilitate l’opzione per il controllo degli accessi in base al ruolo (RBAC) di Kubernetes.
Figura 6: Configurazione dell’autenticazione di Azure Kubernetes Service
Per consentire l’accesso alle applicazioni o per consentire ai componenti dell’applicazione di comunicare tra loro, Kubernetes offre un livello di astrazione per funzionalità di rete virtuale (virtual networks). I nodi Kubernetes vengono connessi a una rete virtuale e possono fornire la connettività in ingresso e in uscita per i pod. Il componente kube-proxy viene eseguito in ogni nodo per fornire queste funzionalità di rete. In Kubernetes, i servizi raggruppano i pod dal punto di vista logico per consentire l’accesso diretto tramite un indirizzo IP o nome DNS e su una porta specifica. È anche possibile distribuire il traffico usando un bilanciamento del carico. Si può anche ottenere un routing più complesso del traffico dell’applicazione con i controller di ingresso. La sicurezza e il filtraggio del traffico di rete per i pod sono possibili con i criteri di rete di Kubernetes.
Nella pagina Networking è possibile configurare in che modo deve essere collegato il cluster di Kubernetes alla rete. Maggiori informazioni sulla configurazione di rete sono disponibili all’indirizzo https://docs.microsoft.com/it-it/azure/aks/concepts-network
Figura 7: Configurazione della rete per Azure Kubernetes Service
Configurate il monitoraggio dei container andando a definire il Log Analytics Workspace. Io ne ho creato uno dedicato allo scopo.
Figura 8: Abilitazione del monitoraggio per Azure Kubernetes Cluster
Una volta completata la convalida, selezionate Crea.
Figura 9: Convalida delle informazioni per la creazione del cluster
La creazione del cluster del servizio Azure Kubernetes richiede alcuni minuti. Al termine della distribuzione, fate clic su Vai alla risorsa oppure individuate il gruppo di risorse che avete utilizzato e selezionate la risorsa Azure Kubernetes Service.
Figura 10: Dashboard del cluster dell’Azure Kubernetes Service
Verrà anche creato un resource group che conterrà tutte le risorse fisiche che saranno utilizzate da Azure Kuberneters Service. Nella figura sotto è possibile visualizzare il Virtual Machine Scale Set, la Virtual Network, il Load Balancer, ecc.
Figura 11: Risorse fisiche create per supportare Azure AKS
Connessione al cluster AKS
Per connettervi e gestire il cluster AKS potete utilizzare il comando kubectl presente in Azure Cloud Shell nella shell Bash.
Come prima operazione collegatevi al cluster, scaricate le credenziali di accesso e configurate la Kubernetes CLI per utilizzarle. Il comando da lanciare è:
1 |
az aks get-credentials --resource-group NomeResourceGroup --name NomeAKSCluster |
Nel mio caso ho utilizzato il comando:
1 |
az aks get-credentials --resource-group KubernetesRG --name AKSCluster01 |
Figura 12: Connessione al cluster AKS utilizzando la Azure Cloud Shell
Per verificare la connessione al vostro cluster e per vedere la lista dei nodi che sono stati creati potete utilizzare il comando
1 |
kubectl get nodes |
Assicuratevi che i nodi riportino la dicitura Ready.
Figura 13: Verifica della corretta creazione dei nodi in Azure Kubernetes Service
Distribuzioni e manifesti YAML
Una distribuzione rappresenta uno o più pod identici gestiti dal controller di distribuzione di Kubernetes. Una distribuzione specifica il numero di repliche (pod) da creare e l’utilità di pianificazione di Kubernetes assicura che, in caso di problemi dei pod o dei nodi, vengano pianificati pod aggiuntivi su nodi integri.
È possibile aggiornare le distribuzioni per modificare la configurazione dei pod, l’immagine del contenitore utilizzata o la risorsa di archiviazione collegata. Il controller di distribuzione svuota e termina un determinato numero di repliche, crea repliche dalla nuova definizione della distribuzione e continua il processo fino a quando non vengono aggiornate tutte le repliche della distribuzione.
Esecuzione di un’applicazione
Per poter eseguire un’applicazione abbiamo bisogno di creare un Kubernetes manifest file, che indicherà quali saranno le immagini dei container (container images) da distribuire ed eseguire. Creeremo come esempio una piccola applicazione per votare (Azure Vote). Questo manifest file include due distribuzioni Kubernetes (deployments), una per l’app di esempio scritta in python che si chiama Azure Vote e l’altra per un’istanza di Redis, un DBMS NoSQL.
Per semplificare la configurazione di rete per i carichi di lavoro dell’applicazione, Kubernetes usa i servizi (services) per raggruppare un set di pod in modo logico e fornire la connettività di rete. Verranno creati anche due servizi, uno interno per l’istanza Redis e un servizio esterno per permetterà l’accesso da Internet all’applicazione Azure Vote.
Noi creeremo manualmente il manifest file, ma è anche possibile in produzione utilizzare Azure Dev Spaces per distribuire e fare debug del codice direttamente nel cluster AKS.
Nella Azure Cloud Shell digitate il comando nano azure-vote.yaml per creare il manifest file.
All’interno del file incollate la seguente definizione YAML, che potete recuperare dall’indirizzo https://github.com/Azure-Samples/azure-voting-app-redis.git :
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 |
apiVersion: apps/v1 kind: Deployment metadata: name: azure-vote-back spec: replicas: 1 selector: matchLabels: app: azure-vote-back template: metadata: labels: app: azure-vote-back spec: nodeSelector: "beta.kubernetes.io/os": linux containers: - name: azure-vote-back image: redis ports: - containerPort: 6379 name: redis --- apiVersion: v1 kind: Service metadata: name: azure-vote-back spec: ports: - port: 6379 selector: app: azure-vote-back --- apiVersion: apps/v1 kind: Deployment metadata: name: azure-vote-front spec: replicas: 1 selector: matchLabels: app: azure-vote-front strategy: rollingUpdate: maxSurge: 1 maxUnavailable: 1 minReadySeconds: 5 template: metadata: labels: app: azure-vote-front spec: nodeSelector: "beta.kubernetes.io/os": linux containers: - name: azure-vote-front image: microsoft/azure-vote-front:v1 ports: - containerPort: 80 resources: requests: cpu: 250m limits: cpu: 500m env: - name: REDIS value: "azure-vote-back" --- apiVersion: v1 kind: Service metadata: name: azure-vote-front spec: type: LoadBalancer ports: - port: 80 selector: app: azure-vote-front |
Figura 14: Creazione del Kubernetes manifest file
Salvate e chiudete il file.
Le distribuzioni vengono in genere create e gestite con kubectl create o kubectl apply. Lanciate il comando per distribuire l’applicazione:
1 |
kubectl apply -f azure-vote.yaml |
Assicuratevi di non ricevere alcun errore.
Figura 15: Avvio del deployment nel cluster AKS
Test dell’applicazione
Una volta avviata l’applicazione, il servizio di Kubernetes espone il front end dell’applicazione verso Internet. Ci possono volere diversi minuti per completare questa operazione.
Per monitorare il processo di deployment è possibile lanciare il comando:
1 |
kubectl get service azure-vote-front –watch |
Figura 16: Monitoraggio del deployment dell’applicazione
Attendete fino a quando non vedete l’indirizzo IP pubblico e premete CTRL+C per interrompere il monitoraggio.
Collegandovi all’indirizzo IP pubblico potrete vedere che l’applicazione Azure Vote è stata distribuita e pubblicata.
Figura 17: L’applicazione è stata distribuita nel cluster ed è raggiungibile da Internet
Dal portale di Azure, selezionando il nodo Insights dell’Azure Kubernetes Service, è possibile monitorare l’utilizzo delle risorse.
Figura 18: Monitoraggio delle risorse utilizzate dal cluster AKS
Per visualizzare i log cliccate sul nodo Logs e utilizzate le query che preferite per estrarre i file di log. Ci sono anche delle query di esempio.
Per chi non sapesse utilizzare Log Analitycs consiglio la lettura dell’articolo Get started with Log Analytics in Azure Monitor
Figura 19. Visualizzazione dei log di AKS
AKS Service Security
Per proteggere i dati dei clienti durante l’esecuzione di carichi di lavoro dell’applicazione in Azure Kubernetes Service, la sicurezza del cluster è un fattore fondamentale. Kubernetes include componenti di sicurezza che vengono combinati in modo che il cluster del servizio Azure Kubernetes esegua sempre gli aggiornamenti della sicurezza del sistema operativo e le versioni di Kubernetes più recenti, con il traffico di pod e l’accesso sicuri alle credenziali sensibili.
I nodi del servizio Azure Kubernetes sono macchine virtuali di Azure gestite dall’utente. I nodi Linux eseguono una distribuzione Ubuntu ottimizzata usando il runtime di Moby container. I nodi di Windows Server (attualmente in anteprima in AKS) eseguono una versione ottimizzata di Windows Server
2019 e usano anche il runtime di Moby container.
La piattaforma Azure applica automaticamente le patch di sicurezza del sistema operativo ai nodi Linux su base giornaliera. Se un aggiornamento della sicurezza del sistema operativo Linux richiede un riavvio dell’host, il riavvio non viene eseguito automaticamente. È possibile riavviare manualmente i nodi Linux oppure usare KURED, un daemon di riavvio open source per Kubernetes. Kured viene eseguito come DaemonSet e monitora ogni nodo per verificare se è presente un file che indichi che è necessario un riavvio.
Per i nodi di Windows Server (attualmente in anteprima in AKS), i Windows Update non vengono eseguiti automaticamente e applicati gli aggiornamenti più recenti. In base a una pianificazione regolare per il ciclo di rilascio Windows Updat, è necessario eseguire un aggiornamento sui pool di nodi di Windows Server nel cluster AKS. Questo processo di aggiornamento crea nodi che eseguono la versione più recente dell’immagine e delle patch di Windows Server, quindi rimuove i nodi precedenti.
Per la sicurezza e la conformità o per usare le funzionalità più recenti, Azure offre strumenti per orchestrare l’aggiornamento di un cluster e dei componenti del Azure Kubernetes Service. Questa orchestrazione dell’aggiornamento include sia il master che i componenti agent di Kubernetes. È possibile visualizzare un elenco delle versioni di Kubernetes disponibili per il cluster del servizio Azure Kubernetes. Per avviare il processo di aggiornamento, si specifica una di queste versioni disponibili. Azure quindi blocca e svuota in modo sicuro ogni nodo del servizio Azure Kubernetes ed esegue l’aggiornamento.
Conclusioni
Quando lo sviluppo di applicazioni si sposta verso un approccio basato su contenitori, è importante la necessità di orchestrare e gestire le risorse. Kubernetes è la piattaforma leader che offre programmazione affidabile di carichi di lavoro applicativi. La piattaforma è incentrata sui carichi di lavoro applicativi e non sui componenti dell’infrastruttura sottostante ed il servizio AKS riduce la complessità delle attività di distribuzione e delle attività principali di gestione, tra cui il coordinamento degli aggiornamenti.