Meilleures pratiques concernant le stockage
Découvrez les meilleures pratiques de stockage pour les clusters créés à l'aide de Kubernetes Engine (OKE).
Cette section présente les meilleures pratiques pour le stockage et Kubernetes Engine.
Meilleure pratique : choisir le type de stockage approprié
Nous vous recommandons de prendre en compte le type de charge globale qu'un cluster exécutera avant de choisir un type de stockage approprié pour cette charge globale.
Si vous avez besoin d'un système de fichiers réseau distribué, évolutif et durable, nous vous recommandons d'utiliser le service Oracle Cloud Infrastructure File Storage.
Si vous avez besoin d'un stockage de blocs persistant, durable et hautes performances, nous vous recommandons d'utiliser le service Oracle Cloud Infrastructure Block Volume.
Meilleure pratique : Créer et utiliser des classes de stockage pour définir les besoins des applications
Nous vous recommandons de définir le type de stockage requis à l'aide des classes de stockage Kubernetes, puis de référencer les classes de stockage dans les spécifications de pod et de déploiement. Les définitions de classe de stockage fonctionnent ensemble pour créer le stockage approprié et le connecter aux pods.
Reportez-vous à Configuration du stockage pour les clusters Kubernetes.
Meilleure pratique : Créer et utiliser des volumes pour le stockage persistant
Nous vous recommandons de créer et d'utiliser des volumes persistants pour stocker des données en dehors des conteneurs et éviter toute perte de données.
Le stockage en conteneur via le système de fichiers racine d'un conteneur est éphémère. Il peut disparaître lors de la suppression et de la création de conteneurs. Afin de fournir un emplacement durable destiné à empêcher la perte de données, créez et utilisez des volumes persistants pour stocker les données en dehors des conteneurs.
Lors de la création d'un volume persistant, la documentation Kubernetes recommande d'effectuer les opérations suivantes :
- Toujours inclure les demandes de volume persistant (PVC) dans les configurations de conteneurs.
- Toujours définir une classe de stockage par défaut pour un cluster, sinon les demandes de volume persistant qui ne spécifient pas de classe spécifique échoueront.
- Donnez toujours des noms significatifs aux classes de stockage.
Reportez-vous à Configuration du stockage pour les clusters Kubernetes.
Meilleures pratiques : provisionnement dynamique des volumes
Nous vous recommandons de provisionner dynamiquement des volumes persistants soutenus par le service Block Volume, plutôt que de créer et d'affecter des volumes de manière statique. Le provisionnement dynamique des volumes réduit les frais de gestion et permet la mise à l'échelle.
Nous vous recommandons également d'inclure une stratégie de récupération appropriée dans les définitions de classe de stockage afin de réduire les coûts de stockage inutiles lorsque des pods sont supprimés.
Le provisionnement dynamique n'est pas disponible pour les PV soutenus par le service File Storage.
Reportez-vous à Création d'une demande de volume persistant sur un volume de blocs à l'aide du module d'extension de volume CSI.
Meilleure pratique : utiliser le module d'extension de volume CSI plutôt que le module d'extension de volume FlexVolume
Nous vous recommandons d'utiliser le module d'extension de volume CSI pour provisionner les demandes de volume persistant sur le service Block Volume, plutôt que le module d'extension de volume FlexVolume.
Nous recommandons le module d'extension de volume CSI car :
- La nouvelle fonctionnalité est uniquement ajoutée au module d'extension de volume CSI, et non au module d'extension de volume FlexVolume (même si les développeurs Kubernetes continueront de gérer le module d'extension de volume FlexVolume).
- Le module d'extension de volume CSI ne nécessite pas d'accès aux dépendances sous-jacentes du système d'exploitation et du système de fichiers racine.
La classe de stockage spécifiée pour une demande de volume persistant détermine le module d'extension de volume à utiliser pour la connexion aux volumes de service Block Volume. Deux classes de stockage sont définies par défaut, oci-bv
pour le module d'extension de volume CSI et oci
pour le module d'extension FlexVolume. Si vous n'indiquez pas explicitement de valeur pour storageClassName
dans le fichier YAML qui définit la PVC, la classe de stockage par défaut du cluster est utilisée.
Le moteur Kubernetes définit initialement la classe de stockage par défaut d'un cluster en fonction de la version de Kubernetes indiquée lors de la création du cluster. Dans les clusters créés par Kubernetes Engine pour exécuter Kubernetes version 1.24 (ou ultérieure), la classe de stockage oci-bv
est initialement définie comme valeur par défaut.
Reportez-vous à Création d'une demande de volume persistant sur un volume de blocs à l'aide du module d'extension de volume CSI (et à Modification de la valeur par défaut StorageClass dans la documentation Kubernetes).
Meilleure pratique : limiter la consommation de ressources de stockage
Nous vous recommandons de limiter l'utilisation du stockage par conteneurs afin de refléter la quantité de stockage réellement disponible dans le centre de données local ou le budget disponible pour les ressources de stockage Oracle Cloud.
Vous pouvez limiter la consommation du stockage des conteneurs à l'aide des options suivantes :
- Quotas de ressource pour limiter la quantité de ressources (y compris le stockage, l'UC et la mémoire) que tous les conteneurs d'un espace de noms Kubernetes peuvent utiliser.
- StorageClasses pour limiter la quantité de stockage provisionnée pour les conteneurs en réponse à une demande de volume persistant (PVC).
Reportez-vous à Configuration du stockage pour les clusters Kubernetes (et à Quotas de ressource dans la documentation Kubernetes).
Meilleure pratique : sécuriser et sauvegarder les données
Nous vous recommandons d'utiliser les outils appropriés pour sécuriser et sauvegarder les données.
-
Meilleure pratique : Utilisez un outil comme Velero pour les sauvegardes.
Nous vous recommandons de sauvegarder les données à l'aide d'un outil tel que Velero adapté au type de stockage. Après avoir effectué des sauvegardes, nous vous recommandons de vérifier l'intégrité et la sécurité de ces sauvegardes.
Reportez-vous à Sauvegarde Velero pour Oracle Container Engine for Kubernetes
-
Meilleure pratique : utilisez un outil comme Longhorn pour persister et répliquer des données.
Nous vous recommandons de conserver et de répliquer les données à l'aide d'un outil tel que Longhorn.
Reportez-vous à Réplication de fichiers inter-région avec Longhorn dans Oracle Cloud et Kubernetes.
- Meilleure pratique : Utilisez un outil comme Rackware SWIFT pour activer la sauvegarde et la récupération après sinistre.
Nous vous recommandons d'activer la sauvegarde et la récupération après sinistre entre les clusters Kubernetes dans les régions à l'aide d'un outil tel que Rackware SWIFT.
Reportez-vous à Protection des charges de travail OKE avec la récupération après sinistre en tant que service (DRaaS) pour Oracle Cloud.
Meilleure pratique : utiliser un système de fichiers distribué pour les cas d'utilisation de ReadWriteMany
Nous vous recommandons d'utiliser un système de fichiers distribué (tel que NFS ou le service Oracle Cloud Infrastructure File Storage) lors du provisionnement de demandes de volume persistant pour les cas d'emploi ReadWriteMany.
Le stockage de volume de blocs avec des fonctionnalités hautes performances (telles que le service Oracle Cloud Infrastructure Block Volume) est plus approprié lors du provisionnement de demandes de volume persistant pour les cas d'utilisation de lecture et d'écriture uniques.
Reportez-vous à Configuration du stockage pour les clusters Kubernetes.