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 la nécessité d'effectuer des opérations répétées dans un environnement multicluster. Ils offrent également cohérence et observabilité complète sur de grands groupes de clusters. Un certain nombre de fonctionnalités 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. Vous pouvez donc 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 Google Cloud donné 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 même projet doivent appartenir au même parc ou n'appartenir à aucun parc. Si un projet contient déjà des membres du parc, vous ne pouvez pas enregistrer de 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 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 elles s'appliquent 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 en cours d'exécution dans des clusters existants, mais être prêt à 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, puis 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 la procédure décrite dans le reste de cette section pour diviser progressivement cet ensemble d'applications en sous-ensembles jusqu'à obtenir le nombre minimal de groupes 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'ensemble de 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 schéma 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 de manière progressive (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 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 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 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 deux clusters ou plus exécutant des déploiements configurés de manière très similaire et gérés comme une seule unité. Ils disposent souvent 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 sur 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 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 les clusters dans le parc souhaité.

Auditer vos clusters

Commencez par créer une liste de tous les clusters Kubernetes de votre organisation. L'inventaire des éléments cloud est l'un des moyens 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 disposer d'une structure informatique fédérée, avec une équipe informatique centrale pour l'ensemble de 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. 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 appartient clairement à 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 du cluster

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 de faire en sorte 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 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 même 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 de charge 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 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.

Penser aux 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, un VPC partagé avec VPC Service Controls) peuvent appartenir à 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 concernant les VPC. Par exemple, elles peuvent exiger que tous les clusters qui les utilisent se trouvent dans le même réseau VPC.

Étape suivante