Quel est un bon plan de contrôle pour exploiter un grand nombre de clusters Kubernetes ?

Ce blog spécifique décrit comment Volterra aide les utilisateurs à exploiter leurs applications et leur infrastructure comme une flotte. Nous expliquerons comment notre approche basée sur le plan de contrôle facilite les opérations d'une grande flotte de clusters d'applications et la comparerons à d'autres approches de plan de gestion multi-clusters comme Google Anthos, Azure Arc, Rancher, etc.

À présent, vous vous demandez peut-être si nous ne faisons pas simplement un marketing et si nous appelons notre gestion multi-cluster des opérations de flotte ! Les approches de gestion multi-cluster et d’exploitation de flotte répondent à différents cas d’utilisation et sont fondamentalement différentes dans leurs architectures. Une approche multi-cluster est conçue pour répondre aux scénarios dans lesquels il existe relativement peu de clusters et où l'utilisateur souhaite gérer ces clusters d'infrastructure à l'aide d'un modèle opérationnel cohérent. Alors que l'approche de flotte est conçue pour répondre aux scénarios dans lesquels il existe une grande échelle de clusters (par exemple, les clusters K8s dans les robots, l'automobile, les passerelles industrielles, des dizaines de régions de cloud public, etc.) et que l'utilisateur souhaite déployer la même application et le même réseau/la même sécurité sur ces clusters à grande échelle. Les deux sections suivantes décrivent et comparent plus en détail l’approche des opérations multi-clusters et de flotte.

Approche multi-clusters

Une approche de gestion multi-cluster est conçue pour répondre aux cas d’utilisation où il y a relativement peu de clusters sous les opérations d’une seule équipe. Des exemples de tels scénarios incluent des dizaines de clusters répartis sur quelques zones de disponibilité pour réduire le rayon d'explosion. De même, les utilisateurs peuvent choisir d’avoir plusieurs clusters répartis sur quelques régions pour répondre aux besoins réglementaires.

Les deux exemples suivants illustrent le fonctionnement des solutions multi-clusters (à un niveau élevé) :

Configuration

Prenons un exemple de déploiement application utilisant une approche multi-cluster de Rancher comme illustré dans la Figure 1. Dans une approche multi-cluster, le client sélectionne les sites cibles pour le déploiement de application un par un. Cette approche de sélection des sites cibles un par un fonctionne lorsque vous avez quelques clusters. Cependant, cette approche n’est pas conçue pour, disons, un millier de clusters.

Observabilité

La figure 2 illustre comment fonctionne l'observabilité dans une approche multi-cluster, en prenant Rancher comme exemple. Avec cette approche, vous devez double-cliquer sur chaque cluster un par un pour voir l'état des pods déployés ainsi que l'utilisation des ressources CPU et mémoire. Observer les sites cibles un par un fonctionne pour un petit nombre de clusters, mais ne convient pas à la gestion d’un grand nombre de clusters.

Groupe 1 :

Groupe 2 :

Une approche évidente pour résoudre le problème décrit dans le premier exemple serait d’écrire une forme d’automatisation qui répéterait les tâches pour chacun des clusters. Par exemple, chaque fois qu'un nouveau cluster est ajouté, le script peut effectuer l'opération suivante pour déployer une nouvelle application (checkoutservice par exemple)

exporter KUBECONFIG=~/Documents/kubeconfig/ce01-ashburn-aws-staging

kubectl apply -f checkoutservice.yaml

Cependant, nous devons construire l'automatisation pour chaque opération — déploiement, mise à jour, politique, réservation de ressources, etc. Nous devons faire en sorte que cette automatisation exécute chaque opération sur de nombreux clusters tout en gérant les conditions d’échec. Lorsque vous gérez des scénarios complexes — comme des tests bêta sur un sous-ensemble de clusters ou des mises à jour progressives sur tous les clusters — l’automatisation devient naturellement plus complexe. Nous l'avons compris dès le début et avons développé un plan de contrôle distribué qui intègre toutes ces fonctions — en nous appuyant sur une approche d’exploitation de flotte décrite ci-après.

