0Pricing
Azure Fundamentals · Lezione

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 Azure Fundamentals 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 Azure Fundamentals, e i tuoi progressi si sincronizzano tra il web e l'app CoddyKit. Il corso Azure Fundamentals 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: 80

Services: 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-svc

Namespace 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-team

ConfigMaps 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_PASSWORD

Volumi 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: /data

Horizontal 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: 50

Controlli 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 startup

Richieste 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 Azure Fundamentals, passa a CoddyKit PRO. Il corso Azure Fundamentals 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 Azure Fundamentals 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 Azure Fundamentals?

Non è richiesta alcuna esperienza precedente. Azure Fundamentals 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 Azure Fundamentals?

Sì. Ogni lezione Azure Fundamentals 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

  1. Azure Container Registry
  2. Azure Container Instances
  3. Concetti Kubernetes per Azure
  4. Distribuzione di carichi di lavoro su AKS
← Torna a Azure Fundamentals