Concetti di base di Kubernetes per servizio Azure Kubernetes (servizio Azure Kubernetes)

Questo articolo descrive i concetti di base di servizio Azure Kubernetes (servizio Azure Kubernetes), un servizio Kubernetes gestito che è possibile usare per distribuire e gestire applicazioni in contenitori su larga scala in Azure. Consente di acquisire informazioni sui componenti dell'infrastruttura di Kubernetes e ottenere una conoscenza più approfondita del funzionamento di Kubernetes nel servizio Azure Kubernetes.

Che cos'è Kubernetes?

Kubernetes è una piattaforma in rapida evoluzione che gestisce le applicazioni basate su contenitori e i componenti di rete e archiviazione associati. Kubernetes è incentrato sui carichi di lavoro dell'applicazione e non sui componenti dell'infrastruttura sottostanti. Kubernetes offre un approccio dichiarativo alle distribuzioni, supportato da un solido set di API per le operazioni di gestione.

È possibile compilare ed eseguire applicazioni moderne, portabili e basate su microservizi usando Kubernetes per orchestrare e gestire la disponibilità dei componenti dell'applicazione. Kubernetes supporta applicazioni senza stato e con stato.

Come piattaforma aperta, Kubernetes consente di compilare le applicazioni con il linguaggio di programmazione, il sistema operativo, le librerie o il bus di messaggistica preferiti. Gli strumenti esistenti di integrazione continua e recapito continuo (CI/CD) possono integrarsi con Kubernetes per pianificare e distribuire le versioni.

Il servizio Azure Kubernetes offre un servizio Kubernetes gestito che riduce la complessità delle attività di distribuzione e gestione di base. La piattaforma Azure gestisce il piano di controllo del servizio Azure Kubernetes e si paga solo per i nodi di tale servizio che eseguono le applicazioni.

Architettura del cluster Kubernetes

Un cluster Kubernetes è suddiviso in due componenti:

• Il Piano di controllo offre i servizi Kubernetes di base e l'orchestrazione dei carichi di lavoro dell'applicazione e
• Nodi che eseguono i carichi di lavoro dell'applicazione.

Piano di controllo

Quando si crea un cluster del servizio Azure Kubernetes, la piattaforma Azure crea e configura automaticamente il piano di controllo associato. Questo piano di controllo a tenant singolo viene fornito gratuitamente come risorsa di Azure gestita astratta dall'utente. Si paga solo per i nodi collegati al cluster del servizio Azure Kubernetes. Il piano di controllo e le relative risorse si trovano solo nell'area in cui è stato creato il cluster.

Il piano di controllo include i componenti principali di Kubernetes seguenti:

Componente	Descrizione
kube-apiserver	Il server API espone le API Kubernetes sottostanti e fornisce l'interazione per gli strumenti di gestione, ad esempio kubectl o il dashboard kubernetes.
etcd	etcd è un archivio chiave-valore a disponibilità elevata all'interno di Kubernetes che consente di mantenere lo stato del cluster e della configurazione di Kubernetes.
kube-scheduler	Quando si creano o si ridimensionano applicazioni, l'utilità di pianificazione determina i nodi che possono eseguire il carico di lavoro e avvia i nodi identificati.
kube-controller-manager	Il responsabile del controller supervisiona una serie di controller più piccoli che eseguono azioni come la replica dei pod e la gestione delle operazioni dei nodi.

Tenere presente che non è possibile accedere direttamente al piano di controllo. Gli aggiornamenti del piano di controllo e dei nodi kubernetes vengono orchestrati tramite l'interfaccia della riga di comando di Azure o portale di Azure. Per risolvere i possibili problemi, è possibile esaminare i log del piano di controllo usando Monitoraggio di Azure.

Nodi

Per eseguire le applicazioni e i servizi di supporto, è necessario un nodo Kubernetes. Ogni cluster del servizio Azure Kubernetes ha almeno un nodo, una macchina virtuale di Azure che esegue i componenti del nodo Kubernetes e il runtime del contenitore.

I nodi includono i componenti principali di Kubernetes seguenti:

