Cube sur cube, métaclusters, nids d'abeilles, distribution des ressources

Riz. 1. Écosystème Kubernetes sur Alibaba Cloud

Depuis 2015, Alibaba Cloud Container Service for Kubernetes (ACK) est l'un des services cloud à la croissance la plus rapide d'Alibaba Cloud. Il sert de nombreux clients et prend également en charge l'infrastructure interne d'Alibaba et les autres services cloud de l'entreprise.

Comme pour les services de conteneurs similaires proposés par des fournisseurs de cloud de classe mondiale, nos principales priorités sont la fiabilité et la disponibilité. Par conséquent, une plate-forme évolutive et accessible à l’échelle mondiale a été créée pour des dizaines de milliers de clusters Kubernetes.

Dans cet article, nous partagerons notre expérience de gestion d'un grand nombre de clusters Kubernetes sur une infrastructure cloud, ainsi que l'architecture de la plateforme sous-jacente.

Entrée

Kubernetes est devenu le standard de facto pour une variété de charges de travail dans le cloud. Comme le montre la fig. 1 ci-dessus, de plus en plus d'applications Alibaba Cloud s'exécutent désormais sur des clusters Kubernetes : applications avec et sans état, ainsi que gestionnaires d'applications. La gestion de Kubernetes a toujours été un sujet de discussion intéressant et sérieux pour les ingénieurs qui construisent et entretiennent l'infrastructure. Lorsqu’il s’agit de fournisseurs de cloud comme Alibaba Cloud, la question de la mise à l’échelle se pose au premier plan. Comment gérer les clusters Kubernetes à cette échelle ? Nous avons déjà abordé les meilleures pratiques pour gérer d'énormes clusters Kubernetes de 10 000 nœuds. Bien entendu, il s’agit d’un problème d’échelle intéressant. Mais il existe une autre échelle : la quantité les clusters eux-mêmes.

Nous avons discuté de ce sujet avec de nombreux utilisateurs d'ACK. La plupart d’entre eux choisissent d’exécuter des dizaines, voire des centaines, de clusters Kubernetes de petite ou moyenne taille. Il y a de bonnes raisons à cela : limiter les dégâts potentiels, séparer les clusters pour les différentes équipes, créer des clusters virtuels pour les tests. Si ACK vise à servir un public mondial avec ce modèle d'utilisation, il doit gérer de manière fiable et efficace un grand nombre de clusters dans plus de 20 régions.

Riz. 2. Problèmes de gestion d'un grand nombre de clusters Kubernetes

Quels sont les principaux défis de la gestion des clusters à cette échelle ? Comme le montre la figure, il y a quatre problèmes à résoudre :

• Hétérogénéité

ACK doit prendre en charge différents types de clusters, notamment standard, sans serveur, Edge, Windows et plusieurs autres. Différents clusters nécessitent différentes options, composants et modèles d'hébergement. Certains clients ont besoin d'aide pour la personnalisation de leurs cas spécifiques.

• Différentes tailles de clusters

La taille des clusters varie, de quelques nœuds avec quelques pods à des dizaines de milliers de nœuds avec des milliers de pods. Les besoins en ressources varient également considérablement. Une mauvaise allocation des ressources peut avoir un impact sur les performances, voire provoquer un échec.

• Différentes versions

Kubernetes évolue très rapidement. De nouvelles versions sont publiées tous les quelques mois. Les clients sont toujours prêts à essayer de nouvelles fonctionnalités. Ils souhaitent donc placer la charge de test sur les nouvelles versions de Kubernetes et la charge de production sur les versions stables. Pour répondre à cette exigence, ACK doit continuellement fournir de nouvelles versions de Kubernetes aux clients tout en conservant des versions stables.

• Conformité à la sécurité

Les clusters sont répartis dans différentes régions. À ce titre, ils doivent se conformer à diverses exigences de sécurité et réglementations officielles. Par exemple, un cluster en Europe doit être conforme au RGPD, tandis qu'un cloud financier en Chine doit disposer de couches de protection supplémentaires. Ces exigences sont obligatoires et il est inacceptable de les ignorer, car cela crée d'énormes risques pour les clients de la plateforme cloud.

La plateforme ACK est conçue pour résoudre la plupart des problèmes ci-dessus. Il gère actuellement de manière fiable et stable plus de 10 XNUMX clusters Kubernetes dans le monde. Examinons comment cela a été réalisé, notamment grâce à plusieurs principes clés de conception/architecture.

Conception

Cube sur cube et nid d'abeille

Contrairement à une hiérarchie centralisée, l'architecture basée sur les cellules est généralement utilisée pour faire évoluer une plateforme au-delà d'un seul centre de données ou pour étendre la portée de la reprise après sinistre.

Chaque région d'Alibaba Cloud se compose de plusieurs zones (AZ) et correspond généralement à un centre de données spécifique. Dans une grande région (par exemple Huangzhou), il existe souvent des milliers de clusters clients Kubernetes exécutant ACK.

ACK gère ces clusters Kubernetes à l'aide de Kubernetes lui-même, ce qui signifie que nous disposons d'un métacluster Kubernetes en cours d'exécution pour gérer les clusters Kubernetes clients. Cette architecture est aussi appelée « kube-on-kube » (KoK). L'architecture KoK simplifie la gestion des clusters clients car le déploiement des clusters est simple et déterministe. Plus important encore, nous pouvons réutiliser les fonctionnalités natives de Kubernetes. Par exemple, gérer les serveurs API via le déploiement, en utilisant l'opérateur etcd pour gérer plusieurs etcd. Une telle récursion apporte toujours un plaisir particulier.

Plusieurs métaclusters Kubernetes sont déployés dans une région, en fonction du nombre de clients. Nous appelons ces cellules des métaclusters. Pour se protéger contre la panne d'une zone entière, ACK prend en charge les déploiements multi-actifs dans une seule région : le métacluster distribue les composants maîtres du cluster client Kubernetes sur plusieurs zones et les exécute simultanément, c'est-à-dire en mode multi-actif. Pour garantir la fiabilité et l'efficacité du maître, ACK optimise le placement des composants et garantit que le serveur API et etcd sont proches les uns des autres.

Ce modèle vous permet de gérer Kubernetes de manière efficace, flexible et fiable.

Planification des ressources Metacluster

Comme nous l'avons déjà mentionné, le nombre de métaclusters dans chaque région dépend du nombre de clients. Mais à quel moment ajouter un nouveau métacluster ? Il s’agit d’un problème typique de planification des ressources. En règle générale, il est d'usage d'en créer un nouveau lorsque les métaclusters existants ont épuisé toutes leurs ressources.

Prenons par exemple les ressources réseau. Dans l'architecture KoK, les composants Kubernetes des clusters clients sont déployés sous forme de pods dans un métacluster. Nous utilisons Terway (Fig. 3) est un plugin hautes performances développé par Alibaba Cloud pour la gestion des réseaux de conteneurs. Il fournit un riche ensemble de politiques de sécurité et vous permet de vous connecter aux cloud privés virtuels (VPC) des clients via l'interface réseau élastique (ENI) d'Alibaba Cloud. Pour distribuer efficacement les ressources réseau entre les nœuds, les pods et les services d'un métacluster, nous devons surveiller attentivement leur utilisation au sein du métacluster de nuages ​​privés virtuels. Lorsque les ressources du réseau arrivent à épuisement, une nouvelle cellule est créée.

Pour déterminer le nombre optimal de clusters clients dans chaque métacluster, nous prenons également en compte nos coûts, nos exigences de densité, notre quota de ressources, nos exigences de fiabilité et nos statistiques. La décision de créer un nouveau métacluster est prise sur la base de toutes ces informations. Veuillez noter que les petits clusters peuvent se développer considérablement à l'avenir, de sorte que la consommation de ressources augmente même si le nombre de clusters reste inchangé. Nous laissons généralement suffisamment d'espace libre pour que chaque cluster puisse se développer.

Riz. 3. Architecture du réseau Terway

Mise à l'échelle des composants de l'assistant sur les clusters clients

Les composants de l'Assistant ont des besoins en ressources différents. Ils dépendent du nombre de nœuds et de pods dans le cluster, du nombre de contrôleurs/opérateurs non standards interagissant avec APIServer.

Dans ACK, chaque cluster client Kubernetes diffère en termes de taille et d'exigences d'exécution. Il n'existe pas de configuration universelle pour placer les composants de l'assistant. Si nous définissons par erreur une limite de ressources faible pour un gros client, son cluster ne sera pas en mesure de faire face à la charge. Si vous définissez une limite élevée et prudente pour tous les clusters, des ressources seront gaspillées.

Pour trouver un compromis subtil entre fiabilité et coût, ACK utilise un système de type. À savoir, nous définissons trois types de clusters : petit, moyen et grand. Chaque type possède un profil d'allocation de ressources distinct. Le type est déterminé en fonction de la charge des composants de l'assistant, du nombre de nœuds et d'autres facteurs. Le type de cluster peut changer avec le temps. ACK surveille en permanence ces facteurs et peut effectuer des saisies haut/bas en conséquence. Une fois le type de cluster modifié, l'allocation des ressources est mise à jour automatiquement avec une intervention minimale de l'utilisateur.

Nous travaillons à améliorer ce système avec une mise à l'échelle plus fine et une mise à jour des types plus précise afin que ces changements se produisent plus facilement et aient plus de sens économique.

Riz. 4. Commutation intelligente de type à plusieurs étages

Evolution des clusters clients à grande échelle

Les sections précédentes ont couvert certains aspects de la gestion d'un grand nombre de clusters Kubernetes. Il reste cependant un autre problème à résoudre : l’évolution des clusters.

