Kubernetes: cos’è e perché utilizzarlo.

Ciao a tutti io sono Alberto, DevOps Engineer a The I, e oggi parleremo di Kubernetes. Vedremo cos’è, quali sono le caratteristiche principali e cerchermo di capire se fa al caso vostro.

1. Che cos’è Kubernetes?
2. Perché utilizzare Kubernetes?
3. Funzionalità principali di Kubernetes
4. Coma funziona Kubernetes?
   1. I Pod
   2. I deployment
   3. I service
   4. L’ingress
5. Altri aspetti di Kubernetes
6. Plugin: l’ecosistema che abbraccia Kubernetes
7. Cloud Providers per Kubernetes
8. Kubernetes fa al caso tuo?

Che cos’è Kubernetes?

Kubernetes è una piattaforma che permette di gestire servizi containerizzati, semplificandone la configurazione, la gestione del ciclo di vita e il deployment in production.

Perché utilizzare Kubernetes?

Perché dovremmo usare Kubernetes? Non basta Docker?

I container sono un ottimo strumento per portare in produzione le vostre applicazioni, ma cosa succede se dovete scalare l’infrastruttura in base alla richieste? Se un container non funziona bene e dovete fare rollback o dovete sostitutirlo?

Kubernetes è nato proprio per questo: rendere i sistemi distirbuiti resilienti, infatti l’availability dei servizi è uno dei punti chiave di K8s.

Funzionalità principali di Kubernetes

Vediamo quali sono le funzionalità principali offerte da kubernetes:

1. Service discovery e load balancing
   K8s permette di esporre un container o una serie di essi sotto il loro IP o un nome DNS. K8s permette di fare automaticamente load balancing tra essi. Se i container aumentano o diminuiscono questi vengono automaticamente registrati o deregistrati dal nome DNS.
2. Self-healing
   i container che non rispondo agli health check, che si bloccano o terminano inaspettatamente vengo automaticamente sostituiti con container nuovi.
3. Gestione dei segreti
   Kubernetes posside su database key-value per la gestione di informazioni sensibili come password, token o chiavi SSH.
4. Rollout e rollback automatizzati

Servizio

Consulenza DevOps

Se hai bisogno di un supporto nell’utilizzo di Kubernetes o vuoi approfondirlo scopri il nostro servizio di consulenza DevOps e non esitare a contattarci.

Approfondisci

Come funziona Kubernetes?

Quando si deploya Kubernetes si ottiene un cluster.
Un cluster è formato prima di tutto dai worker nodes: macchine fisiche che oltre ad eseguire i container specificati dall’utente eseguono anche tutta una serie di applicazioni che servono al corretto funzionamento di kubernets.

È possibile scegliere la strategia con la quale i container devono essere distribuiti nei worker nodes.

Come dicevano affiaco ai container dell’utente girano tutta una serie di applicazioni per far funzionare K8s ovvero:

1. Kube-apiserver
   Serve ad esporre le API di Kubernets. È progettato per scalare orizzontalmente ed il traffico viene automaticamente distributo tra le varie istanze.
2. Etcd
   Database key value utilizzato per memorizzare tutti i dati del cluster
3. Kube-scheduler
   Il componente che gestisce la distribuzione dei container nei worker nodes secondo la strategia che abbiamo scelto
4. Kube-controller manager
   Componente che esegui i processi controller. Il loro scopo è quello di interrograre il kube-apiserver per ottenere lo stato del cluster ed assicurarsi che lo stato ottenuto combaci con lo state desiderato. Ad esempio se l’utente specifica che devono sempre essere presenti 4 container graphql e ce ne sono solo 3, i processi controller si metteranno in movimento per assicurassi che lo stato corrente combaci con quello desiderato.
5. Cloud-controller-manager
   Si occupa di interfacciarsi con alcune API dei cloud provider più popolari. Come vedremo più avanti Kubernetes è in grado di creare delle risorse all’interno di AWS. In un certo senso questo permette a Kubernetes di uscire dal proprio recinto per comuinicare con altri servizi

Dopodiché esistono dei servizi che girano anche all’interno dei worker nodes stessi: alcuni di questi sono:

1. Kubelet
   Un agente che si assicura che all’interno di ogni node i container stiamo girando e che rispettano le specifiche dell’utente.
2. Kube-proxy
   Un proxy di rete che gira su ogni nodo del vostro cluster.
