Le gestionnaire de contrôleurs cloud Kubernetes

Veuillez noter que ce message a été initialement publié par moi sur medium.com, j'ai depuis décidé de passer à dev.to à la place !

Cet article suppose que vous avez une certaine expérience de l'exploitation/de l'exécution de Kubernetes et de certains concepts du langage de programmation Go.

Depuis un an et demi, nous travaillons beaucoup avec OpenStack et Kubernetes chez Etraveli Group. Nous sommes notre propre fournisseur de cloud et les utilisateurs finaux sont les développeurs et les équipes environnantes de l'organisation de développement.

L'un des composants clés de l'exécution de Kubernetes sur OpenStack est le Cloud Controller Manager. C’est l’une des pièces qui relient les deux plates-formes. Pour ceux d'entre vous qui travaillent avec des services Kubernetes gérés, dans des cloud publics (ou privés d'ailleurs) quelque part, cela sera déjà réglé pour vous. Le plan de contrôle Kubernetes sera plus ou moins hors de portée pour vous.

Alors pourquoi écrire quelque chose sur le Cloud Controller Manager alors ? Le principal moteur a été la plus simple des questions posées par un de mes collègues :

"Que fait le Cloud Controller Manager (OpenStack) de toute façon ?"

J'ai essayé de répondre à la question mais je n'avais pratiquement aucune idée de ce dont je parlais, je savais qu'il était responsable de la création d'un équilibreur de charge dans le cloud sous-jacent lorsqu'un objet Service de typeLoadBalancer est créé.

J'ai immédiatement décidé de creuser un peu et j'ai fini par creuser assez profondément, en essayant de comprendre chaque élément du puzzle et dans cet article, je résumerai mes découvertes.

Tout au long de cet article, je ferai référence :

• Cloud Controller Manager en tant que "CCM"

• Le référentiel principal de code source de Kubernetes sous le nom de "k/k"

• Kubernetes en tant que "k8s"

Au moment où j'ai commencé à écrire cet article, j'ai créé un petit projet et un référentiel dans lequel j'ai construit mon propre Cloud Controller Manager selon les règles et j'ai comparé deux minuscules clusters Kubernetes (v1.18.2), l'un exécutant le CCM et un qui ne le fait pas. Il s’agit d’une preuve de concept et vise à vous montrer exactement ce dont vous aurez besoin pour gérer votre propre CCM. Tout, du code qui constitue le CCM aux manifestes k8, dont vous aurez besoin pour le déployer.

Avant de commencer, il est bon de savoir que cet article renvoie à différentes parties des référentiels de code source de k8s, j'ai utilisé la balise v1.18.0.

Toutes les illustrations sont les miennes.

Profitez !

Veuillez laisser un commentaire ou deux (!), tout commentaire est très apprécié !

Le gestionnaire de contrôleur Cloud

Le Cloud Controller Manager peut être décrit comme trois éléments différents d'un point de vue de haut niveau :

• Un binaire

• Un certain nombre de boucles de contrôle

• Une partie de la colle entre les k8 et votre cloud

En ce qui concerne le code, le CCM fait partie du dépôt k/k, jetez un œil ici. Comme mentionné dans la documentation officielle de k8s, le code du CCM en k/k peut être utilisé comme squelette pour votre propre implémentation. La différence sera le code (packages) que vous fournissez et importez pour interagir avec votre cloud.

Le CCM sera le plus souvent déployé via un manifeste k8s et le binaire intégré dans un conteneur (Docker) extrait d'un registre de conteneurs bien connu.

Il convient de noter que le CCM se verra attribuer le port 10258 et que vous devrez l'exposer, si nécessaire. Prêt à l'emploi, le CCM exposera un point de terminaison /healthz pour vérifier l'état du service.

En parcourant l'organisation k8s dans GitHub, vous trouverez un certain nombre d'implémentations CCM différentes, elles sont également appelées CCM externes car elles vivent en dehors du référentiel k/k et consistent en un ensemble d'interfaces Golang bien conçues comme ainsi que le strict minimum pour que chacun puisse créer son propre CCM.

