1~
2Se lavori nel mondo dello sviluppo software, avrai sicuramente sentito parlare di Kubernetes. Ma cos'è esattamente e perché è diventato uno standard de-facto per la gestione di applicazioni containerizzate? Questa guida ti porterà dalle basi ai concetti fondamentali, con esempi pratici e diagrammi per aiutarti a capire.
3~
4## Prima di Kubernetes: Un Po' di Storia
5~
6Per capire perché Kubernetes è così rivoluzionario, facciamo un passo indietro.
7~
81.  **Deployment Tradizionale**: Inizialmente, le applicazioni venivano eseguite su server fisici. Questo approccio era costoso, difficile da scalare e soggetto a conflitti di risorse.
92.  **Deployment Virtualizzato**: Poi sono arrivate le Virtual Machine (VM). Le VM hanno permesso di eseguire più applicazioni isolate sullo stesso hardware, migliorando l'utilizzo delle risorse e la sicurezza. Tuttavia, ogni VM esegue un intero sistema operativo, consumando molte risorse.
103.  **Deployment Containerizzato**: I container (come Docker) sono l'evoluzione successiva. Condividono lo stesso sistema operativo host ma eseguono processi isolati. Sono leggeri, veloci da avviare e portabili.
11~
12I container hanno risolto il problema della portabilità, ma ne hanno creato un altro: come gestire centinaia (o migliaia) di container in un ambiente di produzione? Come garantire che siano sempre in esecuzione, che possano comunicare tra loro e che scalino in base al carico?
13~
14Qui entra in gioco **Kubernetes**.
15~
16## Cos'è Kubernetes?
17~
18Kubernetes (spesso abbreviato in **K8s**) è una piattaforma open-source per l'orchestrazione di container. In parole semplici, automatizza il deployment, la scalabilità e la gestione di applicazioni containerizzate. Creato da Google e ora mantenuto dalla Cloud Native Computing Foundation (CNCF), Kubernetes è diventato lo strumento di riferimento per chiunque lavori con i microservizi su larga scala.
19~
20## L'Architettura di un Cluster Kubernetes
21~
22Un ambiente Kubernetes è chiamato **cluster**. Un cluster è composto da un insieme di macchine, chiamate **nodi**, che eseguono le nostre applicazioni. L'architettura si divide in due parti principali: il Control Plane e i Worker Node.
23~
24```mermaid
25graph TD
26    subgraph "Control Plane (Master)"
27        A["API Server"]
28        B["etcd"]
29        C["Scheduler"]
30        D["Controller Manager"]
31    end
32~
33    subgraph "Worker Node 1"
34        E["Kubelet"] --- F["Container Runtime"]
35        G["Kube-proxy"]
36        F --- H["Pod"]
37        F --- I["Pod"]
38    end
39~
40    subgraph "Worker Node 2"
41        J["Kubelet"] --- K["Container Runtime"]
42        L["Kube-proxy"]
43        K --- M["Pod"]
44    end
45~
46    A -- "Comunica con" --> E
47    A -- "Comunica con" --> J
48    User -- "kubectl" --> A
49    C -- "Assegna Pod ai Nodi" --> E
50    D -- "Mantiene lo stato" --> A
51    A -- "Salva/Legge stato" --> B
52```
53~
54### Control Plane
55~
56Il Control Plane è il "cervello" del cluster. Prende decisioni globali (come lo scheduling) e rileva e risponde agli eventi del cluster. I suoi componenti principali sono:
57~
58-   **API Server (`kube-apiserver`)**: È la porta d'ingresso del cluster. Espone le API di Kubernetes, che vengono utilizzate dagli utenti (tramite `kubectl`), dai componenti del cluster e da strumenti esterni per comunicare.
59-   **etcd**: Un database key-value consistente e altamente disponibile. Memorizza tutti i dati del cluster, rappresentando lo "stato" desiderato e attuale del sistema.
60-   **Scheduler (`kube-scheduler`)**: Assegna i Pod appena creati a un Worker Node disponibile, tenendo conto dei requisiti di risorse, delle policy e di altri vincoli.
61-   **Controller Manager (`kube-controller-manager`)**: Esegue i controller, che sono cicli di controllo che osservano lo stato del cluster e lavorano per portarlo allo stato desiderato. Ad esempio, il `Node Controller` gestisce i nodi, mentre il `Replication Controller` si assicura che il numero corretto di Pod sia in esecuzione.
62~
63### Worker Node
64~
65I Worker Node sono le macchine (fisiche o virtuali) dove le applicazioni vengono effettivamente eseguite. Ogni nodo è gestito dal Control Plane e contiene i seguenti componenti:
66~
67-   **Kubelet**: Un agente che viene eseguito su ogni nodo. Si assicura che i container descritti nei Pod siano in esecuzione e in buono stato.
68-   **Kube-proxy**: Un proxy di rete che gestisce le regole di rete sui nodi. Permette la comunicazione di rete verso i Pod da sessioni di rete interne o esterne al cluster.
69-   **Container Runtime**: Il software responsabile dell'esecuzione dei container. Docker è il più famoso, ma Kubernetes supporta anche altri runtime come `containerd` e `CRI-O`.
70~
71## Oggetti Fondamentali di Kubernetes
72~
73In Kubernetes, tutto è rappresentato da **oggetti**. Questi oggetti sono "intenzioni" (records of intent): una volta creato un oggetto, Kubernetes lavora costantemente per garantire che esista e corrisponda allo stato desiderato.
74~
75Ecco i più importanti:
76~
77### Pod
78~
79Il **Pod** è l'unità di esecuzione più piccola in Kubernetes. Rappresenta uno o più container che vengono eseguiti insieme sullo stesso nodo, condividendo risorse come la rete e lo storage.
80~
81Generalmente, si esegue un solo container per Pod, ma in scenari avanzati (come i "sidecar container" per il logging o il monitoring) se ne possono avere di più.
82~
83Non si creano quasi mai Pod direttamente. Si usano astrazioni di livello superiore come i Deployment.
84~
85### Deployment
86~
87Un **Deployment** è l'oggetto che userai più spesso. Descrive lo stato desiderato per un gruppo di Pod identici. Il controller del Deployment si occupa di:
88~
89-   Creare e gestire un **ReplicaSet** (un altro oggetto che garantisce che un numero specifico di repliche di un Pod sia sempre in esecuzione).
90-   **Scalare** il numero di Pod su o giù.
91-   Gestire gli **aggiornamenti** dell'applicazione in modo controllato (es. *Rolling Update*), senza tempi di inattività.
92~
93Ecco un esempio di file YAML per un Deployment che esegue 3 repliche di un server NGINX:
94~
95```yaml
96# nginx-deployment.yaml
97apiVersion: apps/v1
98kind: Deployment
99metadata:
100  name: nginx-deployment
101spec:
102  replicas: 3
103  selector:
104    matchLabels:
105      app: nginx
106  template:
107    metadata:
108      labels:
109        app: nginx
110    spec:
111      containers:
112      - name: nginx
113        image: nginx:1.14.2
114        ports:
115        - containerPort: 80
116```
117~
118### Service
119~
120I Pod in Kubernetes sono effimeri: possono essere creati e distrutti in qualsiasi momento. Ogni Pod ha un proprio indirizzo IP, ma questo IP non è stabile. Come facciamo, quindi, a esporre la nostra applicazione in modo affidabile?
121~
122Con un **Service**. Un Service è un'astrazione che definisce un set logico di Pod e una policy per accedervi. Fornisce un **punto di accesso stabile** (un indirizzo IP virtuale e un nome DNS) per un gruppo di Pod.
123~
124```mermaid
125graph TD
126    subgraph "Service (nginx-service)"
127        A["ClusterIP: 10.96.0.10"]
128    end
129~
130    subgraph "Pods"
131        B("Pod 1 - IP: 192.168.1.2")
132        C("Pod 2 - IP: 192.168.1.3")
133        D("Pod 3 - IP: 192.168.1.4")
134    end
135~
136    A -- "Selector: app=nginx" --> B
137    A -- "Selector: app=nginx" --> C
138    A -- "Selector: app=nginx" --> D
139~
140    Client -- "Richiesta a nginx-service" --> A
141```
142~
143Il Service utilizza un `selector` basato su etichette (`labels`) per trovare i Pod a cui deve inoltrare il traffico.
144~
145Ecco come creare un Service per il nostro Deployment NGINX:
146~
147```yaml
148# nginx-service.yaml
149apiVersion: v1
150kind: Service
151metadata:
152  name: nginx-service
153spec:
154  selector:
155    app: nginx
156  ports:
157    - protocol: TCP
158      port: 80
159      targetPort: 80
160  type: ClusterIP # Default - espone il servizio solo all'interno del cluster
161```
162~
163Esistono diversi tipi di Service:
164- `ClusterIP`: Espone il servizio su un IP interno al cluster (default).
165- `NodePort`: Espone il servizio su una porta statica su ogni Worker Node.
166- `LoadBalancer`: Crea un load balancer esterno nel cloud provider (es. AWS, GCP) e assegna un IP pubblico al servizio.
167~
168### Ingress
169~
170Un Service di tipo `LoadBalancer` è ottimo, ma crearne uno per ogni servizio può essere costoso. Per esporre più servizi HTTP/HTTPS al mondo esterno, si usa un **Ingress**.
171~
172Un Ingress funge da "router intelligente" per il traffico esterno. Permette di definire regole di routing basate su host (es. `api.miosito.com`) o path (es. `miosito.com/api`).
173~
174```mermaid
175graph LR
176    User -- "miosito.com/api" --> Ingress
177    User -- "miosito.com/ui" --> Ingress
178~
179    subgraph "Cluster"
180        Ingress -- "/api" --> ServiceA("api-service")
181        Ingress -- "/ui" --> ServiceB("ui-service")
182~
183        ServiceA --> PodA1("Pod API 1")
184        ServiceA --> PodA2("Pod API 2")
185~
186        ServiceB --> PodB1("Pod UI 1")
187        ServiceB --> PodB2("Pod UI 2")
188    end
189```
190~
191Ecco un esempio di Ingress:
192```yaml
193# example-ingress.yaml
194apiVersion: networking.k8s.io/v1
195kind: Ingress
196metadata:
197  name: example-ingress
198spec:
199  rules:
200  - host: miosito.com
201    http:
202      paths:
203      - path: /api
204        pathType: Prefix
205        backend:
206          service:
207            name: api-service
208            port:
209              number: 8080
210      - path: /ui
211        pathType: Prefix
212        backend:
213          service:
214            name: ui-service
215            port:
216              number: 3000
217```
218~
219### Altri Oggetti Utili
220~
221-   **Namespace**: Permette di creare "cluster virtuali" all'interno di un cluster fisico. Utile per isolare ambienti (es. `development`, `staging`, `production`) o team.
222-   **ConfigMap e Secret**: Per gestire dati di configurazione e segreti (come password o chiavi API) in modo disaccoppiato dall'immagine del container.
223-   **StatefulSet**: Simile a un Deployment, ma specifico per applicazioni stateful (come i database) che richiedono identità di rete stabili e storage persistente.
224-   **PersistentVolume (PV) e PersistentVolumeClaim (PVC)**: Per gestire lo storage persistente nel cluster.
225~
226## Conclusione
227~
228Kubernetes è uno strumento incredibilmente potente, ma la sua curva di apprendimento può essere ripida. Questa guida ha solo scalfito la superficie, ma speriamo ti abbia dato una solida comprensione dei concetti di base.
229~
230**Cosa fare ora?**
231- **Sperimenta in locale**: Installa [Minikube](https://minikube.sigs.k8s.io/docs/start/) o [Kind](https://kind.sigs.k8s.io/docs/user/quick-start/) per creare un cluster Kubernetes sul tuo computer.
232- **Usa `kubectl`**: Familiarizza con il comando `kubectl`, il tuo strumento principale per interagire con il cluster. Prova a creare il Deployment e il Service NGINX di questo articolo.
233- **Esplora i tutorial ufficiali**: La [documentazione di Kubernetes](https://kubernetes.io/docs/tutorials/) è una risorsa fantastica e piena di esempi.
234~
235L'orchestrazione di container è una competenza fondamentale nel mondo cloud-native, e padroneggiare Kubernetes ti aprirà un mondo di possibilità. Buon divertimento!