Présentation d'Environ

Environ est un concept Google Cloud qui permet d'organiser logiquement des clusters et d'autres ressources. Il vous permet d'utiliser et de gérer des fonctionnalités multicluster, et d'appliquer des règles cohérentes à vos systèmes. Environ est essentiel à la fonctionnalité multicluster d'entreprise dans Anthos. Ce concept est également utilisé dans certaines fonctionnalités de Google Kubernetes Engine (GKE).

Ce guide vous présente Environ : sa définition, son utilisation avec nos composants, ainsi que la configuration de vos systèmes pour tirer parti des fonctionnalités au niveau d'Environ. Nous dévoilons également des exemples pour illustrer l'aide qu'apporte Environ 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.

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.

Pour en savoir plus sur Anthos et sur les composants utilisant Environ, consultez la présentation technique d'Anthos 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 Environ pour aider les administrateurs à gérer plusieurs clusters. Environ permet de regrouper et de normaliser des clusters de manière logique, ce qui facilite l'administration de l'infrastructure. Environ peut être utilisé dans le contexte d'Anthos et de GKE. Vous trouverez une liste des composants Anthos et GKE capables d'exploiter Environ plus loin dans la section Composants compatibles Environ de ce document.

L'adoption d'Environ 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 Environ 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, elle sert de règle et de contrôle des ressources regroupées sous celle-ci, Environ constituant la racine pour la gestion de plusieurs clusters.

Terminologie

Voici quelques termes importants que nous employons au sujet d'Environ.

Ressources compatibles Environ

Les ressources compatibles Environ sont des ressources du projet Google Cloud qui peuvent être regroupées et gérées de manière logique avec Environ. Seuls les clusters Kubernetes peuvent actuellement être membres Environ, bien que nous recommandions des instances de machine virtuelle (VM) et d'autres ressources capables de rejoindre Environ dans les futures itérations de la plate-forme. Google Cloud fournit un service Connect pour enregistrer des ressources en tant que membres Environ.

Projet hôte Environ

La mise en œuvre d'Environ, à l'instar de nombreuses autres ressources Google Cloud, est rootée dans un projet Google Cloud, que nous appelons projet hôte Environ. Un projet Cloud donné ne peut être associé qu'à une seule instance Environ (ou aucune). 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 activés par Environ

Les composants Anthos et GKE suivants exploitent tous le concept d'Environ 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 d'Environ avec chaque composant, consultez la section Configuration requise.

  • Pools d'identités de charge de travail (clusters Anthos et GKE)
    Un environ 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) membres d'Environ.

  • 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 d'Environ, mais appliquées et activées localement dans chacune des ressources membres.

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

Infrastructure de regroupement

Le premier concept important d'environnement est le concept de regroupement, c'est-à-dire le choix des ressources compatibles Environ associées à intégrer à Environ. 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 combinée dans Environ.
    • Les ressources d'un même environnement de déploiement (par exemple, votre environnement de production) doivent être gérées ensemble dans un Environ.
  • Qui gère les ressources ?
    • Le contrôle unifié des ressources (ou du moins approuvé mutuellement) est essentiel pour garantir l'intégrité d'Environ.

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 Environ. Chaque secteur d'activité est également susceptible d'adopter plusieurs instances d'Environ 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 instances Environ en fonction des besoins de votre entreprise.

Uniformité

Le concept d'uniformité est fondamental dans Environ. 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 Environ. 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 Environ. 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 une instance Environ, même si l'instanciation de l'espace de noms n'existe que dans un sous-ensemble de ressources Environ.

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 Environ, 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 d'Environ.

Schéma illustrant l'égalité des espaces de noms dans Environ
Compétences uniformes dans un environnement

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 Environ, 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 espaces de noms dans Environ
Compétences uniformes dans un environnement

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

Les services dans Environ 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 Environ 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 Environ. 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 Environ telles que les 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 environnement 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é d'identité en accédant aux ressources en dehors d'Environ
Uniformité des identités qui accèdent à des ressources en dehors d'Environ

Uniformité de l'identité dans un environnement

Dans Environ, 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 Environ, autorisés une seule fois pour un service externe, ils peuvent également l'être en interne.

Dans l'exemple suivant, nous avons conféré un accès frontend à backend. Avec Environ, nous n'avons pas besoin de spécifier que frontend dans les clusters B et C peut accéder à backend dans les clusters A et B. À la place, nous indiquons simplement que frontend dans Environ peut accéder à backend. 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 Environ est essentielle pour garantir l'intégrité de la communication de service à service.

Schéma illustrant le même degré d'identité dans Environ
Uniformité de l'identité dans Environ

Exclusivité

Les ressources compatibles Environ peuvent uniquement faire partie d'une seule instance Environ à 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 Environ.

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 environnement. Cela permet d'assurer une gestion optimale de ces ressources jusqu'à l'environnement, 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'Environ, 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 d'Environ 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 Environ, afin qu'elles soient isolées au sein d'Environ. Si nécessaire, les services individuels peuvent ensuite être autorisés au-delà de la limite Environ.

Étape suivante

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