Componente	Descrizione
kubelet	Agente Kubernetes che elabora le richieste di orchestrazione dal piano di controllo insieme alla pianificazione ed esecuzione dei contenitori richiesti.
kube-proxy	Il proxy gestisce la rete virtuale in ogni nodo, il routing del traffico di rete e la gestione degli indirizzi IP per servizi e pod.
runtime del contenitore	Il runtime del contenitore consente l'esecuzione e l'interazione delle applicazioni in contenitori con altre risorse, ad esempio la rete virtuale o l'archiviazione. Per altre informazioni, vedere Configurazione del runtime del contenitore.

Le dimensioni delle macchine virtuali di Azure per i nodi definiscono CPU, memoria, dimensioni e tipo di archiviazione disponibile, ad esempio UNITÀ SSD a prestazioni elevate o HDD standard. Pianificare le dimensioni del nodo per determinare se le applicazioni potrebbero richiedere grandi quantità di CPU e memoria o archiviazione ad alte prestazioni. Aumentare il numero di nodi nel cluster del servizio Azure Kubernetes per soddisfare la domanda. Per altre informazioni sul ridimensionamento, vedere Opzioni di ridimensionamento per le applicazioni nel servizio Azure Kubernetes.

Nel servizio Azure Kubernetes l'immagine della macchina virtuale per i nodi del cluster si basa su Ubuntu Linux, Azure Linuxo Windows Server 2022. Quando si crea un cluster AKS o si riduce il numero di nodi, la piattaforma Azure crea e configura automaticamente il numero di macchine virtuali richiesto. I nodi dell'agente vengono fatturati come macchine virtuali standard, quindi vengono applicati automaticamente eventuali sconti sulle dimensioni delle macchine virtuali, incluse le prenotazioni di Azure.

Per i dischi gestiti, le dimensioni e le prestazioni predefinite del disco vengono assegnate in base allo SKU della macchina virtuale e al numero di vCPU selezionati. Per altre informazioni, vedere Ridimensionamento del disco del sistema operativo predefinito.

Configurazione del sistema operativo

Il servizio Azure Kubernetes supporta Ubuntu 22.04 e Azure Linux 2.0 come sistemi operativi del nodo per cluster con Kubernetes 1.25 e versioni successive. Ubuntu 18.04 può anche essere selezionato in fase di creazione del pool di nodi per Kubernetes versioni 1.24 e successive.

Il servizio Azure Kubernetes supporta Windows Server 2022 come sistema operativo predefinito per i pool di nodi Windows nei cluster con Kubernetes 1.25 e versioni successive. Windows Server 2019 può anche essere selezionato in fase di creazione del pool di nodi per Kubernetes versioni 1.32 e successive. Windows Server 2019 viene ritirato dopo che Kubernetes versione 1.32 raggiunge la fine del ciclo di vita e non è supportato nelle versioni future. Per ulteriori informazioni su questo ritiro, consultare le note sulla versione del servizio Azure Kubernetes.

Configurazione del runtime del contenitore

Il runtime del contenitore è un software che esegue i contenitori e gestisce le immagini del contenitore in un nodo. Il runtime consente di astrarre le chiamate sys o le funzionalità specifiche del sistema operativo per eseguire contenitori in Linux o Windows. Per pool di nodi Linux, containerd viene usato in Kubernetes versione 1.19 e successive. Per pool di nodi di Windows Server 2019 e 2022, containerd è generalmente disponibile ed è l'unica opzione di runtime in Kubernetes versione 1.23 e successive. A partire da maggio 2023, Docker è stato ritirato e non è più supportato. Per ulteriori informazioni su questo ritiro, consultare le note sulla versione del servizio Azure Kubernetes.

Containerd è un runtime essenziale di contenitori conforme a OCI (Open Container Initiative) che fornisce il set minimo di funzionalità necessarie per eseguire i contenitori e gestire le immagini in un nodo. Concontainerd nodi e pool di nodi basati su , kubelet comunica direttamente con containerd l'uso del plug-in CRI (container runtime interface), rimuovendo hop aggiuntivi nel flusso di dati rispetto all'implementazione cri di Docker. Di conseguenza, si noterà una migliore latenza di avvio dei pod e un minore utilizzo di risorse (CPU e memoria).

