Delen via

Opslagopties voor toepassingen in AKS ingeschakeld door Azure Arc

Van toepassing op: AKS in Azure Local

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.

Afbeelding van architectuur-opslag waarop een cluster master en node te zien zijn.

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

  • Volumina
  • Permanente volumes
  • Opslagklassen
  • Permanente volumeverzoeken (PVC)

Volumina

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 te behouden over pods en gedurende de levenscyclus van de applicatie.

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

  • emptyDir : dit volume wordt meestal gebruikt als tijdelijke ruimte voor een pod. Alle containers binnen een pod kunnen toegang krijgen 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 deze vereist, en het geheim wordt opgeslagen in tmpfs en niet naar de schijf geschreven. Wanneer de laatste pod op een node die een geheim vereist wordt verwijderd, wordt het geheim verwijderd uit de tmpfs van de node. 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 tijdens onderhoud opnieuw wordt toegewezen aan een andere host, vooral 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 opslagbron kan worden verwijderd of behouden 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 terugbrengbeleid zorgt ervoor dat de onderliggende VHDX wordt verwijderd wanneer het permanente volume dat daarvan gebruikmaakte 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.

Blijvende volumeverzoeken

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 omvat de volumebevestiging zodra het volume aan de pod is gekoppeld.

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 voor 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

Het volgende voorbeeld laat zien hoe u een volume in een Windows-container koppelt en de stationsletter en het pad specificeert:

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

Toegang tot gekoppelde volumes beveiligen

Om uw toepassingen correct uit te voeren, moeten pods worden uitgevoerd als een gedefinieerde gebruiker of groep en niet als root. In het securityContext geval van een pod of container kunt u instellingen zoals fsGroup definiëren om de juiste machtigingen voor de gekoppelde volumes te gebruiken.

fsGroup is een veld binnen de securityContext kubernetes-podspecificatie. Het definieert een aanvullende groeps-id die Kubernetes toewijst aan alle processen in de pod en recursief aan de bestanden in gekoppelde volumes. Dit zorgt ervoor dat de pod de juiste toegang op groepsniveau heeft tot gedeelde opslagvolumes.

Wanneer een volume is gekoppeld, wijzigt Kubernetes het eigendom van de inhoud van het volume zodat deze overeenkomt met de fsGroup-waarde . Dit is met name handig wanneer containers worden uitgevoerd als niet-hoofdgebruikers en schrijftoegang nodig hebben tot gedeelde volumes.

In het volgende voorbeeld van YAML wordt de fsgroup-waarde weergegeven:

securityContext:
  fsGroup: 2000

In dit voorbeeld zijn alle bestanden in gekoppelde volumes toegankelijk voor GID 2000.

Volgende stappen