Planifier les fonctionnalités de parc

Pour planifier les parcs, il est important de déterminer les fonctionnalités de parc que vous souhaitez utiliser. En particulier si vous travaillez avec des clusters existants et des charges de travail de production, vous pouvez identifier les fonctionnalités de parc qui peuvent être adoptées immédiatement avec un minimum de friction ou de risque pour vos applications existantes, tout en planifiant d'autres fonctionnalités qui peuvent nécessiter une adoption plus progressive ou plus prudente. Ce guide décrit les différents types de fonctionnalités activées par l'utilisation de flottes et leurs exigences, et fournit des conseils pratiques sur l'adoption des fonctionnalités.

Ce guide s'adresse aux architectes Cloud qui souhaitent se lancer avec des parcs dans leur organisation. Avant de lire ce guide, assurez-vous de maîtriser notre présentation de la gestion de parc et la section Planifier des ressources de parc, qui explique comment organiser des clusters nouveaux ou existants en parcs.

Bonnes pratiques pour l'adoption des fonctionnalités

Toutes les fonctionnalités de parc (à l'exception de l'observabilité de base du parc) sont activées sur demande. Vous devez donc spécifier que vous souhaitez les utiliser. Le simple ajout d'un cluster existant à un parc ne modifie pas sa configuration. Lorsque vous décidez d'utiliser les fonctionnalités de parc, certaines peuvent être activées immédiatement avec un risque minimal, mais vous devrez peut-être aborder d'autres fonctionnalités avec plus de prudence. Cette section fournit des conseils pour l'adoption des fonctionnalités.

En particulier avec les clusters et les charges de travail existants, vous devez être particulièrement prudent lorsque les fonctionnalités utilisent la similitude. Il s'agit d'un concept de parc selon lequel les espaces de noms, les services ou les identités portant le même nom dans différents clusters sont considérés par la fonctionnalité comme étant identiques. Pour en savoir plus sur le principe d'uniformité et les fonctionnalités qui l'utilisent, consultez Fonctionnement des parcs.

Intégrer les fonctionnalités à faible risque

Les fonctionnalités "ambiantes" suivantes n'impliquent aucun type d'uniformité et n'affectent en rien les clusters. Vous pouvez les utiliser en toute sécurité, même avec des charges de travail et des clusters existants. Vous bénéficiez ainsi immédiatement d'une observabilité et d'informations sur la sécurité améliorées dans votre parc, ainsi que de la possibilité de gérer l'ordre de mise à niveau des clusters en fonction de leur appartenance au parc.

Les fonctionnalités suivantes sont installées sur des clusters individuels. Les fonctionnalités peuvent supposer l'identité, mais uniquement lors de la configuration ou de la spécification de ressources sur plusieurs clusters. Cela signifie que vous pouvez activer ces fonctionnalités en toute sécurité sur vos clusters avec des charges de travail existantes, et que vous n'avez besoin de prendre en compte l'uniformité que lorsque vous créez ou utilisez des configurations pour ceux qui utilisent ces sélecteurs facultatifs.

Intégrer les fonctionnalités multicluster avancées

Les fonctionnalités puissantes suivantes réduisent les coûts opérationnels liés à la gestion de plusieurs clusters. Toutefois, il convient d'être plus prudent avec ces fonctionnalités, car elles nécessitent toutes une hypothèse d'un ou plusieurs types de similitude pour fonctionner. L'activation ou la désactivation de ces fonctionnalités peut affecter plusieurs clusters et leurs charges de travail.

