Cas d'utilisation de multicluster

Bien qu'il soit généralement recommandé d'utiliser le moins de clusters possible, les organisations choisissent de déployer plusieurs clusters pour atteindre leurs objectifs techniques et commerciaux, et ce pour diverses raisons. Au minimum, la plupart des entreprises séparent leurs services hors production de leurs services de production en les plaçant dans des clusters différents. Dans les scénarios plus complexes, les entreprises peuvent choisir plusieurs clusters pour séparer les services entre les niveaux, les paramètres régionaux, les équipes ou les fournisseurs d'infrastructure.

Dans la plupart des cas, l'utilisation de plusieurs clusters relève de trois catégories d'exigences :

  • Isolation : séparation entre le plan de contrôle et le plan de données des services, principalement pour améliorer la fiabilité ou répondre aux besoins de sécurité
  • Emplacement : disposition des services dans des emplacements spécifiques pour répondre aux besoins de disponibilité, de latence et de localisation
  • Scaling : en particulier dans le contexte des clusters Kubernetes, le scaling des services au-delà des limites pratiques imposées par un seul cluster

Nous examinons ces catégories plus en détail dans les sections suivantes.

Dans de nombreux cas, les entreprises doivent équilibrer plusieurs de ces critères en même temps. En ce qui concerne votre propre entreprise, n'oubliez pas que nous recommandons d'utiliser le moins de clusters possible. Déterminez les besoins de multicluster avec le niveau de priorité le plus élevé pour votre entreprise et ne pouvant pas être compromis, puis effectuez les ajustements nécessaires pour créer une architecture multicluster.

Si votre entreprise envisage le mode de cluster par modèle de service ou de cluster par équipe, vous devez tenir compte des contraintes de gestion qui incombent aux opérateurs d'un tel système. Les ressources Environ, ainsi que les composants et fonctionnalités Google Cloud associés, s'appliquent à simplifier du mieux que possible la gestion de plusieurs clusters, mais il existe toujours une complexité supplémentaire en termes de gestion lorsqu'on travaille avec davantage de clusters.

Isolation

Dans ce contexte, l'isolation fait référence à la séparation du plan de contrôle et/ou du plan de données, pouvant s'atteindre dans les deux cas en exécutant plusieurs clusters. Toutefois, en fonction de la mise en œuvre, cette séparation peut également s'étendre à l'isolation du plan de données. L'isolation s'effectue généralement lorsque les conditions suivantes sont remplies :

  • Environnement
    Bien souvent, les entreprises exécutent leurs services de développement, de préproduction/test et de production sur des clusters distincts, souvent exécutés sur différents réseaux et projets Cloud. Cette séparation permet d'éviter toute perturbation accidentelle des services de production et d'empêcher l'accès aux données sensibles lors du développement ou des tests.

  • Hiérarchisation des charges de travail
    Souvent, les entreprises qui gèrent de nombreuses applications complexes hiérarchisent leurs services, en choisissant d'exécuter leurs services les plus critiques sur des clusters qui diffèrent de leurs clusters moins importants. Dans un environnement de ce type, ces services plus critiques et leurs clusters sont traités avec une attention particulière en ce qui concerne l'accès, la sécurité, les mises à niveau, les stratégies, etc. Un exemple de cette hiérarchie consiste à séparer les services sans état et les services avec état, en les plaçant sur des clusters distincts.

  • Impact réduit en cas de défaillance
    Lorsque les entreprises souhaitent limiter les effets d'une erreur d'opérateur, d'une défaillance du cluster ou d'une défaillance d'infrastructure associée, elles peuvent répartir leurs services sur plusieurs clusters.

  • Mises à niveau
    Lorsque les entreprises s'inquiètent des problèmes potentiels liés à la mise à niveau existante (c'est-à-dire en cas d'échec de l'automatisation de la mise à niveau, de la fiabilité de l'application ou de la possibilité d'effectuer un rollback), elles peuvent choisir de déployer une copie de leurs services dans un nouveau cluster. Pour pouvoir être appliquée, cette méthode de mise à niveau nécessite une planification ou une automatisation. Veillez à gérer la gestion du trafic et la réplication de l'état pendant le processus de mise à niveau.

  • Sécurité/séparation réglementaire
    Les entreprises peuvent choisir d'isoler les services pour de nombreuses raisons, y compris pour maintenir la séparation entre les charges de travail soumises à des exigences réglementaires et celles qui sont moins sensibles, ou pour exécuter des services tiers (moins fiables) sur une infrastructure distincte de celles des services (clusters) propriétaires (fiables).

  • Séparation des locataires
    La séparation des locataires en plusieurs clusters est souvent effectuée pour différentes raisons, y compris l'isolation de sécurité, l'isolation des performances, la comptabilité analytique, et même la propriété.

Location (Emplacement)

  • Latence
    Certains services ont des exigences de latence qui doivent être respectées en localisant physiquement la charge de travail dans un emplacement ou une zone géographique spécifique. Cela peut être nécessaire si les utilisateurs finaux ou les services en amont sont sensibles à la latence, mais également si la charge de travail elle-même est sensible à la latence du service en aval.

  • Disponibilité
    L'exécution du même service sur plusieurs zones de disponibilité dans un fournisseur cloud unique (ou à travers plusieurs fournisseurs) peut entraîner une disponibilité globale plus élevée.

  • Juridiction
    La résidence des données et d'autres exigences en termes de traitement juridictionnel peuvent nécessiter que le calcul et le stockage soient actifs dans une région spécifique, ce qui nécessite le déploiement d'une infrastructure dans plusieurs centres de données ou fournisseurs cloud.

  • Gravité des données
    Un corpus de données volumineux, voire certaines instances de base de données, peuvent s'avérer difficiles, voire impossibles à regrouper dans un seul fournisseur ou une seule région Cloud. En fonction des exigences de traitement et de diffusion, une application peut avoir besoin d'être déployée à proximité de ses données.

  • Infrastructure/services anciens
    De même que les données peuvent être difficiles à migrer vers le cloud, certaines ancienne infrastructures peuvent l'être tout autant. Bien que ces anciens services soient immobiles, la possibilité de moderniser leur infrastructure permet d'accroître la vitesse de développement des entreprises.

  • Choix du développeur
    Les entreprises bénéficient souvent du choix des développeurs dans les services gérés dans le cloud qu'elles utilisent. En règle générale, ce choix permet aux équipes de travailler plus rapidement avec des outils qui répondent mieux à leurs besoins au détriment de la nécessité de gérer des ressources supplémentaires allouées à chaque fournisseur.

  • Besoins en calcul local/edge computing
    Enfin, pour les entreprises qui souhaitent adopter des pratiques de modernisation d'applications dans des environnements de travail plus traditionnels (tels que des entrepôts, des sites de production, des commerces de détail, etc.), il sera nécessaire de gérer davantage de charges de travail sur davantage d'éléments d'infrastructure.

Effectuer le scaling

Étant donné que GKE peut effectuer le scaling de clusters à plus de 5 000 nœuds, ces limites s'imposent rarement comme une raison d'exploitation de plusieurs clusters. Avant d'atteindre les limites d'évolutivité d'un cluster, les entreprises décident souvent de séparer les services sur plusieurs clusters. Pour les clusters qui atteignent les limites d'évolutivité, l'exécution d'une application sur plusieurs clusters peut simplifier certains défis, mais avec la complexité supplémentaire liée à la gestion de plusieurs clusters.