Delen via

Opslagopties voor een Kubernetes-cluster

  • Artikel

In dit artikel worden de opslagmogelijkheden van Amazon Elastic Kubernetes Service (Amazon EKS) en Azure Kubernetes Service (AKS) vergeleken en worden de opties beschreven voor het opslaan van workloadgegevens in AKS.

Notitie

Dit artikel maakt deel uit van een reeks artikelen die professionals helpen die bekend zijn met Amazon EKS om inzicht te krijgen in Azure Kubernetes Service (AKS).

Opties voor Amazon EKS-opslag

Bij het uitvoeren van toepassingen waarvoor gegevensopslag is vereist, biedt Amazon EKS verschillende typen volumes voor zowel tijdelijke als langdurige opslag.

Tijdelijke volumes

Voor toepassingen waarvoor tijdelijke lokale volumes nodig zijn, maar die na het opnieuw opstarten geen gegevens hoeven te behouden, kunnen tijdelijke volumes worden gebruikt. Kubernetes ondersteunt verschillende typen kortstondige volumes, zoals emptyDir, configMap, downwardAPI, secreten hostpath. Om kostenefficiëntie en prestaties te garanderen, is het belangrijk om het meest geschikte hostvolume te kiezen. In Amazon EKS kunt u gp3 als hosthoofdvolume gebruiken, dat lagere prijzen biedt in vergelijking met gp2-volumes.

Een andere optie voor tijdelijke volumes is Amazon EC2-exemplaaropslag, die tijdelijke opslag op blokniveau bieden voor EC2-exemplaren. Deze volumes zijn fysiek gekoppeld aan de hosts en bestaan alleen tijdens de levensduur van de instantie. Voor het gebruik van lokale opslagvolumes in Kubernetes is partitionering, configuratie en opmaak van de schijven vereist met behulp van Amazon EC2-gebruikersgegevens.

Permanente volumes

Kubernetes is doorgaans gekoppeld aan het uitvoeren van stateless toepassingen, maar er zijn gevallen waarin permanente gegevensopslag vereist is. Kubernetes Persistente Volumes (PVs) kunnen worden gebruikt om gegevens onafhankelijk van pods op te slaan, zodat de gegevens behouden blijven na de levensduur van een gegeven pod. Amazon EKS ondersteunt verschillende soorten opslagopties voor tv's, waaronder Amazon EBS-, Amazon EFS-, Amazon FSx voor Lustreen Amazon FSx voor NetApp ONTAP.

Amazon EBS volumes zijn geschikt voor opslag op blokniveau en zijn geschikt voor databases en doorvoerintensieve toepassingen. Amazon EKS-gebruikers kunnen gebruikmaken van de nieuwste generatie blokopslag gp3- voor een balans tussen prijs en prestaties. Voor hoogpresterende toepassingen kunnen io2 block express-volumes worden gebruikt.

Amazon EFS- is een serverloos, elastisch bestandssysteem dat kan worden gedeeld tussen meerdere containers en knooppunten. Het groeit automatisch en verkleint wanneer bestanden worden toegevoegd of verwijderd, waardoor capaciteitsplanning niet meer nodig is. Het CSI-stuurprogramma (Amazon Elastic File System Container Storage Interface) wordt gebruikt om Amazon EFS te integreren met Kubernetes.

Amazon FSx voor Lustre- biedt hoogwaardige parallelle bestandsopslag, ideaal voor scenario's met hoge doorvoer en lage latentie. Het kan worden gekoppeld aan een Amazon S3-gegevensopslagplaats om grote gegevenssets op te slaan. Amazon FSx voor NetApp ONTAP is een volledig beheerde oplossing voor gedeelde opslag die is gebouwd op het ONTAP-bestandssysteem van NetApp.

Amazon EKS-gebruikers kunnen gebruikmaken van hulpprogramma's zoals AWS Compute Optimizer en Velero- om opslagconfiguraties te optimaliseren en back-ups en momentopnamen te beheren.

AKS-opslagopties

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 het volgende doen:

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

In dit artikel worden de opslagopties en kernconcepten geïntroduceerd die opslag bieden aan uw toepassingen in AKS.

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 EmptyDirs, Secreten ConfigMaps.

EmptyDirs

Voor een pod die een emptyDir volume definieert, wordt het volume gemaakt wanneer de pod wordt toegewezen aan een knooppunt. Zoals de naam al aangeeft, is het emptyDir volume in eerste instantie leeg. Alle containers in de pod kunnen dezelfde bestanden in het emptyDir volume lezen en schrijven, hoewel dit volume kan worden gekoppeld aan dezelfde of verschillende paden in elke container. Wanneer een pod om welke reden dan ook uit een knooppunt wordt verwijderd, worden de gegevens in de emptyDir permanent verwijderd.

Geheimen

Een Secret is een object dat een kleine hoeveelheid gevoelige gegevens bevat, zoals een wachtwoord, token of sleutel. Deze informatie zou anderszins worden opgenomen in een podspecificatie of containerafbeelding. Door een geheim te gebruiken, voorkomt u dat vertrouwelijke gegevens rechtstreeks in uw toepassingscode worden ingesloten. Omdat Secrets onafhankelijk van de pods kunnen worden aangemaakt die ze gebruiken, bestaat er een verminderd risico dat de Secret (en de bijbehorende gegevens) wordt blootgesteld tijdens de processen van het maken, bekijken en bewerken van pods. Kubernetes kan, samen met de toepassingen die in uw cluster worden uitgevoerd, ook extra voorzorgsmaatregelen nemen met Geheimen, zoals voorkomen dat gevoelige gegevens naar niet-compatibele opslag worden geschreven. Geheimen zijn vergelijkbaar met ConfigMaps, maar ze zijn speciaal ontworpen om vertrouwelijke gegevens op te slaan.

U kunt Geheimen gebruiken voor de volgende doeleinden:

Het Kubernetes-besturingsvlak maakt ook gebruik van Geheimen, zoals bootstraptokengeheimen. Dit is een mechanisme om de registratie van knooppunten te automatiseren.

ConfigMaps

Een ConfigMap- is een Kubernetes-object dat wordt gebruikt voor het opslaan van niet-vertrouwelijke gegevens in sleutel-waardeparen. Pods kunnen ConfigMaps gebruiken als omgevingsvariabelen, als opdrachtregelargumenten of als configuratiebestanden in een volume. Met een ConfigMap kunt u omgevingsspecifieke configuratie loskoppelen van uw containerinstallatiekopieën, zodat uw toepassingen eenvoudig overdraagbaar zijn.

ConfigMap biedt geen geheimhouding of versleuteling. Als de gegevens die u wilt opslaan vertrouwelijk zijn, gebruikt u een Secret in plaats van een ConfigMap, of gebruikt u aanvullende (externe) hulpprogramma's om uw gegevens privé te houden.

U kunt een ConfigMap gebruiken om configuratiegegevens afzonderlijk van toepassingscode in te stellen. Stel dat u een toepassing ontwikkelt die u kunt uitvoeren op uw eigen computer (voor ontwikkeling) en in de cloud (om echt verkeer te verwerken). U schrijft de code om te zoeken in een omgevingsvariabele met de naam DATABASE_HOST. Lokaal stelt u die variabele in op localhost. In de cloud stelt u deze in om te verwijzen naar een Kubernetes Service die het databaseonderdeel beschikbaar maakt voor uw cluster. Hiermee kunt u een containerimage ophalen die in de cloud wordt uitgevoerd en indien nodig de exact dezelfde code lokaal debuggen.

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 tijdens een onderhoudsactiviteit herplaatst wordt op een andere host, met name in StatefulSets. Een persistent volume (PV) is een opslagresource die is gemaakt en beheerd door de Kubernetes-API en die langer kan bestaan dan de levensduur van een individuele pod. U kunt de volgende Azure Storage-services 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 dynamisch 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.

Als u een volledig beheerde oplossing wilt voor toegang op blokniveau tot gegevens, kunt u overwegen om Azure Container Storage- te gebruiken in plaats van CSI-stuurprogramma's. Azure Container Storage kan worden geïntegreerd met Kubernetes, waardoor permanente volumes dynamisch en automatisch kunnen worden ingericht. Azure Container Storage ondersteunt Azure Disks, Volatiele schijven en Azure Elastic SAN (preview) als onderliggende opslag en biedt flexibiliteit en schaalbaarheid voor stateful toepassingen die worden uitgevoerd op Kubernetes-clusters.

Opslagklassen

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

Een opslagklasse definieert ook een vrijmaakbeleid voor . 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 Azure Container Storage-, ziet u een extra opslagklasse met de naam acstor-<storage-pool-name>. Er wordt ook een interne opslagklasse gemaakt.

Voor clusters die gebruikmaken van 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 garandeert dat de onderliggende Azure-schijf wordt verwijderd wanneer het permanente volume dat het gebruikte wordt verwijderd. De opslagklasse configureert ook de permanente volumes zodat ze uitbreidbaar zijn. 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.

Belangrijke: Vanaf Kubernetes versie 1.21 gebruikt AKS standaard CSI-stuurprogramma's en is CSI-migratie ingeschakeld. Hoewel bestaande in-tree permanente volumes blijven functioneren, zal AKS vanaf versie 1.26 geen ondersteuning meer bieden voor volumes die zijn gemaakt met de in-tree driver 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 parameter skuname 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 opgegeven 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

Houd er rekening mee dat AKS de standaardopslagklassen afschrijft en eventuele wijzigingen die u aanbrengt in deze opslagklassen overschrijft.

Zie StorageClass in Kubernetesvoor meer informatie over opslagklassen.

Permanente volumeverzoeken

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 omvat de koppeling van het volume zodra het met de pod is verbonden.

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

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

In het volgende YAML-manifest ziet u een permanente volumeclaim 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 zodat uw toepassingen gegevens kunnen lezen en schrijven.

In het volgende voorbeeld van het YAML-manifest ziet u hoe de vorige persistent 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. Bijvoorbeeld:

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

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.

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 van Azure VM. 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 deze slechts 86 GiB-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 een tijdelijke besturingssysteemconfiguratie. De aangevraagde grootte van 60 GiB is kleiner dan de maximale cachegrootte van 86 GiB.
  • Als u de Standard_D8s_v3 SKU selecteert met een besturingssysteemschijf van 100 GB, ondersteunt deze VM-grootte kortstondige besturingssystemen en heeft deze 200 GiB-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 standaardschijfgrootte 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 besturingssysteemschijf van 60 GiB, 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 met een besturingssysteemschijf van 100 GiB selecteert, biedt deze VM-grootte ondersteuning voor kortstondige besturingssystemen en heeft deze 150 GiB tijdelijke opslag. Als u het type besturingssysteemschijf niet opgeeft, richt Azure standaard een tijdelijke besturingssysteemschijf in op de knooppuntgroep.

Door de 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 AKSvoor 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 te bewaren binnen 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 gebruikmaken van: Azure Disk, Azure Files, Azure NetApp Filesof 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, raadpleegt u de kolom Maximum aantal gegevensschijven voor elke aangeboden VM-SKU. Zie Grootten van virtuele machines voor algemeen gebruikvoor een lijst met aangeboden VM-SKU's en de bijbehorende gedetailleerde capaciteitslimieten.

Raadpleeg de informatie in het artikel Vergelijking van Azure Files en Azure NetApp Filesom te bepalen welk van deze het beste bij uw workload past.

Azure Disk

Standaard wordt een AKS-cluster geleverd met vooraf gemaakte managed-csi en managed-csi-premium opslagklassen die gebruikmaken van Schijfopslag. Net als bij Amazon EBS maken deze klassen een beheerde schijf of blokkeren ze het apparaat dat is gekoppeld aan het knooppunt voor podtoegang.

Met de schijfklassen kunnen zowel statisch als dynamisch volume worden ingericht. Het beleid voor vrijmaken zorgt ervoor dat de schijf wordt verwijderd met het permanente volume. U kunt de schijf uitbreiden door de permanente volumeclaim te bewerken.

Deze opslagklassen maken gebruik van Azure Managed Disks met lokaal redundante opslag (LRS). LRS betekent dat de gegevens drie synchrone kopieën hebben binnen één fysieke locatie in een primaire Azure-regio. LRS is de minst dure replicatieoptie, maar biedt geen bescherming tegen een storing in een datacenter. U kunt aangepaste opslagklassen definiëren die gebruikmaken van zone-redundante opslag (ZRS) beheerde schijven. Met zone-redundante opslag (ZRS) wordt uw beheerde Azure-schijf synchroon gerepliceerd in drie Azure-beschikbaarheidszones in de regio die u selecteert. Elke beschikbaarheidszone is een afzonderlijke fysieke locatie met onafhankelijke voeding, koeling en netwerken. ZRS-schijven bieden ten minste 99,999999999999% (12 9's) duurzaamheid gedurende een bepaald jaar. Een door ZRS beheerde schijf kan worden gekoppeld door een virtuele machine in een andere beschikbaarheidszone. ZRS-schijven zijn momenteel niet beschikbaar in alle Azure-regio's. Zie de optie Zone Redundant Storage (ZRS) voor Azure Disks voor hoge beschikbaarheidvoor meer informatie over ZRS-schijven. Daarnaast kunt u, om het risico op gegevensverlies te beperken, regelmatig back-ups of momentopnamen van Schijfopslaggegevens maken met behulp van Azure Kubernetes Service Backup- of oplossingen van derden, zoals Velero- of Azure Backup- die ingebouwde momentopnametechnologieën kunnen gebruiken.

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

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 Premium SSD v2-schijven

Azure Premium SSD v2-schijven bieden IO-intensieve bedrijfsworkloads , een consistente schijflatentie van submilliseconden en hoge IOPS en doorvoer. De prestaties (capaciteit, doorvoer en IOPS) van Premium SSD v2-schijven kunnen onafhankelijk van elkaar worden geconfigureerd, waardoor het eenvoudiger is voor meer scenario's om kostenefficiënt te zijn tijdens het voldoen aan de prestatiebehoeften. Zie Azure Premium SSD v2-schijven gebruiken in Azure Kubernetes Service voor meer informatie over het configureren van een nieuw of bestaand AKS-cluster voor het gebruik van Azure Premium SSD v2-schijven.

Ultra Disk Storage

Ultra Disk Storage is een door Azure beheerde schijflaag die hoge doorvoer, hoge IOPS en consistente schijfopslag met lage latentie biedt voor Virtuele Azure-machines. Ultra Disk Storage is bedoeld voor workloads die veel gegevens en transacties bevatten. Net als andere Disk Storage-SKU's en Amazon EBS koppelt Ultra Disk Storage één pod tegelijk en biedt deze geen gelijktijdige toegang.

Gebruik de vlag --enable-ultra-ssd om Ultra Disk Storage in te schakelen op uw AKS-cluster.

Als u Ultra Disk Storage kiest, moet u rekening houden met de beperkingen en ervoor zorgen dat u een compatibele VM-grootte selecteert. Ultra Disk Storage is beschikbaar met lokaal redundante opslagreplicatie (LRS).

Bring Your Own Keys (BYOK)

Azure versleutelt alle gegevens in een beheerde schijf-at-rest. Standaard worden gegevens versleuteld met door Microsoft beheerde sleutels. Voor meer controle over versleutelingssleutels kunt u door de klant beheerde sleutels opgeven om te gebruiken voor versleuteling-at-rest voor zowel het besturingssysteem als de gegevensschijven voor uw AKS-clusters. Zie Bring Your Own Keys (BYOK) met Azure Managed Disks in Azure Kubernetes Service (AKS) voor meer informatie.

Azure Files

Disk Storage kan geen gelijktijdige toegang bieden tot een volume, maar u kunt Azure Files gebruiken om een SMB-share (Server Message Block) versie 3.1.1-share of NFS-share (Network File System) versie 4.1 te koppelen die wordt ondersteund door Azure Storage. Dit proces biedt een netwerkopslag die vergelijkbaar is met Amazon EFS. Net als bij Schijfopslag zijn er twee opties:

  • Azure Files Standard-opslag wordt ondersteund door gewone harde schijven (HDD's).
  • Azure Files Premium-opslag biedt back-ups van de bestandsshare met SSD-stations met hoge prestaties. De minimale bestandsgrootte voor Premium is 100 GB.

Azure Files heeft de volgende replicatieopties voor opslagaccounts om uw gegevens te beveiligen in geval van een fout:

Als u de kosten voor Azure Files wilt optimaliseren, koopt u azure Files-capaciteitsreserveringen.

Azure NetApp Files

Azure NetApp Files is een hoogwaardige bestandsopslagservice met hoge prestaties die op Azure draait en volumes ondersteunt die gebruikmaken van NFS- (NFSv3 of NFSv4.1), SMB-en dual-protocol (NFSv3 en SMB, of NFSv4.1 en SMB). Kubernetes-gebruikers hebben twee opties voor het gebruik van Azure NetApp Files-volumes voor Kubernetes-workloads:

  • Maak de Azure NetApp Files-volumes statisch . In dit scenario is het maken van volumes extern voor AKS. Volumes worden gemaakt met behulp van de Azure CLI of de Azure-portal en worden vervolgens blootgesteld aan Kubernetes door een PersistentVolumete maken. Statisch aangemaakte Azure NetApp Files-volumes hebben veel beperkingen (bijvoorbeeld niet vergroot kunnen worden, moeten overgeprovisioneerd worden, enzovoort). Statisch gemaakte volumes worden niet aanbevolen voor de meeste gebruiksvoorbeelden.
  • Maak Azure NetApp Files-volumes dynamischaan en orkestreer deze via Kubernetes. Deze methode is de geprefereerde manier om meerdere volumes rechtstreeks via Kubernetes te maken en wordt bereikt door gebruik te maken van Astra Trident. Astra Trident is een CSI-compatibele dynamische opslagorchestrator waarmee volumes systeemeigen kunnen worden ingericht via Kubernetes.

Zie Azure NetApp Files configureren voor Azure Kubernetes Servicevoor meer informatie.

Azure Blobstorage

Het CSI-stuurprogramma (Azure Blob Storage Container Storage Interface) is een CSI-specificatiecompatibel stuurprogramma dat wordt gebruikt door Azure Kubernetes Service (AKS) om de levenscyclus van Azure Blob Storage te beheren. De CSI is een standaard voor het beschikbaar maken van willekeurige blok- en bestandsopslagsystemen voor workloads in containers in Kubernetes.

Door CSI te gebruiken, kan AKS nu invoegtoepassingen schrijven, implementeren en itereren om nieuwe opslagsystemen in Kubernetes beschikbaar te maken of bestaande te verbeteren. Als u CSI-stuurprogramma's in AKS gebruikt, hoeft u de kubernetes-kerncode niet aan te raken en te wachten op de releasecycli.

Wanneer u Azure Blob Storage als bestandssysteem koppelt aan een container of pod, kunt u blobopslag gebruiken met een aantal toepassingen die enorme hoeveelheden ongestructureerde gegevens verwerken. Bijvoorbeeld:

  • Logboekbestandsgegevens
  • Afbeeldingen, documenten en streaming video of -audio
  • Gegevens voor herstel na noodgevallen

De gegevens in de objectopslag zijn toegankelijk voor toepassingen met behulp van BlobFuse- of Network File System (NFS) 3.0-protocol. Vóór de introductie van het CSI-stuurprogramma voor Azure Blob Storage was de enige optie om handmatig een niet-ondersteund stuurprogramma te installeren voor toegang tot Blob Storage vanuit uw toepassing die wordt uitgevoerd op AKS. Wanneer het CSI-stuurprogramma voor Azure Blob Storage is ingeschakeld op AKS, zijn er twee ingebouwde opslagklassen: azureblob-fuse-premium en azureblob-nfs-premium.

Om een AKS-cluster te maken met ondersteuning voor CSI-stuurprogramma's, zie CSI-stuurprogramma's op AKS. Zie Toegang tot Azure Files, Blob Storage en Azure NetApp Files vergelijken met NFS-voor meer informatie over de verschillen in toegang tussen elk van de Azure-opslagtypen met behulp van het NFS-protocol.

Azure HPC Cache

Azure HPC Cache versnelt de toegang tot uw gegevens voor HPC-taken, met alle schaalbaarheid van cloudoplossingen. Als u deze opslagoplossing kiest, moet u ervoor zorgen dat u uw AKS-cluster implementeert in een regio die ondersteuning biedt voor Azure HPC-cache.

NFS-server

De beste optie voor gedeelde NFS-toegang is om Azure Files of Azure NetApp Files te gebruiken. U kunt ook een NFS-server maken op een Azure-VM die volumes exporteert.

Houd er rekening mee dat deze optie alleen ondersteuning biedt voor statische inrichting. U moet de NFS-shares handmatig inrichten op de server en dit kan niet automatisch vanuit AKS.

Deze oplossing is gebaseerd op IaaS (Infrastructure as a Service) in plaats van PaaS (Platform as a Service). U bent verantwoordelijk voor het beheren van de NFS-server, waaronder updates van het besturingssysteem, hoge beschikbaarheid, back-ups, herstel na noodgevallen en schaalbaarheid.

Breng je eigen sleutels mee (BYOK) met Azure-disks

Azure Storage versleutelt alle gegevens in een opslagaccount in rusttoestand, inclusief het besturingssysteem en de gegevensschijven van een AKS-cluster. Standaard worden gegevens versleuteld met door Microsoft beheerde sleutels. Voor meer controle over versleutelingssleutels kunt u door de klant beheerde sleutels opgeven voor versleuteling in rust van het besturingssysteem en de gegevensschijven van uw AKS-clusters. Zie voor meer informatie:

Azure Container Storage

Azure Container Storage is een cloudgebaseerde volumebeheer-, implementatie- en indelingsservice die systeemeigen is gebouwd voor containers. Het kan worden geïntegreerd met Kubernetes, zodat je dynamisch en automatisch permanente volumes kunt inrichten voor het opslaan van gegevens voor stateful toepassingen die worden uitgevoerd op Kubernetes-clusters.

Azure Container Storage maakt gebruik van bestaande Azure Storage-aanbiedingen voor werkelijke gegevensopslag en biedt een oplossing voor volumeindeling en beheer die speciaal is gebouwd voor containers. Ondersteunde opties voor back-upopslag zijn onder andere:

  • Azure Disks: Gedetailleerde controle over opslag-SKU's en configuraties. Ze zijn geschikt voor databases op laag 1 en algemeen gebruik.
  • Tijdelijke schijven: maakt gebruik van lokale opslagresources op AKS-knooppunten (NVMe of tijdelijke SSD). Het meest geschikt voor toepassingen zonder duurzaamheid van gegevens of met ingebouwde ondersteuning voor gegevensreplicatie. AKS detecteert de beschikbare tijdelijke opslag op AKS-knooppunten en verkrijgt deze voor volume-implementatie.
  • Elastische SAN van Azure: on-demand, volledig beheerde resource inrichten. Geschikt voor databases voor algemeen gebruik, streaming- en berichtenservices, CD/CI-omgevingen en andere workloads van laag 1/laag 2. Meerdere clusters hebben gelijktijdig toegang tot één SAN, maar permanente volumes kunnen slechts door één consument tegelijk worden gekoppeld.

Tot nu toe moet u cloudopslag bieden voor containers die zijn vereist met behulp van CSI-stuurprogramma's (Container Storage Interface) voor het gebruik van opslagservices die zijn bedoeld voor IaaS-workloads (Infrastructure as a Service) en ervoor zorgen dat ze voor containers werken. Dit creëert operationele overhead en verhoogt het risico op problemen met de beschikbaarheid van toepassingen, schaalbaarheid, prestaties, bruikbaarheid en kosten.

Azure Container Storage is afgeleid van OpenEBS, een opensource-oplossing die containeropslagmogelijkheden biedt voor Kubernetes. Door een oplossing voor beheerde volumeindeling aan te bieden via opslagcontrollers op basis van microservices in een Kubernetes-omgeving, maakt Azure Container Storage echte containereigen opslag mogelijk.

Azure Container Storage is geschikt in de volgende scenario's:

  • Versnel VM-naar-containerinitiatieven: Azure Container Storage biedt het volledige spectrum aan azure-blokopslagaanbiedingen die voorheen alleen beschikbaar waren voor VM's en beschikbaar maakt voor containers. Dit omvat tijdelijke schijf die zeer lage latentie biedt voor workloads zoals Cassandra, evenals Azure Elastic SAN die systeemeigen iSCSI- en gedeelde ingerichte doelen biedt.

  • Vereenvoudig volumebeheer met Kubernetes: Door volumeindeling via het Kubernetes-besturingsvlak te bieden, kunt u met Azure Container Storage eenvoudig volumes binnen Kubernetes implementeren en beheren, zonder dat u tussen verschillende besturingsvlakken heen en weer hoeft te gaan.

  • Verminder de totale eigendomskosten (TCO): Verbeter de kostenefficiëntie door de schaal van permanente volumes te verhogen die per pod of knooppunt worden ondersteund. Verminder de opslagbronnen die nodig zijn voor het inrichten door opslagbronnen dynamisch te delen. Houd er rekening mee dat ondersteuning voor omhoog schalen voor de opslaggroep zelf niet wordt ondersteund.

Azure Container Storage biedt de volgende belangrijke voordelen:

  • Snelle uitschalen van stateful pods: Azure Container Storage koppelt permanente volumes via netwerkblokopslagprotocollen (NVMe-oF of iSCSI), waardoor permanente volumes snel worden gekoppeld en losgekoppeld. U kunt zo nodig kleine resources starten en implementeren terwijl u ervoor zorgt dat uw toepassingen niet worden onderbroken of onderbroken, hetzij tijdens de initialisatie of in productie. Toepassingstolerantie wordt verbeterd met pod-respawns in het cluster, waarvoor snelle verplaatsing van permanente volumes vereist is. Met behulp van externe netwerkprotocollen koppelt Azure Container Storage nauw aan de levenscyclus van de pod om uiterst tolerante stateful toepassingen op AKS te ondersteunen.

  • Verbeterde prestaties voor stateful workloads: Azure Container Storage maakt superieure leesprestaties mogelijk en biedt schrijfprestaties op bijna schijf met behulp van NVMe-oF via RDMA. Hierdoor kunnen klanten rendabel voldoen aan de prestatievereisten voor verschillende containerworkloads, waaronder I/O-intensieve laag 1, algemeen gebruik, doorvoergevoelig en dev/test. Versnel de koppel-/loskoppeltijd van permanente volumes en minimaliseer de failovertijd van pods.

  • Kubernetes-systeemeigen volumeindeling: maak opslaggroepen en permanente volumes, leg momentopnamen vast en beheer de volledige levenscyclus van volumes met behulp van kubectl opdrachten zonder tussen toolsets te schakelen voor verschillende besturingsvlakbewerkingen.

Oplossingen van derden

Net als Amazon EKS is AKS een Kubernetes-implementatie en kunt u Kubernetes-opslagoplossingen van derden integreren. Hier volgen enkele voorbeelden van opslagoplossingen van derden voor Kubernetes:

  • Rook verandert gedistribueerde opslagsystemen in zelfbeheerde opslagservices door opslagbeheerderstaken te automatiseren. Rook levert zijn services via een Kubernetes-operator voor elke opslagprovider.
  • GlusterFS is een gratis en opensource schaalbaar netwerkbestandssysteem dat gebruikmaakt van algemene off-the-shelf hardware om grote, gedistribueerde opslagoplossingen te maken voor gegevensintensieve en bandbreedte-intensieve taken.
  • Ceph biedt een betrouwbare en schaalbare geïntegreerde opslagservice met object-, blok- en bestandsinterfaces van één cluster dat is gebouwd op basis van basishardwareonderdelen.
  • Met MinIO multicloud-objectopslag kunnen ondernemingen AWS S3-compatibele gegevensinfrastructuur bouwen in elke cloud, met een consistente, draagbare interface voor uw gegevens en toepassingen.
  • Portworx is een end-to-end oplossing voor opslag en gegevensbeheer voor Kubernetes-projecten en op containers gebaseerde initiatieven. Portworx biedt containergranulatie van opslag, herstel na noodgevallen, gegevensbeveiliging en migraties met meerdere clouds.
  • Quobyte biedt krachtige bestands- en objectopslag die u op elke server of cloud kunt implementeren om prestaties te schalen, grote hoeveelheden gegevens te beheren en het beheer te vereenvoudigen.
  • Ondat biedt een consistente opslaglaag op elk platform. U kunt een database of een permanente workload uitvoeren in een Kubernetes-omgeving zonder dat u de opslaglaag hoeft te beheren.

Overwegingen voor Kubernetes-opslag

Houd rekening met de volgende factoren wanneer u een opslagoplossing kiest voor Amazon EKS of AKS.

Toegangsmodi voor opslagklasse

In Kubernetes versie 1.21 en hoger gebruiken AKS- en Amazon EKS-opslagklassen alleen CSI-stuurprogramma's (Container Storage Interface) en standaard.

Verschillende services ondersteunen opslagklassen met verschillende toegangsmodi.

Service ReadWriteOnce ReadOnlyMany ReadWriteMany
Azure-schijven X
Azure Files X X X
Azure NetApp Files X X X
NFS-server X X X
Azure HPC Cache X X X

Dynamische versus statische inrichting

Dynamisch volumes inrichten om de beheeroverhead van het statisch maken van permanente volumes te verminderen. Stel een correct claimbeleid in om te voorkomen dat ongebruikte schijven worden verwijderd wanneer u pods verwijdert.

Backup

Kies een hulpprogramma om een back-up te maken van permanente gegevens. Het hulpprogramma moet overeenkomen met uw opslagtype, zoals momentopnamen, Azure Backup, Velero of Kasten.

Kostenoptimalisatie

Gebruik Azure-reserveringen om azure Storage-kosten te optimaliseren. Zorg ervoor dat u controleert welke services Azure-reserveringen ondersteunen. Zie ook Cost Management voor een Kubernetes-cluster.

Medewerkers

Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.

Belangrijkste auteurs:

Andere Inzenders:

Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.

Volgende stappen