Dela via


Använda Azure Managed Lustre CSI-drivrutinen med Azure Kubernetes Service

I den här artikeln får du lära dig hur du planerar, installerar och använder Azure Managed Lustre i Azure Kubernetes Service (AKS) med Azure Lustre CSI-drivrutin för Kubernetes. Den här drivrutinen baseras på CSI-specifikationen (Container Support Interface).

Du kan använda Azure Lustre CSI-drivrutinen för Kubernetes för att få åtkomst till Azure Managed Lustre Storage som beständiga lagringsvolymer från Kubernetes-containrar som distribuerats i AKS.

Kompatibla Kubernetes-versioner

Azure Lustre CSI-drivrutinen för Kubernetes är kompatibel med AKS. Andra Kubernetes-installationer stöds inte för närvarande.

AKS Kubernetes version 1.21 och senare stöds. Det här stödet omfattar alla versioner som för närvarande är tillgängliga när du skapar ett nytt AKS-kluster.

Viktigt!

Azure Lustre CSI-drivrutinen för Kubernetes fungerar för närvarande endast med Ubuntu Linux OS SKU för nodpooler i AKS.

Kompatibla Lustre-versioner

Azure Lustre CSI-drivrutinen för Kubernetes är kompatibel med Azure Managed Lustre. Andra Lustre-installationer stöds inte för närvarande.

Azure Lustre CSI-drivrutinsversioner

Följande drivrutinsversioner stöds:

Drivrutinsversion Bild K8s-version som stöds Lustre-klientversion Dynamisk tilldelning
huvudgren mcr.microsoft.com/oss/v2/kubernetes-csi/azurelustre-csi:latest 1.21+ 2.15.5
v0.3.0 mcr.microsoft.com/oss/v2/kubernetes-csi/azurelustre-csi:v0.3.0 1.21+ 2.15.5
v0.2.0 mcr.microsoft.com/oss/v2/kubernetes-csi/azurelustre-csi:v0.2.0 1.21+ 2.15.5
v0.1.18 mcr.microsoft.com/oss/v2/kubernetes-csi/azurelustre-csi:v0.1.18 1.21+ 2.15.5
v0.1.17 mcr.microsoft.com/oss/v2/kubernetes-csi/azurelustre-csi:v0.1.17 1.21+ 2.15.5
v0.1.15 mcr.microsoft.com/oss/v2/kubernetes-csi/azurelustre-csi:v0.1.15 1.21+ 2.15.4
v0.1.14 mcr.microsoft.com/oss/v2/kubernetes-csi/azurelustre-csi:v0.1.14 1.21+ 2.15.3
v0.1.13 mcr.microsoft.com/oss/v2/kubernetes-csi/azurelustre-csi:v0.1.13 1.21+ 2.15.4
v0.1.12 mcr.microsoft.com/oss/v2/kubernetes-csi/azurelustre-csi:v0.1.12 1.21+ 2.15.3
v0.1.11 mcr.microsoft.com/oss/v2/kubernetes-csi/azurelustre-csi:v0.1.11 1.21+ 2.15.1
v0.1.10 mcr.microsoft.com/oss/v2/kubernetes-csi/azurelustre-csi:v0.1.10 1.21+ 2.15.2

En fullständig lista över alla drivrutinsversioner och deras ändringslogg finns på sidan för Azure Lustre CSI-drivrutinsversioner.

Förutsättningar

Planera din AKS-distribution

När du distribuerar Azure Kubernetes Service påverkar flera alternativ åtgärden mellan AKS och Azure Managed Lustre.

Fastställa vilken nätverkstyp som ska användas med AKS

AKS stöder flera nätverksmodeller, var och en med olika funktioner och användningsfall. Alla nätverksmodeller fungerar med Azure Lustre CSI-drivrutinen för Kubernetes, men de har olika krav för konfiguration av virtuella nätverk och kluster.

Omfattande information om hur du väljer rätt nätverksmodell för dina specifika krav finns i Azure Kubernetes Service CNI-nätverksöversikt.

När du skapar ett AKS-kluster i Azure-portalen visas följande nätverksalternativ:

Azure CNI-överlägg (rekommenderas)

  • Sparar VNet IP-adressutrymme med hjälp av logiskt separata CIDR-intervall för poddar
  • Stöder maximal klusterskala (5 000 noder och 250 poddar per nod)
  • Enkel IP-adresshantering
  • Bästa valet för de flesta scenarier

