Planifier les ressources du parc

Comme mentionné dans la présentation de la gestion de parc, les parcs sont un mécanisme de regroupement permettant de gérer, configurer et sécuriser des clusters Kubernetes à grande échelle. Les parcs sont un outil puissant qui élimine le besoin d'effectuer des opérations répétées dans un environnement multicluster, et qui offre une cohérence et une observabilité complète sur de grands groupes de clusters. Un certain nombre de fonctionnalités de GKE Enterprise ne sont disponibles que via un parc.

La stratégie de regroupement que vous utilisez pour créer des parcs peut varier en fonction des besoins techniques et commerciaux de votre organisation. Par exemple, une organisation peut regrouper des clusters en fonction du type d'applications qui y sont exécutées, tandis qu'une autre peut les regrouper par région, par environnement ou par d'autres facteurs intéressants. Toutes choses étant égales par ailleurs, il est pratique de disposer du moins de parcs possible dans votre organisation.

Ce guide s'adresse aux architectes Cloud qui souhaitent se lancer avec des parcs dans leur organisation. Il fournit des conseils pratiques pour organiser vos clusters en parcs, y compris :

  • Lorsque vous souhaitez créer intégralement des clusters.
  • Lorsque vous souhaitez créer des parcs avec des clusters existants.

Les modèles décrits ici fonctionnent pour de nombreuses organisations, mais ils ne sont pas les seuls à permettre de planifier des parcs. Les parcs sont flexibles et vous pouvez décider d'utiliser un autre modèle de regroupement pour vos clusters.

Avant de lire ce guide, vous devez vous familiariser avec les concepts présentés dans notre présentation de la gestion de parc. Ce guide suppose également que vous maîtrisez les concepts de base de Kubernetes et la hiérarchie des ressources Google Cloud.

Limites liées aux parcs et aux ressources

Les limites générales suivantes s'appliquent lors de la création de parcs :

  • Un projet Google Cloud donné ne peut être associé qu'à un seul parc (ou à aucun parc), bien que ce parc puisse inclure des clusters de plusieurs projets. Le projet associé à un parc est appelé projet hôte du parc.
  • Les clusters ne peuvent être membres que d'un seul parc à la fois.
  • La limite par défaut du nombre de clusters dans un parc est de 250. Toutefois, vous pouvez demander une limite plus élevée si nécessaire.

Il peut être pratique de placer plusieurs clusters dans le même projet pour de nombreuses raisons. Toutefois, tenez compte des limites suivantes lorsque vous planifiez les clusters à assembler dans un projet :

Principes généraux

Voici quelques questions générales que vous devez vous poser pour décider de regrouper des clusters dans un parc. Nous verrons plus en détail comment les appliquer dans les sections suivantes.

  • Les ressources sont-elles liées entre elles ?
    • Les ressources qui disposent de grandes quantités de communication interservices bénéficient le plus de la gestion regroupée dans un parc.
    • Les ressources d'un même environnement de déploiement (par exemple, votre environnement de production) doivent être gérées ensemble au sein d'un parc.
  • Qui gère les ressources ?
    • Le contrôle unifié des ressources (ou du moins approuvé mutuellement) est essentiel pour garantir l'intégrité du parc.

Planifier des parcs pour les nouveaux clusters

Cette section explique comment planifier des parcs lorsque vous disposez d'un ensemble d'applications connu, mais que vous êtes flexible quant à l'emplacement de leur déploiement. Cela peut être dû au fait que vous n'avez pas encore développé ces applications ou que vous les migrez depuis une autre plate-forme de conteneur. Il est également possible que vous exécutiez déjà des applications dans des clusters existants, mais que vous soyez ouvert à l'idée de les déplacer vers de nouveaux clusters pour obtenir l'architecture souhaitée.

Une fois les parcs identifiés, vous pouvez créer un projet par parc, créer un parc dans chaque projet, et créer et enregistrer des clusters dans le parc souhaité.

Auditer vos charges de travail

