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 montre comment l’observabilité fonctionne dans une approche multi-cluster en utilisant Rancher comme exemple. Dans une approche multi-cluster, le client doit double-cliquer sur chaque cluster un par un pour voir l'état des pods déployés, l'utilisation des ressources CPU et mémoire. Cette approche consistant à observer les sites cibles un par un est adaptée à un petit nombre de clusters, mais 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, l’automatisation devra être construite pour chaque opération : déploiement, mise à niveau, politique, réservation de ressources, etc. Cette automatisation devra non seulement effectuer l’opération individuelle sur plusieurs clusters, mais également prendre en charge la gestion des conditions de défaillance. De plus, lorsque des scénarios complexes se présentent (par exemple, des tests bêta sur un sous-ensemble de clusters, des mises à niveau progressives sur tous les clusters), l’automatisation devient de plus en plus complexe. Nous avons réalisé cela très tôt dans le processus et avons construit un plan de contrôle distribué qui fournit toutes ces fonctionnalités, en utilisant une approche d’opérations de flotte décrite ci-après.

Approche des opérations de flotte de Volterra

Les opérations de flotte signifient que le client définit de manière déclarative son intention une fois pour toutes pour la flotte, et le système prend en charge la responsabilité de garantir que les sites impactés sont alignés sur l'intention définie. Les exemples d’intention incluent la version du logiciel application , la version du logiciel d’infrastructure (par exemple, la version du système d’exploitation), la politique réseau, la politique de sécurité et la réservation de 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.

Les utilisateurs peuvent obtenir un aperçu rapide de la santé de tous leurs sites sur une carte comme indiqué dans la capture d’écran suivante. La couleur indique si le score de santé est supérieur à 75 (vert), entre 40 et 75 (orange) et rouge s'il est inférieur à 40. Le score de santé est un score agrégé composé de la connectivité, de la fiabilité, de la sécurité et des performances (c'est-à-dire de la consommation de 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.

Ensuite, l’utilisateur peut visualiser les informations agrégées sur tous les sites via la répartition de la charge du processeur et de la mémoire sur les sites. Ces informations sont utiles aux administrateurs informatiques ou de site pour identifier les sites qui sont fortement utilisés et risquent de manquer de ressources. Les administrateurs de site peuvent configurer des alertes pour être avertis lorsque la consommation de ressources dépasse les seuils. Dans cette capture d'écran, les utilisateurs peuvent voir que la moitié des sites consomment plus de 75 % de la mémoire disponible. Ils n’ont pas besoin de cliquer sur des sites individuels ni d’écrire 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!