Kubernetes est le « Linux » du monde du cloud. Il est continuellement mis à jour et devient plus modulaire. Nous devons constamment livrer de nouvelles versions à nos clients, corriger les vulnérabilités et mettre à jour les clusters existants, ainsi que gérer un grand nombre de composants associés (CSI, CNI, Device Plugin, Scheduler Plugin et bien d'autres).

Prenons comme exemple la gestion des composants Kubernetes. Dans un premier temps, nous avons développé un système centralisé d'enregistrement et de gestion de tous ces composants connectés.

Riz. 5. Composants flexibles et enfichables

Avant de continuer, vous devez vous assurer que la mise à jour a réussi. Pour ce faire, nous avons développé un système de vérification de la fonctionnalité des composants. La vérification est effectuée avant et après la mise à jour.

Riz. 6. Vérification préliminaire des composants du cluster

Pour mettre à jour ces composants de manière rapide et fiable, un système de déploiement continu fonctionne avec la prise en charge de l'avancement partiel (niveaux de gris), des pauses et d'autres fonctions. Les contrôleurs Kubernetes standard ne sont pas bien adaptés à ce cas d'utilisation. Par conséquent, pour gérer les composants du cluster, nous avons développé un ensemble de contrôleurs spécialisés, comprenant un plugin et un module de contrôle auxiliaire (gestion side-car).

Par exemple, le contrôleur BroadcastJob est conçu pour mettre à jour les composants sur chaque machine subordonnée ou vérifier les nœuds sur chaque machine. Le travail de diffusion exécute un pod sur chaque nœud du cluster, comme un DaemonSet. Cependant, DaemonSet maintient toujours le pod en marche pendant une longue période, tandis que BroadcastJob le réduit. Le contrôleur de diffusion lance également des pods sur les nœuds nouvellement rejoints et initialise les nœuds avec les composants nécessaires. En juin 2019, nous avons ouvert le code source du moteur d'automatisation OpenKruise, que nous utilisons nous-mêmes au sein de l'entreprise.

Riz. 7. OpenKurise organise l'exécution de la tâche Broadcast sur tous les nœuds

Pour aider les clients à sélectionner les bonnes configurations de cluster, nous fournissons également un ensemble de profils prédéfinis, notamment les profils sans serveur, Edge, Windows et Bare Metal. À mesure que le paysage s'étend et que les besoins de nos clients augmentent, nous ajouterons davantage de profils pour simplifier le processus de configuration fastidieux.

Riz. 8. Profils de cluster avancés et flexibles pour divers scénarios

Observabilité mondiale dans les centres de données

Comme le montre la fig. 9, le service cloud Alibaba Cloud Container a été déployé dans vingt régions du monde. Compte tenu de cette ampleur, l'un des objectifs clés d'ACK est de surveiller facilement l'état des clusters en cours d'exécution afin que si un cluster client rencontre un problème, nous puissions réagir rapidement à la situation. En d'autres termes, vous devez proposer une solution qui vous permettra de collecter efficacement et en toute sécurité des statistiques en temps réel à partir de clusters clients dans toutes les régions - et de présenter visuellement les résultats.

Riz. 9. Déploiement mondial du service Alibaba Cloud Container dans vingt régions

Comme de nombreux systèmes de surveillance Kubernetes, nous utilisons Prometheus comme outil principal. Pour chaque métacluster, les agents Prometheus collectent les métriques suivantes :

• Métriques du système d'exploitation telles que les ressources de l'hôte (CPU, mémoire, disque, etc.) et la bande passante du réseau.
• Métriques pour le système de gestion du métacluster et du cluster client, telles que kube-apiserver, kube-controller-manager et kube-scheduler.
• Métriques de kubernetes-state-metrics et cadvisor.
• métriques etcd telles que le temps d'écriture du disque, la taille de la base de données, le débit des connexions entre les nœuds, etc.

Les statistiques mondiales sont collectées à l'aide d'un modèle d'agrégation multicouche typique. Les données de surveillance de chaque métacluster sont d'abord regroupées dans chaque région, puis envoyées à un serveur central qui affiche une vue d'ensemble. Tout fonctionne grâce au mécanisme de la fédération. Un serveur Prometheus dans chaque centre de données collecte les métriques de ce centre de données, et le serveur Prometheus central est responsable de l'agrégation des données de surveillance. AlertManager se connecte au centre Prometheus et, si nécessaire, envoie des alertes via DingTalk, e-mail, SMS, etc. Visualisation - à l'aide de Grafana.

Dans la figure 10, le système de surveillance peut être divisé en trois niveaux :

• Niveau limite

Le calque le plus éloigné du centre. Le serveur Prometheus Edge s'exécute dans chaque métacluster, collectant les métriques des clusters méta et clients au sein du même domaine réseau.

• Niveau cascade

La fonction de la couche cascade Prometheus est de collecter des données de surveillance provenant de plusieurs régions. Ces serveurs fonctionnent au niveau d'unités géographiques plus grandes comme la Chine, l'Asie, l'Europe et l'Amérique. À mesure que les clusters se développent, la région peut être divisée, puis un serveur Prometheus en cascade apparaîtra dans chaque nouvelle grande région. Avec cette stratégie, vous pouvez évoluer en douceur selon vos besoins.

• Niveau central

Le serveur central Prometheus se connecte à tous les serveurs en cascade et effectue l'agrégation finale des données. Pour des raisons de fiabilité, deux instances centrales de Prometheus ont été créées dans des zones différentes, connectées aux mêmes serveurs en cascade.

Riz. 10. Architecture mondiale de surveillance multi-niveaux basée sur le mécanisme de fédération Prometheus

Résumé

Les solutions cloud basées sur Kubernetes continuent de transformer notre secteur. Le service de conteneur Alibaba Cloud fournit un hébergement sécurisé, fiable et hautes performances - c'est l'un des meilleurs hébergements cloud Kubernetes. L'équipe Alibaba Cloud croit fermement aux principes de l'Open Source et de la communauté open source. Nous continuerons certainement à partager nos connaissances dans le domaine de l'exploitation et de la gestion des technologies cloud.

Source: habr.com