Condividi tramite


Opzioni di archiviazione per le applicazioni nel servizio Azure Kubernetes abilitate da Azure Arc

Si applica a: Servizio Azure Kubernetes in Azure Stack HCI 22H2, servizio Azure Kubernetes in Windows Server

Le applicazioni eseguite nelle distribuzioni del servizio Azure Kubernetes usando servizio Azure Kubernetes abilitate da Azure Arc potrebbero dover archiviare e recuperare i dati. Per alcuni carichi di lavoro dell'applicazione, i dati possono usare l'archiviazione locale e veloce in un nodo non necessario quando i pod vengono eliminati (Kubernetes usa i pod per eseguire un'istanza di un'applicazione).

Altri carichi di lavoro potrebbero richiedere l'archiviazione che persiste in volumi di dati più normali. È possibile che più pod debbano condividere gli stessi volumi di dati o ricollegare i volumi di dati se il pod viene riprogrammato in un nodo diverso. Potrebbe anche essere necessaria un'opzione di archiviazione se i pod contengono dati sensibili o informazioni di configurazione dell'applicazione.

Immagine di archiviazione dell'architettura che mostra un master e un nodo del cluster.

Questo articolo presenta i concetti di base che forniscono l'archiviazione alle applicazioni in AKS Arc, tra cui:

  • Volumi
  • Volumi permanenti
  • Classi di archiviazione
  • Attestazioni di volume persistente (PVC)

Volumi

Le applicazioni devono spesso essere in grado di archiviare e recuperare dati. Poiché Kubernetes considera in genere singoli pod come risorse temporanee, eliminabili, sono disponibili approcci diversi per le applicazioni per usare e rendere persistenti i dati. Un volume rappresenta un modo per archiviare, recuperare e salvare i dati tra i pod e per l'intero ciclo di vita dell'applicazione.

In Kubernetes i volumi possono rappresentare più di una tradizionale in cui vengono archiviate e recuperate le informazioni. I volumi Kubernetes possono essere usati anche come modo per inserire dati in un pod da usare per i contenitori. Alcuni tipi di volumi Kubernetes comuni includono:

  • emptyDir - Questo volume viene comunemente usato come spazio temporaneo per un pod. Tutti i contenitori all'interno di un pod possono accedere ai dati nel volume. I dati scritti in questo tipo di volume rimangono disponibili solo per il ciclo di vita del pod. Quando viene eliminato il pod, viene eliminato anche il volume. Questo volume usa in genere l'archiviazione su disco del nodo locale sottostante, anche se può esistere esclusivamente nella memoria del nodo.

  • secret : questo volume viene usato per includere dati sensibili, ad esempio password, in pod. Prima di tutto, si crea un segreto usando l'API Kubernetes. Quando si definisce il pod o la distribuzione, è possibile richiedere un segreto specifico. I segreti vengono forniti solo ai nodi con un pod pianificato che lo richiede e il segreto viene archiviato in tmpfs, non scritto su disco. Quando l'ultimo pod in un nodo che richiede un segreto viene eliminato, il segreto viene eliminato dal tmpfs del nodo. I segreti vengono archiviati all'interno di un determinato spazio dei nomi e sono accessibili solo dai pod all'interno dello stesso spazio dei nomi.

  • configMap - Questo tipo di volume viene usato per inserire le proprietà di coppie chiave-valore nei pod, ad esempio le informazioni di configurazione dell'applicazione. Anziché definire le informazioni di configurazione dell'applicazione all'interno di un'immagine del contenitore, è possibile definirla come risorsa Kubernetes che può essere facilmente aggiornata e applicata alle nuove istanze di pod durante la distribuzione. Analogamente all'uso di un segreto, creare prima un oggetto ConfigMap usando l'API Kubernetes. Questo ConfigMap può quindi essere richiesto quando si definisce un pod o una distribuzione. Gli oggetti ConfigMap vengono archiviati all'interno di uno spazio dei nomi specificato e possono essere accessibili solo dai pod all'interno dello stesso spazio dei nomi.

Volumi permanenti

I volumi definiti e creati nell'ambito del ciclo di vita del pod esistono solo finché non viene eliminato il pod. I pod si aspettano in genere che le rispettive risorse di archiviazione rimangano disponibili se un pod viene ripianificato su un host diverso durante un evento di manutenzione, in particolare in StatefulSets. Un volume permanente è una risorsa di archiviazione creata e gestita dall'API di Kubernetes che può esistere oltre la durata di un singolo pod.