Par exemple, si vous avez des espaces de noms Kubernetes existants portant le même nom dans différents clusters et applications (y compris l'espace de noms par défaut), vous devez vérifier que vous souhaitez qu'ils soient traités comme le même espace de noms avant d'activer des fonctionnalités qui reposent sur cette hypothèse. De même, si vous souhaitez utiliser Cloud Service Mesh, vous devez comprendre quels points de terminaison de service seront fusionnés dans vos clusters et confirmer que ce comportement est souhaité.

Vérifier l'uniformité de l'espace de noms

Si vous connaissez bien vos applications, vous pouvez auditer vos espaces de noms en vérifiant simplement qu'il n'y a pas deux applications "différentes" qui utilisent le même espace de noms. En particulier, faites attention à l'utilisation ponctuelle de l'espace de noms par défaut. Par exemple, si vous avez un espace de noms appelé default dans un cluster et un espace de noms appelé default dans un autre cluster, mais qu'ils sont utilisés à des fins différentes, vous devez en renommer un.

Pour une approche plus rigoureuse, essayez ce qui suit. Pour chaque ensemble d'espaces de noms portant le même nom sur différents clusters d'un parc, vérifiez les points suivants :

  • Dans chaque cluster, les mêmes règles RBAC sont appliquées au cluster et l'espace de noms des principaux est autorisé à accéder à l'espace de noms.
  • L'ensemble d'images utilisé par les pods (moins le hachage/tag) est le même.
  • L'ensemble de secrets utilisés par les pods est identique.

Si toutes ces conditions sont remplies, les espaces de noms sont suffisamment similaires pour être considérés comme "identiques".

Si vos espaces de noms ne sont pas suffisamment similaires, vous pouvez migrer des applications vers de nouveaux espaces de noms. Une fois que vous êtes prêt à supposer que les espaces de noms sont identiques, vous pouvez activer les fonctionnalités qui l'utilisent.

Uniformité du service d'audit

Si vous souhaitez adopter Cloud Service Mesh pour gérer vos applications basées sur des microservices, vous devez également tenir compte de l'identité des services. Cela signifie que pour toute combinaison d'espace de noms et de nom de service, Cloud Service Mesh les traite comme le même service logique en termes de :

  • Identité (spécifiquement pour la sécurité Cloud Service Mesh) : si namespace1/service1 est autorisé à effectuer une action, les charges de travail avec cette identité provenant de n'importe quel cluster sont autorisées.
  • Gestion du trafic : par défaut, le trafic est équilibré en charge entre les services namespace1/service1 de n'importe quel cluster.
  • Observabilité : les métriques pour namespace1/service1 dans tous les clusters sont agrégées.

Si vous activez Cloud Service Mesh avec de nouveaux clusters et applications, nous vous recommandons de réserver des combinaisons uniques d'espace de noms et de nom de service pour l'ensemble de votre maillage. Pour les applications existantes, effectuez un audit de vos services afin de vous assurer que les services portant le même espace de noms et le même nom dans vos clusters sont ceux que vous souhaitez traiter comme étant le même service en termes d'identité, de gestion du trafic et d'observabilité.

Veillez tout particulièrement à ce que les services logiquement différents (par exemple, une API de compte de paiement et une API de transaction de paiement) n'utilisent pas la même paire [espace de noms, nom] (par exemple, payments/api), car ils seront traités comme étant un seul service une fois dans un maillage de services. Cette jointure conceptuelle se produit même à travers des limites régionales. La fonction assurée par les services peut également être affectée.

L'uniformité de l'espace de noms/du nom de service est également supposée par Multi Cluster Ingress et la passerelle multicluster lors de la redirection du trafic vers des services sur plusieurs clusters, mais uniquement pour les services exposés en dehors des clusters.

Tenir compte de Workload Identity

La fédération d'identité de charge de travail à l'échelle du parc est une fonctionnalité puissante des parcs. Cela étend les fonctionnalités fournies par la fédération d'identité de charge de travail pour GKE, qui permet aux charges de travail de votre cluster de s'authentifier auprès de Google sans avoir à télécharger, effectuer une rotation manuelle ni gérer les clés de compte de service Google Cloud . Les charges de travail s'authentifient à l'aide de jetons de courte durée générés par les clusters, chaque cluster étant ajouté en tant que fournisseur d'identité à un pool d'identités de charge de travail spécial. Les charges de travail exécutées dans un espace de noms spécifique peuvent partager la même identité Identity and Access Management sur différents clusters.

Alors que la fédération d'identité de charge de travail standard pour GKE utilise un pool d'identités à l'échelle du projet, la fédération d'identité de charge de travail à l'échelle du parc utilise un pool d'identités de charge de travail pour l'ensemble du parc, même si les clusters se trouvent dans des projets différents, avec une identité implicite pour les identités dans le parc, ainsi que pour les espaces de noms et les services. Cela simplifie la configuration de l'authentification pour vos applications dans plusieurs projets, mais peut avoir des considérations de contrôle des accès en plus de celles de la fédération d'identité de charge de travail standard pour GKE si vous choisissez de l'utiliser dans des parcs multiprojets, en particulier si le projet hôte du parc comporte un mélange de clusters de parc et de clusters non membres d'un parc.

Pour en savoir plus sur la fédération d'identité de charge de travail pour un parc et sur son utilisation pour accéder aux services Google Cloud , consultez la section Utiliser Workload Identity pour parc. Pour obtenir des conseils sur la réduction des risques avec la fédération d'identité de charge de travail pour un parc avec quelques exemples, consultez la page Bonnes pratiques d'utilisation de Workload Identity pour un parc.

Valeurs par défaut au niveau du parc

GKE vous permet de définir des valeurs par défaut au niveau du parc pour certaines fonctionnalités Enterprise, y compris Cloud Service Mesh, Config Sync et Policy Controller. Cela vous permet de configurer des clusters pour utiliser ces fonctionnalités sans avoir à configurer chaque cluster individuellement. Par exemple, un administrateur peut activer Policy Controller pour son parc et définir des règles par défaut au niveau du parc. L'agent requis est alors installé dans les nouveaux clusters de membres du parc et des règles par défaut leur sont appliquées.

Toutefois, ces valeurs par défaut ne s'appliquent automatiquement qu'aux nouveaux clusters que vous ajoutez au parc lors de la création du cluster. Les clusters existants et leurs charges de travail ne sont pas affectés, même si vous les avez déjà ajoutés au parc ou si vous ajoutez les clusters après avoir configuré les paramètres par défaut de vos fonctionnalités. Cela signifie que vous pouvez configurer en toute sécurité des valeurs par défaut au niveau du parc sans risquer d'activer ou de configurer des fonctionnalités sur les clusters que vous ne souhaitez pas. Vous pourrez toujours choisir d'appliquer les paramètres par défaut aux clusters existants ultérieurement.

Exigences concernant les fonctionnalités

Certaines limites sont à prendre en compte lors de la mise en œuvre de parcs basés sur les fonctionnalités de parc que votre organisation souhaite utiliser. Par exemple, certaines fonctionnalités ne sont pas compatibles avec les clusters qui ne font pas partie du projet hôte du parc, tandis que d'autres ne sont pas compatibles avec les clusters en dehors de Google Cloud.

Le tableau suivant indique les exigences et les limites actuelles de chaque composant, avec des consignes spécifiques dans les sections suivantes.

Caractéristique
 Types de clusters
 Exigences du projet
 Exigences en matière de VPC
Config Sync Tous les clusters compatibles avec GKE Aucun Aucun
Policy Controller Tous les clusters compatibles avec GKE Aucun Aucun
Cloud Service Mesh Consulter les limites Tous les clusters utilisés avec Cloud Service Mesh et appartenant au même projet doivent être enregistrés dans le même parc. Pour en savoir plus, consultez les exigences du parc de Cloud Service Mesh. Les clusters GKE doivent se trouver sur le même réseau VPC.
Services multiclusters (MCS) GKE sur Google Cloud Aucun Consultez MCS sur le VPC partagé.
Multi Cluster Ingress et passerelle multicluster GKE sur Google Cloud Les ressources Ingress/de passerelle, les clusters GKE et le parc doivent se trouver dans le même projet. Les ressources Ingress/de passerelle et les clusters GKE doivent se trouver sur le même réseau VPC.
Pools d'identités de charge de travail Optimisé pour GKE sur Google Cloud et Google Distributed Cloud sur VMware. D'autres clusters Kubernetes sont compatibles, mais une configuration supplémentaire est nécessaire. Aucun Aucun
Autorisation binaire GKE sur Google Cloud, Google Distributed Cloud sur VMware, Google Distributed Cloud sur Bare Metal Aucun Aucun
Advanced Vulnerability Insights GKE sur Google Cloud Aucun Aucun
Stratégie de sécurité GKE sur Google Cloud Aucun Aucun
Posture de conformité GKE sur Google Cloud Aucun Aucun
Métriques d'utilisation des ressources de parc GKE sur Google Cloud Aucun Aucun
Journalisation du parc Tous Aucun Aucun
Passerelle Connect Tous Aucun Aucun
Gestion des équipes de parc Tous Aucun Aucun
Règles de réseau FQDN des pods GKE sur Google Cloud Aucun Aucun
Chiffrement transparent entre les nœuds GKE sur Google Cloud Aucun Aucun
Config Controller Non applicable Aucun Aucun
Séquençage du déploiement GKE sur Google Cloud Aucun Aucun

Tenir compte des exigences du cloud privé virtuel

Si vous prévoyez d'utiliser une fonctionnalité telle que Cloud Service Mesh, qui nécessite que les clusters se trouvent dans un seul réseau cloud privé virtuel (VPC), comme indiqué dans le tableau précédent, vous devez créer un parc pour chaque VPC. Si vous ne prévoyez pas d'utiliser ces fonctionnalités, vous pouvez placer plusieurs VPC dans un même parc.

Par exemple, un schéma courant consiste à ce qu'une organisation dispose de plusieurs projets, chacun avec son propre VPC par défaut. Il est possible que des connexions d'appairage existent déjà entre elles. Si vous n'utilisez pas de fonctionnalité nécessitant un seul VPC, vous pouvez placer les clusters de tous ces VPC dans un même parc. Un autre modèle courant suit une topologie en étoile, qui utilise plusieurs VPC. Si vous n'utilisez pas de fonctionnalité nécessitant un seul VPC, vous pouvez placer les clusters de tous ces VPC dans un même parc. Notez que, dans certains cas, si vous suivez ces consignes, vous risquez de ne disposer que d'un seul cluster pour vos parcs. Dans ce cas, vous devrez peut-être renoncer à utiliser des fonctionnalités avec des restrictions VPC et créer des flottes multiprojets, ou repenser votre architecture et déplacer les charges de travail, le cas échéant.

Exigences concernant la mise en réseau multicluster

Si vous souhaitez utiliser Multi Cluster Ingress ou des passerelles multiclusters pour gérer le trafic, sachez que dans les deux cas, le contrôleur de passerelle ne peut pas s'étendre sur plusieurs projets. Cela signifie que tous les clusters que vous souhaitez utiliser avec ces fonctionnalités doivent se trouver dans le même projet et dans le même parc. Si vous devez créer des parcs incluant des clusters provenant de plusieurs projets, vous pouvez utiliser des passerelles à cluster unique et rediriger le trafic vers la bonne passerelle d'une autre manière (par exemple, en utilisant DNS). Les clusters qui utilisent ces fonctionnalités doivent également se trouver sur le même réseau VPC.

Étape suivante