Nous examinerons tout cela en détail plus tard.

Le cœur du CCM se compose de quatre contrôleurs (cloud) exécutant des boucles de contrôle. Vous pouvez éventuellement exécuter votre ou vos propres contrôleurs aux côtés des autres.

Nous examinerons plus en profondeur chacun des contrôleurs cloud exécutés dans le CCM dans les prochaines sections.

Le contrôleur de nœud

Le contrôleur de nœud s'assure que vos nœuds cloud (par exemple les machines virtuelles) sont étiquetés, entachés et mis à jour avec d'autres informations pertinentes provenant de votre fournisseur de cloud. Le contrôleur effectuera périodiquement les opérations suivantes, dans une liste non ordonnée :

• Initialisez les nouveaux nœuds ajoutés au fournisseur de cloud avec la teinte suivante : node.cloudprovider.kubernetes.io/uninitialized défini sur true et l'effet de teinte sur NoSchedule. Lorsque le nœud est initialisé par le contrôleur de nœud, cette teinte sera supprimée, permettant aux charges de travail d'être planifiées sur le nœud. Les pods qui sont essentiels, par ex. l'exécution du cluster aura bien sûr la tolérance nécessaire pour être planifiée sur des nœuds déjà contaminés.

• Mettez à jour l'adresse IP du nœud en comparant l'adresse IP du fournisseur de cloud avec celle stockée dans l'objet Node de l'API k8s.

• Ajoutez ou mettez à jour les étiquettes des nœuds avec les informations fournies par le cloud, notamment : type d'instance, domaine de défaillance de zone et région de zone. Les informations spécifiques à la zone ne sont pas obligatoires comme nous le verrons plus tard.

Concernant les étiquettes des nœuds et la manière dont les informations sur les instances, mentionnées ci-dessus, sont récupérées et ajoutées aux objets Node. Pour vous donner un exemple, le CCM externe OpenStack le fait soit en lisant les métadonnées à partir du disque (disque de configuration), soit en utilisant le point de terminaison du service de métadonnées accessible dans chaque nœud.

Contrôleur de services

Le contrôleur de service gérera tout ce qui concerne le cycle de vie de l'équilibreur de charge basé sur les objets de service créé dans votre cloud. Un Service fournit un moyen d'exposer votre application en interne et/ou en externe dans la perspective du cluster k8s.

Ce contrôleur particulier ne gérera que les objets Service de type LoadBalancer. Cela signifie, du point de vue du fournisseur de cloud, qu'il garantira qu'un équilibreur de charge quelconque est créé, supprimé et mis à jour dans votre cloud.

En fonction de la manière dont votre CCM a implémenté la logique du contrôleur de service, vous pouvez créer un équilibreur de charge cloud qui uniquement équilibre la charge du trafic réseau en interne dans le cloud. Cela se fait généralement en définissant un ensemble d'annotations dans la section métadonnées de l'objet Service.

Veuillez noter que le comportement par défaut, comme je l'ai noté par ex. OpenStack, c'est que les objets suivants seront créés lors de l'application d'un manifeste d'objet Service simple (de type LoadBalancer) :

• Un équilibreur de charge Cloud avec une liste remplie de nœuds vers lesquels le trafic serait équilibré. L'équilibreur de charge pointera sur chaque nœud en utilisant le NodePort aléatoire généré

• Un objet Service de type NodePort

Comme vu ci-dessus, il y a en fait un certain nombre d'éléments qui composent l'objet Service à la fois dans K8 et dans le fournisseur de cloud. Pour les utilisateurs, cela signifie que la colonne EXTERNAL-IP sera remplie avec l'adresse IP du fournisseur cloud de l'équilibreur de charge cloud. Vu lors de la liste des objets Service à l'aide de kubectl :

$> kubectl get service my-app-svc
NAME       TYPE         CLUSTER-IP    EXTERNAL-IP     PORT(S)
my-app-svc LoadBalancer 172.20.10.100 123.123.123.123 80:31147/TCP

Contrôleur de route