Commencez par créer une liste de toutes les charges de travail Kubernetes (par exemple, les déploiements) que vous souhaitez déployer. Cela n'a pas besoin d'être une liste littérale, mais simplement une idée des charges de travail dont vous aurez besoin. Suivez ensuite les étapes décrites dans le reste de cette section pour diviser progressivement cet ensemble d'applications en sous-ensembles jusqu'à obtenir l'ensemble minimal de regroupements requis. Cela déterminera les parcs et les clusters dont vous avez besoin.

Prendre en compte les unités commerciales

Votre organisation peut disposer d'une structure informatique fédérée, avec une équipe informatique centrale pour l'organisation, ainsi que des équipes informatiques distinctes pour chaque unité commerciale. Dans ce cas, chaque équipe informatique fédérée peut gérer ses propres parcs. Utilisez des parcs distincts si les charges de travail de deux unités commerciales (par exemple, l'audit et le trading dans une banque) ne peuvent pas communiquer entre elles pour des raisons réglementaires.

Séparer les charges de travail par environnement

Un modèle courant qui fonctionne pour de nombreuses organisations consiste à regrouper les clusters par environnement. Une configuration typique comprend trois environnements principaux : développement, hors production (ou préproduction) et production. Les modifications apportées à l'application sont généralement déployées progressivement (ou promues) dans chaque environnement de la liste. Par conséquent, vous disposez de déploiements distincts dans chaque environnement pour la même application sous-jacente, comme le même nom d'image de conteneur de base. Consultez le plan de base de l'entreprise pour découvrir comment créer des environnements dans votre organisation.

Un parc ne doit contenir que des clusters provenant d'un seul environnement. Trois environnements, avec un parc dans chacun, peuvent suffire pour de nombreuses organisations. Consultez le plan d'application d'entreprise pour voir un exemple dans lequel chaque environnement dispose d'un parc et comment les applications peuvent être déployées progressivement.

Combiner des instances de charges de travail redondantes

Lorsqu'une application nécessite une haute disponibilité, une solution consiste à l'exécuter dans deux régions ou plus. Cela implique au moins deux clusters exécutant des déploiements configurés de manière très similaire et gérés comme une seule entité. Souvent, ils disposent d'un équilibreur de charge couvrant les instances d'application de tous les clusters ou utilisent l'équilibrage de charge DNS.

Dans ces scénarios, placez tous ces clusters dans le même parc. En général, les clusters situés dans différentes régions n'ont pas besoin d'être dans des parcs distincts, sauf si cela est requis pour des raisons réglementaires ou autres.

Planifier des parcs avec des clusters existants

Cette section explique comment planifier des parcs lorsque des charges de travail s'exécutent sur des clusters existants et que vous ne prévoyez pas de les déplacer. Ces clusters peuvent se trouver sur Google Cloud ou en dehors. Dans ce scénario, l'objectif est de créer un ensemble de parcs au sein de votre organisation et de leur attribuer des clusters existants.

Une fois les parcs identifiés, vous pouvez créer un projet par parc, créer un parc dans chaque projet et enregistrer des clusters dans le parc souhaité.

Auditer vos clusters

Commencez par obtenir la liste de tous les clusters Kubernetes de votre organisation. L'inventaire des éléments cloud est un moyen de rechercher des ressources de cluster Kubernetes dans votre organisation.

Vous pouvez ensuite suivre les étapes décrites dans le reste de cette section pour diviser progressivement cet ensemble d'applications en sous-ensembles jusqu'à obtenir l'ensemble minimal de regroupements requis. Cela déterminera les parcs dont vous avez besoin.

Prendre en compte les unités commerciales

Votre organisation peut disposer d'une structure informatique fédérée, avec une équipe informatique centrale pour l'organisation, ainsi que des équipes informatiques distinctes pour chaque unité commerciale. Ces équipes informatiques peuvent avoir créé vos clusters existants. Dans ce cas, vous partitionnez généralement l'ensemble des clusters par unité commerciale. Par exemple, les charges de travail de certaines unités commerciales (par exemple, l'audit et le trading dans une banque) ne peuvent pas communiquer entre elles pour des raisons réglementaires.

