Preparare Linux per i volumi Edge

Articolo
11/05/2024

L'articolo descrive come preparare Linux per i volumi Edge usando il servizio Azure Kubernetes abilitato da Azure Arc, Edge Essentials o Ubuntu.

Nota

La versione minima supportata del kernel Linux è 5.1. Attualmente, esistono problemi noti con le versioni 6.4 e 6.2.

Prerequisiti

Nota

Archiviazione di Azure Container abilitato da Azure Arc è disponibile solo nelle aree seguenti: Stati Uniti orientali, Stati Uniti orientali 2, Stati Uniti occidentali, Stati Uniti occidentali 2, Stati Uniti occidentali 3, Europa settentrionale, Europa occidentale.

Disinstallare l'istanza precedente di Archiviazione di Container Azure abilitata dall'estensione Azure Arc

Se in precedenza è stata installata una versione di Archiviazione Azure Container abilitata da Azure Arc precedente alla versione2.1.0-preview, è necessario disinstallare l'istanza precedente per poter installare la versione più recente. Se hai installato la versione 1.2.0-preview o una versione precedente, usare queste istruzioni. Le versioni successive alla 2.1.0-preview sono aggiornabili e non richiedono questa disinstallazione.

Per eliminare la versione precedente dell'estensione, è necessario pulire le risorse Kubernetes che contengono riferimenti alla versione precedente dell'estensione. Eventuali risorse in sospeso possono ritardare la pulizia dell'estensione. Esistono almeno due modi per pulire queste risorse: tramite l'uso di kubectl delete <resource_type> <resource_name> oppure "annullando" l'applicazione dei file YAML usati per creare le risorse. Le risorse che devono essere eliminate sono in genere i pod, il PVC a cui si fa riferimento e il CRD del sottovolume (se è stato configurato il volume Edge di Cloud Ingest). In alternativa, i quattro file YAML seguenti possono essere passati a kubectl delete -f usando i seguenti comandi nell'ordine specificato. Queste variabili devono essere aggiornate con le informazioni personali:
- YOUR_DEPLOYMENT_FILE_NAME_HERE: aggiungere i nomi dei file di distribuzione. Nell'esempio riportato in questo articolo, il nome file usato era deploymentExample.yaml. Se sono state create più distribuzioni, ognuna di esse deve essere eliminata in una riga separata.
- YOUR_PVC_FILE_NAME_HERE: aggiungere i nomi dei file di attestazione del volume permanente. Nell'esempio riportato in questo articolo, se è stato usato il volume Edge di Cloud Ingest, il nome file usato era cloudIngestPVC.yaml. Se è stato usato il volume Edge condiviso locale, il nome file usato era localSharedPVC.yaml. Se sono stati creati più PVC, ognuno di essi deve essere eliminato in una riga separata.
- YOUR_EDGE_SUBVOLUME_FILE_NAME_HERE: aggiungere i nomi file dei sottovolumi Edge. Nell'esempio riportato in questo articolo, il nome file usato era edgeSubvolume.yaml. Se sono stati creati più sottovolumi, ognuno di essi deve essere eliminato in una riga separata.
- YOUR_EDGE_STORAGE_CONFIGURATION_FILE_NAME_HERE: aggiungere qui il nome file di configurazione dell'archiviazione Edge. Nell'esempio riportato in questo articolo, il nome file usato era edgeConfig.yaml.
```
kubectl delete -f "<YOUR_DEPLOYMENT_FILE_NAME_HERE.yaml>"
kubectl delete -f "<YOUR_PVC_FILE_NAME_HERE.yaml>"   
kubectl delete -f "<YOUR_EDGE_SUBVOLUME_FILE_NAME_HERE.yaml>"
kubectl delete -f "<YOUR_EDGE_STORAGE_CONFIGURATION_FILE_NAME_HERE.yaml>"
```
Dopo aver eliminato i file per le distribuzioni, i PVC, i sottovolumi Edge e la configurazione dell'archiviazione Edge dal passaggio precedente, è possibile disinstallare l'estensione usando il comando seguente. Sostituire YOUR_RESOURCE_GROUP_NAME_HERE, YOUR_CLUSTER_NAME_HERE e YOUR_EXTENSION_NAME_HERE con le rispettive informazioni:
```
az k8s-extension delete --resource-group YOUR_RESOURCE_GROUP_NAME_HERE --cluster-name YOUR_CLUSTER_NAME_HERE --cluster-type connectedClusters --name YOUR_EXTENSION_NAME_HERE
```

Cluster Kubernetes connesso ad Arc

Queste istruzioni presuppongono che si disponga già di un cluster Kubernetes connesso ad Arc. Per connettere un cluster Kubernetes esistente ad Azure Arc, vedere queste istruzioni.

Per usare Archiviazione Azure Container abilitato da Azure Arc con operazioni di Azure IoT, seguire le istruzioni per creare un cluster per operazioni IoT di Azure.

Cluster a nodo singolo e multinodo

Un cluster a nodo singolo viene comunemente usato a scopo di sviluppo o test grazie alla sua semplicità d’installazione e ai requisiti minimi di risorse. Questi cluster offrono agli sviluppatori un ambiente leggero e semplice per sperimentare con Kubernetes senza la complessità di una configurazione multinodo. Inoltre, in situazioni in cui risorse come CPU, memoria e archiviazione sono limitate, un cluster a nodo singolo risulta più pratico. La facilità di configurazione e i requisiti minimi delle risorse lo rendono una scelta adatta in ambienti con risorse limitate.

Tuttavia, i cluster a nodo singolo presentano delle limitazioni, per lo più dovute alla mancanza di funzionalità, tra cui la mancanza di disponibilità elevata, la tolleranza agli errori, la scalabilità e le prestazioni.

Una configurazione Kubernetes multinodo viene in genere usata per scenari di produzione, gestione temporanea o su larga scala per via di funzionalità come disponibilità elevata, tolleranza di errore, scalabilità e prestazioni. Un cluster multinodo introduce anche sfide e compromessi, tra cui considerazioni su complessità, costo generale, costi ed efficienza. Ad esempio, la configurazione e la gestione di un cluster multinodo richiedono conoscenze, competenze, strumenti e risorse aggiuntive (rete, archiviazione, calcolo). Il cluster deve gestire il coordinamento e la comunicazione tra i nodi, con conseguenti potenziali latenze ed errori. Inoltre, l'esecuzione di un cluster multinodo è più costosa rispetto a un cluster a nodo singolo. L'ottimizzazione dell'utilizzo delle risorse tra i nodi è fondamentale per mantenere l'efficienza e le prestazioni del cluster e dell'applicazione.

In sintesi, un cluster Kubernetes a nodo singolo potrebbe essere adatto per lo sviluppo, i test e gli ambienti con risorse limitate. Il cluster multinodo è più adatto alle distribuzioni di produzione, alla disponibilità elevata, alla scalabilità e agli scenari in cui le applicazioni distribuite sono un requisito. Questa scelta dipende in definitiva da esigenze e obiettivi specifici per la distribuzione.

Requisiti hardware minimi

Cluster a nodo singolo o a 2 nodi

Macchina virtuale consigliata Standard_D8ds_v5
Specifiche equivalenti per nodo:
- 4 CPU
- 16 GB di RAM

Cluster a più nodi

Macchina virtuale consigliata Standard_D8as_v5
Specifiche equivalenti per nodo:
- 8 CPU
- 32 GB di RAM

32 GB di RAM fungono da buffer; tuttavia, 16 GB di RAM dovrebbero essere sufficienti. Le configurazioni di Edge Essentials richiedono 8 CPU con 10 GB di RAM per nodo, rendendo il requisito minimo di 16 GB di RAM.

Requisiti minimi di archiviazione

Requisiti dei volumi Edge

Quando si usa l'opzione di archiviazione a tolleranza di errore, i volumi Edge allocano lo spazio su disco di un pool di archiviazione a tolleranza di errore, costituito dall'archiviazione esportato da ogni nodo del cluster.

Il pool di archiviazione è configurato per l'uso della replica a 3 vie per garantire la tolleranza di errore. Quando viene effettuato il provisioning di un volume Edge, viene allocato lo spazio su disco dal pool di archiviazione e lo spazio di archiviazione su 3 delle repliche.

Ad esempio, in un cluster a 3 nodi con 20 GB di spazio su disco per nodo, il cluster ha un pool di archiviazione di 60 GB. Tuttavia, grazie alla replica, ha una dimensione di archiviazione effettiva di 20 GB.

Quando viene effettuato il provisioning di un volume Edge con una dimensione richiesta di 10 GB, alloca un volume di sistema riservato (ridimensionato staticamente a 1 GB) e un volume dati (ridimensionato in base alle dimensioni del volume richieste, ad esempio 10 GB). Il volume di sistema riservato utilizza 3 GB (3 x 1 GB) di spazio su disco nel pool di archiviazione, mentre il volume di dati utilizza 30 GB (3 x 10 GB) di spazio su disco nel pool di archiviazione, per un totale di 33 GB.

Requisiti dei volumi della cache

I volumi della cache richiedono almeno 4 GB per nodo di archiviazione. Ad esempio, se si dispone di un cluster a 3 nodi, sono necessari almeno 12 GB di spazio di archiviazione.

Condividi tramite