Verwenden des Azure Managed Lustre CSI-Treibers mit Azure Kubernetes Service

In diesem Artikel erfahren Sie, wie Sie Azure Managed Lustre im Azure Kubernetes Service (AKS) mit dem Azure Lustre CSI-Treiber für Kubernetes planen, installieren und verwenden. Dieser Treiber basiert auf der CSI-Spezifikation (Container Support Interface).

Sie können den Azure Lustre CSI-Treiber für Kubernetes verwenden, um auf Azure Managed Lustre-Speicher als persistente Speichervolumes von Kubernetes-Containern zuzugreifen, die in AKS bereitgestellt werden.

Kompatible Kubernetes-Versionen

Der Azure Lustre CSI-Treiber für Kubernetes ist mit AKSkompatibel. Andere Kubernetes-Installationen werden derzeit nicht unterstützt.

AKS Kubernetes-Versionen 1.21 und höher werden unterstützt. Diese Unterstützung umfasst alle Versionen, die derzeit verfügbar sind, wenn Sie einen neuen AKS-Cluster erstellen.

Kompatible Lustre-Versionen

Der Azure Lustre CSI-Treiber für Kubernetes ist mit Azure Managed Lustrekompatibel. Andere Lustre-Installationen werden derzeit nicht unterstützt.

Azure Lustre CSI-Treiberversionen

Die folgenden Treiberversionen werden unterstützt:

Eine vollständige Liste aller Treiberversionen und ihres Änderungsprotokolls finden Sie auf der Seite "Azure Lustre CSI-Treiberversionen".

Voraussetzungen

• Ein Azure-Konto mit einem aktiven Abonnement. Sie können kostenlos ein Konto erstellen.
• Eine Terminalumgebung mit installierten Azure CLI-Tools. Siehe Erste Schritte mit der Azure CLI.
• kubectl, das in Ihrer Terminalumgebung installiertes Kubernetes-Verwaltungstool. Siehe Schnellstart: Bereitstellen eines Azure Kubernetes Service (AKS)-Clusters mithilfe der Azure CLI-.
• Eine Azure Managed Lustre-Bereitstellung. Weitere Informationen finden Sie in der Azure Managed Lustre-Dokumentation.
• Netzwerkkonnektivität zwischen Ihrem AKS-Cluster und dem virtuellen Azure Managed Lustre-Netzwerk. Weitere Informationen zu Konfigurationsoptionen finden Sie in der folgenden Netzwerkarchitekturplanung .

Planen der AKS-Bereitstellung

Wenn Sie Azure Kubernetes Service bereitstellen, wirken sich mehrere Optionen auf den Betrieb zwischen AKS und Azure Managed Lustre aus.

Ermitteln des netzwerktyps, der mit AKS verwendet werden soll

AKS unterstützt mehrere Netzwerkmodelle mit jeweils unterschiedlichen Funktionen und Anwendungsfällen. Alle Netzwerkmodelle arbeiten mit dem Azure Lustre CSI-Treiber für Kubernetes, haben jedoch unterschiedliche Anforderungen für das Einrichten virtueller Netzwerke und Cluster.

Umfassende Informationen zur Auswahl des richtigen Netzwerkmodells für Ihre spezifischen Anforderungen finden Sie unter Azure Kubernetes Service CNI-Netzwerkübersicht.

Beim Erstellen eines AKS-Clusters im Azure-Portal werden die folgenden Netzwerkoptionen angezeigt:

Empfohlene Optionen:

Azure CNI-Überlagerung (empfohlen)

• Spart VNet-IP-Adressraum, indem logisch getrennte CIDR-Bereiche für Pods verwendet werden
• Unterstützt die maximale Clusterskala (5000 Knoten und 250 Pods pro Knoten)
• Einfache IP-Adressverwaltung
• Beste Wahl für die meisten Szenarien

Azure CNI Pod Subnet

• Pods erhalten vollständige VNet-Konnektivität und können direkt über ihre private IP-Adresse erreicht werden
• Erfordert einen größeren, nicht fragmentierten VNet-IP-Adressraum
• Wählen Sie diese Option aus, wenn Sie direkten externen Zugriff auf Pod-IPs benötigen.

