Utiliser des disques SSD locaux

Cette page décrit la compatibilité avec les disques SSD locaux dans Kubernetes et l'utilisation des disques SSD locaux avec Google Kubernetes Engine (GKE).

Aperçu

Les disques SSD locaux offrent un stockage éphémère hautes performances à chaque nœud du cluster. Ils assurent un débit plus élevé et une latence plus faible que les disques standards. Les disques SSD locaux fonctionnent bien dans les charges de travail qui fournissent une mise en cache et un traitement locaux.

Vous pouvez créer des pools de nœuds dotés de disques SSD locaux dans les limites inhérentes au type de machine de votre cluster et selon les quotas de votre projet.

  • Les données écrites sur un disque SSD local sont éphémères et ne persistent pas lorsque le nœud est supprimé, réparé, mis à niveau ou présente une erreur non récupérable.

  • Un disque SSD local est associé à un seul nœud, et les nœuds eux-mêmes sont éphémères. Une charge de travail peut être programmée sur un nœud différent à tout moment.

Pour plus d'informations sur les avantages et les limites des disques SSD locaux, consultez la section Disques SSD locaux dans la documentation Compute Engine.

Créer un cluster avec des disques SSD locaux

Vous pouvez créer ou mettre à jour un cluster pour utiliser des disques SSD locaux à l'aide de Google Cloud Console ou de l'outil de ligne de commande gcloud.

Console

Vous pouvez créer un cluster ou un pool de nœuds doté de disques SSD locaux à partir du menu GKE dans Cloud Console.

Pour créer un cluster dans lequel le pool par défaut utilise des disques SSD locaux :

  1. Accédez au menu Google Kubernetes Engine de Cloud Console.

    Accéder au menu Google Kubernetes Engine

  2. Cliquez sur le bouton Créer un cluster.

  3. Dans le volet de navigation, sous pools de nœuds, cliquez sur default-pool.

  4. Dans le champ Nombre de nœuds, saisissez 2.

  5. Dans le volet de navigation, sous default-pool, cliquez sur Nœuds.

  6. Développez le menu Plate-forme du processeur et GPU.

  7. Dans le champ Disques SSD locaux, indiquez le nombre de disques SSD souhaité sous la forme d'un nombre absolu.

  8. Cliquez sur Créer.

Pour créer un pool de nœuds avec des disques SSD locaux dans un cluster existant :

  1. Accédez au menu Google Kubernetes Engine de Cloud Console.

    Accéder au menu Google Kubernetes Engine

  2. Sélectionnez le cluster souhaité.

  3. Cliquez sur Modifier.

  4. Sous Pools de nœuds, cliquez sur Ajouter un pool de nœuds.

  5. Dans le champ Taille, saisissez 1.

  6. Dans le champ Disques SSD locaux (par nœud), indiquez le nombre de disques SSD souhaité sous forme de nombre absolu.

  7. Cliquez sur Save.

gcloud

Pour créer un cluster ou un pool de nœuds doté de disques SSD locaux à l'aide de gcloud, spécifiez l'indicateur --local-ssd count. Le paramètre --local-ssd-count indique le nombre de disques SSD locaux à créer par nœud. Le nombre maximal varie selon le type de machine et la région. Lors de la création des nœuds, les disques SSD locaux sont automatiquement formatés et installés sur le système de fichiers du nœud à des points d'installation tels que /mnt/disks/ssd0 pour le premier disque, /mnt/disks/ssd1 pour le deuxième disque, etc.

Pour créer un cluster dans lequel le pool par défaut utilise des disques SSD locaux, exécutez la commande suivante :

gcloud container clusters create cluster-name \
  --num-nodes 2 \
  --local-ssd-count number-of-disks

Pour créer un pool de nœuds avec des disques SSD locaux dans un cluster existant, exécutez la commande suivante :

gcloud container node-pools create pool-name \
  --cluster cluster-name \
  --num-nodes 1 \
  --local-ssd-count number-of-disks

Remplacez l'élément suivant :

  • cluster-name : nom du cluster.
  • pool-name : nom de votre nouveau pool de nœuds.
  • number-of-disks : nombre de disques SSD locaux à provisionner sur chaque nœud.

Créer un pool de nœuds à l'aide d'un stockage éphémère sur des disques SSD locaux

À partir de la version 1.18, un pool de nœuds GKE peut être configuré pour utiliser un disque SSD local pour un stockage éphémère.

Pour créer un pool de nœuds à l'aide d'un stockage éphémère sur des disques SSD locaux, exécutez la commande suivante :

gcloud beta container node-pools create pool-name \
    --ephemeral-storage local-ssd-count=number-of-disks

Remplacez l'élément suivant :

  • pool-name : nom de votre nouveau pool de nœuds.
  • number-of-disks : nombre de disques SSD locaux à provisionner sur chaque nœud.

Les nœuds du pool de nœuds sont créés avec le libellé cloud.google.com/gke-ephemeral-storage-local-ssd. Vous pouvez vérifier les libellés en exécutant la commande suivante :

kubectl describe node node-name

Formater des disques SSD locaux pour les clusters Windows Server

Lorsque vous utilisez des disques SSD locaux avec vos clusters exécutant des pools de nœuds Windows Server, vous devez vous connecter au nœud et formater le disque avant de l'utiliser. Dans l'exemple suivant, le disque SSD local est formaté avec le système de fichiers NTFS. Vous pouvez également créer des répertoires sous le disque. Dans cet exemple, les répertoires se trouvent sous le disque D.

PS C:\> Get-Disk | Where partitionstyle -eq 'raw' | Initialize-Disk -PartitionStyle MBR -PassThru | New-Partition -AssignDriveLetter -UseMaximumSize | Format-Volume -FileSystem ntfs -Confirm:$false
PS C:\> mkdir D:\test-ss

Utiliser des disques SSD locaux

La section suivante explique comment utiliser des disques SSD locaux avec GKE.

Vous pouvez accéder aux disques SSD locaux selon l'une des méthodes suivantes :

  • Utiliser des volumes hostpath, recommandés pour :

    • les charges de travail qui utilisent des contrôleurs DaemonSet ;
    • les charges de travail qui utilisent des pools de nœuds dédiés. Tous les disques SSD locaux doivent être accessibles via le même chemin sur toutes les instances d'un contrôleur DaemonSet.
  • Utiliser local PersistentVolumes, qui est recommandé pour :

    • les charges de travail qui utilisent des contrôleurs StatefulSet et une liste volumeClaimTemplates ;
    • les charges de travail qui partagent des pools de nœuds. Chaque disque SSD local peut être réservé via un objet PersistentVolumeClaim (PVC), et les chemins d'accès à l'hôte spécifiques ne sont pas directement codés dans la spécification du pod ;
    • les pods présentant une exigence de gravité des données sur le même disque SSD local. Un pod est toujours programmé sur le même nœud que son volume persistant local.
  • Utiliser le stockage éphémère en tant queVolume ‌emptyDir (disponible dans la version bêta de GKE 1.18 et ultérieure), qui est recommandée pour :

    • Applications nécessitant un espace de travail éphémère hautes performances.

    Cette fonctionnalité configure un pool de nœuds pour installer le stockage éphémère des nœuds sur le disque SSD local. Les pods utilisant emptyDir utilisent de manière transparente le disque SSD local. Toutefois, cela s'applique à tous les pods de tous les nœuds de ce pool. Certains pods ne peuvent pas utiliser de volumes emptyDir SSD locaux ou de volumes emptyDir conventionnels. Pour les charges de travail qui ne doivent pas utiliser de volumes emptyDir conventionnels, planifiez ces charges de travail sur un pool de nœuds différent.

Exemples utilisant des volumes hostPath

Les exemples suivants vous montrent comment utiliser les volumes hostPath pour Windows et Linux.

Linux

Si vous créez un pool de nœuds avec trois disques SSD locaux, le système d'exploitation hôte installe les disques sur /mnt/disks/ssd0, /mnt/disks/ssd1 et /mnt/disks/ssd2. Vos conteneurs Kubernetes accèdent aux disques à l'aide du paramètre hostPath défini dans le fichier de configuration de votre objet.

Cet exemple de fichier de configuration de pod fait référence à un disque SSD local, /mnt/disks/ssd0 :

apiVersion: v1
kind: Pod
metadata:
  name: "test-ssd"
spec:
  containers:
  - name: "shell"
    image: "ubuntu:14.04"
    command: ["/bin/sh", "-c"]
    args: ["echo 'hello world' > /test-ssd/test.txt && sleep 1 && cat /test-ssd/test.txt"]
    volumeMounts:
    - mountPath: "/test-ssd/"
      name: "test-ssd"
  volumes:
  - name: "test-ssd"
    hostPath:
      path: "/mnt/disks/ssd0"
  nodeSelector:
    cloud.google.com/gke-local-ssd: "true"

Windows

apiVersion: v1
kind: Pod
metadata:
  name: "test-ssd"
spec:
  containers:
  - name: "test"
    image: "mcr.microsoft.com/windows/servercore/iis"
    volumeMounts:
    - mountPath: "/test-ssd/"
      name: "test-ssd"
  volumes:
  - name: "test-ssd"
    hostPath:
      path: "d:\\test-ssd"
  nodeSelector:
    cloud.google.com/gke-local-ssd: "true"
    kubernetes.io/os: windows

Exemples utilisant des PersistentVolumes locaux

Les disques SSD locaux peuvent être spécifiés en tant que PersistentVolumes.

Vous pouvez créer des volumes persistants à partir de disques SSD locaux manuellement ou en exécutant l'approvisionneur statique de volumes locaux.

Limites

  • Actuellement, l'autoscaling des clusters et le provisionnement dynamique ne sont pas compatibles avec les PersistentVolumes locaux.

  • La mise à niveau d'un cluster GKE ou la réparation de nœuds supprime les instances Compute Engine, et donc toutes les données stockées sur les disques SSD locaux.

  • N'activez pas les mises à niveau automatiques de nœuds ni la réparation automatique de nœuds pour des clusters ou des pools de nœuds utilisant des disques SSD locaux pour les données persistantes. Vous devez d'abord sauvegarder vos données d'application, puis restaurer les données sur un nouveau cluster ou un nouveau pool de nœuds.

  • Les objets PersistentVolume locaux ne sont pas nettoyés automatiquement lorsqu'un nœud est supprimé, mis à niveau, réparé ou réduit. Nous vous recommandons d'analyser et de supprimer régulièrement les objets PersistentVolume locaux obsolètes associés à des nœuds supprimés.

Créer manuellement un PersistentVolume

Vous pouvez créer manuellement un volume persistant pour chaque disque SSD local sur chaque nœud de votre cluster.

Utilisez le champ nodeAffinity dans un objet PersistentVolume pour référencer un disque SSD local sur un nœud spécifique. Par exemple, l'exemple Linux suivant est une spécification de PersistentVolume pour un disque SSD local installé dans /mnt/disks/ssd0 sur le nœud gke-test-cluster-default-pool-926ddf80-f166 :

Linux

apiVersion: v1
kind: PersistentVolume
metadata:
  name: "example-local-pv"
spec:
  capacity:
    storage: 375Gi
  accessModes:
  - "ReadWriteOnce"
  persistentVolumeReclaimPolicy: "Retain"
  storageClassName: "local-storage"
  local:
    path: "/mnt/disks/ssd0"
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: "kubernetes.io/hostname"
          operator: "In"
          values: "gke-test-cluster-default-pool-926ddf80-f166"

Windows

apiVersion: v1
kind: PersistentVolume
metadata:
  name: ssd-local-pv
spec:
  capacity:
    storage: 375Gi
  accessModes:
  - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: local-storage
  local:
    path: "d:\\test-ssd"
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - gke-gke-cluster-windows-dds-2263bc7c-wq6m
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: ssd-local-claim
spec:
  accessModes:
  - ReadWriteOnce
  storageClassName: local-storage
  resources:
    requests:
      storage: 37Gi

Vous pouvez maintenant créer un pod pour accéder au disque. Pour faire en sorte que vos pods soient correctement programmés sur des nœuds Windows Server, vous devez ajouter un sélecteur de nœuds à votre spécification de pod :

apiVersion: v1
kind: Pod
metadata:
  name: "test-ssd"
spec:
  containers:
  - name: "test"
    image: "mcr.microsoft.com/windows/servercore/iis"
    volumeMounts:
    - mountPath: "/test-ssd/"
      name: "test-ssd"
  volumes:
  - name: "test-ssd"
    persistentVolumeClaim:
      claimName: ssd-local-claim
  nodeSelector:
    cloud.google.com/gke-local-ssd: "true"
  tolerations:
  - key: "node.kubernetes.io/os"
    value: "windows"
    operator: "Equal"
    effect: "NoSchedule"