Containerd funziona in ogni versione ga di Kubernetes nel servizio Azure Kubernetes, in ogni versione di Kubernetes a partire dalla versione 1.19 e supporta tutte le funzionalità di Kubernetes e del servizio Azure Kubernetes.

containerd limitazioni/differenze

• Per containerd, è consigliabile usare crictl come sostituzione dell'interfaccia della riga di comando di Docker per la risoluzione dei problemi relativi a pod, contenitori e immagini del contenitore nei nodi Kubernetes. Per altre informazioni su , vedere Le opzioni generali di crictlutilizzo e configurazione client.

  • Containerd non fornisce la funzionalità completa dell'interfaccia della riga di comando di Docker. È disponibile solo per la risoluzione problemi.
  • crictl offre un‘interfaccia dei contenitori più adatta a Kubernetes, che include concetti come pod e altri.

• Containerd configura la registrazione usando il formato di registrazione standardizzato cri . La soluzione di registrazione deve supportare il cri formato di registrazione, ad esempio Monitoraggio di Azure per contenitori.

• Non è più possibile accedere al motore Docker, /var/run/docker.socko usare Docker-in-Docker (DinD).

  • Se attualmente si estraggono i log dell'applicazione o i dati di monitoraggio dal motore Docker, usare invece Container Insights . Il servizio Azure Kubernetes non supporta l'esecuzione di comandi fuori banda sui nodi dell’agente che potrebbero causare instabilità.
  • Non è consigliabile creare immagini o usare direttamente il motore Docker. Kubernetes non è pienamente a conoscenza delle risorse utilizzate e questi metodi presentano numerosi problemi, come illustrato qui e qui.

• Quando si compilano immagini, è possibile continuare a usare il flusso di lavoro di compilazione Docker corrente come di consueto, a meno che non si creino immagini all'interno del cluster del servizio Azure Kubernetes. In questo caso, si raccomanda di passare all'approccio consigliato per la compilazione di immagini usando Attività del registro di Azure Container o un'opzione in-cluster più sicura, come Docker Buildx.

Prenotazioni di risorse

Il servizio Azure Kubernetes usa le risorse del nodo per facilitare la funzione del nodo come parte del cluster. Questo utilizzo può creare una discrepanza tra le risorse totali del nodo e le risorse allocabili nel servizio Azure Kubernetes. Tenere presente queste informazioni quando si impostano richieste e limiti per i pod distribuiti dall'utente.

Per trovare la risorsa allocabile di un nodo, è possibile usare il kubectl describe node comando :

kubectl describe node [NODE_NAME]

Per mantenere le prestazioni e le funzionalità dei nodi, il servizio Azure Kubernetes riserva due tipi di risorse, CPU e memoria, in ogni nodo. Man mano che un nodo aumenta di dimensioni maggiori nelle risorse, la prenotazione delle risorse aumenta a causa di una maggiore necessità di gestione dei pod distribuiti dall'utente. Tenere presente che le prenotazioni delle risorse non possono essere modificate.

CPU

La CPU riservata dipende dal tipo di nodo e dalla configurazione del cluster, che può causare una CPU meno allocabile a causa dell'esecuzione di funzionalità aggiuntive. La tabella seguente mostra la prenotazione della CPU in millicores:

Core CPU nell'host	1	2	4	8	16	32	64
Kube-reserved (millicores)	60	100	140	180	260	420	740

Memory

La memoria riservata nel servizio Azure Kubernetes include la somma di due valori:

Servizio Azure Kubernetes 1.29 e versioni successive

1. kubelet Il daemon ha la regola di rimozione memory.available<100Mi per impostazione predefinita. Questa regola garantisce che un nodo abbia almeno 100Mi allocato in qualsiasi momento. Quando un host è inferiore alla soglia di memoria disponibile, kubelet attiva la terminazione di uno dei pod in esecuzione e libera memoria nel computer host.

