Fonctionnement des parcs

Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Cette page explique dans le détail comment les parcs vous aident à gérer les déploiements multiclusters, et en spécifie la terminologie et les concepts clés. Les parcs sont un concept Google Cloud qui permet d'organiser logiquement des clusters et d'autres ressources. Ils vous permettent d'utiliser et de gérer des fonctionnalités multiclusters, et d'appliquer des règles cohérentes sur l'ensemble de vos systèmes. Les parcs sont essentiels à la fonctionnalité multicluster d'entreprise dans Google Cloud.

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 et les espaces de noms : dans le cas contraire, consultez la section Les bases de Kubernetes, la documentation GKE et la section Préparer une application pour Anthos Service Mesh.

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

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é. Actuellement, les membres du parc ne peuvent être que des clusters Kubernetes.

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.

Infrastructure de regroupement

Le premier concept important des 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 espaces de noms portant le même nom dans des clusters différents, 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 ne soit instancié que dans les clusters A et B, il est implicitement réservé dans le cluster C. Cela permet à un service dans l'espace de noms 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 services portant des noms identiques dans le même espace de noms correspondent bien à une même entité.

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, à l'aide des propriétés de maillage de services au sein du parc, le service situé dans l'espace de noms 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, il peut également créer un espace de noms backend et accéder aux services gérés comme s'il appartenait à backend dans le 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 clusters non approuvés par l'administrateur du parc dans leurs propres parcs afin qu'ils soient isolés. Si nécessaire, les services individuels peuvent ensuite être autorisés au-delà de la limite du parc.

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
    Un parc propose un pool d'identités de charge de travail commun, qui peut être utilisé pour authentifier et autoriser les charges de travail de manière uniforme, au sein d'un maillage de services et à destination de services externes.

  • Anthos Service Mesh
    Anthos Service Mesh est une suite d'outils qui vous aide à surveiller et à gérer un maillage de services pour en assurer la fiabilité, sur Google Cloud, sur site ainsi que dans les autres environnements compatibles. Vous pouvez former un maillage de services entre différents clusters faisant partie du même parc.

  • Anthos Config Management
    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, qui sont stockées dans un dépôt Git central en exploitant des concepts fondamentaux de Kubernetes tels que les espaces de noms, les libellés et les annotations. Avec Anthos Config Management, 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.

  • Multi Cluster Ingress
    Multi Cluster Ingress 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é.

  • Cloud Run for Anthos
    Cloud Run for Anthos est une plate-forme de développeur Knative compatible et gérée par Google, qui élimine la complexité de l'infrastructure sous-jacente et facilite la création, le déploiement et la gestion d'applications et de services dans les clusters de votre parc Anthos.

Étape suivante