Cette page explique comment configurer le stockage pour les clusters connectés Distributed Cloud, y compris :
Configurer Distributed Cloud connecté pour Symcloud Storage
Les nœuds connectés Distributed Cloud n'exposent pas directement leur stockage local à vos charges de travail. Au lieu de cela, Distributed Cloud connecté utilise Symcloud Storage de Rakuten, une solution tierce qui fait office de couche d'abstraction de stockage local. Elle s'exécute sur chaque nœud connecté Distributed Cloud et met son stockage local à la disposition des charges de travail exécutées sur tous les nœuds connectés Distributed Cloud d'un cluster.
Container Storage Interface (CSI) 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 gérée et compatible. Lorsque Symcloud Storage est activé, les ressources Kubernetes StorageClasses 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é à partir de Google Cloud Marketplace et est soumis aux conditions qui y sont indiqué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 de Distributed Cloud connecté.
Cette version de Distributed Cloud connecté est fournie avec et prend en charge Symcloud Storage 6.0.0-226. Aucune autre version de Symcloud Storage n'est compatible avec cette version de Distributed Cloud connecté.
Obtenir une licence Symcloud Storage
Vous devez obtenir une licence Symcloud Storage au format YAML à partir de Google Cloud Marketplace :
Prérequis
Avant de commencer, procédez comme suit :
- Configurez la journalisation et la surveillance pour le projet cible Distributed Cloud connecté.
- Créez le cluster cible Distributed Cloud connecté. Vous pouvez surveiller la progression du provisionnement.
- Configurez votre réseau Distributed Cloud afin que les pods du cluster cible Distributed Cloud connecté puissent atteindre le Google Cloud centre de données.
- Liez chaque volume persistant
local-blocksur chaque nœud Distributed Cloud que vous ne souhaitez pas que Symcloud Storage abstrait. 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 dans la documentation Kubernetes.
Installer Symcloud Storage sur un nœud connecté Distributed Cloud
Pour installer Symcloud Storage sur un nœud connecté Distributed Cloud, 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 Symcloud Storage.
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 la section Modifier la ressource StorageClass par défaut dans la documentation Kubernetes.
Classes Symcloud Storage
Cette section décrit les classes de stockage que Symcloud Storage peut activer sur votre cluster connecté Distributed Cloud. Symcloud Storage sur Distributed Cloud connecté n'est pas compatible avec la classe de stockage robin-rwx ni avec les volumes de mode de système de fichiers RWX configurés sur mesure.
Pour en savoir plus sur les classes Symcloud Storage, consultez la section 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éplicas répartis 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 Symcloud Storage abstraits pour les charges de travail
Cette section fournit des exemples d'utilisation des classes Symcloud Storage pour configurer le stockage abstrait pour vos charges de travail connectées Distributed Cloud. Pour en savoir plus sur la configuration des volumes Symcloud Storage, consultez la section Utiliser Robin CNS dans Kubernetes.
Configurer un volume RWO ext4 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 Symcloud Storage.
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 Symcloud Storage.
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.
RemplacezSTORAGE_CLASS par l'une des classes Symcloud Storage.
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.
RemplacezSTORAGE_CLASS par l'une des classes Symcloud Storage.
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 connecté Distributed Cloud et 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 nouvellement créé 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 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 une 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 compagnon
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 en toute sécurité 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é de pod garantit que vos pods sont répartis sur des nœuds de calcul distincts, ce qui fait correspondre la disponibilité de votre calcul à la redondance de votre stockage.
L'exemple suivant illustre une configuration complète qui inclut le service sans adresse IP de cluster (nginx) et un StatefulSet configuré avec une anti-affinité de pod référençant la classe de stockage robin-repl-3. Si les exigences de stockage de votre charge de travail augmentent au fil du temps, vous pouvez redimensionner dynamiquement le volume en modifiant la requête de stockage dans le 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 connecté Distributed Cloud comporte au moins trois nœuds connectés Distributed Cloud.
Supprimer des nœuds qui utilisent Symcloud Storage d'un cluster
Les réplicas de volume Symcloud Storage sont stockés sur des nœuds de calcul de votre cluster connecté Distributed Cloud. Si vous supprimez un nœud du cluster, les données de volume Symcloud Storage stockées sur ce nœud ne sont plus disponibles. Pour éviter cela, vous devez effectuer l'une des opérations suivantes :
- Si vous supprimez l'ensemble 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 la section Évacuer des volumes d'un disque.
Configurer des 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 séquentiellement 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 en faire la demande à 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 une fois qu'il a été 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 une taille de 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 en tant que volume local Linux sur le disque local.
- Mode Vous pouvez configurer le volume stocké dans la partition en tant que volume de bloc ou en tant que volume de système de fichiers. Pour les partitions de volume persistant, 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 d'installation 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 d'installation et de liaison pour chaque partition que vous souhaitez créer dans le schéma.
Lorsque nous recevons votre demande, nous exécutons 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
Distributed Cloud connecté est fourni avec les schémas de stockage local par défaut suivants :
default_control_plane_node. Ce schéma définit les partitions suivantes :- Une partition de volume local de 100 Go en mode système de fichiers.
- Une 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, effectuez l'une des opérations 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 la page Créer un cluster.Pour appliquer un schéma de stockage local aux nœuds de calcul du cluster, utilisez l'option
--node-storage-schemalors de la création d'un pool de nœuds pour le cluster. Pour en savoir plus, consultez la page Créer un pool de nœuds.
Distributed Cloud connecté 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 décrites 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 Symcloud Storage 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 de 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
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 Ready.
Vérifier l'état du daemon de stockage
Pour vérifier que tous les pods de daemon 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 daemon de stockage défaillant, l'association de volume se bloque quel que soit l'état central RobinCluster.
Contacter l'assistance
Si l'état du plan de contrôle Symcloud Storage n'est pas Ready ou si des pods de daemon de stockage ne sont pas à l'état Running, contactez l'Assistance Google.
Lorsque vous envoyez un ticket d'assistance, fournissez les résultats des commandes de dépannage que vous avez exécutées.