2. Frequenza di prenotazioni di memoria impostata in base al valore minore di: 20 MB * Numero massimo di pod supportati nel nodo + 50 MB o 25% delle risorse di memoria di sistema totali.

   Esempi:

   • Se la macchina virtuale fornisce 8 GB di memoria e il nodo supporta fino a 30 pod, il servizio Azure Kubernetes riserva 20 MB * 30 Max Pods + 50MB = 650 MB per kube-reserved. Allocatable space = 8GB - 0.65GB (kube-reserved) - 0.1GB (eviction threshold) = 7.25GB or 90.625% allocatable.
   • Se la macchina virtuale fornisce 4 GB di memoria e il nodo supporta fino a 70 pod, il servizio Azure Kubernetes riserva il 25% * 4 GB = 1000 MB per kube-reserved, poiché si tratta di meno di 20 MB * 70 Max Pod + 50MB = 1450 MB.

   Per altre informazioni, vedere Configurare il numero massimo di pod per nodo in un cluster del servizio Azure Kubernetes.

Versioni del servizio Azure Kubernetes precedenti alla 1.29

1. kubelet Il daemon ha la regola di rimozione memory.available<750Mi per impostazione predefinita. Questa regola garantisce che un nodo abbia sempre almeno 750Mi allocato. Quando un host è inferiore alla soglia di memoria disponibile, kubelet attiva la terminazione di uno dei pod in esecuzione e libera memoria nel computer host.
2. Frequenza regredente delle prenotazioni di memoria per il daemon kubelet per il corretto funzionamento (kube-reserved).
   • 25% dei primi 4 GB di memoria
   • 20% dei successivi 4 GB di memoria (fino a 8 GB)
   • 10% dei successivi 8 GB di memoria (fino a 16 GB)
   • 6% dei successivi 112 GB di memoria (fino a 128 GB)
   • 2% di qualsiasi memoria superiore a 128 GB

Le regole di allocazione della memoria e della CPU sono progettate per:

• Mantenere integri i nodi dell'agente, inclusi alcuni pod del sistema di hosting critici per l'integrità del cluster.
• Fare in modo che il nodo segnala meno memoria e CPU allocabili rispetto a quanto segnala se non fasse parte di un cluster Kubernetes.

Ad esempio, se un nodo offre 7 GB, segnala il 34% della memoria non allocabile, inclusa la soglia di rimozione rigida 750Mi.

0.75 + (0.25*4) + (0.20*3) = 0.75GB + 1GB + 0.6GB = 2.35GB / 7GB = 33.57% reserved

Oltre alle prenotazioni per Kubernetes stesso, il sistema operativo del nodo sottostante riserva anche una quantità di risorse cpu e memoria per gestire le funzioni del sistema operativo.

Per le procedure consigliate associate, vedere Procedure consigliate per le funzionalità di utilità di pianificazione di base nel servizio Azure Kubernetes.

Pool di nodi

I nodi della stessa configurazione vengono raggruppati in pool di nodi. Ogni cluster Kubernetes contiene almeno un pool di nodi. Si definisce il numero iniziale di nodi e dimensioni quando si crea un cluster del servizio Azure Kubernetes, che crea un pool di nodi predefinito. Questo pool di nodi predefinito nel servizio Azure Kubernetes contiene le macchine virtuali sottostanti che eseguono i nodi dell'agente.

È possibile ridimensionare o aggiornare un cluster del servizio Azure Kubernetes rispetto al pool di nodi predefinito. È possibile scegliere di ridimensionare o aggiornare un pool di nodi specifico. Per le operazioni di aggiornamento, i contenitori in esecuzione vengono pianificati in altri nodi del pool fino a quando non vengono aggiornati tutti i nodi.

Per altre informazioni, vedere Creare pool di nodi e Gestire i pool di nodi.

Dimensioni predefinite del disco del sistema operativo

Quando si crea un nuovo cluster o si aggiunge un nuovo pool di nodi a un cluster esistente, il numero di vCPU determina per impostazione predefinita le dimensioni del disco del sistema operativo. Il numero di vCPU si basa sullo SKU della macchina virtuale. La tabella seguente elenca le dimensioni predefinite del disco del sistema operativo per ogni SKU di macchina virtuale:

Macchina virtuale SKU Cores (vCPU)	Livello di default del disco del sistema operativo	Operazioni di I/O al secondo di cui è stato effettuato il provisioning	Velocità effettiva (MB/s) con provisioning
1 - 7	P10/128G	500	100
8 - 15	P15/256G	1100	125
16 - 63	P20/512G	2300	150
64+	P30/1024G	5000	200

Selettori nodi

In un cluster del servizio Azure Kubernetes con più pool di nodi potrebbe essere necessario indicare all'Utilità di pianificazione Kubernetes quale pool di nodi usare per una determinata risorsa. Ad esempio, i controller di ingresso non devono essere eseguiti nei nodi di Windows Server. Si usano selettori di nodo per definire vari parametri, ad esempio il sistema operativo del nodo, per controllare dove deve essere pianificato un pod.

L'esempio di base seguente pianifica un'istanza NGINX in un nodo Linux usando il selettore di nodo "kubernetes.io/os": linux:

kind: Pod
apiVersion: v1
metadata:
  name: nginx
spec:
  containers:
    - name: myfrontend
      image: mcr.microsoft.com/oss/nginx/nginx:1.15.12-alpine
  nodeSelector:
    "kubernetes.io/os": linux

Per altre informazioni, vedere Procedure consigliate per le funzionalità avanzate dell'utilità di pianificazione nel servizio Azure Kubernetes.

Gruppo di risorse del nodo

Quando si crea un cluster del servizio Azure Kubernetes, si specifica un gruppo di risorse di Azure in cui creare le risorse del cluster. Oltre a questo gruppo di risorse, il provider di risorse del servizio Azure Kubernetes crea e gestisce un gruppo di risorse separato denominato gruppo di risorse del nodo. Il gruppo di risorse del nodo contiene le risorse dell'infrastruttura seguenti:

• Set di scalabilità di macchine virtuali e macchine virtuali per ogni nodo nei pool di nodi
• Rete virtuale per il cluster
• Archiviazione per il cluster

Al gruppo di risorse del nodo viene assegnato un nome per impostazione predefinita con il formato seguente: MC_resourceGroupName_clusterName_location. Durante la creazione del cluster, è possibile specificare il nome assegnato al gruppo di risorse del nodo. Quando si usa un modello di Azure Resource Manager, è possibile definire il nome usando la nodeResourceGroup proprietà . Quando si usa l'interfaccia della riga di comando di Azure, usare il --node-resource-group parametro con il az aks create comando , come illustrato nell'esempio seguente:

az aks create --name myAKSCluster --resource-group myResourceGroup --node-resource-group myNodeResourceGroup

Quando si elimina il cluster del servizio Azure Kubernetes, il provider di risorse del servizio Azure Kubernetes elimina automaticamente il gruppo di risorse del nodo.

Il gruppo di risorse del nodo presenta le limitazioni seguenti:

• Non è possibile specificare un gruppo di risorse esistente per il gruppo di risorse del nodo.
• Non è possibile specificare una sottoscrizione diversa per il gruppo di risorse del nodo.
• Non è possibile modificare il nome del gruppo di risorse del nodo dopo la creazione del cluster.
• Non è possibile specificare nomi per le risorse gestite all'interno del gruppo di risorse del nodo.
• Non è possibile modificare o eliminare tag creati da Azure delle risorse gestite all'interno del gruppo di risorse del nodo.

La modifica di qualsiasi tag creato da Azure nelle risorse nel gruppo di risorse del nodo nel cluster del servizio Azure Kubernetes è un'azione non supportata, che interrompe il punto di disconnessione singolo (SLO). Se si modificano o si eliminano tag creati da Azure o altre proprietà delle risorse nel gruppo di risorse del nodo, è possibile ottenere risultati imprevisti, ad esempio la scalabilità e l'aggiornamento degli errori. Il servizio Azure Kubernetes gestisce il ciclo di vita dell'infrastruttura nel gruppo di risorse del nodo, quindi le eventuali modifiche spostano il cluster in uno stato non supportato. Per altre informazioni, vedere Il servizio Azure Kubernetes offre un contratto di servizio?

