Plan de contrôle pour les PaaS Kubernetes distribués

(Ankur Singla) (15 novembre) , 2019)

Auteurs : Ankur Singla , Harshad Nakil

Ce blog est le premier dune série de blogs qui couvrent divers aspects de ce quil nous a fallu pour créer et exploiter notre Service SaaS :

  1. Plan de contrôle pour les PaaS Kubernetes distribués
  2. (Global Service Mesh pour les applications distribuées)
  3. (Sécurité de la plate-forme de linfrastructure distribuée, des applications et des données)
  4. (Sécurité des applications et du réseau des clusters distribués)
  5. Observabilité sur une plate-forme distribuée à léchelle mondiale
  6. Opérations et SRE dune plate-forme distribuée à léchelle mondiale
  7. Cadre de service Golang pour les microservices distribués s

Comme nous lavons décrit dans notre blog précédent , nos clients élaborent des ensembles complexes et diversifiés de solutions commerciales, comme des solutions intelligentes fabrication, criminalistique vidéo pour la sécurité publique, trading algorithmique, réseaux de télécommunications 5G – et nous devons donc offrir une expérience toujours active, connectée et fiable pour ces applications et leurs utilisateurs finaux.

Depuis ces applications pouvant sexécuter dans plusieurs clusters entre les fournisseurs de cloud ou les emplacements périphériques des clients, notre équipe de plate-forme a dû créer un plan de contrôle distribué et un service PaaS pour déployer, sécuriser et exploiter plusieurs clusters Kubernetes multi-locataires. Ce plan de contrôle distribué a apporté de nombreux avantages en termes de fonctionnement, dévolutivité et de performances, que nous aborderons dans notre présentation ( lien vidéo ) – par exemple comment gérer des milliers de clusters Edge K8 avec GitOps – et également en tant que billet de blog séparé dans les semaines à venir.

TL; DR (Résumé)

  1. Nous navons pas pu trouver une solution simple à utiliser sur le marché qui pourrait résoudre le problème du déploiement, de la sécurisation et de lexploitation de plusieurs clusters dapplications répartis sur des fournisseurs de cloud, des clouds privés ou plusieurs emplacements périphériques.
  2. Nous navons pas trouvé de solution robuste Distribution Kubernetes ou PaaS (par exemple, OpenShift, Cloud Foundry, etc.) qui fournissait un ensemble complet de services de sécurité et dexploitation nécessaires pour les clusters distribués – par exemple, lidentité basée sur PKI, la gestion RBAC et laccès des utilisateurs, les secrets et la gestion des clés entre les fournisseurs de cloud , le maillage de services multi-cluster, lobservabilité et les journaux daudit, ou la sécurité des applications et du réseau.
  3. Anthos (Google), Azure Arc (Microsoft) et Rancher sont des stations de gestion multi-cluster et regroupent plusieurs services différents ; notre analyse était que ceux-ci nauraient pas résolu les exigences opérationnelles, dévolutivité, de sécurité et de multi-location que nous avions pour les services dapplication et dinfrastructure sur plusieurs clusters.
  4. Nous avons dû créer notre propre plan de contrôle distribué pour notre PaaS géré qui repose sur Kubernetes. Nous avons commencé avec vanilla Kubernetes, puis avons apporté des changements importants pour fournir les services de plate-forme nécessaires à nos équipes DevOps et SRE. De plus, nous avons dû créer un plan de contrôle pour gérer un grand nombre de clusters distribués et fournir une architecture mutualisée sur une infrastructure hétérogène (en périphérie, notre réseau et plusieurs fournisseurs de cloud).

Kubernetes pour la gestion des applications: Pourquoi & Comment

Nous avons choisi Kubernetes (K8s) pour être le cœur de notre plate-forme de gestion des applications distribuées car il fournit un riche ensemble de fonctionnalités sans être trop normatifs – nous donnant la flexibilité dinnover sur des choses que nous croyons importantes pour nos clients. Nous avons utilisé cela comme une base sur laquelle commencer à développer notre service et avec la popularité croissante des K8, il est également plus facile de trouver des développeurs et des opérateurs qui le connaissent.