Veraltete Optionen (nicht für neue Einführungen empfohlen):

Azure CNI Node Subnet (Legacy)

• Begrenzte Skalierung und ineffiziente Verwendung von VNet-IPs
• Es wird nur empfohlen, wenn Sie speziell ein verwaltetes VNet für Ihren Cluster benötigen, siehe AKS Legacy Container Networking Interfaces (CNI)

Kubenet (Auslaufend)

• Wird am 31. März 2028 eingestellt. Weitere Informationen finden Sie unter AKS verwenden Kubenet.
• Eingeschränkter Umfang und erfordert manuelle Routenverwaltung
• Planen Sie die Migration zu Azure CNI Overlay vor dem Ablaufdatum

Ausführliche Informationen zu Netzwerkmodellen finden Sie unter Azure Kubernetes Service CNI-Netzwerkübersicht.

Bestimmen Sie die Netzwerkarchitektur für die Vernetzung von AKS und Azure Managed Lustre.

Azure Managed Lustre arbeitet in einem privaten virtuellen Netzwerk. Ihre AKS-Instanz muss über netzwerkkonnektivität mit dem virtuellen Azure Managed Lustre-Netzwerk verfügen. Es gibt zwei gängige Methoden zum Konfigurieren des Netzwerks zwischen Azure Managed Lustre und AKS:

• Installieren Sie AKS in einem eigenen virtuellen Netzwerk und erstellen Sie ein Peering virtueller Netzwerke mit dem virtuellen Netzwerk von Azure Managed Lustre.
• Verwenden Sie die Option Eigenes virtuelles Netzwerk von Azure mitbringen in AKS, um AKS in einem neuen Subnetz im virtuellen Netzwerk von Azure Managed Lustre zu installieren.

Peering AKS und Azure Managed Lustre virtual networks

Die Möglichkeit, zwei virtuelle Netzwerke zu koppeln, hat den Vorteil, die Verwaltung der Netzwerke auf verschiedene privilegierte Rollen zu verteilen. Peering kann auch zusätzliche Flexibilität bieten, da Sie es in Azure-Abonnements oder -Regionen implementieren können. Virtuelles Netzwerk-Peering erfordert eine Koordination zwischen den beiden Netzwerken, um zu vermeiden, dass konfliktende IP-Netzwerkplätze ausgewählt werden.

Installieren von AKS in einem Subnetz im virtuellen Netzwerk von Azure Managed Lustre

Die Option zum Installieren des AKS-Clusters im virtuellen Netzwerk von Azure Managed Lustre mit dem Feature Eigenes virtuelles Netzwerk von Azure mitbringen in AKS kann in Szenarien vorteilhaft sein, in denen das Netzwerk einzeln verwaltet wird. Sie müssen ein zusätzliches Subnetz erstellen, das ihren AKS-Netzwerkanforderungen entspricht, im virtuellen Azure Managed Lustre-Netzwerk.

Es gibt keine Trennung von Berechtigungen bei der Netzwerkverwaltung, wenn Sie AKS im virtuellen Netzwerk von Azure Managed Lustre bereitstellen. Der AKS-Dienstprinzipal benötigt Berechtigungen im virtuellen Netzwerk von Azure Managed Lustre.

Bereitstellungsmethoden

Der Azure Lustre CSI-Treiber unterstützt zwei Bereitstellungsmethoden:

Dynamische Bereitstellung (verfügbar in v0.3.0+)

Mit der dynamischen Bereitstellung kann der CSI-Treiber automatisch Azure Managed Lustre-Dateisysteme bei Bedarf erstellen, wenn dauerhafte Volumeansprüche erstellt werden.

Statische Bereitstellung

Die statische Bereitstellung verwendet ein vorhandenes Azure Managed Lustre-Dateisystem. Diese Methode umfasst Folgendes:

• Erstellen von Speicherklassen, die auf vorhandene Lustre-Cluster verweisen
• Manuelle Angabe des Lustre-Dateisystemnamens und der MGS-IP-Adresse
• Geeignet für Szenarien, in denen Sie bereits vorhandene Lustre-Infrastruktur haben

Wählen Sie die Methode aus, die am besten zu Ihrem Anwendungsfall passt. Die dynamische Bereitstellung wird zuerst unten dokumentiert, gefolgt von statischen Bereitstellungsanweisungen.

Dynamische Bereitstellung (öffentliche Vorschau)

Public Preview-Hinweis: Dynamische Bereitstellungsfunktionen befinden sich derzeit in der öffentlichen Vorschau. Einige Features werden möglicherweise nicht unterstützt oder weisen eingeschränkte Funktionen auf.

Bei der dynamischen Bereitstellung werden automatisch Azure Managed Lustre-Dateisysteme bei Bedarf erstellt, wenn persistente Volumeansprüche erstellt werden. Dieses Feature wurde in der CSI-Treiberversion 0.3.0 verfügbar.

Voraussetzungen für die dynamische Bereitstellung

Erlaubnisse

Für die Kubelet-Identität sind die folgenden Berechtigungen erforderlich:

• Lese- und Schreibzugriff auf die Ressourcengruppe, in der Cluster erstellt werden
• Netzwerkberechtigungen zum Erstellen und Verwalten von Subnetzen bei Bedarf
• Azure Managed Lustre-Dienstberechtigungen

Ausführliche Berechtigungsanforderungen finden Sie in der Dokumentation zu Treiberparametern.

Netzwerkanforderungen

• Ein vorhandenes virtuelles Netzwerk und Subnetz für den Azure Managed Lustre-Cluster
• Ausreichende IP-Adressen, die im Subnetz für den Cluster verfügbar sind
• Richtige Regeln für Netzwerksicherheitsgruppen, um Lustre-Datenverkehr zuzulassen

Erstellen eines AKS-Clusters für die dynamische Bereitstellung

Wenn Sie Ihren AKS-Cluster noch nicht erstellt haben, erstellen Sie eine Clusterbereitstellung. Siehe Bereitstellen eines Azure Kubernetes Service (AKS)-Clusters mithilfe des Azure-Portals.

Erstellen eines virtuellen Netzwerk-Peerings für die dynamische Bereitstellung

Das virtuelle AKS-Netzwerk wird in einer separaten Ressourcengruppe von der Ressourcengruppe des AKS-Clusters erstellt. Sie finden den Namen dieser Ressourcengruppe, indem Sie im Azure-Portal zu Ihrem AKS-Cluster wechseln, dann zu Eigenschaften wechseln und die Ressourcengruppe Infrastruktur auffinden. Diese Ressourcengruppe enthält das virtuelle Netzwerk, das mit dem virtuellen Azure Managed Lustre-Netzwerk gekoppelt werden muss. Es entspricht dem Muster <.>

Um das virtuelle AKS-Netzwerk mit Ihrem virtuellen Azure Managed Lustre-Netzwerk zu verknüpfen, konsultieren Sie Peering virtueller Netzwerke.

Verbindung zum AKS-Cluster für die dynamische Bereitstellung herstellen.

1. Öffnen Sie eine Terminalsitzung mit Zugriff auf die Azure CLI-Tools, und melden Sie sich bei Ihrem Azure-Konto an:

   az login
   

2. Melden Sie sich beim Azure-Portal an.

3. Suchen Sie Ihren AKS-Cluster. Wählen Sie im Bereich Übersicht die Schaltfläche Verbinden aus, und kopieren Sie dann den Befehl für Clusteranmeldeinformationen herunterladen.

4. Fügen Sie in Ihrer Terminalsitzung den Befehl ein, um die Anmeldeinformationen herunterzuladen. Der Befehl ähnelt folgendem:

   az aks get-credentials --subscription <AKS_subscription_id> --resource_group <AKS_resource_group_name> --name <name_of_AKS>
   

5. Installieren Sie Kubectl, wenn sie in Ihrer Umgebung nicht vorhanden ist:

   az aks install-cli
   