3. Container runtime
   È il software che è responsabile del funzionamento dei container.
   Kubernetes supporta diversi runtime dei container: Docker, containerd, CRI-O.

Ora che abbiamo visto quali sono le applicazioni per il funzionamento di Kubernetes vediamo le componenti con la quale vi interfacciate quando definite il vostro container.

I Pod

La componente fondamentale di un cluster sono i pod. I pod sono un wrapper dei container e rappresentano la più piccola unità di computazione di un cluster. I pod possiedo un indirizzo IP, degli eventuali volumi attaccati e possiedo al configurazione che determinano come il container dentro di essi deve essere eseguito. I pod sono intelligenti in quanto se piazzati sulla stessa rete sono in grado di scoprirsi tra di loro.
È possibile creare un pod standalone, ma non ha molto senso perché sarebbe come creare un singolo container all’interno del cluster, non ando a risolvere il problema che abbiamo citato all’inizio.

I Deployment

Nella quasi totalità dei casi i pod vengono creati da altre entità chiamate controller.
La più usate tra esse sono i Deployment, i quali dichiarano come la nostra applicazione o una parte di essa deve essere eseguita.

Per esempio se volessimo se volessimo 3 container GraphQL non creeremmo 3 pods, ma piuttosto un deployment dove specifichiamo il container che vogliamo eseguire, quante repliche vogliamo e moltre altre informazioni.

Un aspetto fondamentale quando si dichiarano i deployment sono i tag, ogni pod in kubernets può avere uno o più tag. I tag vengono utilizzati dai deployment per capire quali sono i pod sotto il suo controllo.

Un vantaggio di utilizzare i Deployment è che eventuali modifiche apportate al pod template nel deployment vengono poi perpetrate ai pod che gestisce. Inoltre i deployment ci assicurano che un numero specificato di pod sia sempre up-and-running.

I deployment dunque permettono di gestire i pod, che abbiamo capito essere delle entità effimere, nascono e muoiono in base alle nostre necessità.

Facciamo un esempio un po’ più complesso, mettiamo caso che questi pod GraphQL che chiameremo backend forniscano delle api da altri pod che chiameremo frontend. Dal momento che i pod del backend possono cambire da un momento all’altro quindi potenzialmente avere un IP sempre diverso come fanno i pod del frontend a capire a quali indirizzi IP collegarsi? Per risolvere questo problema esistono i service, un altro componente fondamentale di kubernetes.

I service

I service permettono di selezionare un set di pods e di esporli all’interno del cluster sottoforma di network service. Ai service è possible assegnare un nome che deve essere un nome dns valido.

Quindi i pod del frontend invece che comunicare direttamente con i pod del backend comunicano attraverso il service che si occupa di fare load balacing tra i pod che gestisce.

Esistono divresi tipi di service, i quali espongono i servizi offerti dai pod selezionati in maniera diversa.

1. I service di default sono di tipo ClusterIp, ovvero il servizio è esposto con un ip interno del cluster o un nome dns interno al cluster
2. Il secondo tipo è NodePort: il servizio è esposto sull’IP di ogni worker node su una porta specifica
3. LoadBalancer: espone il service all’esterno attraverso un load balancer del cloud provider sul quale Kubernetes sta girando.

Ritornando alla definizione di service, i service non solo uno strumento che permette di esporre meramente dei pod sotto un’interfaccia comune ma permettono più in generale di esporre un servizio all’interno o all’esterno del cluster sotto forma di servizio web. Questo fa intuire che sotto al service in verità può esserci un po’ di tutto.

Per farvi un esempio concreto un nostro cliente recentemente ci ha chiesto di spostare un DB che girava su kubernetes su delle instance ec2 ma facendo sì che il cluster potesse comunque accedere al database. Dopo aver spostato il database su un cluster di ec2 è bastato dire al service che prima esponeva i pod del db di esporre un paio di endpoint. Questo ha fatto si che i pod non si sono accorti di nulla

L’Ingress

L’ultimo strumento che vedremo per esporre i servizi al mondo esterno è l’ingress. Un ingress permette di esporre all’esterno i servizi interni del cluster Kuberntes sottoforma di endpoint HTTP o HTTPS.