Azure CNI Pod-undernät

  • Poddar får fullständig VNet-anslutning och kan nås direkt via sin privata IP-adress
  • Kräver större, icke-fragmenterat VNet IP-adressutrymme
  • Välj detta om du behöver direkt extern åtkomst till podd-IP-adresser

Azure CNI Node-undernät (äldre)

Kubenet (går i pension)

  • Går i pension den 31 mars 2028. Mer information finns i AKS-användning av Kubenet.
  • Begränsad skala och kräver manuell väghantering
  • Planera att migrera till Azure CNI Overlay före slutdatumet

Detaljerad information om nätverksmodeller finns i Översikt över Azure Kubernetes Service CNI-nätverk.

Fastställa nätverksarkitekturen för sammankoppling av AKS och Azure Managed Lustre

Azure Managed Lustre fungerar i ett privat virtuellt nätverk. Din AKS-instans måste ha nätverksanslutning till det virtuella Azure Managed Lustre-nätverket. Det finns två vanliga sätt att konfigurera nätverk mellan Azure Managed Lustre och AKS:

  • Installera AKS i ett eget virtuellt nätverk och skapa en virtuell nätverkskoppling med ett virtuellt Azure Managed Lustre-nätverk.
  • Använd alternativet Bring your own Azure virtual network i AKS för att installera AKS i ett nytt undernät i det virtuella Azure Managed Lustre-nätverket.

Kommentar

Vi rekommenderar inte att du installerar AKS i samma undernät som Azure Managed Lustre.

Peering av virtuella AKS- och Azure Managed Lustre-nätverk

Alternativet att sammanlänka två virtuella nätverk har fördelen att dela upp hanteringen av nätverken mellan olika privilegierade roller. Peering kan också ge ytterligare flexibilitet eftersom du kan implementera den i azure-prenumerationer eller regioner. Peering för virtuella nätverk kräver samordning mellan de två nätverken för att undvika att välja motstridiga IP-nätverksutrymmen.

diagram som visar två virtuella nätverk, ett för Azure Managed Lustre och ett för AKS, med en peeringpil som ansluter dem.

Installera AKS i ett undernät i det virtuella Azure Managed Lustre-nätverket

Alternativet att installera AKS-klustret i det virtuella Azure Managed Lustre-nätverket med Bring your own Azure virtual network-funktionen i AKS kan vara fördelaktigt i scenarier där nätverket hanteras unikt. Du måste skapa ytterligare ett undernät, storleksanpassat för att uppfylla dina KRAV för AKS-nätverk, i det virtuella Azure Managed Lustre-nätverket.

Det finns ingen behörighetsavgränsning för nätverkshantering när du etablerar AKS i det virtuella Azure Managed Lustre-nätverket. AKS-tjänstens klient behöver behörigheter i Azure Managed Lustre-nätverksmiljön.

diagram som visar ett virtuellt Azure Managed Lustre-nätverk med två undernät, ett för Filsystemet Lustre och ett för AKS.

Provisioneringsmetoder

Azure Lustre CSI-drivrutinen stöder två etableringsmetoder:

Dynamisk tilldelning (tillgänglig i v0.3.0+)

Med dynamisk etablering kan CSI-drivrutinen automatiskt skapa Azure Managed Lustre-filsystem på begäran när beständiga volymanspråk skapas.

Kommentar

Dynamisk etablering är tillgänglig från och med Azure Lustre CSI Driver version 0.3.0 och finns för närvarande i offentlig förhandsversion. Mer information finns i viktig information om v0.3.0.

Statisk tilldelning

Statisk etablering använder ett befintligt Azure Managed Lustre-filsystem. Den här metoden omfattar:

  • Skapa lagringsklasser som refererar till befintliga Lustre-kluster
  • Ange Namnet på Lustre-filsystemet manuellt och MGS IP-adressen
  • Lämplig för scenarier där du har befintlig Lustre-infrastruktur

Välj den metod som passar bäst för ditt användningsfall. Dynamisk etablering dokumenteras först nedan, följt av statiska etableringsinstruktioner.

Dynamisk tilldelning (offentlig förhandsvisning)