Cela dit, déployer et gérer un grand nombre de clusters Kubernetes de qualité production dans un environnement hybride (plusieurs clouds, POP réseau et emplacements périphériques) nest pas très facile car il ny a pas des solutions -box pour Kubernetes qui peuvent:

  1. Harmoniser les ressources dinfrastructure hétérogènes avec un clustering automatisé, une mise à léchelle et un provisionnement sans intervention; cela a été particulièrement pénible à la périphérie et dans nos PoP de réseau
  2. Fournissez une connectivité haute performance et fiable sur des sites disparates, en particulier lorsque vous traversez des fournisseurs de cloud et en provenance demplacements périphériques
  3. Résolvez la sécurité problème de données en transit, de données au repos, de secrets, de clés et de réseau… le tout soutenu par une identité PKI uniforme qui fonctionne à travers la périphérie, le réseau et le cloud
  4. Fournir une véritable multi-location – isolation des locataires et des garanties de sécurité – avec la possibilité dexécuter des charges de travail de production et de développement pour les besoins internes et des clients sur les mêmes clusters
  5. Offrir une observabilité et des opérations sur des clusters distribués en lien avec une politique et une intention centralisées, sans avoir à construire collecte de journaux et de métriques

Après plusieurs preuves de concept avec plusieurs fournisseurs de cloud et plates-formes open source comme GKE, AKS, EKS et RKE ainsi quOpenShift et Cloud Foundry – nous avons réalisé quaucun dentre eux ne pouvait rencontrer tous les fi cinq exigences ci-dessus. En conséquence, nous avons décidé de créer notre propre PaaS – en commençant par Kubernetes «vanille» et avons fait plusieurs ajouts – pour lidentité, la mise en réseau, la sécurité, la multi-location, la journalisation, les métriques, etc. Alors que nous utilisons Kubernetes pour répondre à nos besoins internes, nous avons dû prendre des décisions difficiles comme ne pas exposer ces clusters Kubernetes directement à nos utilisateurs internes et / ou clients pour exécuter leurs charges de travail (nous en parlerons plus tard, car la multi-location était un objectif clé pour nous).

En plus des multiples nouvelles fonctionnalités que nous devions ajouter, il était également nécessaire dexécuter nos charges de travail / services parallèlement aux charges de travail des clients dans de nombreux endroits à la périphérie, sur notre réseau et sur les clouds publics / privés. Cela signifiait que nous devions créer des capacités supplémentaires pour gérer plusieurs clusters dans plusieurs environnements … tous connectés à laide de notre réseau mondial et de nos passerelles dapplications distribuées pour fournir une connectivité sans confiance et au niveau des applications sur ces clusters.

Le Partie matérielle: Multi-Tenancy et Multi-Cluster pour Kubernetes

La création et lexploitation dapplications sexécutant dans un seul cluster Kubernetes est une tâche non triviale, même si vous utilisez un cluster géré par un fournisseur de cloud. Cest pourquoi il est courant pour les équipes DevOps et SRE de minimiser leurs frais généraux et de ne pas faire face à la complexité de nombreux clusters. Il est assez courant de voir des équipes créer un grand cluster Kubernetes et placer tous les types de ressources dans le même cluster. Bien que cela semble génial car ils peuvent simplifier les opérations et exécuter le cluster pour une efficacité et un coût de calcul maximaux, ce nest pas la meilleure idée pour plusieurs raisons. Premièrement, les besoins en charges de travail de production sont très différents de ceux du test de développement et de la staging – des charges de travail de développement instables peuvent potentiellement causer des problèmes pour des charges de travail de production plus stables.

En plus des besoins de charges de travail variées, la sécurité de K8 et les limitations disolement sont un autre pilote pour le multi-cluster. Une approche typique pour résoudre la sécurité de K8 et lisolation des ressources consiste à créer des clusters indépendants pour chaque client à laide dun modèle multi-tenant. Bien que cela puisse être faisable dans le cloud, il nest pas possible à la périphérie dexécuter plusieurs clusters. Les sites périphériques présentent des limitations de ressources de calcul et de stockage et une bande passante réseau limitée pour envoyer des journaux et des métriques pour chaque cluster supplémentaire au cloud central.

