Concetti Kubernetes per Azure
Ripassi i costrutti fondamentali di Kubernetes — pod, deployment, servizi e namespace — e comprenda come AKS gestisce il piano di controllo per Suo conto.
Concetti Kubernetes per Azure è una lezione Cloud & IT Cert Prep gratuita su CoddyKit. Questa è la lezione 3 di 4. Puoi leggere la lezione completa qui gratuitamente — poi esercitati direttamente nel browser con un editor di codice integrato e un tutor IA disponibile 24/7. Fa parte del percorso di apprendimento Cloud & IT Cert Prep, e i tuoi progressi si sincronizzano tra il web e l'app CoddyKit. Il corso Cloud & IT Cert Prep include 4 lezioni in totale.
Che cos'è Kubernetes?
Kubernetes (K8s) è una piattaforma open source di orchestrazione dei container, sviluppata originariamente da Google. Automatizza la distribuzione, la scalabilità e la gestione delle applicazioni containerizzate. Invece di eseguire manualmente i container, si dichiara lo stato desiderato dell'applicazione nei manifest YAML e Kubernetes lavora continuamente per far coincidere lo stato effettivo con quello desiderato: riavvia i container che hanno avuto errori, pianifica i carichi di lavoro su nodi integri e modifica il numero di repliche.
Architettura del cluster: piano di controllo e nodi
Un cluster Kubernetes è costituito da un piano di controllo e da nodi worker. Il piano di controllo contiene il server API, punto di ingresso per tutti i comandi kubectl, etcd, l'archivio dello stato distribuito, lo scheduler, che assegna i pod ai nodi, e il controller manager, che mantiene lo stato desiderato. I nodi worker eseguono kubelet, l'agente del nodo, kube-proxy, che gestisce le regole di rete, e un runtime per container, ovvero containerd. In AKS, Microsoft gestisce il piano di controllo: Lei deve gestire solo i nodi worker.
# Kubernetes control plane components
# kube-apiserver - REST API for all cluster operations
# etcd - Distributed key-value store (cluster state)
# kube-scheduler - Assigns pending pods to nodes
# kube-controller-manager - Runs reconciliation controllers
# Worker node components
# kubelet - Node agent, ensures containers run
# kube-proxy - Network routing for services
# containerd - Container runtime (runs containers)Pod: l'unità distribuibile più piccola
Un pod è l'unità distribuibile più piccola in Kubernetes. Un pod racchiude uno o più container che condividono lo spazio dei nomi di rete, lo stesso indirizzo IP, i volumi di archiviazione e il ciclo di vita. I container all'interno di un pod comunicano tramite localhost. I pod sono effimeri: quando si verifica un errore, vengono sostituiti da nuovi pod con indirizzi IP diversi. Raramente si creano pod direttamente; si creano invece risorse di livello superiore che li gestiscono.
# Simple pod manifest
apiVersion: v1
kind: Pod
metadata:
name: myapp-pod
labels:
app: myapp
spec:
containers:
- name: myapp
image: mycontainerregistry.azurecr.io/myapp:v1.0
ports:
- containerPort: 80
resources:
requests:
cpu: '100m'
memory: '128Mi'
limits:
cpu: '500m'
memory: '512Mi'Deployment: gestione dei ReplicaSet
Un Deployment è il metodo standard per eseguire applicazioni senza stato in Kubernetes. Crea e gestisce un ReplicaSet che mantiene il numero desiderato di repliche identiche del pod. I Deployment supportano gli aggiornamenti in sequenza, che sostituiscono gradualmente i vecchi pod con quelli nuovi, e i rollback alle versioni precedenti. È sufficiente descrivere il modello del pod desiderato e il numero di repliche: Kubernetes gestirà tutto il resto.
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp
spec:
replicas: 3
selector:
matchLabels:
app: myapp
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1 # Create 1 extra pod during update
maxUnavailable: 0 # Never reduce below desired count
template:
metadata:
labels:
app: myapp
spec:
containers:
- name: myapp
image: mycontainerregistry.azurecr.io/myapp:v1.0
ports:
- containerPort: 80Services: endpoint di rete stabili
Poiché i pod sono effimeri e i loro indirizzi IP cambiano, i Services forniscono un endpoint di rete stabile che distribuisce il traffico tra i pod corrispondenti. Il servizio usa un selettore di etichette per individuare i pod. Tipi di servizio: ClusterIP (solo interno, predefinito), NodePort (espone una porta su ogni nodo), LoadBalancer (crea un Azure Load Balancer con un IP pubblico) ed ExternalName (alias DNS per un servizio esterno).
# Service exposing myapp pods externally
apiVersion: v1
kind: Service
metadata:
name: myapp-svc
spec:
type: LoadBalancer # Creates Azure Load Balancer
selector:
app: myapp # Routes traffic to pods with this label
ports:
- port: 80 # Service port
targetPort: 80 # Pod/container port
# After creation, check the EXTERNAL-IP (Azure LB public IP)
# kubectl get service myapp-svcNamespace per il multi-tenancy
I Namespace suddividono un singolo cluster Kubernetes in più cluster virtuali. Le risorse appartenenti a namespace diversi sono isolate in base al nome: è possibile avere contemporaneamente un Deployment myapp nei namespace development e production. I namespace sono l'unità principale per applicare RBAC, quote delle risorse e criteri di rete a un team o a un ambiente. I namespace predefiniti includono default, kube-system e kube-public.
# Create a namespace for the dev team
kubectl create namespace dev-team
# Deploy into a specific namespace
kubectl apply -f deployment.yaml --namespace dev-team
# List all resources in a namespace
kubectl get all --namespace dev-team
# Set default namespace for current context
kubectl config set-context --current --namespace dev-teamConfigMaps e Secrets
ConfigMaps archivia dati di configurazione non sensibili come coppie chiave-valore o file, iniettandoli nei pod come variabili di ambiente o montaggi di volumi. Secrets archivia dati sensibili, come password e token, codificati in base64 (non crittografati per impostazione predefinita: per una vera crittografia a riposo, usi Azure Key Vault Provider for Secrets Store CSI Driver). Entrambi sono associati a un namespace e vengono referenziati nelle specifiche dei pod tramite il nome.
# Create a ConfigMap from literal values
kubectl create configmap app-config \
--from-literal=APP_ENV=production \
--from-literal=LOG_LEVEL=info
# Create a Secret
kubectl create secret generic db-secret \
--from-literal=DB_PASSWORD='super-secret'
# Reference in a pod spec
# env:
# - name: APP_ENV
# valueFrom:
# configMapKeyRef:
# name: app-config
# key: APP_ENV
# - name: DB_PASSWORD
# valueFrom:
# secretKeyRef:
# name: db-secret
# key: DB_PASSWORDVolumi persistenti in Azure
Le applicazioni con stato richiedono uno spazio di archiviazione che sopravviva ai singoli pod. Kubernetes usa PersistentVolumes (PVs) e PersistentVolumeClaims (PVCs) per separare lo spazio di archiviazione dal ciclo di vita dei pod. In AKS, le classi di archiviazione integrate Azure Disk e Azure Files eseguono automaticamente il provisioning di dischi gestiti e condivisioni file quando viene creato un PVC. Azure Disk è destinato all'accesso da parte di un singolo pod; Azure Files supporta più pod che leggono e scrivono contemporaneamente.
# PersistentVolumeClaim using Azure Disk
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: my-disk-pvc
spec:
accessModes:
- ReadWriteOnce # Single-node read/write (Azure Disk)
storageClassName: managed-csi
resources:
requests:
storage: 10Gi
# Mount in a pod
# volumes:
# - name: data
# persistentVolumeClaim:
# claimName: my-disk-pvc
# volumeMounts:
# - name: data
# mountPath: /dataHorizontal Pod Autoscaler
Horizontal Pod Autoscaler (HPA) modifica automaticamente il numero di repliche di un Deployment in base all'utilizzo rilevato di CPU o memoria oppure a metriche personalizzate. Il controller HPA interroga il server delle metriche ogni 15 secondi e aumenta o riduce il numero di repliche per mantenere l'utilizzo vicino all'obiettivo. Si impostano un numero minimo e uno massimo di repliche come limiti di sicurezza, così da evitare una scalabilità incontrollata.
# Create an HPA targeting 50% CPU utilisation
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: myapp-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: myapp
minReplicas: 2
maxReplicas: 20
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 50Controlli di integrità: probe di liveness e readiness
Kubernetes usa le probe per monitorare lo stato dei container. Una liveness probe verifica che un container sia ancora in esecuzione; se non supera il controllo, Kubernetes riavvia il container. Una readiness probe verifica che un container sia pronto a gestire il traffico; se non supera il controllo, il pod viene rimosso dal bilanciamento del carico del Service senza essere riavviato. Una startup probe ritarda le altre probe finché l'applicazione non è stata inizializzata, evitando riavvii prematuri durante un avvio lento.
livenessProbe:
httpGet:
path: /health
port: 80
initialDelaySeconds: 15
periodSeconds: 20
failureThreshold: 3
readinessProbe:
httpGet:
path: /ready
port: 80
initialDelaySeconds: 5
periodSeconds: 10
failureThreshold: 3
startupProbe:
httpGet:
path: /startup
port: 80
failureThreshold: 30
periodSeconds: 10 # Allow 300s for slow startupRichieste e limiti delle risorse
Ogni container in Kubernetes dovrebbe dichiarare richieste di risorse, ovvero l'allocazione minima garantita usata dallo scheduler, e limiti, ovvero il valore massimo consentito, oltre il quale il container viene limitato o terminato. Le richieste di CPU sono espresse in millicore (m): 1000m = 1 core CPU. Impostare correttamente richieste e limiti previene i problemi causati dai vicini rumorosi e consente allo scheduler di distribuire in modo efficiente i pod sui nodi senza sovrallocare le risorse.
resources:
requests:
cpu: '250m' # 0.25 CPU core guaranteed
memory: '256Mi' # 256 MiB guaranteed
limits:
cpu: '1' # Max 1 CPU core
memory: '512Mi' # Max 512 MiB (OOMKilled if exceeded)Verifica rapida
Verifichi la Sua comprensione dei concetti di Microsoft Azure Fundamentals (AZ-900) trattati in questa lezione.
Riepilogo della lezione
In questa lezione ha imparato che: i pod sono le unità distribuibili più piccole che condividono rete e spazio di archiviazione; i Deployment gestiscono i replica set senza stato e supportano gli aggiornamenti progressivi; i Services forniscono endpoint stabili che bilanciano il traffico tra pod effimeri. Ora esamineremo la distribuzione dei carichi di lavoro in AKS.
Domande Frequenti
La lezione «Concetti Kubernetes per Azure» è gratuita?
Sì — il testo completo di «Concetti Kubernetes per Azure» è gratuito qui sul web. Per esercitarvi in modo interattivo (un editor di codice integrato e un tutor IA 24/7) e sbloccare il resto del corso Cloud & IT Cert Prep, passa a CoddyKit PRO. Il corso Cloud & IT Cert Prep include 4 lezioni in totale.
Cosa imparerò in «Concetti Kubernetes per Azure»?
Ripassi i costrutti fondamentali di Kubernetes — pod, deployment, servizi e namespace — e comprenda come AKS gestisce il piano di controllo per Suo conto. Eserciti Cloud & IT Cert Prep con codice pratico che esegui direttamente nel browser, e un tutor IA 24/7 risponde alle tue domande mentre lavori sulla lezione.
Ho bisogno di esperienza per iniziare Cloud & IT Cert Prep?
Non è richiesta alcuna esperienza precedente. Cloud & IT Cert Prep su CoddyKit è strutturato per principianti e studenti avanzati, quindi puoi iniziare da qui o dall'inizio e procedere al tuo ritmo. Questa è la lezione 3 di 4.
Quanto tempo richiede la lezione «Concetti Kubernetes per Azure»?
La maggior parte delle lezioni CoddyKit richiede circa 5–10 minuti. Ogni lezione è breve e interattiva, quindi fai progressi costanti e riprendi esattamente da dove hai lasciato su web e app.
Posso scrivere ed eseguire codice in questa lezione Cloud & IT Cert Prep?
Sì. Ogni lezione Cloud & IT Cert Prep include un editor di codice integrato, quindi scrivi ed esegui codice reale direttamente nel tuo browser e ricevi feedback istantaneo dall'IA — nessuna configurazione locale necessaria.
Tutte le lezioni di questo corso
- Azure Container Registry
- Azure Container Instances
- Concetti Kubernetes per Azure
- Distribuzione di carichi di lavoro su AKS