Opslagopties voor toepassingen in AKS ingeschakeld door Azure Arc

Van toepassing op: AKS in Azure Local 22H2, AKS op Windows Server

Toepassingen die worden uitgevoerd in AKS-implementaties met behulp van Azure Kubernetes Service waarvoor Azure Arc is ingeschakeld, moeten mogelijk gegevens opslaan en ophalen. Voor sommige toepassingsworkloads kunnen de gegevens lokale, snelle opslag op een overbodig knooppunt gebruiken wanneer de pods worden verwijderd (Kubernetes maakt gebruik van pods om een exemplaar van een toepassing uit te voeren).

Voor andere workloads is mogelijk opslag vereist die op meer reguliere gegevensvolumes wordt bewaard. Meerdere pods moeten mogelijk dezelfde gegevensvolumes delen of gegevensvolumes opnieuw koppelen als de pod opnieuw wordt gepland op een ander knooppunt. Mogelijk hebt u ook een opslagoptie nodig als de pods gevoelige gegevens of toepassingsconfiguratiegegevens bevatten.

In dit artikel worden de belangrijkste concepten geïntroduceerd die opslag bieden aan uw toepassingen in AKS Arc, waaronder:

• Volumes
• Permanente volumes
• Opslagklassen
• Permanente volumeclaims (PVC)

Volumes

Toepassingen moeten vaak gegevens kunnen opslaan en ophalen. Omdat Kubernetes doorgaans afzonderlijke pods behandelt als tijdelijke, wegwerpbronnen, zijn er verschillende benaderingen beschikbaar voor toepassingen die gegevens kunnen gebruiken en behouden. Een volume vertegenwoordigt een manier om gegevens op te slaan, op te halen en op te slaan in pods en gedurende de levenscyclus van de toepassing.

In Kubernetes kunnen volumes meer vertegenwoordigen dan alleen een traditionele gegevens die worden opgeslagen en opgehaald. Kubernetes-volumes kunnen ook worden gebruikt als een manier om gegevens in te voegen in een pod die containers kunnen gebruiken. Enkele veelvoorkomende Kubernetes-volumetypen zijn:

• emptyDir : dit volume wordt meestal gebruikt als tijdelijke ruimte voor een pod. Alle containers in een pod hebben toegang tot de gegevens op het volume. Gegevens die naar dit volumetype worden geschreven, blijven alleen behouden voor de levensduur van de pod. Wanneer de pod wordt verwijderd, wordt het volume verwijderd. Dit volume maakt doorgaans gebruik van de onderliggende schijfopslag voor lokale knooppunten, hoewel het ook alleen in het geheugen van het knooppunt kan bestaan.

• secret : dit volume wordt gebruikt voor het opnemen van gevoelige gegevens, zoals wachtwoorden, in pods. Eerst maakt u een geheim met behulp van de Kubernetes-API. Wanneer u uw pod of implementatie definieert, kunt u een specifiek geheim aanvragen. Geheimen worden alleen verstrekt aan knooppunten met een geplande pod die dit vereist en het geheim wordt opgeslagen in tmpfs, niet naar schijf geschreven. Wanneer de laatste pod op een knooppunt waarvoor een geheim is vereist, wordt het geheim verwijderd uit de tmpfs van het knooppunt. Geheimen worden opgeslagen in een bepaalde naamruimte en kunnen alleen worden geopend door pods binnen dezelfde naamruimte.

• configMap : dit volumetype wordt gebruikt om eigenschappen van sleutel-waardepaar in pods te injecteren, zoals informatie over toepassingsconfiguratie. In plaats van toepassingsconfiguratiegegevens in een containerinstallatiekopie te definiëren, kunt u deze definiëren als een Kubernetes-resource die eenvoudig kan worden bijgewerkt en toegepast op nieuwe exemplaren van pods wanneer ze worden geïmplementeerd. Net als bij het gebruik van een geheim maakt u eerst een ConfigMap met behulp van de Kubernetes-API. Deze ConfigMap kan vervolgens worden aangevraagd wanneer u een pod of implementatie definieert. ConfigMaps worden opgeslagen in een bepaalde naamruimte en kunnen alleen worden geopend door pods binnen dezelfde naamruimte.