Pour résoudre le problème de plusieurs clusters Kubernetes, nous avons évalué Rancher pour une gestion centralisée de nos clusters Kubernetes (lorsque nous avons démarré, Anthos et Azure Arc nexistaient pas) et KubeFed. Les deux approches disponibles à lépoque étaient (et toujours la même situation aujourdhui):

  1. La gestion multi-cluster (par exemple Rancher) à partir dune console centrale nous aurait donné la possibilité de déployer plusieurs clusters dans nimporte quel endroit et effectuer des opérations de gestion du cycle de vie comme des mises à niveau, des restaurations, etc. Certains de ces systèmes ont également donné la possibilité dadresser un cluster individuel avec lautomatisation pour la configuration et le déploiement des applications
  2. Une autre approche consiste à déployer un Kubernetes le plan de contrôle de la fédération de cluster (KubeFed) et il peut faire ressembler plusieurs clusters physiques à un seul cluster. Ce projet ne faisait que commencer au moment où nous lavons regardé et, aujourdhui encore, il nen est quau stade alpha.

Après lannonce récente de GCP Anthos et Azure Arc, nous avons réévalué notre décision initiale de construire un plan de contrôle distribué et la conclusion était que même ces deux nouvelles offres nauraient pas pu résoudre deux problèmes critiques avec les clusters distribués.Ces deux fonctionnalités clés dont nous avions besoin pour notre plate-forme étaient les suivantes:

  1. Gérer plusieurs clusters en tant que flotte pour résoudre le problème de lexécution des opérations sur lensemble ou sur un groupe logique de clusters – opérations telles que la configuration, déploiement, métriques, etc. Ceci est essentiel car nous voulons réduire les frais généraux dexploitation de nos équipes SRE, améliorer la capacité de débogage de nos DevOps et améliorer lévolutivité de notre système
  2. Capacité à découper une personne physique Cluster Kubernetes pour la multi-location sans avoir besoin de faire tourner des clusters physiques – ceci est particulièrement critique dans les environnements à ressources limitées où nous ne voulons pas ajouter de nouveaux clusters physiques uniquement pour la multi-location

Pour résoudre ces deux problèmes, nous avons dû trouver une nouvelle technique – plan de contrôle distribué – pour résoudre la surcharge opérationnelle de «Plusieurs» clusters et fournir un équivalent de «multiples clusters» pour la multi-location en ressource-constraine d.

Plan de contrôle distribué: comment nous avons réalisé Kubernetes multi-clusters

Notre équipe de plateforme a décidé de créer un plan de contrôle distribué pour Kubernetes qui expose les API Kubernetes à lusage de notre équipe, cependant , ces API proviennent de clusters «virtuels» qui nexistent que dans notre plan de contrôle – un serveur dAPI K8s (vK8s) virtuel pour un cluster K8s virtuel (comme illustré dans Figure 1 ). Ce plan de contrôle mappe lintention de lutilisateur sur plusieurs clusters Kubernetes physiques sexécutant dans notre périphérie, nos POP réseau et nos emplacements de cloud public. Ces clusters physiques ne sont accessibles quà notre plan de contrôle distribué, et non à un locataire / utilisateur individuel.

Figure 1: Plan de contrôle distribué

Ce plan de contrôle fournit à chaque locataire un ou plusieurs clusters dapplications «virtuels» où ils peuvent déployer leurs applications ) et en fonction de la configuration, le plan de contrôle le répliquera et le gérera sur plusieurs clusters Kubernetes physiques. Outre les opérations de configuration et de déploiement, les opérations de surveillance suivent également ce cluster «virtuel» sans quil soit nécessaire de créer des outils pour collecter et disséquer les données de plusieurs clusters physiques.

Prenons un exemple dapplication dinterface utilisateur appelé productpage, où lintention de lutilisateur est de lexécuter réparti sur 3 emplacements – pa2-par, ny8-nyc et ams9-ams avec 2 répliques dans chacun deux. Lorsque lutilisateur crée un objet vK8s et lattache à un cluster virtuel, qui provisionne immédiatement un serveur API vK8s qui peut être utilisé avec kubectl standard.

À létape suivante, lutilisateur télécharge le kubeconfig pour ce virtuel cluster et crée un yaml standard pour décrire un déploiement K8 pour la page produit.

Suite à la création de la spécification de déploiement , lutilisateur peut procéder à la création dun déploiement sur ce cluster virtuel:

Maintenant si lutilisateur vérifie son déploiement, il voit 6 répliques a été commencé avec 2 dans chaque emplacement (pa2-par, ny8-nyc et ams9-ams).

La sortie suivante montre 2 pods en cours dexécution dans chaque emplacement avec un mappage vers un nœud physique particulier

Cet exemple simple montre à quel point il est trivial dobtenir une réplication multi-cluster de nimporte quelle application en quelques minutes es sans aucune charge dinstallation et de gestion. En plus de mapper lintention, le plan de contrôle distribué offre également lobservabilité pour le cluster virtuel et non sur une base de cluster individuel.

Contrôle distribué et gestion centralisée pour la multi-location

Comme vous pouvez voir dans la Figure 2 , notre plan de gestion centralisé fonctionne sur deux fournisseurs de cloud public (une région chacun) – un dans AWS et un dans Azure (pour la redondance). Ce plan de gestion permet à notre SRE de créer des locataires avec une multi-location dure – par ex. une équipe de développement travaillant sur notre service VoltMesh peut être un locataire et une équipe de solutions client travaillant sur les POC clients peut être son propre locataire avec son propre ensemble dutilisateurs.

Figure 2: Multi-Tenancy et Multi-Cluster

Chacun de ces locataires peut en créer plusieurs espaces de noms et affectez un groupe dutilisateurs pour collaborer sur ces espaces de noms. Ces espaces de noms ne sont pas des espaces de noms Kubernetes – ils constituent une limite disolement dans notre plate-forme avec des règles RBAC et des politiques IAM pour les utilisateurs.

Lorsquun utilisateur dans un espace de noms souhaite créer un cluster dapplications, il crée un objet vK8s et qui à son tour crée un serveur API vK8s dans notre plan de gestion.À laide de cet objet vK8s, lutilisateur peut créer des déploiements, des ensembles avec état, des PVC, etc. et le plan de contrôle sassurera que ces opérations se produisent sur un ou plusieurs clusters physiques, en fonction des sites associés à lobjet vK8s.

Étant donné que chaque locataire et utilisateur utilise les opérations K8 standard sans aucune modification, cela permet au système dêtre compatible avec un certain nombre doutils qui sont populaires auprès des opérateurs – par exemple Spinnaker, Helm, Jenkins, etc.

Gains réalisés à partir dun plan de contrôle distribué

Le gros avantage dun plan de contrôle distribué est quil a résolu la surcharge opérationnelle de nos SRE et DevOps équipes. Ils peuvent désormais effectuer des opérations (configuration, déploiement, surveillance, stratégie, etc.) sur un cluster virtuel et le plan de contrôle le mappera automatiquement sur plusieurs clusters physiques. En plus de la simplification opérationnelle pour plusieurs clusters, le plan de contrôle a également résolu le problème de sécurité et disolement pour la multi-location.

Ce plan de contrôle distribué a également amélioré la productivité des développeurs qui souhaitent ajouter de nouvelles fonctionnalités à notre plate-forme – ils nont pas à créer une nouvelle automatisation chaque fois quils ajoutent de nouvelles fonctionnalités qui ont un impact sur la configuration ou les opérations sur plusieurs clusters. Ils utilisent le modèle de configuration basé sur lintention et le plan de contrôle sait ce qui doit être fait. De plus, ils peuvent continuer à interagir avec cet objet de cluster distribué et multiple – virtual kubernetes – en utilisant kubectl et pas encore une autre CLI.

Après lavoir exécuté dans nos environnements de test de développement, de préparation et de production pour plus depuis maintenant plus dun an, nous nous sommes rendu compte que ce plan de contrôle distribué à léchelle mondiale (fonctionnant dans notre réseau POP) offre également des avantages significatifs en termes déchelle, de performances et de fiabilité – ce que nous navions pas complètement imaginé à nos débuts. Nous couvrirons cette découverte dans notre prochaine présentation KubeCon et dans un article de blog séparé dans les semaines à venir.

À suivre…

Cette série de blogs couvrira divers aspects de ce quelle Il nous a fallu construire et exploiter notre service SaaS distribué à léchelle mondiale avec de nombreux clusters dapplications dans le cloud public, nos PoP de réseau privé et nos sites périphériques. La prochaine étape est (Global Service Mesh pour les applications distribuées)…