Si les unités commerciales existent uniquement à des fins de comptabilité des coûts, mais utilisent une équipe informatique commune, envisagez de regrouper leurs clusters dans un seul parc, en particulier s'il existe des dépendances interservices importantes entre les unités commerciales.

Regrouper les clusters par environnement

Identifiez les environnements utilisés dans votre organisation. Les noms d'environnement les plus courants sont "dev", "non-production" (ou "préproduction") et "prod".

Si chaque cluster se trouve clairement dans un seul de vos environnements, séparez votre liste de clusters par environnement. Toutefois, si certains clusters contiennent des charges de travail qui appartiennent logiquement à différents environnements, nous vous recommandons de redéployer les applications dans des clusters ne contenant que des applications appartenant à un seul environnement logique.

Réduire le nombre de propriétaires de clusters

Lorsque vous combinez des projets existants dans un parc, il peut y avoir différents ensembles d'utilisateurs autorisés à agir en tant qu'administrateurs sur ces clusters, en tenant compte à la fois des règles IAM (container.admin) et du RBAC (ClusterRoleBinding administrateur). Si vous prévoyez d'utiliser des fonctionnalités qui nécessitent une similitude, l'objectif doit être d'obtenir tous les clusters ayant le même ensemble d'administrateurs et de disposer d'un petit ensemble d'administrateurs pour le parc. Si les clusters doivent avoir des administrateurs différents et que l'objectif est d'utiliser les fonctionnalités qui nécessitent l'identité, ils n'appartiennent probablement pas au même parc.

Par exemple, si les clusters C1 et C2 ont des administrateurs différents qui ne se font pas mutuellement confiance et ne souhaitent pas partager les autorisations d'administrateur avec une équipe de plate-forme centrale qui gère les parcs, ils ne doivent pas être regroupés dans un parc.

Pour en savoir plus sur l'uniformité et les fonctionnalités qui l'exigent, consultez la page Fonctionnement des parcs.

Prendre en compte les fonctionnalités du parc

Que vous utilisiez des clusters nouveaux ou existants, les fonctionnalités de parc que vous choisissez peuvent également affecter l'organisation optimale de votre parc. Par exemple, si vous choisissez d'utiliser la fédération d'identité de charge de travail pour l'ensemble du parc, vous pouvez organiser vos parcs de manière à minimiser les risques lors de la configuration de l'authentification de charge de travail pour l'ensemble du parc. Si vous souhaitez utiliser Cloud Service Mesh, vous devrez peut-être placer certains clusters dans le même parc. Si vous utilisez un cloud privé virtuel (VPC), certaines fonctionnalités nécessitent l'utilisation d'un seul VPC par parc.

Pour en savoir plus sur l'adoption des fonctionnalités de parc, ainsi que sur leurs exigences et leurs limites, consultez le prochain guide de cette série, Planifier les fonctionnalités de parc.

Prendre en compte les périmètres VPC

Un autre problème à prendre en compte pour les clusters nouveaux et existants est de savoir si vous avez choisi de créer ou si vous souhaitez créer vos propres réseaux privés sur Google Cloud avec le cloud privé virtuel (VPC). Les clusters d'un périmètre VPC (par exemple, sur un VPC partagé doté de VPC Service Controls) peuvent se trouver dans un même parc. Si vous disposez de VPC partagés restreints et non restreints, il est recommandé de les placer dans des parcs distincts.

Si vous prévoyez d'utiliser des périmètres VPC Service Controls, certaines charges de travail se trouvent généralement dans le périmètre, tandis que d'autres se trouvent en dehors. Vous devez prévoir d'avoir des versions VPC Service Controls et des versions "non VPC Service Controls" de chaque parc dans chaque environnement (ou au moins la version de production et l'environnement immédiatement avant la production).

Lorsque vous planifiez des parcs avec des VPC, sachez que certaines fonctionnalités de parc ont des exigences spécifiques en termes de VPC, par exemple, tous les clusters qui les utilisent doivent se trouver dans le même réseau VPC.

Étape suivante