Il servizio Azure Kubernetes consente di creare e modificare i tag propagati alle risorse nel gruppo di risorse del nodo ed è possibile aggiungere tali tag durante la creazione o l'aggiornamento del cluster. È possibile creare o modificare tag personalizzati per assegnare, ad esempio, un business unit o un centro di costo. È anche possibile creare criteri di Azure con un ambito nel gruppo di risorse gestite.

Per ridurre le probabilità di modifiche nel gruppo di risorse del nodo che influiscono sui cluster, è possibile abilitare il blocco del gruppo di risorse del nodo per applicare un'assegnazione di rifiuto alle risorse del servizio Azure Kubernetes. per altre informazioni, vedere Gruppo di risorse completamente gestito (anteprima).

Pod

Kubernetes usa i pod per eseguire istanze dell'applicazione. Un singolo pod rappresenta una singola istanza dell'applicazione.

I pod hanno in genere un mapping 1:1 con un contenitore. Negli scenari avanzati, un pod potrebbe contenere più contenitori. I pod multi-contenitore vengono pianificati insieme nello stesso nodo e consentono ai contenitori di condividere le risorse correlate.

Quando si crea un pod, è possibile definire richieste di risorse per una determinata quantità di CPU o memoria. L'Utilità di pianificazione di Kubernetes prova a soddisfare la richiesta pianificando i pod per l'esecuzione in un nodo con le risorse disponibili. È anche possibile specificare limiti massimi per le risorse per impedire a un pod di usare troppe risorse di calcolo del nodo sottostante. La procedura consigliata consiste nell'includere i limiti delle risorse per tutti i pod per consentire all'utilità di pianificazione kubernetes di identificare le risorse necessarie e consentite.

Per altre informazioni, vedere Pod di Kubernetes e Ciclo di vita dei pod di Kubernetes.

Un pod è una risorsa logica, ma i carichi di lavoro applicativi sono eseguiti nei contenitori. I pod sono costituiti in genere da risorse temporanee eliminabili. Nei pod pianificati singolarmente mancano alcune delle funzionalità di disponibilità elevata e ridondanza di Kubernetes. I controller Kubernetes, ad esempio il controller di distribuzione, distribuiscono e gestiscono i pod.

Distribuzioni e manifesti YAML

Una distribuzione rappresenta pod identici gestiti dal controller di distribuzione Kubernetes. Una distribuzione definisce il numero di repliche di pod da creare. L'utilità di pianificazione Kubernetes garantisce che i pod aggiuntivi vengano pianificati in nodi integri se i pod o i nodi riscontrano problemi. È possibile aggiornare le distribuzioni per modificare la configurazione dei pod, l'immagine del contenitore o l'archiviazione collegata.

Il controller di distribuzione gestisce il ciclo di vita della distribuzione ed esegue le azioni seguenti:

• Svuota e termina un determinato numero di repliche.
• Crea repliche dalla nuova definizione di distribuzione.
• Continua il processo fino a quando non vengono aggiornate tutte le repliche nella distribuzione.

La maggior parte delle applicazioni senza stato in servizio Azure Kubernetes dovrebbe usare il modello di distribuzione anziché pianificare singoli pod. Kubernetes può monitorare l'integrità e lo stato della distribuzione per assicurarsi che il numero di repliche necessarie venga eseguito all'interno del cluster. Quando pianificati singolarmente, i pod non vengono riavviati se riscontrano un problema e non vengono riprogrammati nei nodi integri se il nodo corrente rileva un problema.

Non si vuole interrompere le decisioni di gestione con un processo di aggiornamento se l'applicazione richiede un numero minimo di istanze disponibili. I budget di interruzione dei pod definiscono il numero di repliche in una distribuzione che può essere disattivata durante un aggiornamento di un aggiornamento o di un nodo. Ad esempio, se nella distribuzione sono presenti cinque repliche, è possibile definire un'interruzione del pod di quattro per consentire l'eliminazione o la riprogrammazione di una sola replica alla volta. Come per i limiti delle risorse dei pod, la procedura consigliata consiste nel definire i budget di interruzione dei pod nelle applicazioni che richiedono un numero minimo di repliche per essere sempre presenti.

