Concetti di base di Kubernetes per servizio Azure Kubernetes

Lo sviluppo di applicazioni continua a spostarsi verso un approccio basato su contenitori, aumentando la necessità di orchestrare e gestire le risorse. Come piattaforma leader, Kubernetes offre una pianificazione affidabile dei carichi di lavoro delle applicazioni a tolleranza di errore. servizio Azure Kubernetes (AKS), un'offerta Kubernetes gestita, semplifica ulteriormente la distribuzione e la gestione di applicazioni basate su contenitori.

Questo articolo presenta i concetti di base:

• Componenti dell'infrastruttura Kubernetes:

  • piano di controllo
  • Nodi
  • pool di nodi

• Risorse del carico di lavoro:

  • Baccelli
  • Distribuzioni
  • Imposta

• Raggruppare le risorse usando gli spazi dei nomi.

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 applicativi e non sui componenti dell'infrastruttura sottostante. Kubernetes offre un approccio dichiarativo alle distribuzioni, supportato da un solido set di API per le operazioni di gestione.

È possibile creare ed eseguire applicazioni moderne, portabili e basate su microservizi utilizzando Kubernetes per orchestrare e gestire la disponibilità dei componenti dell'applicazione. Kubernetes supporta applicazioni senza stato e con stato man mano che i team avanzano attraverso l'adozione di applicazioni basate su microservizi.

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 fornisce un servizio Kubernetes gestito che riduce la complessità delle attività di distribuzione e gestione di base, ad esempio il coordinamento degli aggiornamenti. 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:

• Piano di controllo: offre i servizi Kubernetes di base e l'orchestrazione dei carichi di lavoro dell'applicazione.
• Nodi: eseguire i carichi di lavoro applicativi.

Piano di controllo

Quando si crea un cluster del servizio Azure Kubernetes, viene creato e configurato automaticamente un piano di controllo. Il piano di controllo è fornito gratuitamente come risorsa di Azure gestita indipendente 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 indica il modo in cui le API Kubernetes sottostanti sono esposte. Questo componente fornisce l'interazione per gli strumenti di gestione, ad esempio kubectl o il dashboard di Kubernetes.
etcd	Per mantenere lo stato del cluster e della configurazione kubernetes, l'etcd a disponibilità elevata è un archivio di valori chiave all'interno di Kubernetes.
kube-scheduler	Quando si creano o si ridimensionano applicazioni, l'Utilità di pianificazione determina quali nodi possono eseguire il carico di lavoro e li avvia.
kube-controller-manager	Controller Manager supervisiona un certo numero di controller più piccoli che eseguono azioni come la replica dei pod e la gestione delle operazioni dei nodi.

Il servizio Azure Kubernetes fornisce un piano di controllo a tenant singolo, con un server API dedicato, un'utilità di pianificazione e così via. Si definiscono il numero e le dimensioni dei nodi e la piattaforma Azure configura la comunicazione sicura tra il piano di controllo e i nodi. L'interazione con il piano di controllo viene eseguita tramite le API Kubernetes, ad esempio kubectl o il dashboard kubernetes.

Anche se non è necessario configurare componenti (ad esempio un archivio etcd a disponibilità elevata) con questo piano di controllo gestito, 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 tramite i log di Monitoraggio di Azure.

Per configurare o accedere direttamente a un piano di controllo, distribuire un cluster Kubernetes autogestito usando Cluster API Provider Azure.

Per le procedure consigliate associate, vedere Procedure consigliate per la sicurezza e gli aggiornamenti del cluster nel servizio Azure Kubernetes.

Per informazioni sulla gestione dei costi del servizio Azure Kubernetes, vedere Nozioni di base sui costi del servizio Azure Kubernetes e Prezzi per il servizio Azure Kubernetes.

Nodi e pool di nodi

Per eseguire le applicazioni e i servizi di supporto, è necessario un nodo Kubernetes. Un 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.

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	Gestisce la rete virtuale in ogni nodo. Il proxy instrada il traffico di rete e gestisce gli indirizzi IP per i servizi e i pod.
runtime del contenitore	Consente alle applicazioni in contenitori di eseguire e interagire con risorse aggiuntive, ad esempio la rete virtuale o l'archiviazione. I cluster del servizio Azure Kubernetes che usano Kubernetes versione 1.19+ per i pool di nodi Linux usano containerd come runtime del contenitore. A partire da Kubernetes versione 1.20 per i pool di nodi Windows, containerd può essere usato in anteprima per il runtime del contenitore, ma Docker è ancora il runtime del contenitore predefinito. I cluster del servizio Azure Kubernetes che usano versioni precedenti di Kubernetes per i pool di nodi usano Docker come 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 possono 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 Linux o Windows Server 2019. Quando si crea un cluster del servizio Azure Kubernetes o si aumenta il numero di nodi, la piattaforma Azure crea e configura automaticamente il numero richiesto di macchine virtuali. 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 verranno assegnate in base allo SKU della macchina virtuale e al numero di vCPU selezionati. Per altre informazioni, vedere Dimensionamento predefinito del disco del sistema operativo.