Meddelande om offentlig förhandsversion: Funktionen för dynamisk etablering är för närvarande i offentlig förhandsversion. Vissa funktioner kanske inte stöds eller har begränsade funktioner.

Dynamisk provisionering skapar automatiskt Azure Managed Lustrefilsystem vid behov när beständiga volymkrav skapas. Den här funktionen blev tillgänglig i CSI-drivrutinsversion 0.3.0.

Förutsättningar för dynamisk etablering

Permissions

Viktigt!

Innan du använder den här CSI-drivrutinen för att dynamiskt skapa Azure Managed Lustre-kluster måste kubelet-identiteten ha rätt behörighet.

Kubelet-identiteten kräver följande behörigheter:

  • Läs- och skrivåtkomst till resursgruppen där kluster skapas
  • Nätverksbehörigheter för att skapa och hantera undernät om det behövs
  • Azure Managed Lustre-tjänstbehörigheter

Detaljerade behörighetskrav finns i dokumentationen om drivrutinsparametrar.

Nätverkskrav

  • Ett befintligt virtuellt nätverk och undernät för Azure Managed Lustre-klustret
  • Tillräckligt med IP-adresser i undernätet för klustret
  • Rätt regler för nätverkssäkerhetsgrupp för att tillåta Lustre-trafik

Skapa ett AKS-kluster för dynamisk tilldelning

Om du inte redan har skapat ditt AKS-kluster skapar du en klusterdistribution. Se Distribuera ett AKS-kluster (Azure Kubernetes Service) med hjälp av Azure-portalen.

Skapa en virtuell nätverkspeering för dynamisk provisionering

Kommentar

Hoppa över det här nätverkspeeringssteget om du har installerat AKS i ett undernät i det virtuella Azure Managed Lustre-nätverket.

Det virtuella AKS-nätverket skapas i en separat resursgrupp från AKS-klustrets resursgrupp. Du hittar namnet på den här resursgruppen genom att gå till ditt AKS-kluster i Azure-portalen, gå till Egenskaperoch hitta resursgruppen Infrastruktur. Den här resursgruppen innehåller det virtuella nätverk som måste kopplas ihop med det virtuella Azure Managed Lustre-nätverket. Den matchar mönstret <.>

Om du vill koppla samman det virtuella AKS-nätverket med ditt virtuella Azure Managed Lustre-nätverk, se Peering för virtuella nätverk.

Dricks

På grund av namngivning av MC_ resursgrupper och virtuella nätverk kan namn på nätverk vara liknande eller samma i flera AKS-distributioner. När du konfigurerar peering bör du vara noga med att välja de AKS-nätverk som du tänker välja.

Anslut till AKS-klustret för dynamisk resurstilldelning

  1. Öppna en terminalsession med åtkomst till Azure CLI-verktygen och logga in på ditt Azure-konto:

    az login
    
  2. Logga in på Azure-portalen.

  3. Hitta ditt AKS-kluster. I fönstret Översikt väljer du knappen Anslut och kopierar sedan kommandot för Ladda ned klusterautentiseringsuppgifter.

  4. I terminalsessionen klistrar du in kommandot för att ladda ned autentiseringsuppgifterna. Kommandot är likt detta:

    az aks get-credentials --subscription <AKS_subscription_id> --resource_group <AKS_resource_group_name> --name <name_of_AKS>
    
  5. Installera kubectl om det inte finns i din miljö:

    az aks install-cli
    
  6. Kontrollera att den aktuella kontexten är DET AKS-kluster där du precis har installerat autentiseringsuppgifterna och att du kan ansluta till det:

    kubectl config current-context
    kubectl get deployments --all-namespaces=true
    

Installera drivrutinen för dynamisk etablering

Kör följande kommando för att installera Azure Lustre CSI-drivrutinen för Kubernetes:

curl -skSL https://raw.githubusercontent.com/kubernetes-sigs/azurelustre-csi-driver/main/deploy/install-driver.sh | bash

Information om hur du hämtar exempelkommandon för en lokal installation finns i Installera Azure Lustre CSI-drivrutinen på ett Kubernetes-kluster.

Skapa en lagringsklass för dynamisk etablering