6. Stellen Sie sicher, dass der aktuelle Kontext der AKS-Cluster ist, in dem Sie die Anmeldeinformationen soeben installiert haben und dass Sie eine Verbindung damit herstellen können:

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

Treiber für die dynamische Bereitstellung installieren

Führen Sie den folgenden Befehl aus, um den Azure Lustre CSI-Treiber für Kubernetes zu installieren:

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

Um Beispielbefehle für eine lokale Installation zu erhalten, siehe Azure Lustre CSI-Treiber auf einem Kubernetes-Cluster installieren.

Erstellen einer Speicherklasse für die dynamische Bereitstellung

Erstellen Sie eine Datei mit dem Namen storageclass_dynprov_lustre.yaml und kopieren Sie das folgende YAML hinein. Bearbeiten Sie die Parameter nach Bedarf für Ihre Umgebung:

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"

Wenden Sie die Speicherklasse auf Ihren AKS-Cluster an:

kubectl apply -f storageclass_dynprov_lustre.yaml

Erstellen eines persistenten Volumeanspruchs für die dynamische Bereitstellung

Erstellen Sie eine Datei mit dem Namen pvc_storageclass_dynprov.yaml und kopieren Sie den folgenden YAML-Inhalt hinein.

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

Wenden Sie das PVC auf Ihren AKS-Cluster an:

kubectl apply -f pvc_storageclass_dynprov.yaml

Überwachen der Clustererstellung

Die Erstellung des Azure Managed Lustre-Clusters kann 10 Minuten oder mehr dauern. Sie können den Fortschritt überwachen:

kubectl describe pvc pvc-lustre-dynprov

Beim Erstellen wird der Status Pending angezeigt mit einer Nachricht wie: Waiting for a volume to be created either by the external provisioner 'azurelustre.csi.azure.com'...

Sobald es fertig ist, hat es den Status Bound mit einer Erfolgsmeldung.

Erstellen eines Pods für die dynamische Bereitstellung

Erstellen Sie eine Datei mit dem Namen pod_echo_date_dynprov.yaml und kopieren Sie den folgenden YAML-Inhalt hinein.

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

Wenden Sie den Pod auf Ihren AKS-Cluster an:

kubectl apply -f pod_echo_date_dynprov.yaml

Überprüfen Sie die dynamische Bereitstellung

Sobald der Pod läuft, können Sie überprüfen, ob das dynamisch erstellte Azure Managed Lustre-Dateisystem ordnungsgemäß eingebunden ist.

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

Sie sollten das Azure Managed Lustre-Dateisystem sehen, das unter /mnt/lustre.

Bereinigen dynamischer Ressourcen

So löschen Sie die dynamisch erstellten Ressourcen:

kubectl delete pvc pvc-lustre-dynprov

Wenn die Speicherklasse vorhanden ist reclaimPolicy: Delete, wird dadurch auch der Azure Managed Lustre-Cluster gelöscht. Bei Festlegung auf Retain", müssen Sie den Cluster manuell löschen, wenn er nicht mehr benötigt wird.

Statische Bereitstellung

Mithilfe der statischen Bereitstellung können Sie ein vorhandenes Azure Managed Lustre-Dateisystem mit Ihrem AKS-Cluster verwenden, indem Sie die erforderlichen Kubernetes-Ressourcen manuell erstellen.

Voraussetzungen für die statische Bereitstellung

• Ein vorhandenes Azure Managed Lustre-Dateisystem. Weitere Informationen zum Erstellen eines Azure Managed Lustre-Dateisystems finden Sie unter Erstellen eines Azure Managed Lustre-Dateisystems.
• Die MGS-IP-Adresse und der interne Dateisystemname von Ihrem Azure Managed Lustre-Cluster

Erstellen eines Azure Managed Lustre-Dateisystemclusters für die statische Bereitstellung