Se è necessaria una configurazione e un controllo avanzati nel runtime e nel sistema operativo del contenitore del nodo Kubernetes, è possibile distribuire un cluster autogestito usando il provider di API cluster di Azure.

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 le risorse allocabili di un nodo, eseguire:

kubectl describe node [NODE_NAME]

Per mantenere le prestazioni e le funzionalità dei nodi, il servizio Azure Kubernetes riserva le risorse 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.

Nota

L'uso di componenti aggiuntivi del servizio Azure Kubernetes, ad esempio Container Insights (OMS) utilizzerà risorse del nodo aggiuntive.

Sono riservati due tipi di risorse:

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.

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

Memoria

La memoria utilizzata dal servizio Azure Kubernetes include la somma di due valori.

Importante

Le anteprime del servizio Azure Kubernetes 1.29 a gennaio 2024 e includono alcune modifiche alle prenotazioni di memoria. Queste modifiche sono descritte in dettaglio nella sezione seguente.

Servizio Azure Kubernetes 1.29 e versioni successive

1. kubelet Il daemon ha la regola di rimozione memory.available<100Mi per impostazione predefinita. Ciò garantisce che un nodo abbia sempre 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 viene installato in tutti i nodi dell'agente Kubernetes per gestire la creazione e la terminazione del contenitore. Per impostazione predefinita nel servizio Azure Kubernetes, kubelet il daemon ha la regola di rimozione memory.available<750Mi , assicurando che un nodo debba avere sempre almeno 750Mi allocabile in qualsiasi momento. Quando un host è inferiore alla soglia di memoria disponibile, kubelet verrà attivato per terminare uno dei pod in esecuzione e liberare 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

Nota

Il servizio Azure Kubernetes riserva altri 2 GB per il processo di sistema nei nodi Windows che non fanno parte della memoria calcolata.

Le regole di allocazione della memoria e della CPU sono progettate per eseguire le operazioni seguenti:

• 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.

Non è possibile modificare le prenotazioni di risorse precedenti.

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

Nota

Il pool di nodi Linux di Azure è ora disponibile a livello generale. Per informazioni sui vantaggi e sui passaggi di distribuzione, vedere Introduzione all'host contenitore Linux di Azure per il servizio Azure Kubernetes.

I nodi della stessa configurazione vengono raggruppati in pool di nodi. Un cluster Kubernetes contiene almeno un pool di nodi. Il numero e le dimensioni iniziali dei nodi vengono definiti 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.

Nota

Per garantire che il cluster funzioni in modo affidabile, è necessario eseguire almeno due (2) nodi nel pool di nodi predefinito.

È 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 su come usare più pool di nodi nel servizio Azure Kubernetes, vedere Creare più pool di nodi per un cluster nel servizio Azure Kubernetes.

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.

I selettori di nodo consentono di 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 su come controllare dove sono pianificati i pod, 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, è necessario specificare un gruppo di risorse in cui creare la risorsa cluster. Oltre a questo gruppo di risorse, il provider di risorse del servizio Azure Kubernetes crea e gestisce anche 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, ad esempio MC_myResourceGroup_myAKSCluster_eastus. Durante la creazione del cluster, è anche possibile specificare il nome assegnato al gruppo di risorse del nodo. 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.

Se si modificano o si eliminano tag creati da Azure e altre proprietà delle risorse nel gruppo di risorse del nodo, è possibile ottenere risultati imprevisti, ad esempio errori di ridimensionamento e aggiornamento. Man mano che il servizio Azure Kubernetes gestisce il ciclo di vita dell'infrastruttura nel gruppo di risorse del nodo, eventuali modifiche sposteranno il cluster in uno stato non supportato.

Uno scenario comune in cui i clienti vogliono modificare le risorse è tramite tag. 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. Potrebbe essere necessario creare o modificare tag personalizzati da assegnare ad esempio a una business unit o a un centro di costo. A tale scopo, è anche possibile creare Criteri di Azure con un ambito nel gruppo di risorse gestite.

