Présentation de Kubernetes CCM (Cloud Controller Manager) pour Yandex.Cloud

Dans la continuité du récent Version du pilote CSI pour Yandex.Cloud, nous publions un autre projet Open Source pour ce cloud - Gestionnaire de contrôleur cloud. CCM est requis non seulement pour le cluster dans son ensemble, mais également pour le pilote CSI lui-même. Les détails sur son objectif et certaines fonctionnalités de mise en œuvre sont sous la coupe.

introduction

Pourquoi est-ce

Les motivations qui nous ont poussé à développer CCM pour Yandex.Cloud coïncident complètement avec celles déjà décrites dans annonce Pilotes CSI. Nous maintenons de nombreux clusters Kubernetes provenant de différents fournisseurs de cloud, pour lesquels nous utilisons un seul outil. Il met en œuvre de nombreuses commodités « contournant » les solutions gérées de ces fournisseurs. Oui, nous avons un cas et des besoins assez particuliers, mais les développements créés grâce à eux pourront être utiles à d'autres utilisateurs.

Qu’est-ce que le CCM exactement ?

Généralement, nous préparons l'environnement qui nous entoure pour le cluster de l'extérieur - par exemple, en utilisant Terraform. Mais il est parfois nécessaire de gérer l'environnement cloud qui nous entoure du cluster. Cette possibilité est prévue, et c'est elle qui est mise en œuvre CCM.

Plus précisément, Cloud Controller Manager propose cinq principaux types d'interaction :

1. Cas – implémente une relation 1:1 entre un objet nœud dans Kubernetes (Node) et une machine virtuelle chez le fournisseur de cloud. Pour cela nous :
   • remplissez le champ spec.providerID dans l'objet Node. Par exemple, pour OpenStack CCM, ce champ a le format suivant : openstack:///d58a78bf-21b0-4682-9dc6-2132406d2bb0. Vous pouvez voir le nom du fournisseur cloud et l'UUID unique du serveur (machine virtuelle dans OpenStack) de l'objet ;
   • complément nodeInfo dans l'objet Node informations sur la machine virtuelle. Par exemple, nous spécifions le type d'instance dans AWS ;
   • Nous vérifions la présence d'une machine virtuelle dans le cloud. Par exemple, si un objet Node est entré dans un état NotReady, vous pouvez vérifier si la machine virtuelle existe chez le fournisseur de cloud en providerID. S'il n'y est pas, supprimez l'objet Node, qui autrement resterait pour toujours dans le cluster ;
2. Zones – définit le domaine de défaillance de l'objet Node, afin que le planificateur puisse sélectionner un nœud pour le pod en fonction des régions et des zones du fournisseur de cloud ;
3. Équilibreur de charge – lors de la création d’un objet Service avec type LoadBalancer crée une sorte d'équilibreur qui dirigera le trafic de l'extérieur vers les nœuds du cluster. Par exemple, dans Yandex.Cloud, vous pouvez utiliser NetworkLoadBalancer и TargetGroup à ces fins ;
4. Itinéraire – construit un réseau entre les nœuds, car Selon les exigences de Kubernetes, chaque pod doit avoir sa propre adresse IP et pouvoir atteindre n'importe quel autre pod. A ces fins, vous pouvez utiliser un réseau overlay (VXLAN, GENEVE) ou définir une table de routage directement dans le réseau virtuel du fournisseur cloud :

   

5. Volume – Permet un classement dynamique des PV à l'aide de PVC et SC. Initialement, cette fonctionnalité faisait partie de CCM, mais en raison de sa grande complexité, elle a été déplacée vers un projet distinct, Container Storage Interface (CSI). Nous avons parlé de CSI plus d'une fois écrit et, comme déjà mentionné, même libéré Pilote CSI.

Auparavant, tout le code interagissant avec le cloud se trouvait dans le référentiel Git principal du projet Kubernetes à l'adresse k8s.io/kubernetes/pkg/cloudprovider/providers, mais ils ont décidé d'abandonner cela en raison de l'inconvénient de travailler avec une grande base de code. Toutes les anciennes implémentations ont été déplacées vers référentiel séparé. Pour faciliter le support et le développement ultérieurs, tous les composants communs ont également été déplacés vers référentiel séparé.

Comme pour CSI, de nombreux grands fournisseurs de cloud ont déjà conçu leurs CCM pour exploiter les cloud sur Kubernetes. Si le fournisseur ne dispose pas de CCM, mais que toutes les fonctions nécessaires sont disponibles via l'API, vous pouvez alors implémenter CCM vous-même.

Pour écrire votre propre implémentation de CCM, il suffit d'implémenter Interfaces Go requises.

И C'est ce que nous avons obtenu.

exécution

Comment en es-tu arrivé là

Nous avons commencé le développement (ou plutôt même l'utilisation) avec prêt (!) CCM pour Yandex.Cloud il y a un an.

Cependant, dans cette implémentation, il nous manquait :

• authentification via le jeton JWT IAM ;
• Prise en charge du contrôleur de service.

En accord avec l'auteur (dlisin) dans Telegram, nous avons créé Yandex-cloud-controller-manager et ajouté les fonctions manquantes.

Caractéristiques principales

Actuellement, CCM prend en charge les interfaces suivantes :

• Cas;
• Zones;
• Équilibreur de charge.

À l'avenir, lorsque Yandex.Cloud commencera à fonctionner avec des capacités VPC avancées, nous ajouterons une interface Routes.

LoadBalanacer comme défi principal

Initialement, nous avons essayé, comme d'autres implémentations CCM, de créer une paire de LoadBalancer и TargetGroup pour chaque Service avec type LoadBalancer. Cependant, Yandex.Cloud a découvert une limitation intéressante : vous ne pouvez pas utiliser TargetGroups avec intersection Targets (paire SubnetID - IpAddress).

Par conséquent, à l'intérieur du CCM créé, un contrôleur est lancé qui, lorsque les objets changent Node collecte des informations sur toutes les interfaces de chaque machine virtuelle, les regroupe selon leur appartenance à certains NetworkID, crée par TargetGroup sur NetworkID, et surveille également la pertinence. Par la suite, lors de la création d'un objet Service avec type LoadBalanacer nous attachons simplement un pré-créé TargetGroup A nouveau NetworkLoadBalanacer'suis.

Comment commencer à utiliser ?

CCM prend en charge Kubernetes version 1.15 et ultérieure. Dans un cluster, pour que cela fonctionne, il faut que le flag --cloud-provider=external était fixé à true pour kube-apiserver, kube-controller-manager, kube-scheduler et tous les kubelets.

Toutes les étapes nécessaires à l'installation elle-même sont décrites dans README. L'installation se résume à créer des objets dans Kubernetes à partir de manifestes.

Pour utiliser CCM, vous aurez également besoin de :

• préciser dans le manifeste l'identifiant du répertoire (folder-id) Yandex.Cloud ;
• compte de service pour interagir avec l'API Yandex.Cloud. Dans le manifeste Secret nécessaire transférer les clés autorisées du compte de service. Dans le document décrit, comment créer un compte de service et obtenir des clés.

Nous serons heureux de recevoir vos commentaires et nouveaux problèmessi vous rencontrez des problèmes !

Les résultats de

Nous avons utilisé le CCM implémenté dans cinq clusters Kubernetes au cours des deux dernières semaines et prévoyons d'étendre leur nombre à 20 au cours du mois à venir. Nous ne recommandons actuellement pas d'utiliser CCM pour les installations K8 volumineuses et critiques.

Comme dans le cas de CSI, nous serons heureux si les développeurs Yandex prennent en charge le développement et le support de ce projet - nous sommes prêts à transférer le référentiel à leur demande afin de traiter des tâches qui nous concernent plus.

PS

A lire aussi sur notre blog :

• «Notre expérience dans le développement d'un pilote CSI dans Kubernetes pour Yandex.Cloud";
• «Est-il facile et pratique de préparer un cluster Kubernetes ? Annonce de l'opérateur complémentaire";
• «Extension et complément de Kubernetes (revue et rapport vidéo)».

Source: habr.com