Notre expérience dans le développement de pilotes CSI dans Kubernetes pour Yandex.Cloud

Nous sommes heureux d'annoncer que la société « Flant » renforce sa contribution aux outils Open Source pour Kubernetes en lançant la version alpha du pilote CSI (Container Storage Interface) pour Yandex.Cloud.

Mais avant de passer aux détails de mise en œuvre, répondons à la question de l'utilité de cela, étant donné que Yandex propose déjà le service Managed Service for Kubernetes.

Introduction

Pourquoi faire cela ?

Au sein de notre entreprise, depuis le tout début de l'exploitation de Kubernetes en production (c'est-à-dire depuis plusieurs années), nous développons notre propre outil (deckhouse), que nous prévoyons également de rendre disponible prochainement en tant que projet Open Source. Grâce à cela, nous configurons et paramétrons uniformément tous nos clusters, et actuellement, nous en avons déjà plus de 100, sur des configurations matérielles très diverses et dans tous les services cloud disponibles.

Les clusters utilisant deckhouse comportent tous les composants nécessaires au bon fonctionnement : équilibrages de charge, surveillance avec des graphiques, des métriques et des alertes pratiques, authentification des utilisateurs via des fournisseurs externes pour accéder à tous les dashboards, etc. Un cluster aussi « avancé » n'a pas de sens à déployer dans une solution gérée, car cela est souvent soit impossible, soit nécessite de désactiver la moitié des composants.

NB: C'est notre expérience, qui est assez spécifique. Nous ne prétendons en aucun cas que tout le monde devrait déployer des clusters Kubernetes par leurs propres moyens au lieu d'utiliser des solutions toutes faites. À propos, nous n'avons pas d'expérience réelle d'exploitation de Kubernetes de la part de Yandex et nous ne donnerons pas d'évaluation de ce service dans cet article.

Qu'est-ce que c'est et pour qui ?

Donc, nous avons déjà parlé de l'approche moderne des stockages dans Kubernetes : comment fonctionne le CSI et comment la communauté est arrivée à cette approche.

Actuellement, de nombreux grands fournisseurs de services cloud ont développé des pilotes pour utiliser leurs disques « cloud » comme Persistent Volume dans Kubernetes. Si le fournisseur n'a pas de tel pilote mais que toutes les fonctionnalités nécessaires sont disponibles via une API, rien n'empêche de développer un pilote par leurs propres moyens. C'est ce que nous avons fait avec Yandex.Cloud.

Nous avons pris comme base pour le développement le pilote CSI pour le cloud DigitalOcean et quelques idées du pilote pour GCP, car l'interaction avec les API de ces clouds (Google et Yandex) présente plusieurs similitudes. En particulier, l'API de GCP, et celle de Yandex retourne l'objet Opération pour suivre l'état des opérations longues (par exemple, la création d'un nouveau disque). Pour interagir avec l'API de Yandex.Cloud, le SDK Yandex.Cloud Go SDK.

Le résultat du travail effectué est publié sur GitHub et peut être utile à ceux qui, pour une raison quelconque, utilisent leur propre installation de Kubernetes sur des machines virtuelles de Yandex.Cloud (mais pas un cluster géré) et souhaiteraient utiliser (commander) des disques via CSI.

Mise en œuvre

Fonctionnalités principales

Actuellement, le pilote prend en charge les fonctionnalités suivantes :

• Commande de disques dans toutes les zones du cluster selon la topologie des nœuds présents dans le cluster ;
• Suppression des disques commandés auparavant ;
• Redimensionnement hors ligne pour les disques (Yandex.Cloud ne prend pas en charge augmentation des disques qui sont montés sur la machine virtuelle). Pour savoir comment le pilote a dû être modifié afin de réaliser le redimensionnement de manière aussi indolore que possible, voir ci-dessous.

À l'avenir, nous prévoyons d'implémenter la prise en charge de la création et de la suppression de snapshots de disques.

La principale difficulté et sa surmontée

L'absence dans l'API de Yandex.Cloud de la possibilité d'augmenter les disques en temps réel — une limitation qui complique l'opération de redimensionnement pour PV (Volume Persistant) : car dans ce cas, il est nécessaire que le pod d'application utilisant le disque soit arrêté, ce qui peut entraîner un temps d'arrêt de l'application.

Selon de la spécification CSI, si le contrôleur CSI indique qu'il peut effectuer le redimensionnement des disques uniquement « hors ligne » (VolumeExpansion.OFFLINE), le processus d'augmentation du disque doit être le suivant :

Si le plugin n'a que VolumeExpansion.OFFLINE capacité d'expansion et que le volume est actuellement publié ou disponible sur un nœud, alors ControllerExpandVolume DOIT être appelé UNIQUEMENT après l'une des conditions suivantes :

• Le plugin a un contrôleur capacité PUBLISH_UNPUBLISH_VOLUME et ControllerUnpublishVolume a été invoqué avec succès. OU ALORS

Le plugin n'a PAS de capacité de contrôleur, le plugin a un nœud

• capacité STAGE_UNSTAGE_VOLUME, et capacité PUBLISH_UNPUBLISH_VOLUME et NodeUnstageVolume a été terminé avec succès. capacité, ni nœud NodeUnpublishVolume a été terminé avec succès.

Le plugin n'a PAS de capacité de contrôleur, le plugin a un nœud

• capacité STAGE_UNSTAGE_VOLUME, et capacité PUBLISH_UNPUBLISH_VOLUME et En substance, cela signifie la nécessité de détacher le disque de la machine virtuelle avant de l'augmenter. a été terminé avec succès. capacité, ni nœud Cependant, malheureusement, les spécifications CSI via des sidecars ne répondent pas à ces exigences :

Dans le conteneur sidecar

csi-attacher implémentation , qui est supposé assurer la présence du bon intervalle entre les montages, cette fonctionnalité n'est tout simplement pas réalisée lors du redimensionnement hors ligne. Cette discussion a été lancée

• Dans le conteneur sidecar csi-attacher, qui est censé garantir l'espace nécessaire entre les montages, cette fonctionnalité n'est tout simplement pas implémentée lors du redimensionnement hors ligne. La discussion à ce sujet a été initiée ici.
• Qu'est-ce qu'un conteneur sidecar dans ce contexte ? Le plugin CSI ne s'occupe pas de l'interaction avec l'API Kubernetes, mais réagit uniquement aux appels gRPC que lui envoient les conteneurs sidecar. Ces derniers sont développés sont communautaires Kubernetes.

Dans notre cas (plugin CSI), l'opération d'augmentation du disque se présente comme suit :

1. Nous recevons un appel gRPC ControllerExpandVolume;
2. Nous essayons d'augmenter le disque via l'API, mais nous recevons une erreur indiquant qu'il n'est pas possible d'exécuter l'opération, car le disque est monté ;
3. Nous sauvegardons l'identifiant du disque dans une map contenant les disques pour lesquels l'opération d'augmentation doit être effectuée. Afin de simplifier, nous appellerons cette map volumeResizeRequired;
4. Nous supprimons manuellement le pod qui utilise le disque. Kubernetes le redémarrera alors. Pour nous assurer que le disque n'est pas monté (ControllerPublishVolume) avant la fin de l'opération d'augmentation lors de la tentative de montage, nous vérifions que ce disque est toujours dans volumeResizeRequired et nous retournons une erreur ;
5. Le driver CSI essaie de réexécuter l'opération de redimensionnement. Si l'opération réussit, nous supprimons le disque de volumeResizeRequired;
6. Comme l'identifiant du disque est absent dans volumeResizeRequired, ControllerPublishVolume réussit, le disque est monté, le pod redémarre.

Tout cela semble assez simple, mais comme toujours, il y a des pièges. L'augmentation des disques est gérée par external-resizer, qui, en cas d'erreur lors de l'exécution de l'opération utilise une file d'attente avec un temps d'attente exponentiel jusqu'à 1000 secondes :

func DefaultControllerRateLimiter() RateLimiter {
  return NewMaxOfRateLimiter(
  NewItemExponentialFailureRateLimiter(5*time.Millisecond, 1000*time.Second),
  // 10 qps, 100 bucket size. C'est seulement pour la vitesse de réessaie et c'est juste le facteur global (pas par élément)
  &BucketRateLimiter{Limiter: rate.NewLimiter(rate.Limit(10), 100)},
  )
}

Cela peut occasionnellement faire en sorte que l'opération d'augmentation de disque s'étale sur 15 minutes ou plus, entraînant ainsi l'indisponibilité du pod correspondant.

La seule option qui nous a permis de réduire facilement et sans douleur le temps d'arrêt potentiel a été d'utiliser notre propre version de external-resizer avec une limite d'attente maximale de 5 secondes:

workqueue.NewItemExponentialFailureRateLimiter(5*time.Millisecond, 5*time.Second)

Nous n'avons pas jugé nécessaire de déclencher de manière urgente une discussion ou de patcher external-resizer, car le redimensionnement hors ligne des disques est un vestige qui disparaîtra bientôt chez tous les fournisseurs de cloud.

Comment commencer à utiliser ?

Le driver est supporté dans Kubernetes version 1.15 et supérieure. Pour que le driver fonctionne, les exigences suivantes doivent être remplies :

• Drapeau --allow-privileged défini sur true pour l'API du serveur et kubelet ;
• Activé --feature-gates=VolumeSnapshotDataSource=true,KubeletPluginsWatcher=true,CSINodeInfo=true,CSIDriverRegistry=true pour l'API du serveur et kubelet ;
• La propagation de montage (mount propagation) doit être activée dans le cluster. Lors de l'utilisation de Docker, le démon doit être configuré pour autoriser les objets de montage partagés (shared mounts).

Tous les étapes nécessaires à l'installation proprement dite sont décrites dans le README. L'installation consiste à créer des objets dans Kubernetes à partir de manifests.

Pour que le pilote fonctionne, vous aurez besoin de :

• Indiquer dans le manifeste l'identifiant de répertoire (folder-id) de Yandex.Cloud (voir la documentation);
• . Pour interagir avec l'API de Yandex.Cloud dans le pilote CSI, un compte de service est utilisé. Dans le manifeste Secret, il est nécessaire de transmettre les clés d'autorisation du compte de service. Dans la documentation est décrit, il est expliqué comment créer un compte de service et obtenir des clés.

En général — essayez, et nous serons ravis de recevoir des retours et de nouveaux problèmes, si vous rencontrez des soucis !

Support ultérieur

En guise de conclusion, nous tenons à souligner que ce pilote CSI a été développé non par un grand désir de s'amuser à écrire des applications en Go, mais par une nécessité pressante au sein de l'entreprise. Nous ne considérons pas qu'il soit judicieux de maintenir notre propre implémentation, donc si Yandex montre de l'intérêt et décide de continuer à soutenir le pilote, nous transmettrons volontiers le dépôt à leur disposition.

De plus, il est probable que Yandex ait sa propre implémentation du pilote CSI dans son cluster Kubernetes managé, qu'il pourrait publier en Open Source. Ce développement nous semble également favorable — la communauté pourrait utiliser un pilote éprouvé du fournisseur de services, et non d'une société tierce.

P.S.

Lisez aussi dans notre blog :

• «Plugins de volumes pour le stockage dans Kubernetes : de Flexvolume à CSI»;
• «Comprendre l'Interface de Stockage des Conteneurs (dans Kubernetes et au-delà)»;
• «Préparer un cluster Kubernetes est-il simple et pratique ? Nous annonçons l'addon-operator»;
• «Élargir et compléter Kubernetes (aperçu et vidéo de la présentation)».

Source : habr.com