Si vous supprimez le volume persistant, vous devez effacer manuellement les données du disque.

Exécuter l'approvisionneur statique de volumes locaux

Vous pouvez créer automatiquement des volumes persistants pour les disques SSD locaux à l'aide de l'approvisionneur statique de volumes locaux. L'approvisionneur est un DaemonSet qui gère les disques SSD locaux sur chaque nœud, crée et supprime les PersistentVolumes pour eux et nettoie les données sur le disque SSD local lors de la publication du PersistentVolume.

Pour exécuter l'approvisionneur statique de volumes locaux :

  1. Téléchargez la spécification gke.yaml à partir du dépôt sig-storage-local-static-provisioner, puis modifiez les champs namespace de la spécification selon vos besoins.

    La spécification comprend les éléments suivants :

    • ServiceAccount pour l'approvisionneur
    • ClusterRole et ClusterRoleBindings pour les autorisations permettant :
      • de créer et supprimer des objets PersistentVolume ;
      • d'obtenir des objets Node.
    • ConfigMap avec les paramètres d'approvisionneur pour GKE
    • DaemonSet pour l'exécution de l'approvisionneur
  2. Déployez l'approvisionneur :

    kubectl apply -f gke.yaml
    

Une fois exécuté, il crée un objet PersistentVolume pour chaque disque SSD local du cluster.

Activer la liaison de volume différée

Pour améliorer la programmation, nous vous recommandons de créer également une classe StorageClass avec volumeBindingMode: WaitForFirstConsumer. Cela retarde la liaison de la PersistentVolumeClaim (PVC) jusqu'à la programmation du pod, de sorte qu'un disque SSD local soit choisi à partir d'un nœud approprié pouvant exécuter le pod. Lorsque vous sélectionnez un nœud pour un pod exécutable, ce comportement de programmation amélioré prend en compte les demandes de processeurs et de mémoire du pod, d'affinité des nœuds, d'affinité et d'anti-affinité du pod, de PVC multiples ainsi que les nœuds pour lesquels des disques SSD locaux sont disponibles.

Cet exemple utilise le mode de liaison de volume retardé :

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: "local-scsi"
provisioner: "kubernetes.io/no-provisioner"
volumeBindingMode: "WaitForFirstConsumer"

Lorsque vous utilisez des clusters avec des pools de nœuds Windows Server, vous devez créer une StorageClass, car la StorageClass par défaut utilise ext4 comme type de système de fichiers, qui fonctionne uniquement pour les conteneurs Linux.

Le fichier YAML suivant, intitulé storageclass-name, utilise un disque persistant Compute Engine avec NTFS comme type de stockage de fichiers. Vous pouvez utiliser cette StorageClass lorsque vous travaillez avec des clusters Windows.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: storageclass-name
parameters:
  type: pd-standard
  fstype: NTFS
provisioner: kubernetes.io/gce-pd
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer

Pour créer une StorageClass avec liaison différée, enregistrez le fichier manifeste YAML en tant que fichier local et appliquez-le au cluster à l'aide de la commande suivante :

kubectl apply -f filename

Exemple d'utilisation du stockage éphémère en tant que volume emptyDir

Un pool de nœuds GKE peut être configuré pour utiliser un disque SSD local pour un stockage éphémère, y compris des volumes emptyDir.

Voici un exemple de fichier YAML pour un pod qui utilise un emptyDir et un sélecteur de nœud cloud.google.com/gke-ephemeral-storage-local-ssd. Vous pouvez appliquer une technique semblable pour les objets Deployment ou StatefulSet.

apiVersion: v1
kind: Pod
metadata:
  name: pod-name
spec:
  containers:
    - name: container-name
      image: "k8s.gcr.io/pause"
      resources:
        requests:
          ephemeral-storage: "400Gi"
      volumeMounts:
        - mountPath: /cache
          name: scratch-volume
  nodeSelector:
    cloud.google.com/gke-ephemeral-storage-local-ssd: "true"
  volumes:
    - name: scratch-volume
      emptyDir: {}

Étape suivante