Méthodes de stockage persistées dans Kubernetes

Cet article est basée sur la présentation “Introduction to Kubernetes Storage Primitives for Stateful Workloads” par the {Code} team à la conférence OSS 2017 à Prague.

Commençons par qu’est-ce que Kubernetes ?

Kubernetes

Kubernetes vient du mot grec “Helmsman” qui est également la racine du mot “Gouverneur”

Kubernetes

  • est un orchestrateur de conteneurs
  • supporte plusieurs environnements de conteneur (dont runC de Docker)
  • supporte des clusters bare-metal et dans le cloud
  • est inspiré et profite de l’expérience de Google
  • est OpenSource et écrit en Go

Kubernetes gère des applications, pas des machines !

Separation of Concerns

On peut séparer un système d’information en 4 couches :

  • Applicatif
  • Cluster (Kubernetes se place ici)
  • Kernel/OS
  • Hardware

Idéallement, chacune des couches devrait être remplaçable de manière transparente. Kubernetes applique cette philosophie en se basant principalement sur des APIs.

Les objectifs de Kubernetes

  • Des APIs ouvertes et implémentées
  • Modulaire / remplaçable
  • Ne force pas  les applications à connaître les concepts
    • Spécifiques à un cloud provider
    • Spécifiques à Kubernetes
  • Permets aux utilisateurs de
    • Écrire un code exécutable partout
    • Éviter les vérouillages fournisseur (vendor lock-in)
    • Éviter un couplage lourd de l’applicatif avec l’infrastructure

Étudions maintenant le concept de “pod” dans Kubernetes. C’est l’équivalent d’un “node” dans Docker Swarm.

Les Pods

Un pod est un élément atomique à déployer dans Kubernetes. Il est composé dans ensemble de conteneurs et volumes interconnectés.

Les principales propriétés d’un pod sont :

  • Un namespace partagé
    • les conteneurs partagent une adresse IP et un localhost
    • ils partagent des communications interprocess (IPC), …
  • Un cycle de vie
    • un pod est lié à un noeud, s’il doit être relancé c’est sur le même noeud
    • un pod peut mourir et ne peut être relancé avec le même ID

Par exemple:

Les modifications de fichier dans un conteneur sont liées à l’instance du conteneur uniquement, ainsi si un container crash ou est supprimé on a une perte de donnée. C’est particulièrement problématique pour des applications avec un stockage persistant (stateful apps) ou si des conteneurs ont des fichiers partagés.

L’abstraction de volumes dans Kubernetes permet de résoudre ces deux problèmes.

Les Volumes Kubernetes

Un volume Kubernetes n’est pas la même chose qu’un volume Docker. Dans Docker, un volume est simplement un dossier sur disque ou dans un autre conteneur. Jusque récemment, les cycles de vie n’étaient pas gérés et il s’agissait uniquement de volumes persistés sur disque local. A l’inverse, un volume Kubernetes a un cycle de vie défini.

Un volume Kubernetes est :

  • Un dossier, pouvant contenir des données
  • Accessible par tous les conteneurs d’un pod

Les plugins de volume définissent :

  • Comment un dossier est mis en place
  • Le média qui le stocke
  • Le contenu du dossier

La durée de vie d’un volume est celle d’un pod ou plus long.

Le plus important est que Kubernetes supporte énormément de types de volumes.

Les plugins de volume Kubernetes

Kubernetes propose beaucoup de plugins de volume :

  • Stockage distant :
    • Disque persistant GCE
    • AWS
    • Azure (FileSystem et disque de données)
    • Dell EMC ScaleIO
    • iSCSI
    • Flocker
    • NFS
    • vSphere
    • GlusterFS
    • Ceph File et RBD
    • Cinder
    • Quobyte Volume
    • FibreChannel
    • VMware Photon PD
  • Sockage éphémère :
    • Dossier vide (tmpfs)
    • API Kubernetes exposées :
      • Secret
      • ConfigMap
      • DownwardAPI
  • Stockage local (Alpha)
    • Conteneurs exposant un stockage basé sur du software
  • “Out-of-Tree” (ne faisant pas partie du tronc Kubernetes)
    • Flex (exécution d’un binaire, permet d’utiliser des driver externes)
    • CSI (Cloud Storage Interface, spécification d’API générique définissant un accès de stockage pour des conteneurs, disponinbles dans une release future)
  • Autre :
    • Path sur la machine hôte