Le distribuzioni vengono in genere create e gestite con kubectl create o kubectl apply. È possibile creare una distribuzione definendo un file manifesto nel formato YAML. L'esempio seguente mostra un file manifesto della distribuzione di base per un server Web NGINX:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: mcr.microsoft.com/oss/nginx/nginx:1.15.2-alpine
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: 250m
            memory: 64Mi
          limits:
            cpu: 500m
            memory: 256Mi

Una suddivisione delle specifiche di distribuzione nel file manifesto YAML è la seguente:

Specifica	Descrizione
.apiVersion	Specifica il gruppo di API e la risorsa API da usare durante la creazione della risorsa.
.kind	Specifica il tipo di risorsa da creare.
.metadata.name	Specifica il nome della distribuzione. Questo file YAML di esempio esegue l'immagine nginx dall'hub Docker.
.spec.replicas	Specifica il numero di pod da creare. Questo file YAML di esempio crea tre pod duplicati.
.spec.selector	Specifica quali pod saranno interessati da questa distribuzione.
.spec.selector.matchLabels	Contiene una mappa di coppie {key, value} che consentono alla distribuzione di trovare e gestire i pod creati.
.spec.selector.matchLabels.app	Deve corrispondere .spec.template.metadata.labelsa .
.spec.template.labels	Specifica le coppie {key, value} associate all'oggetto .
.spec.template.app	Deve corrispondere .spec.selector.matchLabelsa .
.spec.spec.containers	Specifica l'elenco di contenitori appartenenti al pod.
.spec.spec.containers.name	Specifica il nome del contenitore specificato come etichetta DNS.
.spec.spec.containers.image	Specifica il nome dell'immagine del contenitore.
.spec.spec.containers.ports	Specifica l'elenco di porte da esporre dal contenitore.
.spec.spec.containers.ports.containerPort	Specifica il numero di porte da esporre nell'indirizzo IP del pod.
.spec.spec.resources	Specifica le risorse di calcolo richieste dal contenitore.
.spec.spec.resources.requests	Specifica la quantità minima di risorse di calcolo necessarie.
.spec.spec.resources.requests.cpu	Specifica la quantità minima di CPU richiesta.
.spec.spec.resources.requests.memory	Specifica la quantità minima di memoria richiesta.
.spec.spec.resources.limits	Specifica la quantità massima di risorse di calcolo consentite. Kubelet applica questo limite.
.spec.spec.resources.limits.cpu	Specifica la quantità massima di CPU consentita. Kubelet applica questo limite.
.spec.spec.resources.limits.memory	Specifica la quantità massima di memoria consentita. Kubelet applica questo limite.

È possibile creare applicazioni più complesse includendo servizi, ad esempio servizi di bilanciamento del carico, all'interno del manifesto YAML.

Per altre informazioni, vedere le distribuzioni Kubernetes.

Gestione dei pacchetti con Helm

Helm viene comunemente usato per gestire le applicazioni in Kubernetes. È possibile distribuire le risorse creando e usando grafici Helm pubblici esistenti che contengono una versione in pacchetto del codice dell'applicazione e i manifesti YAML di Kubernetes. È possibile archiviare grafici Helm in locale o in un repository remoto, ad esempio un repository del grafico Helm Registro Azure Container.

Per usare Helm, installare il client Helm nel computer o usare il client Helm in Azure Cloud Shell. Cercare o creare grafici Helm e quindi installarli nel cluster Kubernetes. Per altre informazioni, vedere Installare le applicazioni esistenti con Helm nel servizio Azure Kubernetes.

Oggetti StatefulSet e DaemonSet

Il controller di distribuzione usa l'utilità di pianificazione Kubernetes ed esegue repliche in qualsiasi nodo disponibile con risorse disponibili. Anche se questo approccio potrebbe essere sufficiente per le applicazioni senza stato, il controller di distribuzione non è ideale per le applicazioni che richiedono le specifiche seguenti:

• Convenzione di denominazione permanente o archiviazione.
• Una replica da esistere in ogni nodo selezionato all'interno di un cluster.

Due risorse Kubernetes, tuttavia, consentono di gestire questi tipi di applicazioni: StatefulSets e DaemonSets.

