Utiliser le pilote CSI SMB pour accéder aux volumes SMB sur les nœuds Windows Server

Cette page fournit un exemple d'utilisation du pilote CSI SMB Open Source pour Kubernetes pour accéder à un volume SMB NetApp Cloud Volumes Service sur un cluster Google Kubernetes Engine (GKE) avec des nœuds Windows Server.

Présentation

Server Message Block (SMB) est un protocole de partage de fichiers réseau utilisé pour Microsoft Windows. Pour utiliser SMB avec des clusters GKE utilisant des pools de nœuds Windows Server, vous pouvez utiliser le pilote CSI SMB Open Source pour Kubernetes.

Tâches

Les sections suivantes présentent un exemple d'accès à un volume SMB NetApp Cloud Volumes Service sur un cluster GKE avec des nœuds Windows Server. L'exemple utilise le pilote CSI SMB Open Source pour Kubernetes.

Déployer Active Directory

Cette tâche crée un répertoire Active Directory. Si vous disposez déjà d'un service Active Directory à utiliser, vous pouvez ignorer cette tâche.

Pour déployer un service Active Directory autogéré, les instructions suivantes utilisent une solution Google Cloud Marketplace pour créer un domaine Active Directory, avec deux contrôleurs de domaine Active Directory.

  1. Dans Google Cloud Console, accédez à la page Microsoft Active Directory de Cloud Marketplace.
  2. Cliquez sur Lancement.
  3. Terminez la configuration de déploiement. Vérifiez que le serveur DNS se trouve dans la même région que le volume SMB NetApp Cloud Volumes Service. Vérifiez la disponibilité des régions.
  4. Cliquez sur Déployer.

Si vous préférez utiliser le service géré pour Microsoft Active Directory (service Microsoft AD géré), procédez comme suit :

  1. Créez un domaine Microsoft AD géré.
  2. Configurez l'appairage de domaines entre le domaine et le réseau de NetApp Cloud Volumes Service.
  3. Pour effectuer les tâches liées à Active Directory, connectez-vous au domaine.

Créer une zone de transfert DNS privée

Créez une zone de transfert DNS privé qui transfère les requêtes DNS à vos contrôleurs de domaine Active Directory.

Mettre à jour votre règle de pare-feu

Pour permettre aux requêtes de Cloud DNS d'atteindre votre connexion AD, dans la règle de pare-feu de votre AD, ajoutez 35.199.192.0/19 en tant que plage d'adresses IP source au filtre source.

Pour en savoir plus, consultez la section Considérations liées à la sécurité pour l'accès de SMB au service Cloud Volumes.

Créer une connexion Active Directory avec le service Cloud Volumes

Pour savoir comment procéder, consultez la section Créer une connexion AD.

Créer un volume SMB dans le service Cloud Volumes

Pour obtenir des instructions, consultez la section Créer un volume SMB.

Utilisez la cible d'installation du nouveau volume SMB en tant que valeur source dans votre objet PersistentVolume ou StorageClass, au format suivant :

"//SMB_SERVER_NAME/SHARE_NAME"

Les cibles et les instructions d'installation sont disponibles sur la page répertoriant les volumes Cloud Volumes et sur les pages d'informations sur les volumes.

Créer un cluster avec des nœuds associés au domaine AD

Suivez les instructions de la section Configurer les nœuds Windows Server pour les associer automatiquement à un domaine Active Directory.

Installer le pilote CSI SMB

  1. Installez le pilote CSI SMB Open Source pour Kubernetes.

  2. Pour accéder à un volume SMB à partir d'un pod, créez un secret qui encode le nom d'utilisateur et le mot de passe.

    kubectl create secret generic SECRET_NAME \
    --from-literal username="USERNAME" \
    --from-literal password="PASSWORD"

    Remplacez l'élément suivant :

    • SECRET_NAME : nom de votre secret.
    • USERNAME : nom d'utilisateur. Le nom d'utilisateur encodé dans le secret doit inclure un nom de domaine et se présenter au format suivant : domain\$username. Si votre partage SMB ne fait partie d'aucun domaine, le domaine peut être n'importe quelle chaîne.
    • PASSWORD : mot de passe de l'utilisateur.

