Présentation des parcs

Les parcs (anciennement appelés Environ) sont un concept de Google Cloud permettant d'organiser de manière logique les clusters et d'autres ressources. Vous pouvez ainsi utiliser et gérer des fonctionnalités multiclusters et appliquer des règles cohérentes à vos systèmes. Les parcs sont essentiels à la fonctionnalité multicluster d'entreprise dans Google Cloud.

Ce guide présente les parcs : ce que nous entendons par "parc", où les parcs sont utilisées dans nos composants et comment configurer vos systèmes pour tirer parti des fonctionnalités au niveau du parc. Nous dévoilons également des exemples pour illustrer l'aide que peuvent apporter les parcs pour simplifier la gestion de vos clusters et de vos systèmes, ainsi que des bonnes pratiques à suivre lors de la création et de l'exploitation de systèmes multicluster comportant des parcs.

Ce guide se destine aux lecteurs techniques, y compris les architectes système, les opérateurs de plate-forme et les opérateurs de service, qui souhaitent exploiter plusieurs clusters et une infrastructure associée. Ces concepts sont utiles chaque fois que votre entreprise exécute plusieurs clusters, que ce soit dans Google Cloud, via plusieurs fournisseurs cloud ou sur site.

Vous devez connaître les concepts de base de Kubernetes, tels que les clusters : dans le cas contraire, consultez les sections Principes de base de Kubernetes, Documentation GKE et Préparer une application pour Anthos Service Mesh.

Si vous souhaitez en savoir plus sur Anthos et les composants qui utilisent des parcs, consultez notre présentation technique et le tutoriel Découvrir Anthos. Toutefois, vous n'avez pas besoin de connaître Anthos pour suivre ce guide.

Présentation

En règle générale, lorsque les entreprises adoptent des technologies cloud natives telles que les conteneurs, l'orchestration de conteneurs et les maillages de services, elles atteignent un point où l'exécution d'un seul cluster ne suffit plus. Les entreprises choisissent de déployer plusieurs clusters pour atteindre leurs objectifs techniques et commerciaux, et ce pour diverses raisons. Par exemple, pour préparer la production des environnements hors production ou séparer les services entre les niveaux, les paramètres régionaux ou les équipes. Pour en savoir plus sur les avantages et les compromis qu'impliquent les approches multicluster, consultez la section Cas d'utilisation de multicluster.

À mesure que le nombre de clusters augmente, la gestion et la gouvernance de ces clusters et des ressources qu'ils contiennent deviennent de plus en plus complexes. Souvent, à ce stade, les entreprises ont besoin de créer des outils personnalisés et des règles opérationnelles pour disposer du niveau de contrôle adéquat.

Google Cloud intègre le concept de parc pour aider les administrateurs à gérer plusieurs clusters. Un parc permet de regrouper et de normaliser des clusters de manière logique, ce qui facilite l'administration de l'infrastructure. Les parcs peuvent être utilisées dans le contexte d'Anthos et de GKE. Vous trouverez la liste des composants Anthos et GKE permettant d'exploiter les parcs dans la section Composants compatibles avec le parc plus loin dans ce document.

L'adoption des parcs facilite la gestion de niveau supérieur de votre entreprise, depuis des clusters individuels vers des groupes entiers de clusters. En outre, la normalisation requise par les parcs peut aider vos équipes à adopter les bonnes pratiques similaires à celles utilisées par Google. À titre de comparaison, tout comme la ressource "Organisation" est le nœud racine de la hiérarchie des ressources Google Cloud et est utilisée pour les règles et le contrôle des ressources regroupées sous celle-ci, le parc constitue la racine pour la gestion de plusieurs clusters.

Terminologie

Voici quelques termes importants que nous employons au sujet des parcs.

Ressources compatibles avec les parcs

Les ressources compatibles avec les parcs sont des ressources de projet Google Cloud qui peuvent être regroupées logiquement et gérées en tant que parc unifié. Seuls les clusters Kubernetes peuvent actuellement être rattachés à un parc. Nous envisageons toutefois d'intégrer les instances de machine virtuelle (VM) et d'autres ressources aux parcs dans les futures itérations de la plate-forme. Google Cloud fournit un service Connect pour enregistrer des ressources en tant que membres d'un parc.

Projet hôte du parc

La mise en œuvre des parcs, à l'instar de nombreuses autres ressources Google Cloud, est enracinée dans un projet Google Cloud, que nous appelons projet hôte du parc. Un projet Cloud donné ne peut être associé qu'à un seul parc (ou à aucun parc). Cette restriction renforce l'utilisation des projets Cloud pour assurer une isolation plus forte entre les ressources qui ne sont pas contrôlées ni consommées conjointement.

Composants compatibles avec les parcs