Gli oggetti StatefulSet mantengono lo stato delle applicazioni oltre un ciclo di vita di un singolo pod. DaemonSets garantisce un'istanza in esecuzione in ogni nodo all'inizio del processo di bootstrap di Kubernetes.

Oggetti StatefulSet

Lo sviluppo di applicazioni moderne ha spesso lo scopo di applicazioni senza stato. Per le applicazioni con stato, ad esempio quelle che includono componenti di database, è possibile usare StatefulSets. Analogamente alle distribuzioni, un oggetto StatefulSet crea e gestisce almeno un pod identico. Le repliche in un oggetto StatefulSet seguono un approccio sequenziale normale alle operazioni di distribuzione, scalabilità, aggiornamento e terminazione. La convenzione di denominazione, i nomi di rete e l'archiviazione vengono mantenuti man mano che le repliche vengono riprogrammate con un oggetto StatefulSet.

È possibile definire l'applicazione in formato YAML usando kind: StatefulSet. Da qui, il controller StatefulSet gestisce la distribuzione e la gestione delle repliche necessarie. I dati vengono scritti in un archivio permanente, fornito da Azure Managed Disks o File di Azure. Con StatefulSets, l'archiviazione permanente sottostante rimane, anche quando viene eliminato StatefulSet.

Per altre informazioni, vedere Oggetti StatefulSet di Kubernetes.

Oggetti DaemonSet

Per una raccolta o un monitoraggio di log specifici, potrebbe essere necessario eseguire un pod in tutti i nodi o in un set di nodi selezionato. È possibile usare DaemonSets per eseguire la distribuzione in uno o più pod identici. Il controller DaemonSet garantisce che ogni nodo specificato esegua un'istanza del pod.

Il controller DaemonSet può pianificare i pod nei nodi all'inizio del processo di avvio del cluster prima dell'avvio dell'utilità di pianificazione Kubernetes predefinita. Questa capacità garantisce che i pod in uno stato DaemonSet prima che i pod tradizionali in un oggetto Deployment o StatefulSet siano pianificati.

Analogamente a StatefulSets, è possibile definire un DaemonSet come parte di una definizione YAML usando kind: DaemonSet.

Per altre informazioni, vedere Oggetti DaemonSet di Kubernetes.

Namespaces (Spazi dei nomi)

Le risorse Kubernetes, ad esempio pod e distribuzioni, vengono raggruppate logicamente in spazi dei nomi per dividere un cluster del servizio Azure Kubernetes e creare, visualizzare o gestire l'accesso alle risorse. Ad esempio, è possibile creare spazi dei nomi per separare gruppi aziendali. Gli utenti possono interagire solo con le risorse all'interno degli spazi dei nomi assegnati.

Quando si crea un cluster del servizio Azure Kubernetes sono disponibili gli spazi dei nomi seguenti:

Spazio dei nomi	Descrizione
default	Nei casi in cui non viene fornita alcuna opzione, i pod e le distribuzioni vengono creati per impostazione predefinita. Negli ambienti più piccoli è possibile distribuire le applicazioni direttamente nello spazio dei nomi predefinito senza creare altre suddivisioni logiche. Quando si interagisce con l'API di Kubernetes, ad esempio kubectl get pods, viene usato lo spazio dei nomi predefinito se non ne viene specificato un altro.
kube-system	Nel caso in cui siano presenti risorse di base, ad esempio funzioni di rete come DNS e proxy, o il dashboard Kubernetes. In genere non si distribuiscono le proprie applicazioni in questo spazio dei nomi.
kube-public	In genere non viene usato, è possibile usarlo per consentire la visibilità delle risorse nell'intero cluster e può essere visualizzato da qualsiasi utente.

Per altre informazioni, vedere Spazi dei nomi di Kubernetes.

Passaggi successivi

Per altre informazioni sui concetti fondamentali di Kubernetes e del servizio Azure Kubernetes, vedere gli articoli seguenti:

• Accesso e identità del servizio Azure Kubernetes
• Sicurezza del servizio Azure Kubernetes
• Reti virtuali del servizio Azure Kubernetes
• Archiviazione del servizio Azure Kubernetes
• Scalabilità del servizio Azure Kubernetes