Wenn Sie ihren Azure Managed Lustre-Dateisystemcluster noch nicht erstellt haben, erstellen Sie den Cluster jetzt. Weitere Anweisungen finden Sie unter Erstellen eines Azure Managed Lustre-Dateisystems mithilfe des Azure-Portals. Für die statische Bereitstellung ist ein vorhandenes Azure Managed Lustre-Dateisystem erforderlich.

Erstellen eines AKS-Clusters für die statische Bereitstellung

Wenn Sie Ihren AKS-Cluster noch nicht erstellt haben, erstellen Sie eine Clusterbereitstellung. Siehe Bereitstellen eines Azure Kubernetes Service (AKS)-Clusters mithilfe des Azure-Portals.

Erstellen eines virtuellen Netzwerk-Peerings für die statische Bereitstellung

Das virtuelle AKS-Netzwerk wird in einer separaten Ressourcengruppe von der Ressourcengruppe des AKS-Clusters erstellt. Sie finden den Namen dieser Ressourcengruppe, indem Sie im Azure-Portal zu Ihrem AKS-Cluster wechseln, dann zu Eigenschaften wechseln und die Ressourcengruppe Infrastruktur auffinden. Diese Ressourcengruppe enthält das virtuelle Netzwerk, das mit dem virtuellen Azure Managed Lustre-Netzwerk gekoppelt werden muss. Es entspricht dem Muster <.>

Um das virtuelle AKS-Netzwerk mit Ihrem virtuellen Azure Managed Lustre-Netzwerk zu verknüpfen, konsultieren Sie Peering virtueller Netzwerke.

Stellen Sie eine Verbindung mit dem AKS-Cluster für die statische Bereitstellung her.

1. Öffnen Sie eine Terminalsitzung mit Zugriff auf die Azure CLI-Tools, und melden Sie sich bei Ihrem Azure-Konto an:

   az login
   

2. Melden Sie sich beim Azure-Portal an.

3. Suchen Sie Ihren AKS-Cluster. Wählen Sie im Bereich Übersicht die Schaltfläche Verbinden aus, und kopieren Sie dann den Befehl für Clusteranmeldeinformationen herunterladen.

4. Fügen Sie in Ihrer Terminalsitzung den Befehl ein, um die Anmeldeinformationen herunterzuladen. Der Befehl ähnelt folgendem:

   az aks get-credentials --subscription <AKS_subscription_id> --resource_group <AKS_resource_group_name> --name <name_of_AKS>
   

5. Installieren Sie Kubectl, wenn sie in Ihrer Umgebung nicht vorhanden ist:

   az aks install-cli
   

6. Stellen Sie sicher, dass der aktuelle Kontext der AKS-Cluster ist, in dem Sie die Anmeldeinformationen soeben installiert haben und dass Sie eine Verbindung damit herstellen können:

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

Installieren Sie den Treiber für die statische Bereitstellung

Führen Sie den folgenden Befehl aus, um den Azure Lustre CSI-Treiber für Kubernetes zu installieren:

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

Um Beispielbefehle für eine lokale Installation zu erhalten, siehe Azure Lustre CSI-Treiber auf einem Kubernetes-Cluster installieren.

Erstellen und Konfigurieren eines persistenten Volumes für die statische Bereitstellung

So erstellen Sie ein persistentes Volume für ein vorhandenes Azure Managed Lustre-Dateisystem:

1. Kopieren Sie die folgenden Konfigurationsdateien aus dem Ordner "/docs/examples/" im Repository "azurelustre-csi-driver ". Wenn Sie das Repository geklont haben, als Sie den Treiber installiert haben, sind bereits lokale Kopien verfügbar.

   • storageclass_existing_lustre.yaml
   • pvc_storageclass.yaml

   Wenn Sie das gesamte Repository nicht klonen möchten, können Sie jede Datei einzeln herunterladen. Öffnen Sie jeden der folgenden Links, kopieren Sie den Inhalt der Datei, und fügen Sie den Inhalt dann in eine lokale Datei mit demselben Dateinamen ein.

   • storageclass_existing_lustre.yaml
   • pvc_storageclass.yaml

