Cette page explique comment configurer le stockage pour les clusters connectés Distributed Cloud, y compris :
Configurer Distributed Cloud connected pour Symcloud Storage
Les nœuds connectés Distributed Cloud n'exposent pas leur stockage local directement à vos charges de travail. Distributed Cloud Connected utilise plutôt Rakuten Symcloud Storage, une solution tierce qui sert de couche d'abstraction de stockage local. Elle s'exécute sur chaque nœud Distributed Cloud Connected et met son stockage local à la disposition des charges de travail exécutées sur tous les nœuds Distributed Cloud Connected d'un cluster.
L'interface CSI (Container Storage Interface, interface de stockage en conteneurs) est une API standard Open Source, compatible avec la plupart des fournisseurs de stockage connus, qui permet à Kubernetes d'exposer des systèmes de stockage arbitraires à des charges de travail conteneurisées. Dans Distributed Cloud connecté, Symcloud Storage est la solution de stockage CSI compatible et gérée. Lorsque Symcloud Storage est activé, les StorageClasses Kubernetes requises sont configurées pour vous. Vous pouvez ensuite configurer vos charges de travail pour qu'elles utilisent la classe de stockage appropriée.
Symcloud Storage est déployé depuis Google Cloud Marketplace et est soumis aux conditions qui y sont énoncées. Google fournit une assistance limitée pour l'utilisation de Symcloud Storage avec Distributed Cloud connecté et peut faire appel au fournisseur tiers pour obtenir de l'aide. Les mises à jour logicielles de Symcloud Storage sont incluses dans les mises à jour logicielles connectées Distributed Cloud.
Cette version de Distributed Cloud Connected est fournie avec Symcloud Storage 6.0.0-226 et est compatible avec cette version. Aucune autre version de Symcloud Storage n'est compatible avec cette version de Distributed Cloud Connected.
Obtenir une licence Symcloud Storage
Vous devez obtenir une licence Symcloud Storage au format YAML sur Google Cloud Marketplace :
Prérequis
Avant de commencer, procédez comme suit :
- Configurez la journalisation et la surveillance pour le projet connecté Distributed Cloud cible.
- Créez le cluster Distributed Cloud connecté cible.
- Configurez votre réseau Distributed Cloud afin que les pods du cluster connecté Distributed Cloud cible puissent accéder au centre de données Google Cloud .
- Associez chaque volume persistant
local-blocksur chaque nœud Distributed Cloud que vous ne souhaitez pas voir être abstrait par Symcloud Storage. Si vous dissociez un volume persistantlocal-blocklié, l'installation de Symcloud Storage efface le contenu de ce volume persistant. Pour obtenir des instructions, consultez la section Liaison de la documentation Kubernetes.
Installer Symcloud Storage sur un nœud connecté Distributed Cloud
Pour installer Symcloud Storage sur un nœud Distributed Cloud connecté, procédez comme suit :
Utilisez la commande suivante pour appliquer la licence Symcloud Storage à votre cluster. Remplacez
LICENSE_FILEpar le chemin d'accès complet et le nom du fichier de licence Symcloud Storage.kubectl apply -f LICENSE_FILE -n robin-admin
Utilisez la commande suivante pour vérifier l'état du service
RobinClusteret de tous les nœuds Symcloud Storage :kubectl describe robinclusters -n robinio
La commande renvoie un résultat semblable à celui-ci :
[...] Status: [...] Phase: Ready robin_node_status: [...] Status: Ready [...] Status: Ready [...] Status: Ready [...]L'état attendu pour le service et les nœuds est
Ready.
Définir Symcloud Storage comme classe de stockage par défaut
Utilisez la commande suivante pour définir Symcloud Storage comme classe de stockage par défaut sur votre cluster connecté Distributed Cloud. Remplacez STORAGE_CLASS par l'une des classes de stockage Symcloud.
kubectl patch storageclass STORAGE_CLASS -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
Pour en savoir plus sur la définition de la classe de stockage par défaut, consultez Modifier la ressource StorageClass par défaut dans la documentation de Kubernetes.
Classes de stockage Symcloud
Cette section décrit les classes de stockage que Symcloud Storage peut activer sur votre cluster connecté Distributed Cloud. Symcloud Storage sur Distributed Cloud Connected n'est pas compatible avec la classe de stockage robin-rwx ni avec les volumes de mode système de fichiers RWX configurés sur mesure.
Pour en savoir plus sur les classes de stockage Symcloud, consultez Utiliser Robin CNS dans Kubernetes.
Classe de stockage robin
La classe de stockage robin est une classe de stockage de base Read Write-Once (RWO). L'exemple suivant illustre l'instanciation de la classe :
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: robin
labels:
app.kubernetes.io/instance: robin
app.kubernetes.io/managed-by: robin.io
app.kubernetes.io/name: robin
provisioner: robin
reclaimPolicy: Delete
allowVolumeExpansion: true
volumeBindingMode: WaitForFirstConsumer
Classe de stockage robin-immediate
La classe de stockage robin-immediate est identique à robin, sauf que le volume persistant est créé immédiatement après la création de la revendication de volume persistant correspondante. L'exemple suivant illustre l'instanciation de la classe :
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: robin-immediate
labels:
app.kubernetes.io/instance: robin
app.kubernetes.io/managed-by: robin.io
app.kubernetes.io/name: robin
provisioner: robin
reclaimPolicy: Delete
allowVolumeExpansion: true
volumeBindingMode: Immediate
Classe de stockage robin-repl-3
robin-repl-3 est une classe de stockage RWO avec trois répliques qui s'étendent sur plusieurs nœuds Distributed Cloud. L'exemple suivant illustre l'instanciation de la classe :
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: robin-repl-3
labels:
app.kubernetes.io/instance: robin
app.kubernetes.io/managed-by: robin.io
app.kubernetes.io/name: robin
provisioner: robin
reclaimPolicy: Delete
allowVolumeExpansion: true
volumeBindingMode: WaitForFirstConsumer
parameters:
replication: "3"
faultdomain: host
Configurer des volumes de stockage Symcloud abstraits pour les charges de travail
Cette section fournit des exemples d'utilisation des classes de stockage Symcloud pour configurer le stockage abstrait pour vos charges de travail Distributed Cloud connectées. Pour en savoir plus sur la configuration des volumes Symcloud Storage, consultez Utiliser Robin CNS dans Kubernetes.
Configurer un volume ext4 RWO en mode système de fichiers
L'exemple suivant montre comment configurer une revendication de volume persistant pour un volume RWO en mode système de fichiers avec le système de fichiers ext4. Remplacez STORAGE_CLASS par l'une des classes de stockage Symcloud.
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: rwo-fs-pvc
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 10Gi
storageClassName: STORAGE_CLASS
Configurer un volume RWO en mode bloc
L'exemple suivant montre comment configurer une revendication de volume persistant pour un volume RWO en mode bloc. Remplacez STORAGE_CLASS par l'une des classes de stockage Symcloud.
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: rwo-block-pvc
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 10Gi
storageClassName: STORAGE_CLASS
volumeMode: Block
Modifier la configuration d'un volume existant
L'exemple suivant montre comment modifier la configuration d'un volume RWO compressé LZ4 Symcloud Storage existant à l'aide d'annotations.
Remplacez STORAGE_CLASS par l'une des classes de stockage Symcloud.
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: compressed-rwo-fs-pvc
annotations:
robin.io/compression: LZ4
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 10Gi
storageClassName: STORAGE_CLASS
L'exemple suivant montre comment modifier la configuration d'un volume RWO Symcloud Storage existant avec le système de fichiers xfs à l'aide d'annotations.
Remplacez STORAGE_CLASS par l'une des classes de stockage Symcloud.
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: rwo-xfs-pvc
annotations:
robin.io/fstype: xfs
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 10Gi
storageClassName: STORAGE_CLASS
Configurer le client CLI Symcloud Storage
Symcloud Storage fournit un client d'interface de ligne de commande (CLI) que vous pouvez utiliser pour gérer votre configuration Symcloud Storage. Pour configurer le client sur votre cluster connecté Distributed Cloud, procédez comme suit :
Obtenez le chemin d'accès à l'image Symcloud Storage utilisée par l'instance de service
RobinClusterdéployée sur votre cluster Distributed Cloud connecté, puis définissez vos variables d'environnement comme suit :image_robin=$(kubectl get robincluster -o jsonpath='{.items[].spec.image_robin}') image_registry_path=$(kubectl get robincluster -o jsonpath='{.items[].spec.image_registry_path}') ROBIN_CNS_IMAGE="$image_registry_path/$image_robin"Créez une ressource
robincliavec le contenu suivant :kind: Deployment apiVersion: apps/v1 metadata: name: robincli namespace: default labels: name: robincli spec: replicas: 1 selector: matchLabels: name: robincli template: metadata: annotations: product: robin labels: name: robincli spec: containers: - name: robincli image: ROBIN_CNS_IMAGE workingDir: /root command: ["/bin/bash","-c","mkdir -p /root/.robin; ln -s -t /usr/lib/python3.7/site-packages/ /opt/robin/current/python3/site-packages/robincli /opt/robin/current/python3/site-packages/stormgr_def.py /opt/robin/current/python3/site-packages/stormgr_lib.py; /opt/robin/current/bin/robin client add-context robin-master.robinio --set-current; while true; do sleep 10000; done"] resources: requests: memory: "10Mi" cpu: "100m"Remplacez
ROBIN_CNS_IMAGEpar le chemin d'accès complet au dépôt et le nom de l'image que vous avez obtenus à l'étape 1.Appliquez la ressource
robinclià votre cluster connecté Distributed Cloud.Lors de l'installation initiale, Symcloud Storage génère un secret
default-admin-userdans l'espace de nomsrobinioavec un mot de passe aléatoire. Utilisez les commandes suivantes pour obtenir ces identifiants de connexion :Obtenez le nom d'utilisateur :
kubectl -n robinio get secret default-admin-user -o jsonpath='{.data.username}' | base64 -dObtenez le mot de passe :
kubectl -n robinio get secret default-admin-user -o jsonpath='{.data.password}' | base64 -d
Connectez-vous au pod que vous venez de créer et exécutez le client :
kubectl exec -it robincli -- bash
Référencer la classe de stockage dans un StatefulSet
L'exemple suivant montre comment référencer une classe de stockage Symcloud dans une charge de travail StatefulSet.
L'exemple suppose que vous utilisez la classe de stockage robin-repl-3 préconfigurée, qui fournit des volumes répliqués sur trois nœuds de calcul distincts pour une haute disponibilité.
Lorsque vous configurez un StatefulSet pour la haute disponibilité, incluez les bonnes pratiques suivantes dans votre configuration :
- Service sans adresse IP de cluster : un StatefulSet nécessite un service sans adresse IP de cluster associé correspondant au champ
serviceName. Un service sans adresse IP de cluster est un service avecclusterIP: None. Ce service attribue des noms d'hôte DNS stables à chaque pod de l'ensemble. - Anti-affinité de pod : si vous utilisez une classe de stockage répliquée comme
robin-repl-3, vos données sont mises en miroir de manière sécurisée sur plusieurs nœuds de calcul. Toutefois, si Kubernetes planifie tous les pods de votre application sur le même nœud de calcul, une panne d'un seul nœud peut entraîner l'arrêt de votre application. La configuration de l'anti-affinité des pods garantit que vos pods sont répartis sur des nœuds de calcul distincts, ce qui permet d'adapter la disponibilité de votre calcul à la redondance de votre stockage.
L'exemple suivant illustre une configuration complète qui inclut le service sans interface graphique (nginx) et un StatefulSet configuré avec une anti-affinité de pod faisant référence à la classe de stockage robin-repl-3. Si les besoins de stockage de votre charge de travail augmentent au fil du temps, vous pouvez redimensionner le volume de manière dynamique en modifiant la demande de stockage dans PersistentVolumeClaim.
statefulset.yaml
apiVersion: v1 kind: Service metadata: name: nginx labels: app: nginx spec: ports: - port: 80 name: web clusterIP: None selector: app: nginx --- apiVersion: apps/v1 kind: StatefulSet metadata: name: web spec: serviceName: "nginx" replicas: 2 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: app operator: In values: - nginx topologyKey: "kubernetes.io/hostname" containers: - name: nginx image: registry.k8s.io/nginx-slim:0.8 volumeMounts: - name: www mountPath: /usr/share/nginx/html volumeClaimTemplates: # Reference the storage class in this specification - metadata: name: www spec: accessModes: [ "ReadWriteOnce" ] resources: requests: storage: 10Gi # Symcloud Storage classes support dynamic volume expansion if more storage is needed storageClassName: robin-repl-3 # References the Symcloud storage class
Limites de Symcloud Storage
Lorsque vous utilisez Symcloud Storage avec Distributed Cloud connecté, vous ne pouvez atteindre une haute disponibilité que si votre cluster Distributed Cloud connecté comporte au moins trois nœuds Distributed Cloud connectés.
Supprimer des nœuds qui utilisent Symcloud Storage d'un cluster
Les répliques de volumes de stockage Symcloud sont stockées sur des nœuds de calcul dans votre cluster connecté Distributed Cloud. Si vous supprimez un nœud du cluster, les données du volume de stockage Symcloud stockées sur ce nœud deviennent indisponibles. Pour éviter cela, vous devez effectuer l'une des opérations suivantes :
- Si vous supprimez l'intégralité du cluster, supprimez les charges de travail et leurs volumes persistants Symcloud Storage correspondants avant de supprimer le cluster lui-même.
- Si vous supprimez des nœuds spécifiques du cluster, vous devez migrer les données de charge de travail stockées sur ces nœuds avant de les supprimer du cluster. Pour obtenir des instructions, consultez Évacuer des volumes d'un disque.
Configurer les schémas de stockage local
Un schéma de stockage est un regroupement logique d'une ou plusieurs partitions. Chaque partition est une unité de stockage logiquement indépendante. Les partitions sont créées de manière séquentielle sur votre cluster jusqu'à ce que l'espace disque physique soit épuisé. Chaque schéma de stockage possède un nom unique qui l'identifie.
Pour créer un schéma de stockage local pour votre cluster connecté Distributed Cloud, vous devez le demander à Google. Une fois que nous avons testé le schéma et l'avons créé sur votre cluster, vous pouvez l'appliquer à l'aide de la CLI gcloud.
Vous ne pouvez pas modifier un schéma après l'avoir appliqué à un cluster. Pour modifier un schéma existant, vous devez demander à Google de le supprimer, puis demander la création d'un nouveau schéma pour le remplacer.
Définir des partitions pour un schéma de stockage local
Avant de pouvoir demander un schéma de stockage local, vous devez d'abord définir les partitions de ce schéma.
Une partition possède les propriétés suivantes :
- Taille Vous pouvez spécifier la taille d'une partition en octets binaires ou utiliser tout l'espace restant sur le disque local.
- Type Vous pouvez configurer une partition en tant que volume persistant Kubernetes (PV) ou volume local Linux sur le disque local.
- Mode : Vous pouvez configurer le volume stocké dans la partition en tant que volume de blocs ou volume de système de fichiers. Pour les partitions de volumes persistants, la classe de stockage de la partition est respectivement
local-blockoulocal-disks. Pour les partitions de volume local, vous pouvez spécifier les points de liaison et de montage pour les systèmes de fichiers contenus.
Demander un schéma de stockage local
Pour demander un nouveau schéma de stockage local pour votre cluster connecté Distributed Cloud, contactez l'assistance Google et indiquez la taille, le type, le mode et, éventuellement, les points de montage et de liaison pour chaque partition que vous souhaitez créer dans le schéma.
Lorsque nous recevons votre demande, nous effectuons une série de tests pour nous assurer de la robustesse du schéma, puis nous le créons sur votre cluster connecté Distributed Cloud.
Schémas de stockage local par défaut
Les navires connectés Distributed Cloud sont fournis avec les schémas de stockage local par défaut suivants :
default_control_plane_node. Ce schéma définit les partitions suivantes :- Partition de volume local de 100 Go en mode système de fichiers.
- Partition de volume persistant en mode bloc qui occupe l'espace disque libre restant.
default_worker_node. Ce schéma définit une partition de volume persistant de 410 Go en mode bloc.
Appliquer un schéma de stockage local à un cluster
Pour appliquer un schéma de stockage local à votre cluster connecté Distributed Cloud, procédez de l'une des manières suivantes :
Pour appliquer un schéma de stockage local aux nœuds du plan de contrôle du cluster, utilisez l'option
--control-plane-node-storage-schemalors de la création du cluster. Pour en savoir plus, consultez Créer un cluster.Pour appliquer un schéma de stockage local aux nœuds de calcul du cluster, utilisez
--node-storage-schemalorsque vous créez un pool de nœuds pour le cluster. Pour en savoir plus, consultez Créer un pool de nœuds.
Distributed Cloud Connected crée les partitions définies dans votre schéma de stockage local une fois le cluster ou le pool de nœuds créé.
Dépannage
Si les PersistentVolumeClaims restent en attente de manière inattendue ou si les charges de travail ne parviennent pas à associer des volumes, suivez les étapes de dépannage listées dans cette section.
Les PersistentVolumeClaims restent en attente
Si vos PersistentVolumeClaims restent à l'état Pending, vérifiez le volumeBindingMode de votre classe de stockage. Les classes de stockage Symcloud préconfigurées utilisent volumeBindingMode: WaitForFirstConsumer, ce qui retarde le provisionnement du volume jusqu'à ce que le pod référençant la revendication soit planifié. Assurez-vous que le pod de votre charge de travail est correctement planifié.
Si la planification du pod est terminée, mais que la revendication reste en attente, ou si l'association du volume échoue, vérifiez l'état du plan de contrôle Symcloud Storage et des daemons au niveau du nœud.
Vérifier l'état du plan de contrôle
Pour vérifier que le plan de contrôle Symcloud Storage est opérationnel et prêt à provisionner des volumes, exécutez la commande kubectl describe pour vérifier l'état de la ressource personnalisée RobinCluster :
kubectl describe robinclusters -n robinio
Dans le résultat de la commande, vérifiez que Phase est défini sur Ready.
Vérifier l'état du daemon de stockage
Pour vérifier que tous les pods de démon de stockage au niveau du nœud sont en cours d'exécution, exécutez la commande kubectl get :
kubectl get pods -n robinio
Dans le résultat de la commande, assurez-vous que tous les pods sont à l'état Running. Si une charge de travail est planifiée sur un nœud avec un pod de démon de stockage défaillant, l'association de volume est suspendue, quel que soit l'état RobinCluster central.
Contacter l'assistance
Si l'état du plan de contrôle Symcloud Storage n'est pas Ready ou si des pods de démon de stockage ne sont pas à l'état Running, contactez l'assistance Google.
Lorsque vous envoyez une demande d'assistance, fournissez les résultats des commandes de dépannage que vous avez exécutées.