Permanente volumes

Volumes die zijn gedefinieerd en gemaakt als onderdeel van de levenscyclus van de pod, bestaan pas nadat de pod is verwijderd. Pods verwachten vaak dat hun opslag behouden blijft als een pod opnieuw wordt gepland op een andere host tijdens een onderhoudsevenement, met name in StatefulSets. Een permanent volume is een opslagresource die is gemaakt en beheerd door de Kubernetes-API die kan bestaan na de levensduur van een afzonderlijke pod.

U kunt AKS-schijfvolumes gebruiken die worden ondersteund door VHDX die zijn gekoppeld als ReadWriteOnce en toegankelijk zijn voor één knooppunt tegelijk. U kunt ook AKS-bestandsvolumes gebruiken die worden ondersteund door SMB- of NFS-bestandsshares. Deze zijn gekoppeld als ReadWriteMany en zijn gelijktijdig beschikbaar voor meerdere knooppunten.

Een clusterbeheerder kan statisch een permanent volume maken of het volume kan dynamisch worden gemaakt door de Kubernetes-API-server. Als een pod is gepland en opslag aanvraagt die momenteel niet beschikbaar is, kan Kubernetes het onderliggende VHDX-bestand maken en deze vervolgens aan de pod koppelen. Dynamische inrichting maakt gebruik van een StorageClass om te bepalen welk type opslag moet worden gemaakt.

Opslagklassen

Als u verschillende lagen (en locatie) van opslag wilt definiëren, kunt u een StorageClass maken. De StorageClass definieert ook de reclaimPolicy. Deze reclaimPolicy bepaalt het gedrag van de onderliggende opslagresource wanneer de pod wordt verwijderd en het permanente volume mogelijk niet meer vereist is. De onderliggende opslagresource kan worden verwijderd of bewaard voor gebruik met een toekomstige pod.

In AKS Arc wordt de standaardopslagklasse automatisch gemaakt en wordt CSV gebruikt om volumes met VHDX-ondersteuning te maken. Het claimbeleid zorgt ervoor dat de onderliggende VHDX wordt verwijderd wanneer het permanente volume dat het gebruikte volume wordt verwijderd. De opslagklasse configureert ook de permanente volumes die kunnen worden uitgebreid, dus u hoeft alleen de permanente volumeclaim te bewerken met de nieuwe grootte.

Als er geen StorageClass is opgegeven voor een permanent volume, wordt de standaardOpslagklasse gebruikt. Wanneer u permanente volumes aanvraagt, moet u ervoor zorgen dat deze de juiste opslag gebruiken. U kunt een StorageClass maken voor aanvullende behoeften.

Claims voor permanente volumes

Een PersistentVolumeClaim vraagt ReadWriteOnce - of ReadWriteMany-opslag van een bepaalde StorageClass en grootte aan. De Kubernetes-API-server kan de onderliggende opslagresource dynamisch inrichten in AKS Arc als er geen bestaande resource is om aan de claim te voldoen op basis van de gedefinieerde StorageClass. De poddefinitie bevat de volumekoppeling zodra het volume is verbonden met de pod.

Een PersistentVolume is gebonden aan een PersistentVolumeClaim zodra een beschikbare opslagresource is toegewezen aan de pod die deze aanvraagt. Er is een 1:1-toewijzing van permanente volumes aan claims.

In het volgende voorbeeld van het YAML-manifest wordt een permanente volumeclaim weergegeven die gebruikmaakt van de standaardopslagklasse en een 5Gi-schijf aanvraagt:

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

Wanneer u een poddefinitie maakt, geeft u de permanente volumeclaim op om de gewenste opslag aan te vragen. Vervolgens geeft u de volumeMount voor uw toepassingen op om gegevens te lezen en te schrijven. In het volgende voorbeeld van het YAML-manifest ziet u hoe de vorige permanente volumeclaim kan worden gebruikt om een volume te koppelen op /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 

In het volgende voorbeeld ziet u hoe u een volume in een Windows-container koppelt en de stationsletter en het pad opgeeft:

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

Volgende stappen

• Gebruik de AKS in CSI-stuurprogramma's (Container Storage Interface) van Azure Local Disk.