2. Aktualisieren Sie in der Datei storageclass_existing_lustre.yaml den internen Namen des Lustre-Clusters und die IP-Adresse des Lustre Management Service (MGS).

   

   Beide Einstellungen werden im Azure-Portal im Bereich Clientverbindung für Ihr Azure Managed Lustre-Dateisystem angezeigt.

   

   Führen Sie die folgenden Updates aus:

   • Ersetzen Sie den EXISTING_LUSTRE_FS_NAME vom System zugewiesenen internen Namen des Lustre-Clusters in Ihrem Azure Managed Lustre-Dateisystem. Der interne Name ist in der Regel lustrefs. Der interne Name ist nicht der Name, den Sie beim Erstellen des Dateisystems angegeben haben.

     Der vorgeschlagene mount Befehl enthält den in der folgenden Adresszeichenfolge hervorgehobenen Namen.

     

   • Ersetzen Sie EXISTING_LUSTRE_IP_ADDRESS durch die MGS-IP-Adresse.

3. Führen Sie den folgenden kubectl Befehl aus, um die Speicherklasse und den dauerhaften Volumeanspruch zu erstellen:

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

Erstellen Sie einen Pod für die statische Bereitstellung

Erstellen Sie einen Pod, der das PVC verwendet, um das Azure Managed Lustre-Dateisystem einzubinden.

Erstellen Sie eine Datei mit dem Namen pod_echo_date.yaml und kopieren Sie den folgenden YAML-Inhalt hinein.

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

Wenden Sie den Pod auf Ihren AKS-Cluster an:

kubectl apply -f pod_echo_date.yaml

Überprüfung der statischen Bereitstellung

Nachdem der Pod ausgeführt wird, können Sie überprüfen, ob das Azure Managed Lustre-Dateisystem ordnungsgemäß bereitgestellt ist.

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

Sie sollten das Azure Managed Lustre-Dateisystem sehen, das unter /mnt/lustre.

Führen Sie zum Anzeigen von Zeitstempeln in der Konsole während der Schreibvorgänge den folgenden Befehl aus:

kubectl logs -f lustre-echo-date

Bereinigen statischer Ressourcen

So bereinigen Sie Ressourcen, wenn Sie fertig sind:

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

Überprüfung von Container-Image-Signaturen

Azure Lustre CSI Driver signiert seine Containerimages, damit Benutzer die Integrität und den Ursprung der verwendeten Bilder überprüfen können. Das Signieren verwendet ein öffentliches/privates Schlüsselpaar, um zu beweisen, dass Microsoft ein Containerimage erstellt hat, indem eine digitale Signatur erstellt und dem Image hinzugefügt wird. Dieser Abschnitt enthält die Schritte, um zu überprüfen, ob ein Bild von Microsoft signiert wurde.

Grundlegendes zur Imagesicherheit in Kubernetes-Systemkomponenten

Container-Images, die vom Azure Lustre CSI-Treiber verwendete werden, werden im kube-system Namespace deployiert, der als vertrauenswürdiger Systemnamespace in Kubernetes gilt. Aus Sicherheits- und Betriebsgründen werden Imageintegritätsrichtlinien in der Regel nicht für Systemnamespaces erzwungen, da:

• Bootstrap-Anforderungen: Systemkomponenten wie CSI-Treiber müssen gestartet werden, bevor Richtlinienerzwingungssysteme (z. B. Gatekeeper und Ratify) verfügbar sind.
• Vertrauenswürdige Komponenten: Images in kube-system sind Kernkomponenten der Kubernetes-Infrastruktur, die von vertrauenswürdigen Anbietern verwaltet werden
• Betriebsstabilität: Das Erzwingen von Richtlinien für Richtlinienerzwingungskomponenten selbst kann Clusterfunktionen verhindern.

Sie können jedoch die Integrität von CSI-Treiberimages vor der Bereitstellung weiterhin überprüfen.

Überprüfung des Images vor der Bereitstellung

Vor der Bereitstellung des Azure Lustre CSI-Treibers können Sie die digitalen Signaturen und die Authentizität der Containerimages mithilfe der öffentlichen Signaturzertifikate von Microsoft überprüfen:

Überprüfen von Bildsignaturen mit Notation CLI

1. Notation CLI herunterladen:

   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. Laden Sie das öffentliche Microsoft-Signaturzertifikat herunter:

   curl -sSL "https://www.microsoft.com/pkiops/certs/Microsoft%20Supply%20Chain%20RSA%20Root%20CA%202022.crt" -o msft_signing_cert.crt
   

3. Fügen Sie das Zertifikat zur Notation CLI hinzu:

   notation cert add --type ca --store supplychain msft_signing_cert.crt
   

4. Überprüfen Sie die Notation des Zertifikats:

   notation cert ls
   

   Die Ausgabe des Befehls sieht wie im folgenden Beispiel aus:

   STORE TYPE  STORE NAME  CERTIFICATE 
   ca          supplychain msft_signing_cert.crt
   

5. Erstellen Sie eine TrustPolicy-Datei für Azure Lustre CSI-Treiberimages:

   Erstellen sie eine Datei namens 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. Verwenden Sie die Notation, um Azure Lustre CSI-Treiberimages zu überprüfen:

   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
   

   Die Ausgabe einer erfolgreichen Überprüfung sieht wie im folgenden Beispiel aus:

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

Integrität des Abbilds von Anwendungsworkloads

Um die Sicherheit in Produktionsumgebungen zu verbessern, sollten Sie die AKS-Imageintegrität aktivieren, um Containerimagesignaturen für Ihre Anwendungsworkloads automatisch zu überprüfen. Während CSI-Treiberimages im kube-system-Namespace typischerweise von der Richtlinienimplementierung ausgeschlossen sind, können Sie Integritätsrichtlinien für Bilder in Ihren Anwendung-Namespaces konfigurieren.

Weitere Informationen zum Implementieren von Imageintegritätsrichtlinien für Ihre Anwendungsworkloads finden Sie unter Image Integrity in Azure Kubernetes Service (AKS).

Problembehandlung

Informationen zur Problembehandlung mit dem Azure Lustre CSI-Treiber finden Sie im CSI-Treiber-Problembehandlungshandbuch im GitHub-Repository.

Häufige Probleme sind beispielweise:

• Netzwerkkonnektivitätsprobleme zwischen AKS und Azure Managed Lustre – Überprüfen des virtuellen Netzwerk-Peerings oder der Subnetzkonfiguration
• Falsche Konfiguration : Überprüfen Sie die MGS-IP-Adresse und den Dateinamen in Ihrer Konfiguration der Speicherklasse.
• Pod-Planungsprobleme – Stellen Sie sicher, dass Sie ubuntu Linux OS SKU für Knotenpools verwenden, da dies die einzige unterstützte Konfiguration ist.
• Berechtigungsprobleme – Überprüfen, ob der AKS-Dienstprinzipal über entsprechende Berechtigungen für das virtuelle Azure Managed Lustre-Netzwerk verfügt

Für spezifische Probleme bei der dynamischen Bereitstellung:

• Authentifizierungs-/Autorisierungsfehler – Überprüfen der Kubelet-Identitätsberechtigungen zum Erstellen von Azure Managed Lustre-Clustern
• SKU- und Zonenvalidierungsfehler – stellen Sie sicher, dass die angegebene SKU in Ihrer Regions- und Zonenkonfiguration unterstützt wird.
• Verfügbarkeit von Netzwerk-IP-Adressen – bestätigen Sie, dass genügend IP-Adressen im Zielsubnetz verfügbar sind.
• Kontingentbeschränkungen – Überprüfen Sie sowohl Kubernetes-Ressourcenkontingente als auch Azure-Abonnementkontingente für Azure Managed Lustre-Cluster

Weitere Ressourcen zur Problembehandlung finden Sie unter:

• Azure Managed Lustre –Problembehandlung
• GitHub-Repository des Azure Lustre CSI-Treibers

Verwandte Inhalte

• Erstellen eines Exportauftrags zum Exportieren von Daten aus Azure Managed Lustre