È possibile usare volumi di dischi del servizio Azure Kubernetes supportati da VHDX montati come ReadWriteOnce e accessibili a un singolo nodo alla volta. In alternativa, è possibile usare volumi di file del servizio Azure Kubernetes supportati da condivisioni file SMB o NFS. Questi vengono montati come ReadWriteMany e sono disponibili per più nodi contemporaneamente.

Un amministratore del cluster può creare in modo statico un volume permanente oppure il volume può essere creato dinamicamente dal server API Kubernetes. Se un pod è pianificato e richiede l'archiviazione non attualmente disponibile, Kubernetes può creare il file VHDX sottostante e quindi collegarlo al pod. Il provisioning dinamico usa storageClass per identificare il tipo di archiviazione da creare.

Classi di archiviazione

Per definire livelli diversi (e posizione) di archiviazione, è possibile creare una StorageClass. StorageClass definisce anche l'oggetto reclaimPolicy. Questo metodo reclaimPolicy controlla il comportamento della risorsa di archiviazione sottostante quando il pod viene eliminato e il volume permanente potrebbe non essere più necessario. La risorsa di archiviazione sottostante può essere eliminata o mantenuta per l'uso con un pod futuro.

In AKS Arc la classe di archiviazione predefinita viene creata automaticamente e usa CSV per creare volumi supportati da VHDX. Il criterio di recupero garantisce che il VHDX sottostante venga eliminato quando viene eliminato il volume permanente usato. La classe di archiviazione configura anche i volumi persistenti in modo che siano espandibili, quindi è sufficiente modificare l'attestazione del volume permanente con le nuove dimensioni.

Se per un volume permanente non viene specificato alcun oggetto StorageClass, viene usato l'oggetto StorageClass predefinito. Quando si richiedono volumi permanenti, assicurarsi di usare l'archiviazione appropriata. È possibile creare un oggetto StorageClass per esigenze aggiuntive.

Attestazioni di volume permanente

Un oggetto PersistentVolumeClaim richiede l'archiviazione ReadWriteOnce o ReadWriteMany di una determinata storageClass e dimensioni. Il server API Kubernetes può effettuare in modo dinamico il provisioning della risorsa di archiviazione sottostante in AKS Arc se non esiste alcuna risorsa esistente per soddisfare l'attestazione basata su StorageClass definito. La definizione del pod include il montaggio del volume dopo la connessione del volume al pod.

Un oggetto PersistentVolume è associato a un oggetto PersistentVolumeClaim dopo l'assegnazione di una risorsa di archiviazione disponibile al pod che lo richiede. Esiste un mapping 1:1 tra volumi permanenti e attestazioni.

Il manifesto YAML di esempio seguente mostra un'attestazione di volume permanente che usa l'oggetto StorageClass predefinito e richiede un disco 5Gi:

apiVersion: v1 
kind: PersistentVolumeClaim 
metadata: 
  name: aks-hci-vhdx 
spec: 
  accessModes: 
  - ReadWriteOnce 
  storageClassName: default 
  resources: 
    requests: 
      storage: 5Gi 

Quando si crea una definizione di pod, si specifica l'attestazione del volume permanente per richiedere l'archiviazione desiderata. È anche possibile specificare per le applicazioni la volumeMount lettura e la scrittura dei dati. Il manifesto YAML di esempio seguente mostra come usare l'attestazione del volume persistente precedente per montare un volume in /mnt/aks-hci:

kind: Pod 
apiVersion: v1 
metadata: 
  name: nginx 
spec: 
  containers: 
    - name: myfrontend 
      image: k8s.gcr.io/nginx 
      volumeMounts: 
      - mountPath: "/mnt/aks-hci" 
        name: volume
  nodeSelector:
      kubernetes.io/os: linux
  volumes: 
    - name: volume 
      persistentVolumeClaim: 
        claimName: aks-hci-vhdx 

L'esempio seguente illustra come montare un volume in un contenitore di Windows e specificare la lettera e il percorso dell'unità:

volumeMounts: 
        - mountPath: "d:" 
          name: volume 
        - mountPath: "c:\k" 
          name: k-dir 

Passaggi successivi