Kubernetes étant ouvert, des stockages de tierce partie sont disponibles avec les plugins “out-of-tree”.

Afin d’assurer l’inter-opérabilité des différents orchestrateurs, CloudFoundry, Mesos et Kubernetes travaillent à la standardisation des APIs “out-of-tree” pour le stockage des données d’un containeur avec le CSI.

Exemple GCE PD

Un volume peut être référencé directement, par exemple :

Cependant, référencer directement un volume est “comme se tatouer le prénom de sa copine sur le bras à 16 ans”, ça peut paraître une bonne idée au début car vous pensez que cela durera toujours, mais ce n’est généralement pas le cas !

Persistent volume claim (PVC)

Le principe est de séparer la déclaration d’un volume persistant de son pod.

On déclare d’abord les volumes persistants avec un processus spécifique, puis on rattache le pod à un volume disponible avec le persistent volume claim.

Exemple PV

Créons un volume persistant pv1 avec 10GB et un pv2 avec 100GB, voici la définition de pv2 :

Et voici comment on le créé :

Exemple PVC

Maintenant que nous avons un volume persistant, nous pouvons le rattacher à un container avec PVC :

Lorsqu’un PVC est créé, Kubernetes va rattacher le pod à un volume persistant disponible :

Vous pouvez configurer un PVC directement dans la déclaration d’un pod :

Dynamic Provisioning et StorageClasses

  • Permet de créer un stockage à la demande (lorsque le user en a besoin)
  • Élimine le besoin de pré-création de stockage par un administrateur
  • Les administrateurs de cluster / stockage autorisent le “dynamic provisioning” en créant des “StorageClass”
  • Un StorageClass défini les paramètres à utiliser à la création du volume
  • Les paramètres StorageClass sont découplés de Kubernetes, ainsi les fournisseurs de stockage peuvent exposer autant de paramètres paramètres personnalisés que nécessaire

Voici comment déclarer un StorageClass :

  • L’utilisateur consomme le stockage de la même manière qu’avec un PVC
  • La sélection d’un StorageClass dans un PVC déclanche la création dynamique du volume

Voici comment créer un PVC avec un StorageClass :

L’utilisateur peut ensuite référencer le volume avec un PVC :

Les StorageClass par défaut

Les StorageClass par défault permettent la création dynamique d’un volume même si le StorageClass n’est pas spécifié dans le PVC.

Les StorageClasses pré-installées par défaut sont :

  • Amazon AWS – EBS volume
  • Google Cloud (GCE/GKE) – GCE PD
  • Openstack – Cinder Volume

La fonctionnalité de StorageClass par défaut a été introduite en alpha dans Kubernetes 1.2 (GA depuis la 1.6)

Quel futur pour le stockage Kubernetes ?

Le stockage Kubernetes tend vers :

  • Container Storage Interface (CSI)
    • Standardisation de plugins de volume block et fichier “Out-of-Tree”
  • Stockage local
    • Rendre le stockage local d’un noeud disponible en tant que volume persistant
  • Isolation des capacités
    • Mettre en place des limites afin qu’un unique pod ne puisse consommer toutes les ressources de stockage d’un noeud via overlay FS, des logs, etc.

Impressions

Kubernetes fourni, à travers des APIs et des drivers / plugis, une méthode propre, standardisée et agnostique de déclarer et utiliser un volume dans un conteneur Kubernetes. Avec cette fonctionnalité, vous pouvez facilement et proprement migrer votre FS backend. L’effort de convergence et standardisation de ces plugins avec la CSI poussé par CloudFoundry, Kubernetes est un bon point cependant il y a encore peu d’informations disponibles.

Par |2018-06-05T22:36:50+00:00October 28th, 2017|Open Source Summit Europe 2017|0 commentaire

À propos de l'auteur :

Laisser un commentaire