Skapa en fil med namnet storageclass_dynprov_lustre.yaml och kopiera i följande YAML. Redigera parametrarna efter behov för din miljö:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: azurelustre-dynprov
provisioner: azurelustre.csi.azure.com
parameters:
  sku-name: "AMLFS-Durable-Premium-125"  # Choose appropriate SKU
  zone: "1"  # Specify zone if required for your SKU/location
  maintenance-day-of-week: "Sunday"
  maintenance-time-of-day-utc: "22:00"
  location: "eastus"  # Optional: defaults to AKS cluster location
  resource-group: "my-resource-group"  # Optional: defaults to AKS cluster RG
  vnet-name: "my-vnet"  # Optional: defaults to AKS cluster VNET
  subnet-name: "my-subnet"  # Optional: defaults to AKS cluster subnet
reclaimPolicy: Delete  # Change to "Retain" to keep clusters after PVC deletion
volumeBindingMode: Immediate
---
# Optional: Resource quota to limit number of clusters
apiVersion: v1
kind: ResourceQuota
metadata:
  name: pvc-lustre-dynprov-quota
spec:
  hard:
    azurelustre-dynprov.storageclass.storage.k8s.io/persistentvolumeclaims: "1"

Tillämpa lagringsklassen på ditt AKS-kluster:

kubectl apply -f storageclass_dynprov_lustre.yaml

Skapa en beständig volymbegäran för dynamisk tilldelning

Skapa en fil med namnet pvc_storageclass_dynprov.yaml och kopiera i följande YAML:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-lustre-dynprov
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: azurelustre-dynprov
  resources:
    requests:
      storage: 48Ti  # Minimum size for AMLFS-Durable-Premium-125

Använd PVC på ditt AKS-kluster:

kubectl apply -f pvc_storageclass_dynprov.yaml

Övervaka skapande av kluster

Det kan ta 10 minuter eller mer att skapa Azure Managed Lustre-klustret. Du kan övervaka förloppet:

kubectl describe pvc pvc-lustre-dynprov

När du skapar kommer statusen att vara Pending med ett meddelande som: Waiting for a volume to be created either by the external provisioner 'azurelustre.csi.azure.com'...

När den är klar har den en Bound status med ett meddelande om att det lyckades.

Skapa en pod för dynamisk tilldelning

Skapa en fil med namnet pod_echo_date_dynprov.yaml och kopiera i följande YAML:

apiVersion: v1
kind: Pod
metadata:
  name: lustre-echo-date-dynprov
spec:
  containers:
  - image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
    name: lustre-echo-date-dynprov
    command:
      - "/bin/sh"
      - "-c"
      - "while true; do echo $(date) >> /mnt/lustre/outfile; sleep 1; done"
    volumeMounts:
    - name: lustre-storage
      mountPath: /mnt/lustre
  volumes:
  - name: lustre-storage
    persistentVolumeClaim:
      claimName: pvc-lustre-dynprov

Tillämpa podden på ditt AKS-kluster:

kubectl apply -f pod_echo_date_dynprov.yaml

Verifiera dynamisk etablering

När podden har körts kan du kontrollera att det dynamiskt skapade Azure Managed Lustre-filsystemet är korrekt monterat:

kubectl exec -it lustre-echo-date-dynprov -- df -h

Du bör se filsystemet Azure Managed Lustre monterat på /mnt/lustre.

Rensa dynamiska resurser

Så här tar du bort de dynamiskt skapade resurserna:

kubectl delete pvc pvc-lustre-dynprov

Om lagringsklassen har reclaimPolicy: Deletetas även Azure Managed Lustre-klustret bort. Om värdet är Retaininställt på måste du ta bort klustret manuellt när det inte längre behövs.

Statisk tilldelning

Med statisk etablering kan du använda ett befintligt Azure Managed Lustre-filsystem med ditt AKS-kluster genom att manuellt skapa nödvändiga Kubernetes-resurser.

Förutsättningar för statisk provisionering

  • Ett befintligt Azure Managed Lustre-filsystem. Mer information om hur du skapar ett Azure Managed Lustre-filsystem finns i Skapa ett Azure Managed Lustre-filsystem.
  • MGS IP-adressen och det interna filsystemnamnet från ditt Azure Managed Lustre-kluster

Skapa ett Azure Managed Lustre-filsystemkluster för statisk etablering