Il routing del traffico entrante è regolato dall’ingress. Un ingress inoltre può fornire load-balancing, SSL termination. Un ingress per funzionare ha bisogno di un ingress-controller, che è il componente che si interfaccia con il cloud provider di turno per istanziare un load-balancer che gestisce il traffico.

Implementare un ingress sostanzialmente consiste nello scrivere le regole di routing che indirizzano il traffico in entrata verso i servizi che si vogliono esporre. Possono essere presenti più ingress per cluster per esporre diversi servizi.

Servizio

Consulenza DevOps

Se hai bisogno di un supporto nell’utilizzo di Kubernetes o vuoi approfondirlo scopri il nostro servizio di consulenza DevOps e non esitare a contattarci.

Approfondisci

Altri aspetti di Kubernetes

Ora che abbiamo visto le componenti principali vediamo come dichiarare un cluster.

Kubernets utilizza YAML per definire i propri componenti. Qui potete vedere un esempio di pod.

Per deployare su un cluster kuberntes si può usare Kubectl,un tool a riga di comando che permette anche di ottenere ogni tipo di informazione riguardante il proprio cluster.

PLUGIN: l’ecosistema che abbraccia Kubernetes

Un altro aspetto interessante di Kuberntes sono i plugin, i quali permettono di espandere le funzionalità di kubernetes. I plugin inoltre estendono il comportamento di kubectl aggiungendo nuovi comandi.

Tra i plugin molto utili troviamo Graph, che permette di generare dei grafici di tutti i componenti di un cluster o debug che permette di collegare un container ad un pod per debuggarlo.

Cloud Providers per Kubernetes

Tipicamente per deployare un cluster Kubernetes ci si appoggia ad un cloud provider. Il supporto migliore è offerto da Google Cloud con il suo Google Kubernetes Engine.

AWS invece offre EKS, Elastic Kubernetes Service. Un aspetto interessante di AWS è la gestione dei worker nodes, infatti è possibile designare un cluster di ec2 da utilizzare come pool di worker nodes oppure ci si può affidare ad AWS Fargate che permette di astrarre completamento quell’aspetto dalle nostre responsabilità. Fargate è in grado di aumentare o diminuire autonomamente le prestazioni dei worker node per ottenere il miglior rapporto costi/performance.

Kubernetes fa al caso tuo?

Kubernetes è una tecnologia molto complessa e padroneggiarla richiede molto tempo.

Una caratteristica particolare di Kubernetes è che è una tecnologia che permea completamente il proprio ambiente di sviluppo o produzione, quindi quando si adotta Kubernetes è un all-in. Di conseguenza è importante possedere in azienda le skill necessarie altrimenti il rischio è di ritorvarsi l’ambiente di produzione completamente governato da una tecnologia che non si comprende a fondo, quindi se qualcosa va storto è meglio saprere cosa toccare.

Se invece la propria infrastruttura è molto complessa e l’availability dei propri servizi è un requisito fondamentale, e spesso le due cose vanno a braccetto, Kubernetes diventa in pratica quasi l’unico modo di gestire un ambiente completamente containerizzato in maniera efficace.

Vengono messi a disposizione numerosi strumenti per garantire l’uptime dei servizi, dalle repliche ai rollback automatici quando qualcosa va storto.

Per dare un altro esempio su come K8s sia progettato per la resilienza, quando devono essere effettuate delle modifiche, ad esempio aggiornare la configurazione dei pod, i pod vengono aggiornati progressivamente e non tutti d’un colpo.

In questa maniera Kubernetes ha il tempo di rendersi conto che qualcosa non va e può interrompere l’aggiornamento e rideployare i pod con la configurazione vecchia per ripristinare la configurazione precedente.

Guarda il Video

---

Ciao a tutti io sono Alberto, lavoro per The I e sono un DevOps Engineer.
Il mio lavoro consiste principalmente nel progettare processi di deployment che si inseriscono nel processi già attivi dei nostri client in modo da efficientare i processi che portano il codice in produzione.

The I opera da 15 anni in ambito di Cybersecurity.
Sviluppiamo per i nostri clienti strategie di security aziendale che possano prevenire gli attacchi informatici, gestire rischi, evitare downtime e malfunzionamenti e proteggere informazioni e dati sensibili.

Eseguiamo Security Assessment, Penetretion Test , Vulnerability Assessment, Log managment, Incedent Responce Team e SIEM.
Contattaci per una consulenza o un preventivo.