Accéder au volume SMB

Pour accéder au volume SMB, vous pouvez choisir l'une des options suivantes :

Accéder au volume SMB à l'aide d'une ressource StorageClass

Pour accéder au volume SMB via un objet StorageClass, procédez comme suit :

  1. Créez un objet StorageClass. Voici un exemple de fichier manifeste nommé sc-smb.yaml :

    apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: smb
provisioner: smb.csi.k8s.io
parameters:
  source: "//SMB_SERVER_NAME/SHARE_NAME"
  csi.storage.k8s.io/node-stage-secret-name: "SECRET_NAME"
  csi.storage.k8s.io/node-stage-secret-namespace: "default"
  createSubDir: "false"    # optional: create a sub dir for new volume
reclaimPolicy: Retain      # only Retain is supported
volumeBindingMode: Immediate
mountOptions:
  - dir_mode=0777
  - file_mode=0777
  - uid=1001
  - gid=1001

    Dans cet exemple, nous utilisons le champ mountOptions, qui est facultatif pour Windows Server, mais qui permet à StorageClass de fonctionner à la fois avec Linux et Windows Server.

    Remplacez l'élément suivant :

    • SMB_SERVER_NAME : nom d'hôte du serveur SMB, domaine compris. Par exemple, le nom d'hôte du chemin d'installation //adserver-faab.cvssmb.com/eager-hungry-skossi est adserver-faab.cvssmb.com.
    • SHARE_NAME : nom du partage SMB. Par exemple, le nom de partage du chemin d'accès d'installation //adserver-faab.cvssmb.com/eager-hungry-skossi est eager-hungry-skossi. N'utilisez le partage racine que pour un partage SMB. Pour en savoir plus, consultez le problème connu associé.
    • SECRET_NAME : le nom du secret contient l'identifiant permettant d'accéder au volume SMB.

  2. Créez la ressource StorageClass en fonction du fichier manifeste :

    kubectl create -f sc-smb.yaml

  3. Déployez un pod qui utilise l'objet StorageClass. Voici un exemple de fichier manifeste nommé statefulset-smb.yaml. Le pod déployé pour ce StatefulSet crée un fichier data.txt dans le lecteur SMB installé :

    apiVersion: v1
kind: Service
metadata:
  name: busybox
  labels:
    app: busybox
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: busybox
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: statefulset-smb
  labels:
    app: busybox
spec:
  serviceName: statefulset-smb
  replicas: 1
  template:
    metadata:
      labels:
        app: busybox
    spec:
      nodeSelector:
        "kubernetes.io/os": windows
      containers:
        - name: statefulset-smb
          image: e2eteam/busybox:1.29
          command:
            - "powershell.exe"
            - "-Command"
            - "while (1) { Add-Content -Encoding Ascii C:\\sc\\smb\\data.txt $(Get-Date -Format u); sleep 1 }"
          volumeMounts:
            - name: smb
              mountPath: "/sc/smb"
      tolerations:
        - key: "node.kubernetes.io/os"
          operator: "Exists"
          effect: "NoSchedule"
  updateStrategy:
    type: RollingUpdate
  selector:
    matchLabels:
      app: busybox
  volumeClaimTemplates:
    - metadata:
        name: smb
        annotations:
          volume.beta.kubernetes.io/storage-class: smb
      spec:
        accessModes: ["ReadWriteMany"]
        resources:
          requests:
            storage: 10Gi

  4. Créez la ressource StatefulSet en fonction du fichier manifeste :

    kubectl create -f statefulset-smb.yaml

Utiliser un objet PersistentVolume et PersistentVolumeClaim pour accéder au volume

Pour accéder au volume SMB via un objet PersistentVolume et PersistentVolumeClaim, procédez comme suit :

  1. Créez un objet PersistentVolume. Voici un exemple de fichier manifeste nommé pv-smb.yaml :

    apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-smb