Om du inte redan har skapat ditt Azure Managed Lustre-filsystemkluster skapar du klustret nu. Anvisningar finns i Skapa ett Azure Managed Lustre-filsystem med hjälp av Azure-portalen. Statisk etablering kräver ett befintligt Azure Managed Lustre-filsystem.

Skapa ett AKS-kluster för statisk provisionering

Om du inte redan har skapat ditt AKS-kluster skapar du en klusterdistribution. Se Distribuera ett AKS-kluster (Azure Kubernetes Service) med hjälp av Azure-portalen.

Skapa en virtuell nätverkspeering för statisk förberedelse

Kommentar

Hoppa över det här nätverkspeeringssteget om du har installerat AKS i ett undernät i det virtuella Azure Managed Lustre-nätverket.

Det virtuella AKS-nätverket skapas i en separat resursgrupp från AKS-klustrets resursgrupp. Du hittar namnet på den här resursgruppen genom att gå till ditt AKS-kluster i Azure-portalen, gå till Egenskaperoch hitta resursgruppen Infrastruktur. Den här resursgruppen innehåller det virtuella nätverk som måste kopplas ihop med det virtuella Azure Managed Lustre-nätverket. Den matchar mönstret <.>

Om du vill koppla samman det virtuella AKS-nätverket med ditt virtuella Azure Managed Lustre-nätverk, se Peering för virtuella nätverk.

Dricks

På grund av namngivning av MC_ resursgrupper och virtuella nätverk kan namn på nätverk vara liknande eller samma i flera AKS-distributioner. När du konfigurerar peering bör du vara noga med att välja de AKS-nätverk som du tänker välja.

Anslut till AKS-klustret för statisk provisionering

  1. Öppna en terminalsession med åtkomst till Azure CLI-verktygen och logga in på ditt Azure-konto:

    az login
    
  2. Logga in på Azure-portalen.

  3. Hitta ditt AKS-kluster. I fönstret Översikt väljer du knappen Anslut och kopierar sedan kommandot för Ladda ned klusterautentiseringsuppgifter.

  4. I terminalsessionen klistrar du in kommandot för att ladda ned autentiseringsuppgifterna. Kommandot är likt detta:

    az aks get-credentials --subscription <AKS_subscription_id> --resource_group <AKS_resource_group_name> --name <name_of_AKS>
    
  5. Installera kubectl om det inte finns i din miljö:

    az aks install-cli
    
  6. Kontrollera att den aktuella kontexten är DET AKS-kluster där du precis har installerat autentiseringsuppgifterna och att du kan ansluta till det:

    kubectl config current-context
    kubectl get deployments --all-namespaces=true
    

Installera drivrutinen för statisk etablering

Kör följande kommando för att installera Azure Lustre CSI-drivrutinen för Kubernetes:

curl -skSL https://raw.githubusercontent.com/kubernetes-sigs/azurelustre-csi-driver/main/deploy/install-driver.sh | bash

Information om hur du hämtar exempelkommandon för en lokal installation finns i Installera Azure Lustre CSI-drivrutinen på ett Kubernetes-kluster.

Skapa och konfigurera en persistent volym för statisk tilldelning

Så här skapar du en beständig volym för ett befintligt Azure Managed Lustre-filsystem:

  1. Kopiera följande konfigurationsfiler från mappen /docs/examples/ i lagringsplatsen azurelustre-csi-driver . Om du klonade lagringsplatsen när du installerade drivrutinenhar du lokala kopior redan tillgängliga.

    • storageclass_existing_lustre.yaml
    • pvc_storageclass.yaml

    Om du inte vill klona hela lagringsplatsen kan du ladda ned varje fil individuellt. Öppna var och en av följande länkar, kopiera filens innehåll och klistra sedan in innehållet i en lokal fil med samma filnamn.

  2. I filen storageclass_existing_lustre.yaml uppdaterar du det interna namnet på Lustre-klustret och IP-adressen för Lustre Management Service (MGS).

    Skärmbild av filen storageclass_existing_lustre.yaml med värden som ska ersättas markerade.

    Båda inställningarna visas i Azure-portalen i fönstret Klientanslutning för ditt Azure Managed Lustre-filsystem.

    Skärmbild av fönstret för klientanslutning i Azure-portalen. MGS IP-adressen och namnet

    Gör följande uppdateringar:

    • Ersätt EXISTING_LUSTRE_FS_NAME med det systemtilldelade interna namnet på Lustre-klustret i ditt Azure Managed Lustre-filsystem. Det interna namnet är vanligtvis lustrefs. Det interna namnet är inte det namn som du gav filsystemet när du skapade det.

      Det föreslagna mount kommandot innehåller namnet som är markerat i följande adresssträng.

      Skärmbild av en exempeladresssträng i fönstret för klientanslutning. Det interna namnet på Lustre-klustret är markerat.

    • Ersätt EXISTING_LUSTRE_IP_ADDRESS med MGS IP-adressen.

  3. Kör följande kubectl kommando för att skapa lagringsklassen och det beständiga volymanspråket:

    kubectl create -f storageclass_existing_lustre.yaml
    kubectl create -f pvc_storageclass.yaml
    