Approche des opérations de flotte de Volterra

Les opérations de flotte signifient que vous définissez votre intention une fois pour l'ensemble, puis le système veille à ce que les sites concernés respectent cette directive. Parmi les intentions figurent la version du logiciel d’application, la version du logiciel d'infrastructure (par exemple, celle du système d’exploitation), la politique réseau, la politique de sécurité et la réservation des ressources.

Une fois l’intention prise, le système permet aux utilisateurs de visualiser l’état et la santé de la flotte. Cela signifie que les utilisateurs obtiennent une vue agrégée de l'état de l'infrastructure et des applications sur tous les sites de la flotte dans une seule fenêtre, réduisant ainsi la complexité opérationnelle pour l'équipe d'exploitation du client. Les utilisateurs n’ont pas besoin de cliquer sur chaque site ou cluster un par un pour déterminer l’état et d’écrire des outils d’automatisation pour regrouper les informations.

L’approche des opérations de flotte de Volterra se compose de trois composants principaux : la segmentation, la configuration et l’observabilité, que nous aborderons dans les sections suivantes.

Segmentation de la flotte

Les utilisateurs disposent souvent d'un mélange de sites dans la flotte, tels que des sites de développement, de test et de calcul de production. Différentes charges de travail doivent être déployées sur un segment spécifique de sites en raison des politiques de l'organisation, telles que les charges de travail de développement ne sont affectées qu'aux sites de développement. Nous permettons aux utilisateurs d'étiqueter de manière flexible les sites avec une étiquette composée de deux parties, clé et valeur. Voici quelques exemples : 

• Étiquette-Clé=région. Étiquette-valeur = US-Ouest, JP-Nord, JP-Sud
   
• année-modèle=(2015, 2016, 2017, 2018)
   
• fonction=(pulvérisation, soudure)

Une fois les sites étiquetés, les utilisateurs peuvent définir un « site virtuel » à l’aide de conditions clé-valeur d’étiquette. Dans un scénario multi-cloud, les utilisateurs peuvent baliser leurs sites comme dev, pre-prod, prod par exemple. La figure 3 suivante montre un exemple de cas d’utilisation de la robotique utilisant les valeurs de clé d’étiquette décrites précédemment.

Voici un extrait de configuration sur Volterra où l'utilisateur peut utiliser la syntaxe blend/go-sdk pour créer un site virtuel. Dans cet exemple particulier, les sites individuels ont été étiquetés avec la clé d'étiquette = ves.io/country et la valeur d'étiquette ves-io-jpn

Les utilisateurs sont habitués à un modèle opérationnel consistant à définir des segments de leur flotte a priori, puis à étiqueter leurs sites au moment de la mise en service pour les inclure dans la flotte ; les sites virtuels s’intègrent parfaitement au modèle opérationnel existant des utilisateurs. Lorsqu'un nouveau site est provisionné avec la balise appropriée, il est automatiquement inclus dans le site virtuel défini précédemment sans nécessiter d'étapes manuelles supplémentaires. De plus, Volterra découvre des informations pré-approvisionnées telles que le fabricant du matériel ou le type de cloud public pour pré-remplir les balises système. Les utilisateurs peuvent éventuellement choisir d’utiliser ces balises découvertes automatiquement pour définir leurs sites virtuels.

Configuration de la flotte

Les capacités de configuration de la flotte peuvent être mieux décrites à travers les trois exemples suivants : 

• Configuration d'une politique réseau/sécurité – Prenons l'exemple d'un client qui déploie un nouveau service qui nécessite la possibilité pour chaque cluster de communiquer avec une URL spécifique, par exemple github.com . En règle générale, les utilisateurs utilisent la liste blanche, ce qui signifie que les clusters ne sont autorisés à atteindre que des destinations spécifiques. Par conséquent, le déploiement de ce nouveau service nécessiterait que les utilisateurs se rendent dans chaque cluster et modifient la politique réseau pour ajouter github.com à la liste blanche. De plus, le client souhaite tester cette solution sur quelques sites tests avant de la déployer sur tous les sites. Pour atteindre cet objectif sur Volterra, le client commence par définir un site virtuel « test » sur la console Volterra SaaS qui sélectionne un segment de la flotte. L'utilisateur définit ensuite une politique réseau telle que la liste blanche des URL ( github.com dans cet exemple) et l'applique au site virtuel « test ». Le plan de contrôle distribué de Volterra envoie la politique réseau au plan de contrôle local sur chaque site sélectionné par le site virtuel (comme défini ci-dessus). Le plan de contrôle local sur chaque site applique la politique réseau et collecte des statistiques sur les règles appliquées par site. Une fois que le client est satisfait du fonctionnement du service comme prévu, il peut alors appliquer la politique réseau au site virtuel « prod » qui sélectionne les sites restants de la flotte. Voici un extrait de configuration utilisant Json et utilisant l'interface utilisateur sur le système de Volterra.

• Mise à niveau du logiciel d'infrastructure - La capacité de configuration de la flotte permet à un utilisateur de mettre à niveau le logiciel d'infrastructure, par exemple la version du système d'exploitation sur l'ensemble de la flotte (ou un segment de la flotte). Tout d’abord, l’utilisateur définit l’intention de mettre à niveau le système d’exploitation de la version 1 à la version 2. Ensuite, l'utilisateur définit une stratégie de déploiement sur l'ensemble de la flotte, comme une mise à jour continue, bleue/verte entre autres. Une mise à jour continue signifie que le système d'exploitation de chaque site de la flotte (ou segment de la flotte) est mis à niveau de manière séquentielle. Une stratégie de déploiement bleu/vert signifie que l'utilisateur souhaite tester la mise à niveau sur un ensemble de sites « bleus » (par exemple, des sites de développement) et comparer l'état avec des sites « verts » (par exemple, des sites de production) qui ne sont pas mis à niveau. Dans les deux cas, le plan de contrôle distribué de Volterra envoie le logiciel version 2 au plan de contrôle local sur chaque site sélectionné par le site virtuel et tel que défini dans la stratégie de déploiement. Le plan de contrôle local sur chaque site met à niveau le système d'exploitation de manière A/B, ce qui signifie qu'il crée une nouvelle partition, déploie la version 2 dans la nouvelle partition et permet au client de mesurer l'état de santé. Si l’installation de la version 2 échoue, le système revient automatiquement à la version 1 dans la partition d’origine. Voici quelques captures d'écran montrant comment l'utilisateur peut effectuer une mise à niveau du logiciel d'infrastructure à l'aide du portail Volterra SaaS. L'utilisateur peut voir la version actuelle du logiciel d'infrastructure et la dernière version du logiciel disponible pour tous les sites, comme indiqué dans la figure suivante. L'utilisateur peut facilement mettre à niveau des sites spécifiques ou tous les sites comme l'exige le modèle opérationnel.

• Déploiement d' applications à l'échelle de la flotte - Volterra fournit un objet appelé Virtual Kubernetes (vK8s) qui permet aux utilisateurs de gérer les applications sur l'ensemble de leur flotte à l'aide des API Kubernetes. L'utilisateur déploie ses applications à l'aide des méthodes Kubernetes standard (c'est-à-dire le fichier Kubeconfig et les API Kubernetes) avec le fichier manifeste de déploiement et indique le segment de sites (ou l'ensemble de la flotte) où l' application doit être déployée. Virtual Kubernetes (vK8s) de Volterra prend alors en charge la responsabilité de déployer l' application sur chaque site (ou segment de) la flotte. En cas de défaillance lors du déploiement de application , comme des défaillances de connectivité ou d'infrastructure, Volterra Virtual Kubernetes continue de réessayer le déploiement en suivant le paradigme Kubernetes d'un modèle finalement cohérent. La capture d'écran suivante montre un exemple de l'utilisateur déployant une application appelée « kuard » (voir Kubernetes-up-and-running-demo-app ) sur un site virtuel appelé « jpn-all-sites » qui sélectionne 140 sites de la flotte. Pour ajouter un nouveau déploiement, l’utilisateur doit simplement ajouter un nouveau déploiement, en cliquant sur « Ajouter un déploiement » et en spécifiant l’emplacement de déploiement en termes de site virtuel.