Les composants Anthos et GKE suivants exploitent tous les concepts de parc tels que l'espace de noms et l'uniformité d'identité, afin de simplifier l'utilisation de vos clusters et services. Pour connaître les exigences ou les limites concernant l'utilisation des parcs avec chaque composant, consultez la section Configuration requise.

  • Pools d'identités de charge de travail (clusters Anthos et GKE)
    Un parc fournit un pool d'identités de charge de travail commun pouvant être utilisé pour l'authentification et l'autorisation des charges de travail de manière uniforme dans un maillage de services et vers des services externes.

  • Anthos Service Mesh (Anthos)
    Anthos Service Mesh est une suite d'outils qui vous permet de surveiller et de gérer un maillage de services fiable sur Google Cloud ou sur site. Vous pouvez former un maillage de services sur l'ensemble des ressources (telles que les clusters et les VM) d'un même parc.

  • Anthos Config Management (Anthos) et Config Sync (GKE)
    Anthos Config Management vous permet de déployer et de surveiller les modifications de règle et de configuration déclaratives pour votre système stocké dans un dépôt Git central, d'exploiter des concepts fondamentaux de Kubernetes tels que les espaces de noms, les libellés et les annotations. Avec Anthos Config Management (et son produit associé Config Sync pour les clusters autres que Anthos), la règle et la configuration sont définies au niveau du parc, mais appliquées et activées localement dans chacune des ressources membres.

  • Ingress multicluster (Anthos)
    Un objet Ingress multicluster utilise le parc pour définir l'ensemble de clusters et de points de terminaison de service sur lesquels le trafic peut être équilibré, ce qui permet de bénéficier de services à faible latence et à haute disponibilité.

Infrastructure de regroupement

Le premier concept important concernant les parcs est le concept de regroupement, c'est-à-dire le choix des ressources compatibles associées à intégrer à un parc. La décision de regrouper les questions nécessite de répondre aux questions 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.

Pour illustrer ce point, prenons l'exemple d'une entreprise qui comporte plusieurs secteurs d'activité. Dans ce cas, les services communiquent rarement hors de leur secteur d'activité (par exemple, les cycles de mise à jour diffèrent selon les secteurs d'activités) et peuvent disposer d'ensembles d'administrateurs différents pour chaque secteur. Dans ce cas, il peut être judicieux que chaque secteur d'activité dispose de son parc. Chaque secteur d'activité est également susceptible d'adopter plusieurs parcs pour séparer ses services de production et hors production.

Étant donné que d'autres concepts de base sont abordés dans les sections suivantes, vous découvrirez d'autres raisons de créer plusieurs parcs en fonction des besoins de votre entreprise.

Uniformité

Le concept d'uniformité est fondamental dans les parcs. Cela signifie que certains objets Kubernetes, tels que des clusters portant le même nom dans différents contextes, sont traités de la même manière. Cette normalisation permet de gérer l'administration des ressources de parcs. Elle fournit des conseils précis sur la configuration des espaces de noms, des services et des identités. Cependant, elle suit également ce que la plupart des entreprises mettent déjà en œuvre elles-mêmes.

Identité de l'espace de noms

Les espaces de noms sont un exemple fondamental illustrant l'uniformité dans un parc. Les espaces de noms portant le même nom dans différents clusters sont considérés comme identiques par de nombreux composants. Une autre façon de considérer cette propriété est qu'un espace de noms est défini de manière logique dans un parc, même si l'instanciation de l'espace de noms n'existe que dans un sous-ensemble de ressources de parc.

Prenons l'exemple de l'espace de noms backend suivant. Bien que l'espace de noms soit instancié uniquement dans les clusters A et B, il est implicitement réservé dans le cluster C (cela permet au service backend d'être également planifié dans le cluster C si nécessaire). Entre autres, les espaces de noms sont alloués à l'ensemble du parc, et non au cluster. Ainsi, l'uniformité d'espace de noms nécessite une propriété de l'espace de noms cohérente au sein du parc.

Schéma illustrant l'uniformité d'espace de noms dans un parc
Uniformité d'espace de noms dans un parc

Uniformité du service

Anthos Service Mesh et l'objet Ingress multicluster utilisent le concept d'uniformité de services dans un espace de noms. Comme pour l'uniformité d'espace de noms, cela signifie que les services ayant le même espace de noms et le même nom de service sont considérés comme étant le même service.

Les points de terminaison de service peuvent être fusionnés sur l'ensemble du maillage avec Anthos Service Mesh. Avec un objet Ingress multicluster, une ressource MultiClusterService (MCS) rend la fusion de points de terminaison plus explicite. Cependant, nous recommandons des pratiques semblables en matière d'attribution de noms. Pour cette raison, il est important de s'assurer que les noms de services au nom similaire dans le même espace de noms sont bien identiques.

Dans l'exemple suivant, la charge du trafic Internet est équilibrée sur un service portant le même nom dans l'espace de noms frontend présent dans les clusters B et C. De même, en utilisant les propriétés de maillage de services dans le parc, le service frontend peut atteindre un service portant le même nom dans l'espace de noms auth présent dans les clusters A et C.

Schéma illustrant l'uniformité des services dans un parc
Uniformité des services dans un parc

Uniformité d'identité lors de l'accès à des ressources externes

Les services dans un parc permettent d'exploiter une identité commune lors de leur sortie pour accéder à des ressources externes telles que des services Google Cloud, des espaces de stockage, etc. Cette identité commune permet de donner aux services d'un parc un accès unique à une ressource externe plutôt que cluster par cluster.

Pour mieux illustrer ce point, prenons l'exemple suivant. Les clusters A, B et C sont inscrits dans le cadre d'une identité commune dans leur parc. Lorsque les services de l'espace de noms backend accèdent aux ressources Google Cloud, leur identité est mappée à un compte de service Google Cloud commun appelé back. Le compte de service Google Cloud back peut être autorisé sur plusieurs services gérés, de Cloud Storage à Cloud SQL. Lorsque de nouvelles ressources de parc telles que des clusters sont ajoutées dans l'espace de noms backend, elles héritent automatiquement des propriétés de similarité de l'identité de la charge de travail.

En raison de l'uniformité des identités, il est important que toutes les ressources d'un parc soient approuvées et bien validées. Pour reprendre l'exemple précédent, si le cluster C appartient à une équipe distincte non approuvée, cette équipe peut également créer un espace de noms backend et accéder aux services gérés comme s'il s'agissait des services de backend du cluster A ou B.

Schéma illustrant l'uniformité des identités accédant aux ressources en dehors d'un parc
Uniformité des identités accédant à des ressources en dehors d'un parc

Uniformité de l'identité dans un parc

Dans le parc, l'uniformité d'identité est employée de la même manière que l'identité externe évoquée précédemment. À l'instar des services de parc, autorisés une seule fois pour un service externe, ils peuvent également l'être en interne.

Dans l'exemple suivant, nous utilisons Anthos Service Mesh pour créer un maillage de services multicluster où frontend a accès à backend. Avec Anthos Service Mesh et les parcs, il n'est pas nécessaire de spécifier que les frontend des clusters B et C peuvent accéder aux backend des clusters A et B. Il suffit juste de spécifier que les frontend du parc peuvent accéder aux backend du parc. Cette propriété simplifie non seulement l'autorisation, mais rend également les limites de ressources plus flexibles. Désormais, les charges de travail peuvent facilement être déplacées d'un cluster à un autre sans affecter leur autorisation. Comme pour l'uniformité de l'identité de la charge de travail, la gouvernance des ressources de parc est essentielle pour garantir l'intégrité de la communication de service à service.

Schéma illustrant l'uniformité de l'identité au sein d'un parc
Uniformité de l'identité dans un parc

Exclusivité

Les ressources compatibles d'un parc peuvent uniquement faire partie d'un seul parc à la fois. Il s'agit d'une restriction appliquée par les outils et les composants Google Cloud. Cette restriction garantit qu'il n'existe qu'une seule source fiable pour un cluster. Sans exclusivité, même les composants les plus simples seraient difficiles à utiliser, ce qui oblige votre entreprise à comprendre et à configurer l'interaction de plusieurs composants provenant de plusieurs parcs.

Confiance élevée

L'uniformité des services, l'uniformité d'identité de la charge de travail et celle du maillage reposent sur un principe de confiance élevé entre les membres d'un parc. Cela permet d'assurer une gestion optimale de ces ressources jusqu'au parc, plutôt que de gérer les ressources par ressource (c'est-à-dire, par cluster pour les ressources Kubernetes), et de faire en sorte que la ressource limite du cluster soit moins importante.

En d'autres termes, au sein d'un parc, les clusters offrent une protection contre les problèmes de rayons d'impact, de disponibilité (du plan de contrôle et de l'infrastructure sous-jacente), des voisins bruyants, etc. Toutefois, ils ne constituent pas une forte limite d'isolation pour la stratégie et la gouvernance, car les administrateurs de tout membre dans un parc peuvent potentiellement affecter les opérations de services d'autres membres.

Par conséquent, nous recommandons de conserver les ressources non approuvées par l'administrateur du parc dans leurs propres parcs afin qu'elles soient isolées. Si nécessaire, les services individuels peuvent ensuite être autorisés au-delà de la limite du parc.

Étape suivante

Êtes-vous prêt à appliquer ces concepts à vos propres systèmes ? Consultez les exigences et les bonnes pratiques concernant les parcs.