La modifica di eventuali tag creati da Azure nelle risorse nel gruppo di risorse del nodo nel cluster del servizio Azure Kubernetes è un'azione non supportata, che interrompe l'obiettivo del livello di servizio (SLO). Per altre informazioni, vedere Il servizio Azure Kubernetes offre un contratto di servizio?

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. Altre informazioni sono disponibili in Configurazione cluster nel servizio Azure Kubernetes.

Avviso

Se il blocco del gruppo di risorse del nodo non è abilitato, è possibile modificare direttamente qualsiasi risorsa nel gruppo di risorse del nodo. La modifica diretta delle risorse nel gruppo di risorse del nodo può causare l'instabilità o la mancata risposta del cluster.

Pod

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

I pod hanno in genere un mapping 1:1 con un contenitore. Negli scenari avanzati un pod può 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 richiedere una determinata quantità di risorse 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 per le risorse di tutti i pod per aiutare l'Utilità di pianificazione di Kubernetes a identificare le risorse necessarie 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 pod vengono invece distribuiti e gestiti dai controller Kubernetes, ad esempio il controller di distribuzione.

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 altri pod vengano pianificati in nodi integri se si verificano problemi nei pod o nei nodi.

È possibile aggiornare le distribuzioni per modificare la configurazione dei pod, l'immagine del contenitore usata o l'archiviazione collegata. Controller di distribuzione:

• 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 in 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 (5) repliche, è possibile definire un'interruzione del pod pari a 4 (quattro) per consentire l'eliminazione o la riprogrammazione di una sola replica alla volta. Come per i limiti delle risorse dei pod, è consigliabile definire 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. Creare una distribuzione definendo un file manifesto nel formato YAML.

L'esempio seguente crea una distribuzione di base del server Web NGINX. La distribuzione specifica tre (3) repliche da creare e richiede che la porta 80 sia aperta nel contenitore. Richieste e limiti relativi alle risorse sono definiti anche per la CPU e la memoria.

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 eseguirà l'immagine nginx dall'hub Docker.
.spec.replicas	Specifica il numero di pod da creare. Questo file creerà 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. Questo limite viene applicato dal kubelet.
.spec.spec.resources.limits.cpu	Specifica la quantità massima di CPU consentita. Questo limite viene applicato dal kubelet.
.spec.spec.resources.limits.memory	Specifica la quantità massima di memoria consentita. Questo limite viene applicato dal kubelet.

È possibile creare applicazioni più complesse includendo servizi (ad esempio i 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

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

• 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:

• 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 normale e sequenziale alla distribuzione, alla scalabilità, all'aggiornamento e alla 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.

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 nella risorsa di archiviazione permanente fornita da Managed Disks di Azure o File di Azure. Con StatefulSets, l'archiviazione permanente sottostante rimane, anche quando viene eliminato StatefulSet.

Per altre informazioni, vedere Oggetti StatefulSet di Kubernetes.

Le repliche in un oggetto StatefulSet sono pianificate ed eseguire su tutti i nodi disponibili in un cluster servizio Azure Kubernetes. Per assicurarsi che almeno un pod nel set venga eseguito in un nodo, usare invece un oggetto DaemonSet.

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 selezionato di nodi. È 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 in una delle prime fasi del processo di avvio del cluster, prima che sia avviata l'utilità di pianificazione predefinita di Kubernetes. Questa capacità garantisce che i pod di un oggetto DaemonSet vengono avviati prima che siano pianificati i pod tradizionali in una distribuzione o in un oggetto StatefulSet.

Come gli oggetti StatefulSet, un oggetto DaemonSet viene definito come parte di una definizione YAML usando kind: DaemonSet.

Per altre informazioni, vedere Oggetti DaemonSet di Kubernetes.

Nota

Se si usa il componente aggiuntivo Nodi virtuali, DaemonSets non creerà pod nel nodo virtuale.

Namespaces (Spazi dei nomi)

Le risorse Kubernetes, ad esempio pod e distribuzioni, vengono raggruppate logicamente in uno spazio 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 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, ma può essere usato per le risorse visibili nell'intero cluster e può essere visualizzato da qualsiasi utente.

Per altre informazioni, vedere Spazi dei nomi di Kubernetes.

Passaggi successivi

Questo articolo tratta alcuni dei componenti principali di Kubernetes descrivendo come si applicano ai cluster servizio Azure Kubernetes. 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