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 assure la cohérence et une observabilité complète sur de grands groupes de clusters. Un certain nombre de fonctionnalités de GKE 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 cette page, assurez-vous de maîtriser les concepts suivants :

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 donné Google Cloud ne peut être associé qu'à un seul parc (ou à aucun parc), bien que ce parc puisse inclure des clusters provenant 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.
  • Tous les clusters d'un projet donné doivent appartenir au même parc ou à aucun parc. Si un projet contient déjà des membres de parc, vous ne pouvez pas enregistrer un cluster de ce projet dans un autre parc.
  • 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, pour de nombreuses raisons, de placer plusieurs clusters dans le même projet. 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 comment elles s'appliquent plus en détail 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 conteneurs. Vous pouvez également avoir des applications qui s'exécutent déjà dans des clusters existants, mais vous êtes prêt à les déplacer vers de nouveaux clusters pour obtenir une architecture préférée.

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

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. Ensuite, suivez les étapes du reste de cette section pour diviser progressivement cet ensemble d'applications en sous-ensembles jusqu'à obtenir l'ensemble minimal de regroupements nécessaires. Cela déterminera les parcs et les clusters dont vous avez besoin.

Prendre en compte les unités commerciales

Votre organisation peut avoir 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 d'application sont généralement déployées progressivement (ou promues) dans chaque environnement de la liste. Pour cette raison, vous disposez de déploiements distincts dans chaque environnement pour la même application sous-jacente, par exemple le même nom d'image de conteneur de base. Consultez le plan des bases d'entreprise pour obtenir un exemple de création d'environnements dans votre organisation.

Un parc ne doit contenir que des clusters provenant d'un seul environnement. Trois environnements, avec un parc dans chacun d'eux, peuvent suffire à 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 charge de travail redondantes

Lorsqu'une application a besoin d'une haute disponibilité, un modèle consiste à l'exécuter dans deux régions ou plus. Cela implique que deux clusters ou plus exécutent des déploiements configurés de manière très similaire et gérés comme une seule unité. Souvent, ils disposent d'un équilibreur de charge couvrant les instances d'application dans 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 dans ou en dehors de Google Cloud. Dans ce scénario, l'objectif est de créer un ensemble de parcs au sein de votre organisation et d'y 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, puis enregistrer des clusters dans le parc prévu.

Auditer vos clusters

Commencez par créer une liste de tous les clusters Kubernetes de votre organisation. Cloud Asset Inventory est un moyen de rechercher des ressources de cluster Kubernetes dans votre organisation.

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

Prendre en compte les unités commerciales

Votre organisation peut avoir 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 par unité commerciale ont peut-être créé vos clusters existants. En règle générale, dans ce cas, vous partitionnez l'ensemble de 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 qui ne contiennent 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 l'identité, l'objectif doit être que tous les clusters aient le même ensemble d'administrateurs et qu'il y ait 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 confiance mutuellement et qui ne sont pas disposés à partager des 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 à l'échelle du parc, vous pouvez organiser vos parcs de manière à minimiser les risques lors de la configuration de l'authentification des charges de travail à l'échelle du parc. Si vous souhaitez utiliser Cloud Service Mesh, vous devrez peut-être placer certains clusters dans le même parc. Si vous utilisez le 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 guide suivant 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 situés dans un périmètre VPC (par exemple, sur un VPC partagé doté de VPC Service Controls) peuvent se trouver ensemble dans un 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 matière de VPC, par exemple, elles nécessitent que tous les clusters qui les utilisent se trouvent dans le même réseau VPC.

Étape suivante