Dela via

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

Gäller för: AKS på Azure Local

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 regelbundna 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änslig data eller programkonfigurationsinformation.

Bild av arkitekturlagring som visar ett klusterhuvud och en nod.

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 volymanrop (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 spara data mellan poddar och genom programmets livscykel.

I Kubernetes kan volymer representera mer än bara ett traditionellt medium där information 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 pod. Alla containers inom en pod 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 din podd eller distribution kan du begära en specifik hemlighet. Hemligheter tillhandahålls endast till noder med en schemalagd pod som kräver det, och hemligheten lagras i tmpfs och skrivs inte 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 i ett angivet namnområde och kan endast nås av poddar inom samma namnområde.

  • configMap – Den här volymtypen används för att mata in nyckel/värde-paregenskaper 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 hjälp av Kubernetes-API:et. Den här ConfigMap kan sedan begäras när du definierar en podd eller distribution. ConfigMaps lagras i 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 har tagits 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 och som kan existera bortom en enskild podds livslängd.

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 är schemalagd och begär lagring som för närvarande inte är tillgänglig kan Kubernetes skapa den underliggande VHDX-filen och sedan bifoga den i 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. Den här 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-säkerhetskopierade volymer. Återställningsprincipen säkerställer att den underliggande VHDX tas bort när den beständiga volymen som har använt den tas bort. Lagringsklassen konfigurerar också beständiga volymer 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 volymbegäran

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. Poddens definition inkluderar volymfästet när volymen har anslutits till podden.

En PersistentVolume är bunden till en PersistentVolumeClaim när en tillgänglig lagringsresurs har tilldelats den podd som begär den. Det finns en 1:1-mappning av persistenta 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 anger du det persistenta volymkravet för att begära den nödvändiga lagringen. Du kan också ange volumeMount för dina program att läsa och skriva data. Följande YAML-exempelmanifest visar hur det tidigare "Persistent Volume Claim" 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 genom att ange vilken enhetsbeteckning och sökväg som ska användas:

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

Säker poddåtkomst till monterade volymer

För att dina program ska kunna köras korrekt ska poddar köras som en definierad användare eller grupp och inte som rot. Med securityContext för en podd eller container kan du definiera inställningar som fsGroup för att anta lämpliga behörigheter på de monterade volymerna.

fsGroup är ett fält i securityContext kubernetes-poddspecifikationen. Den definierar ett kompletterande grupp-ID som Kubernetes tilldelar till alla processer i podden och rekursivt till filerna i monterade volymer. Detta säkerställer att podden har rätt åtkomst på gruppnivå till delade lagringsvolymer.

När en volym monteras ändrar Kubernetes ägarskapet för volymens innehåll så att det matchar värdet fsGroup . Detta är särskilt användbart när containrar körs som icke-rotanvändare och behöver skrivåtkomst till delade volymer.

I följande exempel visar YAML värdet fsgroup :

securityContext:
  fsGroup: 2000

I det här exemplet är alla filer i monterade volymer tillgängliga via GID 2000.

Nästa steg