Skapa en pod för statisk etablering

Skapa en podd som använder PVC för att montera Azure Managed Lustre-filsystemet.

Skapa en fil med namnet pod_echo_date.yaml och kopiera i följande YAML:

apiVersion: v1
kind: Pod
metadata:
  name: lustre-echo-date
spec:
  containers:
  - image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
    name: lustre-echo-date
    command:
      - "/bin/sh"
      - "-c"
      - "while true; do echo $(date) >> /mnt/lustre/outfile; sleep 1; done"
    volumeMounts:
    - name: lustre-storage
      mountPath: /mnt/lustre
  volumes:
  - name: lustre-storage
    persistentVolumeClaim:
      claimName: pvc-lustre

Tillämpa podden på ditt AKS-kluster:

kubectl apply -f pod_echo_date.yaml

Verifiera statisk tilldelning

När podden har körts kan du kontrollera att Azure Managed Lustre-filsystemet är korrekt monterat:

kubectl exec -it lustre-echo-date -- df -h

Du bör se filsystemet Azure Managed Lustre monterat på /mnt/lustre.

Om du vill visa tidsstämplar i konsolen under skrivningar kör du följande kommando:

kubectl logs -f lustre-echo-date

Rensa statiska resurser

Så här rensar du resurser när du är klar:

kubectl delete pod lustre-echo-date
kubectl delete pvc pvc-lustre
kubectl delete storageclass azurelustre-static

Viktigt!

Detta tar bara bort Kubernetes-resurserna. Själva Azure Managed Lustre-filsystemet kommer att finnas kvar och kan återanvändas.

Verifiera signaturer för containerbilder

Azure Lustre CSI Driver signerar sina containeravbildningar så att användarna kan verifiera integriteten och ursprunget för de bilder som de använder. Signering använder ett offentligt/privat nyckelpar för att bevisa att Microsoft har skapat en containeravbildning genom att skapa en digital signatur och lägga till den i avbildningen. Det här avsnittet innehåller stegen för att verifiera att en avbildning har signerats av Microsoft.

Förstå bildsäkerhet i Kubernetes-systemkomponenter

Containeravbildningar som används av Azure Lustre CSI-drivrutinen distribueras i kube-system namnområdet, som anses vara ett betrott systemnamnområde i Kubernetes. Av säkerhets- och driftsskäl tillämpas vanligtvis inte principer för bildintegritet på systemnamnområden eftersom:

  • Bootstrap-krav: Systemkomponenter som CSI-drivrutiner måste starta innan system för principframtvingande (som Gatekeeper och Ratify) är tillgängliga
  • Betrodda komponenter: Avbildningar i kube-system är viktiga Kubernetes-infrastrukturkomponenter som hanteras av betrodda leverantörer
  • Driftsstabilitet: Genom att tillämpa principer för själva principframtvingande komponenter kan det förhindra klusterfunktioner

Du kan dock fortfarande verifiera integriteten för CSI-drivrutinsbilder före distributionen.

Avbildningsverifiering före distribution

Innan du distribuerar Azure Lustre CSI-drivrutinen kan du verifiera digitala signaturer och äkthet för containeravbildningarna med hjälp av Microsofts offentliga signeringscertifikat:

Verifiera bildsignaturer med Notation CLI

  1. Ladda ned Notation CLI:

    export NOTATION_VERSION=1.3.2
    curl -LO https://github.com/notaryproject/notation/releases/download/v$NOTATION_VERSION/notation_$NOTATION_VERSION\_linux_amd64.tar.gz
    sudo tar xvzf notation_$NOTATION_VERSION\_linux_amd64.tar.gz -C /usr/bin/ notation
    
  2. Ladda ned det offentliga Microsoft-signeringscertifikatet:

    curl -sSL "https://www.microsoft.com/pkiops/certs/Microsoft%20Supply%20Chain%20RSA%20Root%20CA%202022.crt" -o msft_signing_cert.crt
    
  3. Lägg till certifikatet i notation CLI:

    notation cert add --type ca --store supplychain msft_signing_cert.crt
    
  4. Kontrollera certifikatet i notationen:

    notation cert ls
    

    Kommandots utdata ser ut som i följande exempel:

    STORE TYPE  STORE NAME  CERTIFICATE 
    ca          supplychain msft_signing_cert.crt
    
  5. Skapa en säkerhetspolicyfil för Azure Lustre CSI-drivrutinsbilder:

    Skapa en fil med namnet trustpolicy.json:

    {
        "version": "1.0",
        "trustPolicies": [
            {
                "name": "supplychain",
                "registryScopes": [ "*" ],
                "signatureVerification": {
                    "level" : "strict" 
                },
                "trustStores": [ "ca:supplychain" ],
                "trustedIdentities": [
                    "x509.subject: CN=Microsoft SCD Products RSA Signing,O=Microsoft Corporation,L=Redmond,ST=Washington,C=US"
                ]
            }
        ]
    }
    
  6. Använd notation för att verifiera Azure Lustre CSI-drivrutinsbilder:

    notation policy import trustpolicy.json
    export NOTATION_EXPERIMENTAL=1
    
    # Verify the controller image
    notation verify --allow-referrers-api mcr.microsoft.com/oss/v2/kubernetes-csi/azurelustre-csi:v0.3.0
    

    Resultatet av en lyckad verifiering ser ut som i följande exempel:

    Successfully verified signature for mcr.microsoft.com/oss/v2/kubernetes-csi/azurelustre-csi@sha256:a1b2c3d4e5f6789012345678901234567890abcdef1234567890abcdef123456
    

Integritet hos arbetslastbilder för applikationer

För ökad säkerhet i produktionsmiljöer kan du överväga att aktivera AKS-avbildningsintegritet för att automatiskt validera signaturer för containeravbildningar för dina programarbetsbelastningar. Även om CSI-drivrutinsbilder i kube-system namnområdet vanligtvis undantas från principframtvingande, kan du konfigurera principer för bildintegritet för dina programnamnområden.

Mer information om hur du implementerar principer för bildintegritet för dina programarbetsbelastningar finns i Bildintegritet i Azure Kubernetes Service (AKS).

Felsökning

Felsökningsproblem med Azure Lustre CSI-drivrutinen finns i felsökningsguiden för CSI-drivrutinen på GitHub-lagringsplatsen.

Vanliga problem:

  • Problem med nätverksanslutning mellan AKS och Azure Managed Lustre – verifiera peering för virtuella nätverk eller konfiguration av undernät
  • Felaktig konfiguration – dubbelkolla MGS IP-adress och filsystemnamn i konfigurationen av lagringsklassen
  • Problem med poddschemaläggning – se till att du använder Ubuntu Linux OS SKU för nodpooler, eftersom det här är den enda konfiguration som stöds
  • Behörighetsproblem – kontrollera att AKS-tjänstens huvudnamn har rätt behörigheter i det virtuella Azure Managed Lustre-nätverket

För specifika problem med dynamisk tilldelning:

  • Autentiserings-/auktoriseringsfel – verifiera kubelet-identitetsbehörigheter för att skapa Azure Managed Lustre-kluster
  • SKU- och zonvalideringsfel – kontrollera att den angivna SKU:n stöds i din region och att zonkonfigurationen är korrekt
  • Tillgänglighet för nätverks-IP-adress – bekräfta att tillräckligt många IP-adresser är tillgängliga i målundernätet
  • Kvotbegränsningar – kontrollera både Kubernetes-resurskvoter och Azure-prenumerationskvoter för Azure Managed Lustre-kluster

Ytterligare felsökningsresurser finns i: