Delen via

Opslagopties voor toepassingen in Azure Kubernetes Service (AKS)

  • Artikel

Toepassingen die worden uitgevoerd in Azure Kubernetes Service (AKS) moeten mogelijk gegevens opslaan en ophalen. Hoewel sommige toepassingsworkloads lokale, snelle opslag op onnodige, geleegde knooppunten kunnen gebruiken, vereisen anderen opslag die op meer reguliere gegevensvolumes binnen het Azure-platform blijft bestaan.

Mogelijk moeten meerdere pods:

  • Dezelfde gegevensvolumes delen.
  • Gegevensvolumes opnieuw koppelen als de pod opnieuw wordt gepland op een ander knooppunt.

Mogelijk moet u ook gevoelige gegevens of toepassingsconfiguratiegegevens verzamelen en opslaan in pods.

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

Diagram van opslagopties voor toepassingen in een AKS-cluster (Azure Kubernetes Services).

Standaardgrootte van besturingssysteemschijf

Wanneer u een nieuw cluster maakt of een nieuwe knooppuntgroep toevoegt aan een bestaand cluster, bepaalt het aantal vCPU's standaard de grootte van de besturingssysteemschijf. Het aantal vCPU's is gebaseerd op de VM-SKU. De volgende tabel bevat de standaardschijfgrootte van het besturingssysteem voor elke VM-SKU:

VM SKU Cores (vCPU's) Standaardlaag van besturingssysteemschijf Ingerichte IOPS Ingerichte doorvoer (Mbps)
1 - 7 P10/128G 500 100
8 - 15 P15/256G 1100 125
16 - 63 P20/512G 2300 150
64+ P30/1024G 5000 200

Belangrijk

Standaardgrootte van besturingssysteemschijven wordt alleen gebruikt op nieuwe clusters of knooppuntgroepen wanneer tijdelijke besturingssysteemschijven niet worden ondersteund en er geen standaardgrootte van de besturingssysteemschijf is opgegeven. De standaardgrootte van de besturingssysteemschijf kan van invloed zijn op de prestaties of kosten van uw cluster. U kunt de schijfgrootte van het besturingssysteem niet wijzigen nadat het cluster of de knooppuntgroep is gemaakt. Deze standaardschijfgrootte is van invloed op clusters of knooppuntgroepen die zijn gemaakt op juli 2022 of hoger.

Kortstondige besturingssysteemschijf

Standaard repliceert Azure automatisch de besturingssysteemschijf voor een virtuele machine naar Azure Storage om gegevensverlies te voorkomen wanneer de virtuele machine naar een andere host wordt verplaatst. Omdat containers echter niet zijn ontworpen om de lokale status te behouden, biedt dit gedrag een beperkte waarde en biedt dit enkele nadelen. Deze nadelen zijn onder andere, maar zijn niet beperkt tot, tragere inrichting van knooppunten en een hogere latentie voor lezen/schrijven.

Tijdelijke besturingssysteemschijven worden daarentegen alleen opgeslagen op de hostcomputer, net als een tijdelijke schijf. Met deze configuratie krijgt u een lagere latentie voor lezen/schrijven, samen met snellere schaalaanpassing van knooppunten en clusterupgrades.

Notitie

Wanneer u azure managed disks niet expliciet aanvraagt voor het besturingssysteem, wordt AKS standaard ingesteld op kortstondige besturingssystemen , indien mogelijk voor een bepaalde configuratie van een knooppuntgroep.

De groottevereisten en aanbevelingen voor tijdelijke besturingssysteemschijven zijn beschikbaar in de Documentatie voor Virtuele Azure-machines. Hier volgen enkele algemene overwegingen voor het aanpassen van de grootte:

  • Als u ervoor kiest om de standaard-VM-grootte van AKS te gebruiken Standard_DS2_v2 SKU met de standaardgrootte van de besturingssysteemschijf van 100 GiB, ondersteunt de standaard-VM-grootte tijdelijke besturingssystemen, maar heeft slechts 86 GiB van de cachegrootte. Deze configuratie wordt standaard ingesteld op beheerde schijven als u deze niet expliciet opgeeft. Als u een kortstondig besturingssysteem aanvraagt, ontvangt u een validatiefout.

  • Als u dezelfde Standard_DS2_v2 SKU aanvraagt met een 60 GiB-besturingssysteemschijf, wordt deze configuratie standaard ingesteld op kortstondige besturingssystemen. De aangevraagde grootte van 60 GiB is kleiner dan de maximale cachegrootte van 86 GiB.

  • Als u de Standard_D8s_v3 SKU met een besturingssysteemschijf van 100 GB selecteert, biedt deze VM-grootte ondersteuning voor kortstondige besturingssystemen en heeft deze 200 GiB aan cacheruimte. Als u het type besturingssysteemschijf niet opgeeft, ontvangt de knooppuntgroep standaard een kortstondig besturingssysteem.

De nieuwste generatie VM-serie heeft geen toegewezen cache, maar alleen tijdelijke opslag. Als u bijvoorbeeld de Standard_E2bds_v5 VM-grootte hebt geselecteerd met de standaardgrootte van de besturingssysteemschijf van 100 GiB, ondersteunt deze tijdelijke besturingssysteemschijven, maar slechts 75 GB tijdelijke opslag. Deze configuratie wordt standaard ingesteld op beheerde besturingssysteemschijven als u deze niet expliciet opgeeft. Als u een tijdelijke besturingssysteemschijf aanvraagt, ontvangt u een validatiefout.

  • Als u dezelfde Standard_E2bds_v5 VM-grootte aanvraagt met een 60 GiB-besturingssysteemschijf, wordt deze configuratie standaard ingesteld op tijdelijke besturingssysteemschijven. De aangevraagde grootte van 60 GiB is kleiner dan de maximale tijdelijke opslag van 75 GiB.

  • Als u Standard_E4bds_v5 SKU selecteert met een besturingssysteemschijf van 100 GiB, ondersteunt deze VM-grootte kortstondige besturingssystemen en heeft 150 GiB tijdelijke opslag. Als u het type besturingssysteemschijf niet opgeeft, richt Azure standaard een tijdelijke besturingssysteemschijf in op de knooppuntgroep.

Door klant beheerde sleutels

U kunt versleuteling voor uw tijdelijke besturingssysteemschijf beheren met uw eigen sleutels op een AKS-cluster. Zie Door klant beheerde sleutel gebruiken met Azure-schijf op AKS voor meer informatie.

Volumes

Kubernetes behandelt doorgaans afzonderlijke pods als tijdelijke, wegwerpresources. Toepassingen hebben verschillende benaderingen voor het gebruik en persistent maken van gegevens. 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.

Traditionele volumes worden gemaakt als Kubernetes-resources die worden ondersteund door Azure Storage. U kunt handmatig gegevensvolumes maken die rechtstreeks aan pods moeten worden toegewezen of kubernetes automatisch laten maken. Gegevensvolumes kunnen worden gebruikt: Azure Disk, Azure Files, Azure NetApp Files of Azure Blobs.

Notitie

Afhankelijk van de VM-SKU die u gebruikt, heeft het Azure Disk CSI-stuurprogramma mogelijk een volumelimiet per knooppunt. Voor sommige vm's met hoge prestaties (bijvoorbeeld 16 kernen) is de limiet 64 volumes per knooppunt. Als u de limiet per VM-SKU wilt identificeren, bekijkt u de kolom Max-gegevensschijven voor elke aangeboden VM-SKU. Zie De grootten van virtuele machines voor algemeen gebruik voor een lijst met aangeboden VM-SKU's en de bijbehorende gedetailleerde capaciteitslimieten.

Raadpleeg de informatie in het artikel Azure Files en Azure NetApp Files om te bepalen wat het beste past bij uw workload tussen Azure Files en Azure NetApp Files.

Azure-schijf

Gebruik Azure Disk om een Kubernetes DataDisk-resource te maken. Schijftypen zijn onder andere:

  • Premium SSD's (aanbevolen voor de meeste workloads)
  • Ultraschijven
  • Standard-SSD's
  • Standard - HDD's

Tip

Gebruik Premium SSD's voor de meeste productie- en ontwikkelingsworkloads.

Omdat een Azure-schijf is gekoppeld als ReadWriteOnce, is deze alleen beschikbaar voor één knooppunt. Gebruik Azure Files voor opslagvolumes die tegelijkertijd toegankelijk zijn voor pods op meerdere knooppunten.

Azure Files

Gebruik Azure Files om een SMB-share (Server Message Block) versie 3.1.1 of NFS-share (Network File System) versie 4.1 te koppelen. Met Azure Files kunt u gegevens delen over meerdere knooppunten en pods en kunt u het volgende gebruiken:

  • Azure Premium-opslag ondersteund door ssd's met hoge prestaties
  • Azure Standard-opslag ondersteund door reguliere HDD's

Azure NetApp Files

  • Ultra-opslag
  • Premium Storage
  • Standaardopslag

Azure Blob-opslag

Gebruik Azure Blob Storage om een blobopslagcontainer te maken en deze te koppelen met behulp van het NFS v3.0-protocol of BlobFuse.

  • Blok-blobs

Volumetypen

Kubernetes-volumes vertegenwoordigen meer dan alleen een traditionele schijf voor het opslaan en ophalen van informatie. Kubernetes-volumes kunnen ook worden gebruikt als een manier om gegevens in een pod te injecteren voor gebruik door de containers.

Algemene volumetypen in Kubernetes zijn onder andere:

emptyDir

Vaak 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. Nadat u de pod hebt verwijderd, wordt het volume verwijderd. Dit volume maakt doorgaans gebruik van de onderliggende schijfopslag voor lokale knooppunten, maar kan ook alleen bestaan in het geheugen van het knooppunt.

geheim

U kunt geheime volumes gebruiken om gevoelige gegevens in pods te injecteren, zoals wachtwoorden.

  1. Maak een geheim met behulp van de Kubernetes-API.
  2. Definieer uw pod of implementatie en vraag een specifiek geheim aan.
    • Geheimen worden alleen verstrekt aan knooppunten met een geplande pod waarvoor ze zijn vereist.
    • Het geheim wordt opgeslagen in tmpfs, niet naar schijf geschreven.
  3. Wanneer u de laatste pod op een knooppunt verwijdert waarvoor een geheim is vereist, wordt het geheim verwijderd uit de tmpfs van het knooppunt.
    • Geheimen worden opgeslagen in een bepaalde naamruimte en worden alleen geopend door pods binnen dezelfde naamruimte.

configMap

U kunt configMap gebruiken om eigenschappen van sleutel-waardepaar in pods te injecteren, zoals informatie over toepassingsconfiguratie. Definieer toepassingsconfiguratiegegevens als een Kubernetes-resource, eenvoudig bijgewerkt en toegepast op nieuwe exemplaren van pods wanneer ze worden geïmplementeerd.

Zoals het gebruik van een geheim:

  1. Maak een ConfigMap met behulp van de Kubernetes-API.
  2. Vraag de ConfigMap aan wanneer u een pod of implementatie definieert.
    • ConfigMaps worden opgeslagen in een bepaalde naamruimte en worden alleen geopend door pods binnen dezelfde naamruimte.

Permanente volumes

Volumes die zijn gedefinieerd en gemaakt als onderdeel van de levenscyclus van de pod, bestaan alleen totdat u de pod verwijdert. 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 (PV) is een opslagresource die is gemaakt en beheerd door de Kubernetes-API die kan bestaan na de levensduur van een afzonderlijke pod.

U kunt de volgende Azure Storage-gegevensservices gebruiken om het permanente volume te bieden:

Zoals vermeld in de sectie Volumes , wordt de keuze van Azure Disks of Azure Files vaak bepaald door de noodzaak van gelijktijdige toegang tot de gegevens of de prestatielaag.

Diagram van permanente volumes in een AKS-cluster (Azure Kubernetes Services).

Een clusterbeheerder kan statisch een permanent volume maken of een 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 de onderliggende Azure Disk- of File Storage maken en deze koppelen aan de pod. Dynamische inrichting maakt gebruik van een opslagklasse om te bepalen welk type resource moet worden gemaakt.

Belangrijk

Permanente volumes kunnen niet worden gedeeld door Windows- en Linux-pods vanwege verschillen in bestandssysteemondersteuning tussen de twee besturingssystemen.

Opslagklassen

Als u verschillende opslaglagen wilt opgeven, zoals Premium of Standard, kunt u een opslagklasse maken.

Een opslagklasse definieert ook een claimbeleid. Wanneer u het permanente volume verwijdert, bepaalt het claimbeleid het gedrag van de onderliggende Azure Storage-resource. De onderliggende resource kan worden verwijderd of bewaard voor gebruik met een toekomstige pod.

Voor clusters die gebruikmaken van de CSI-stuurprogramma's (Container Storage Interface) worden de volgende extra opslagklassen gemaakt:

Opslagklasse Beschrijving
managed-csi Maakt gebruik van Azure Standard SSD lokaal redundante opslag (LRS) om een beheerde schijf te maken. Het claimbeleid zorgt ervoor dat de onderliggende Azure-schijf wordt verwijderd wanneer het permanente volume dat het gebruikte volume wordt verwijderd. De opslagklasse configureert ook de permanente volumes om uit te breiden. U kunt de permanente volumeclaim bewerken om de nieuwe grootte op te geven. Vanaf Kubernetes versie 1.29, in AKS-clusters (Azure Kubernetes Service) die zijn geïmplementeerd in meerdere beschikbaarheidszones, maakt deze opslagklasse gebruik van Zone-redundante opslag (ZRS) van Azure Standard SSD om beheerde schijven te maken.
managed-csi-premium Maakt gebruik van lokaal redundante Azure Premium-opslag (LRS) om een beheerde schijf te maken. Het claimbeleid zorgt er opnieuw voor dat de onderliggende Azure-schijf wordt verwijderd wanneer het permanente volume dat het gebruikte volume wordt verwijderd. Op dezelfde manier kunt u met deze opslagklasse permanente volumes uitbreiden. Vanaf Kubernetes versie 1.29, in AKS-clusters (Azure Kubernetes Service) die zijn geïmplementeerd in meerdere beschikbaarheidszones, maakt deze opslagklasse gebruik van Azure Premium zone-redundante opslag (ZRS) om beheerde schijven te maken.
azurefile-csi Maakt gebruik van Azure Standard Storage om een Azure-bestandsshare te maken. Het claimbeleid zorgt ervoor dat de onderliggende Azure-bestandsshare wordt verwijderd wanneer het permanente volume dat deze heeft gebruikt, wordt verwijderd.
azurefile-csi-premium Maakt gebruik van Azure Premium Storage om een Azure-bestandsshare te maken. Het claimbeleid zorgt ervoor dat de onderliggende Azure-bestandsshare wordt verwijderd wanneer het permanente volume dat deze heeft gebruikt, wordt verwijderd.
azureblob-nfs-premium Maakt gebruik van Azure Premium Storage om een Azure Blob Storage-container te maken en verbinding te maken met behulp van het NFS v3-protocol. Het claimbeleid zorgt ervoor dat de onderliggende Azure Blob Storage-container wordt verwijderd wanneer het permanente volume dat deze heeft gebruikt, wordt verwijderd.
azureblob-fuse-premium Maakt gebruik van Azure Premium Storage om een Azure Blob Storage-container te maken en verbinding te maken met behulp van BlobFuse. Het claimbeleid zorgt ervoor dat de onderliggende Azure Blob Storage-container wordt verwijderd wanneer het permanente volume dat deze heeft gebruikt, wordt verwijderd.

Tenzij u een opslagklasse voor een permanent volume opgeeft, wordt de standaardopslagklasse gebruikt. Zorg ervoor dat volumes de juiste opslag gebruiken die u nodig hebt bij het aanvragen van permanente volumes.

Belangrijk

Vanaf Kubernetes versie 1.21 gebruikt AKS standaard alleen CSI-stuurprogramma's en is CSI-migratie ingeschakeld. Hoewel bestaande permanente volumes in de structuur blijven functioneren, vanaf versie 1.26, bieden AKS geen ondersteuning meer voor volumes die zijn gemaakt met stuurprogramma voor de structuur en opslag die is ingericht voor bestanden en schijven.

De default klasse is hetzelfde als managed-csi.

Vanaf Kubernetes versie 1.29, wanneer u AKS-clusters (Azure Kubernetes Service) implementeert in meerdere beschikbaarheidszones, maakt AKS nu gebruik van zone-redundante opslag (ZRS) om beheerde schijven te maken binnen ingebouwde opslagklassen. ZRS zorgt voor synchrone replicatie van uw door Azure beheerde schijven in meerdere Azure-beschikbaarheidszones in uw gekozen regio. Deze redundantiestrategie verbetert de tolerantie van uw toepassingen en beschermt uw gegevens tegen datacenterfouten.

Het is echter belangrijk om te weten dat zone-redundante opslag (ZRS) een hogere kosten heeft ten opzichte van lokaal redundante opslag (LRS). Als kostenoptimalisatie een prioriteit is, kunt u een nieuwe opslagklasse maken met de skuname parameter die is ingesteld op LRS. Vervolgens kunt u de nieuwe opslagklasse gebruiken in uw Persistent Volume Claim (PVC).

U kunt een opslagklasse maken voor andere behoeften met behulp van kubectl. In het volgende voorbeeld worden premium beheerde schijven gebruikt en wordt aangegeven dat de onderliggende Azure-schijf moet worden bewaard wanneer u de pod verwijdert:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: managed-premium-retain
provisioner: disk.csi.azure.com
parameters:
  skuName: Premium_ZRS
reclaimPolicy: Retain
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

Notitie

AKS afstemmen de standaardopslagklassen en overschrijft eventuele wijzigingen die u aanbrengt in deze opslagklassen.

Zie StorageClass in Kubernetes voor meer informatie over opslagklassen.

Claims voor permanente volumes

Een permanente volumeclaim (PVC) vraagt om opslag van een bepaalde opslagklasse, toegangsmodus en grootte. De Kubernetes-API-server kan de onderliggende Azure Storage-resource dynamisch inrichten als er geen bestaande resource aan de claim kan voldoen op basis van de gedefinieerde opslagklasse.

De poddefinitie bevat de volumekoppeling zodra het volume is verbonden met de pod.

Diagram van permanente volumeclaims in een AKS-cluster (Azure Kubernetes Services).

Zodra een beschikbare opslagresource is toegewezen aan de pod die opslag aanvraagt, is het permanente volume gebonden aan een permanente volumeclaim. Permanente volumes worden toegewezen aan claims in een toewijzing van 1:1.

In het volgende voorbeeld van het YAML-manifest wordt een permanente volumeclaim weergegeven die gebruikmaakt van de beheerde Premium-opslagklasse en een Azure-schijf aanvraagt die 5Gi groot is:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: azure-managed-disk
spec:
  accessModes:
  - ReadWriteOnce
  storageClassName: managed-premium-retain
  resources:
    requests:
      storage: 5Gi

Wanneer u een poddefinitie maakt, geeft u ook het volgende op:

  • De permanente volumeclaim om de gewenste opslag aan te vragen.
  • De volumekoppeling voor uw toepassingen voor het lezen en schrijven van gegevens.

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/azure:

kind: Pod
apiVersion: v1
metadata:
  name: nginx
spec:
  containers:
    - name: myfrontend
      image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
      volumeMounts:
      - mountPath: "/mnt/azure"
        name: volume
  volumes:
    - name: volume
      persistentVolumeClaim:
        claimName: azure-managed-disk

Geef de stationsletter en het pad op voor het koppelen van een volume in een Windows-container. Voorbeeld:

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

Volgende stappen

Zie Best practices voor opslag en back-ups in AKS- en AKS-opslagoverwegingen voor de bijbehorende aanbevolen procedures.

Als u wilt zien hoe u CSI-stuurprogramma's gebruikt, raadpleegt u de volgende artikelen:

Zie de volgende artikelen voor meer informatie over de belangrijkste Kubernetes- en AKS-concepten: