Lagringsalternativ för program i AKS som aktiveras av Azure Arc

Gäller för: AKS på Azure Stack HCI 22H2, AKS på Windows Server

Program som körs i AKS-distributioner med hjälp av Azure Kubernetes Service som aktiveras av Azure Arc kan behöva lagra och hämta data. För vissa programarbetsbelastningar kan data använda lokal, snabb lagring på en nod som inte behövs när poddarna tas bort (Kubernetes använder poddar för att köra en instans av ett program).

Andra arbetsbelastningar kan kräva lagring som bevaras på mer vanliga datavolymer. Flera poddar kan behöva dela samma datavolymer eller återansluta datavolymer om podden schemaläggs om på en annan nod. Du kan också behöva ett lagringsalternativ om poddarna innehåller känsliga data eller programkonfigurationsinformation.

Den här artikeln beskriver de grundläggande begreppen som tillhandahåller lagring till dina program i AKS Arc, inklusive:

• Volymer
• Beständiga volymer
• Lagringsklasser
• Beständiga volymanspråk (PVC)

Volymer

Program måste ofta kunna lagra och hämta data. Eftersom Kubernetes vanligtvis behandlar enskilda poddar som tillfälliga, disponibla resurser är olika metoder tillgängliga för program att använda och bevara data. En volym representerar ett sätt att lagra, hämta och bevara data mellan poddar och genom programmets livscykel.

I Kubernetes kan volymer representera mer än bara en traditionell information som lagras och hämtas. Kubernetes-volymer kan också användas som ett sätt att infoga data i en podd som containrar kan använda. Några vanliga Kubernetes-volymtyper är:

• emptyDir – Den här volymen används ofta som tillfälligt utrymme för en podd. Alla containrar i en podd kan komma åt data på volymen. Data som skrivs till den här volymtypen bevaras endast under poddens livslängd – när podden tas bort tas volymen bort. Den här volymen använder vanligtvis den underliggande lokala noddisklagringen, även om den också kan finnas enbart i nodens minne.

• secret – Den här volymen används för att inkludera känsliga data, till exempel lösenord, i poddar. Först skapar du en hemlighet med kubernetes-API:et. När du definierar podden eller distributionen kan du begära en specifik hemlighet. Hemligheter tillhandahålls endast till noder med en schemalagd podd som kräver det, och hemligheten lagras i tmpfs, inte skrivs till disk. När den sista podden på en nod som kräver en hemlighet tas bort, tas hemligheten bort från nodens tmpfs. Hemligheter lagras inom ett visst namnområde och kan bara nås av poddar inom samma namnområde.

• configMap – Den här volymtypen används för att mata in nyckel/värde-par-egenskaper i poddar, till exempel programkonfigurationsinformation. I stället för att definiera programkonfigurationsinformation i en containeravbildning kan du definiera den som en Kubernetes-resurs som enkelt kan uppdateras och tillämpas på nya instanser av poddar när de distribueras. Precis som när du använder en hemlighet skapar du först en ConfigMap med kubernetes-API:et. Den här ConfigMap kan sedan begäras när du definierar en podd eller distribution. ConfigMaps lagras inom ett angivet namnområde och kan endast nås av poddar inom samma namnområde.

Beständiga volymer

Volymer som definieras och skapas som en del av poddlivscykeln finns bara tills podden tas bort. Poddar förväntar sig ofta att deras lagring ska finnas kvar om en podd schemaläggs om på en annan värd under en underhållshändelse, särskilt i StatefulSets. En beständig volym är en lagringsresurs som skapas och hanteras av Kubernetes-API:et som kan finnas utanför livslängden för en enskild podd.

Du kan använda AKS-diskvolymer som backas upp av VHDX som är monterade som ReadWriteOnce och som är tillgängliga för en enskild nod i taget. Du kan också använda AKS-filvolymer som backas upp av SMB- eller NFS-filresurser. Dessa monteras som ReadWriteMany och är tillgängliga för flera noder samtidigt.

En klusteradministratör kan statiskt skapa en beständig volym, eller så kan volymen skapas dynamiskt av Kubernetes API-servern. Om en podd har schemalagts och begär lagring som för närvarande inte är tillgänglig kan Kubernetes skapa den underliggande VHDX-filen och sedan koppla den till podden. Dynamisk etablering använder en StorageClass för att identifiera vilken typ av lagring som behöver skapas.

Lagringsklasser

Om du vill definiera olika lagringsnivåer (och platser) kan du skapa en StorageClass. StorageClass definierar även reclaimPolicy. Denna reclaimPolicy styr beteendet för den underliggande lagringsresursen när podden tas bort och den beständiga volymen kanske inte längre krävs. Den underliggande lagringsresursen kan tas bort eller behållas för användning med en framtida podd.

I AKS Arc skapas standardlagringsklassen automatiskt och använder CSV för att skapa VHDX-baserade volymer. Återtagandeprincipen säkerställer att den underliggande VHDX tas bort när den beständiga volymen som använde den tas bort. Lagringsklassen konfigurerar också de beständiga volymerna så att de kan expanderas, så du behöver bara redigera det beständiga volymanspråket med den nya storleken.

Om ingen StorageClass har angetts för en beständig volym används standardlagringsklassen . När du begär beständiga volymer kontrollerar du att de använder rätt lagring. Du kan skapa en StorageClass för ytterligare behov.

Beständiga volymanspråk

En PersistentVolumeClaim begär antingen ReadWriteOnce - eller ReadWriteMany-lagring av en viss StorageClass och storlek. Kubernetes API-servern kan dynamiskt etablera den underliggande lagringsresursen i AKS Arc om det inte finns någon befintlig resurs för att uppfylla anspråket baserat på den definierade StorageClass. Podddefinitionen innehåller volymmonteringen när volymen har anslutits till podden.

En PersistentVolume är bunden till ett PersistentVolumeClaim när en tillgänglig lagringsresurs har tilldelats den podd som begär den. Det finns en 1:1-mappning av beständiga volymer till anspråk.

Följande YAML-exempelmanifest visar ett beständigt volymanspråk som använder standardlagringsklassen och begär en 5Gi-disk:

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

När du skapar en podddefinition anges det beständiga volymanspråket för att begära önskad lagring. Du kan också ange volumeMount för dina program att läsa och skriva data. Följande YAML-exempelmanifest visar hur det tidigare beständiga volymanspråket kan användas för att montera en volym på /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 

I följande exempel visas hur du monterar en volym i en Windows-container och anger enhetsbeteckningen och sökvägen:

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

Nästa steg

• Använd DRIVRUTINERna för AKS på Azure Stack HCI-disken CSI (Container Storage Interface).