Sur les quatre contrôleurs, il y en a un qui est un peu spécial et c'est le contrôleur de route (Cloud), il ne démarrera que si vous fournissez les indicateurs --allocate-node-cidrs ou --configure-cloud-routes à le CCM. De plus, si vous n'avez implémenté aucune logique de gestion d'itinéraire, ce contrôleur ne démarrera pas, nous en reparlerons plus tard.

Ce contrôleur essaiera périodiquement d'effectuer les opérations suivantes :

• Répertoriez toutes les routes associées à un cluster k8s, cela se fait en interrogeant la ou les API du fournisseur de cloud.

• Répertoriez tous les nœuds en interrogeant l'API k8s.

• Parcourez chaque champ Node et thepodCIDRs de la spécification Node. Le CIDR du pod et le nom du nœud seront utilisés pour créer des routes via la ou les API du fournisseur de cloud.

De plus, pendant la boucle de contrôle, le contrôleur supprimera les itinéraires inutilisés. Lorsque toutes les routes auront été créées, le nœud sera considéré comme prêt, cela signifie que le champ de condition du nœud de NetworkUnavailable sera défini sur false . Si le nœud n’est associé à aucune route, le champ NetworkUnavailable sera défini sur true . Ces conditions sont traduites en souillures par le contrôleur NodeLifeCycle, à ne pas confondre avec celui dont le CCM est responsable.

Contrôleur de cycle de vie

Le contrôleur de cycle de vie (Cloud Node) veillera à ce que vos nœuds, représentés sous forme d'objets de nœud d'API Kubernetes, soient supprimés si les nœuds sont supprimés de votre cloud.

De plus, si un nœud est dans un état d'arrêt spécifié par le fournisseur de cloud, le nœud est corrompu en conséquence par node.cloudprovider.kubernetes.io/shutdown et l'effet de contamination de NoSchedule .