Si un nouveau site est ajouté à la flotte avec l'étiquette appropriée, le nouveau site est automatiquement ajouté au site virtuel (jpn-all-sites dans cet exemple) et la configuration de la flotte (c'est-à-dire le déploiement Kuard dans cet exemple) est automatiquement appliquée au site nouvellement ajouté, réduisant ainsi la charge des équipes d'exploitation et éliminant les erreurs humaines.

Observabilité de la flotte

Les sites virtuels et Virtual Kubernetes (vK8) ne sont pas seulement utilisés pour la configuration, mais également pour regrouper l'état de santé des sites distribués de la flotte. Il s’agit d’un outil vraiment puissant par rapport à d’autres solutions où les utilisateurs devraient écrire des outils pour obtenir le statut de chaque site un par un et agréger les informations. Le système regroupe automatiquement l’état de santé de tous les sites, dans une seule fenêtre, réduisant ainsi la complexité opérationnelle pour l’équipe d’exploitation du client. L'état de santé collecté comprend de nombreux aspects, tels que l'état de déploiement de application , l'état de santé du site et l'état de santé de application , etc.

Vous pouvez rapidement visualiser l'état de santé de tous vos sites sur une carte comme montré dans la capture d'écran suivante. Les couleurs indiquent si le score de santé dépasse 75 (vert), est compris entre 40 et 75 (orange), ou est inférieur à 40 (rouge). Le score de santé combine des critères de connectivité, fiabilité, sécurité et performances (c’est-à-dire la consommation des ressources).

Les utilisateurs peuvent également voir une vue agrégée de la connectivité sur tous leurs sites ainsi que de l’état du site. L'état de connectivité de chaque lien reliant les sites au réseau principal de Volterra est également illustré comme illustré dans la Figure 10. L'utilisateur peut cliquer sur des liens peu performants en fonction de l'état de santé pour révéler des statistiques détaillées sur les demandes et les erreurs et résoudre les problèmes de connectivité, comme indiqué dans la figure 11.

Vous pouvez ensuite consulter des informations agrégées sur tous les sites, comme la répartition de la charge CPU et mémoire. Ces données aident les équipes informatiques ou les administrateurs de site à identifier les sites très sollicités et ceux risquant une pénurie de ressources. Les administrateurs peuvent paramétrer des alertes pour être prévenus quand la consommation de ressources dépasse les seuils définis. Sur cette capture d'écran, vous voyez que la moitié des sites utilise plus de 75 % de la mémoire disponible. Vous n'avez ni à cliquer sur chaque site ni à développer des outils supplémentaires pour obtenir ces informations.

Les capacités de vérification continue sur l'objet de flotte fournissent l'état des déploiements de POD : combien de POD ont été déployés, sont en cours ou ont échoué. Une fois déployés, les utilisateurs peuvent également visualiser l'état de santé des Pods : s'ils sont en cours d'exécution, en attente d'une image, à court de mémoire, etc.

De plus, les utilisateurs peuvent voir une vue agrégée de l’efficacité de la politique de sécurité et obtenir des hits sur tous leurs sites, comme le montre la capture d’écran suivante.

Résumé

Pour en savoir plus sur la manière dont l'approche d'exploitation de flotte de Volterra a été utilisée pour gérer une flotte de 3 000 clusters, veuillez regarder la présentation de Volterra lors d'une conférence Kubernetes et lire ce blog de Jakub Pavlik

Dans le prochain blog, intitulé « Time to Effect », j’expliquerai comment le plan de contrôle distribué et le backbone de Volterra aident à propager et à assurer la cohérence de la configuration sur les sites distribués à l’échelle mondiale dans un laps de temps très court. Restez à l'écoute!