spec:
  capacity:
    storage: 100Gi
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  mountOptions:
    - dir_mode=0777
    - file_mode=0777
    - vers=3.0
  csi:
    driver: smb.csi.k8s.io
    readOnly: false
    volumeHandle: VOLUME_ID
    volumeAttributes:
      source: "//SMB_SERVER_NAME/SHARE_NAME"
    nodeStageSecretRef:
      name: SECRET_NAME
      namespace: default

    Dans cet exemple, nous utilisons le champ mountOptions, qui est facultatif pour Windows Server, mais qui permet à PersistentVolume de fonctionner à la fois avec Linux et Windows Server.

    Remplacez l'élément suivant :

    • VOLUME_ID : identifiant unique du volume.
    • SMB_SERVER_NAME : nom d'hôte du serveur SMB, domaine compris.
    • SHARE_NAME : nom du partage SMB.
    • SECRET_NAME : nom du secret qui contient l'identifiant permettant d'accéder au volume SMB.

  2. Créez une ressource PersistentVolume en fonction du fichier manifeste :

    kubectl create -f pv-smb.yaml

  3. Créez un objet PersistentVolumeClaim. Voici un exemple de fichier manifeste nommé pvc-smb.yaml :

    apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-smb
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 10Gi
  volumeName: pv-smb
  storageClassName: ""

  4. Créez une ressource PersistentVolumeClaim en fonction du fichier manifeste :

    kubectl create -f pvc-smb.yaml

  5. Déployez un pod qui utilise l'objet PersistentVolumeClaim. Voici un exemple de fichier manifeste nommé busybox-smb.yaml pour un déploiement de pod utilisant pvc-smb. Ce déploiement crée un fichier data.txt dans le disque SMB installé :

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: busybox-smb
  labels:
    app: busybox
spec:
  replicas: 1
  template:
    metadata:
      name: busybox
      labels:
        app: busybox
    spec:
      nodeSelector:
        "kubernetes.io/os": windows
      containers:
        - name: busybox
          image: e2eteam/busybox:1.29
          command:
            - "powershell.exe"
            - "-Command"
            - "while (1) { Add-Content -Encoding Ascii C:\\pv\\pv-smb\\data.txt $(Get-Date -Format u); sleep 1 }"
          volumeMounts:
            - name: smb
              mountPath: "/pv/pv-smb"
      tolerations:
        - key: "node.kubernetes.io/os"
          operator: "Exists"
          effect: "NoSchedule"
      volumes:
        - name: smb
          persistentVolumeClaim:
            claimName: pvc-smb
  selector:
    matchLabels:
      app: busybox

  6. Créez un Deployment à partir du fichier manifeste :

    kubectl apply -f  busybox-smb.yaml

Tester l'accès au volume SMB

Pour vérifier que vous pouvez accéder au fichier data.txt sur le volume SMB, effectuez l'une des tâches suivantes :

  • Démarrez une session PowerShell dans le conteneur et répertoriez le fichier data.txt :

    kubectl exec POD_NAME -- powershell.exe -c "ls PATH_TO_THE_FILE"

  • Ouvrez le lecteur SMB dans une autre VM pour vérifier que le fichier data.txt a bien été créé dans le partage distant.

Problèmes connus

Erreur d'installation sous Windows après le redémarrage

Problème : par exemple, si \\smb-server\share\test1 est déjà installé, vous pouvez obtenir une erreur lors de l'installation du volume \\smb-server\share\test2 après le redémarrage du nœud Windows.

Motif : le champ source de StorageClass et PersistentVolume ne doit utiliser le partage racine que pour un serveur SMB dans un cluster. En outre, vous devez utiliser la propriété volumeMounts.subPath dans le déploiement.

Solution : n'utilisez que \\smb-server\share comme source.

Pour consulter d'autres problèmes connus, accédez à la page Problèmes connus du pilote Open Source CSI SMB pour Kubernetes.

Étape suivante