C'est à peu près toutes les fonctionnalités que vous obtiendrez d'un CCM, la plupart du temps, votre cloud peut avoir son propre contrôleur (fourni dans un binaire séparé à partir d'un référentiel séparé) pour gérer les objets k8s de type Ingress , ou vous aider s'intégrer nativement à l'infrastructure réseau sous-jacente.

Le CCM ne sera pas la solution à guichet unique, c'est juste une pièce d'un puzzle plus grand.

Si vous avez suivi et peut-être jeté un œil au code source des différents contrôleurs gérés par le CCM, vous avez peut-être remarqué qu'il n'y a aucun code spécifique au fournisseur de cloud nulle part. Il y a simplement un tas d'appels à des méthodes quelque peu mystérieuses sur divers objets.

Le code spécifique du fournisseur de cloud et son câblage seront la pièce manquante de ce puzzle CCM.

Un regard dans le rétroviseur

Avant de passer au package du fournisseur de cloud (k8s.io/cloud-provider), la pièce manquante du puzzle CCM, nous passerons en revue une partie de l'histoire de CCM et du ou des fournisseurs de cloud. Comment ils ont évolué au fil des années et comment tout est né.

Dès le début, les intégrations cloud ont été un élément fondamental d'une partie des k8, pour des raisons évidentes. Jetons un coup d'œil aux fournisseurs de cloud qui avaient leur code de fournisseur spécifique dans le référentiel k8s (k/k) de la v1.0, publié en juillet 2015 :

• AWS
• GCE
• Mésos
• OpenStack
• Ovirt
• Rackspace
• Vagabond

Vous reconnaîtrez peut-être tous les « fournisseurs de cloud » ci-dessus, certains d'entre eux sont des technologies de virtualisation et ne correspondent pas exactement à ce que nous considérons généralement en tant que fournisseur de cloud. C'est le moins qu'on puisse dire.

En juillet 2015, tout le code spécifique au fournisseur de cloud a été importé et utilisé par le kubelet, l'un des composants de nœud critiques qui composent un nœud de cluster k8s.

Il existe un certain nombre de problèmes avec la mise en œuvre originale du code spécifique au fournisseur de cloud que la communauté des k8 a reconnu et sur lesquels elle travaille jusqu'à présent.

Voici quelques-uns des problèmes qui sont apparus au fil des années :

• Le kubelet ne doit pas exécuter de boucles de contrôle spécifiques au fournisseur de cloud. Ceux-ci ont maintenant été déplacés vers le CCM.

• Les fournisseurs de cloud ne doivent pas faire partie de k/k (in-tree), la raison en est que le code du fournisseur de cloud serait lié au cycle de publication de k8 et que la validation du code dans k/k peut être une tâche fastidieuse.

• Prenez en charge les fournisseurs de cloud externes (hors arborescence) en fournissant un package séparé avec un moyen enfichable d'intégrer votre cloud avec k8s. C'est devenu le package k8s.io/cloud-provider.

• Tout le code du contrôleur cloud utilisé par le CCM doit être déplacé vers le package k8s.io/cloud-provider, il reste encore des restes de code dans l'arborescence qui seront déplacés.

Pour des raisons de compatibilité ascendante, le code qui était dans l'arborescence sera disponible pendant un certain temps, mais il s'agit désormais de son propre package (k8s.io/legacy-cloud-providers).

J'ai essayé de suivre la création du CCM et de k8s.io/cloud-provider en fouillant dans les différents référentiels de l'organisation k8s, presque comme une archéologie numérique. Voici quelques-uns des faits saillants :

• En septembre 2016, le problème d'amélioration n°88 (KEP) est créé pour prendre en charge les fournisseurs de cloud hors arborescence (enfichables).

• Début de la division du gestionnaire de contrôleur (kube) en deux morceaux, octobre 2016. Veuillez noter que ce PR mentionne le volumeController , c'est la période précédant CSI. Ce contrôleur a depuis été supprimé du CCM.

• Discussions sur Cloud Controller Manager en juillet 2017. Passé en version bêta dans la version 1.11.

• Voici une bonne explication sur l’étroitesse du couplage entre kubelet et le fournisseur de cloud. Il existe trois approches pour découpler le kubelet et le fournisseur de cloud.

Le package du fournisseur de cloud

Le package du fournisseur cloud est importé sous k8s.io/cloud-provider dans votre CCM et définit un certain nombre d'interfaces (Golang). La principale est l'interface Interface, qui rend ce package enfichable pour les fournisseurs de cloud.

L'interface définit un ensemble de méthodes, certaines d'entre elles renvoient d'autres interfaces. Ces interfaces renvoyées sont également définies dans le fichier cloud.go du package du fournisseur cloud.

$> kubectl get service my-app-svc
NAME       TYPE         CLUSTER-IP    EXTERNAL-IP     PORT(S)
my-app-svc LoadBalancer 172.20.10.100 123.123.123.123 80:31147/TCP

Comme vous pouvez le voir ci-dessus, les signatures de méthode spécifient une valeur de retour booléenne à côté des interfaces renvoyées, cela signifie que vous pouvez activer/désactiver la fonctionnalité si elle ne peut pas ou ne doit pas être implémentée par le CCM. C'est quelque chose qui sera vérifié lors de l'initialisation du contrôleur qui implémente la fonctionnalité définie par l'interface.

Voici un aperçu rapide des méthodes d'interface k8s.io/cloud-provider utilisées par quel contrôleur :

• Les méthodes de l'interface Instances seront appelées depuis les contrôleurs Node et Lifecycle.

• Les méthodes d'interface Zones seront appelées depuis les contrôleurs Node et Lifecycle.

• Les méthodes de l'interface Route seront appelées depuis le contrôleur Route.

• Les méthodes de l'interface LoadBalancer seront appelées depuis le contrôleur de service.

• L'interface Clusters est utilisée uniquement par le fournisseur cloud externe GCP.

Notez qu'il existe un certain nombre d'endroits dans le référentiel k/k où se trouvent des appels à diverses méthodes dans les interfaces ci-dessus, par ex. à la fois dans le kubelet et sur le serveur API.

Outre les interfaces ci-dessus, le package k8s.io/cloud-provider comprend également tout le nécessaire pour enregistrer et initialiser votre fournisseur de cloud auprès du CCM.

Jetons un coup d'œil à l'interface LoadBalancer, vous verrez un tas de méthodes que vous devez implémenter :

LoadBalancer() (LoadBalancer, bool)
Instances() (Instances, bool)
Zones() (Zones, bool)
Clusters() (Clusters, bool)
Routes() (Routes, bool)

Ces méthodes seront appelées par le contrôleur de service qui s'exécute dans le CCM, je montre ces méthodes à titre d'exemple car vous verrez ces méthodes être appelées dans le code source du contrôleur de service.

Ce qui circule réellement dans le CCM, c'est votre objet instancié qui se comportera comme un fournisseur de cloud (satisfaisant toutes les interfaces du fournisseur de cloud).

C'est ainsi que les contrôleurs cloud gérés par CCM sont capables de créer, mettre à jour et supprimer des ressources dans votre cloud.

Le package k8s.io/cloud-provider ne définira aucun moyen de se connecter et, par ex. authentifiez-vous sur votre cloud. Ce genre de logique est quelque chose que vous devrez intégrer au CCM.

Lorsque vous avez satisfait à toutes les interfaces définies dans le package k8s.io/cloud-provider et que vous avez tout câblé ensemble, vous êtes devenu avec succès un fournisseur de cloud. Il ne reste plus qu'à créer et empaqueter votre binaire CCM dans un conteneur et à le déployer sur k8 !

En ce qui concerne l'avenir, il se passe en fait beaucoup de choses lorsque l'on examine les parties du fournisseur de cloud du référentiel k/k. Au moment d'écrire ces lignes, il y a une initiative en cours pour restructurer et rendre le k8s.io/cloud-provider plus ou moins indépendant. Cela signifie que par ex. les contrôleurs cloud feront partie du package k8s.io/cloud-provider, cela signifie qu'en fin de compte, en tant que fournisseur de cloud, vous importerez un package pour pouvoir créer et implémenter votre propre CCM et fournisseur de cloud externe.

Du point de vue de Kubernetes

Pour pouvoir exécuter votre CCM nouvellement assemblé et emballé dans Docker, vous devez configurer quelques éléments lors de la mise en place du plan de contrôle k8s :

• les kubelet doivent être démarrés avec l'indicateur --cloud-provider=external, cela signale au kubelet qu'il y a un autre contrôleur qui initialise les nœuds.

Comme mentionné au début de cet article, il y a ce référentiel dans lequel je montre et explique l'aspect technique de la gestion de votre propre fournisseur de cloud externe CCM.

Si, disons, vous étiez actuellement sur AWS et que vous développiez votre propre cluster k8s sur des instances EC2 et souhaitiez une intégration plus native à AWS, vous auriez déployé le fournisseur de cloud AWS CCM. Vous pouvez également, bien que cela ne soit pas recommandé, simplement spécifier --cloud-provider=aws sur le kubelet. C'est ainsi que vous signalez aux k8 que vous souhaitez utiliser des fournisseurs de cloud dans l'arborescence, il n'y en a qu'une poignée implémentés. Tout cloud privé/public « plus récent » aurait un fournisseur de cloud externe CCM.

Le code des fournisseurs de cloud dans l'arborescence est importé via k8s.io/legacy-cloud-providers , veuillez noter que lorsque vous utilisez le code squelette CCM de k/k, vous importerez ce package depuis le début .

Ressources

Pour suivre ce qui se passe concernant tout ce qui concerne les fournisseurs de cloud dans le contexte des k8, veuillez consulter ces ressources :

• Fournisseur Cloud SIG

• Chaîne sig-cloud-provider dans l'espace Slack k8s

• Tous les problèmes d'amélioration du k8 étiquetés avec sig/cloud-provider

Voici une liste de fournisseurs de cloud externes, idéale à utiliser comme référence ou si vous êtes simplement curieux de savoir comment d'autres ont fait :

• OpenStack

• DigitalOcéan

• AWS

• GCP

• Alibaba Nuage

• Huawei Cloud

• Nuage Baidu

• vSphère

• Azur

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!