Planifier les fonctionnalités de parc

Une partie importante de la planification des parcs consiste à choisir les fonctionnalités compatibles avec les parcs que vous souhaitez utiliser. En particulier, si vous travaillez avec des clusters et des charges de travail de production existants, 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 rendus possibles par les parcs et leurs exigences, et fournit des conseils pratiques sur l'adoption des fonctionnalités.

Bon nombre des fonctionnalités décrites dans ce guide ne sont disponibles que dans GKE Enterprise. Pour en savoir plus, consultez la page Options de déploiement de GKE Enterprise.

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 connaître notre présentation de la gestion des parcs et notre planification des ressources de parc, qui expliquent comment organiser des clusters nouveaux ou existants en parcs.

Bonnes pratiques pour l'adoption des fonctionnalités

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

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 dans lequel les espaces de noms, les services ou les identités portant le même nom sur différents clusters sont supposés être la même entité. Pour en savoir plus sur le principe d'uniformité et sur les fonctionnalités qui l'utilisent, consultez la section Fonctionnement des parcs.

Intégrer des fonctionnalités à faible risque

Les fonctionnalités "ambiantes" suivantes n'impliquent aucun type d'uniformité et n'affectent en rien les clusters. Ils peuvent tous être utilisés en toute sécurité, même avec des charges de travail et des clusters existants, ce qui vous permet de bénéficier immédiatement d'une observabilité et d'insights de sécurité améliorés sur l'ensemble de votre parc. Vous pouvez également gérer l'ordre des mises à niveau des clusters en fonction de l'appartenance à un parc.

Les fonctionnalités suivantes sont installées sur des clusters individuels. Les fonctionnalités peuvent supposer l'uniformité, 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égration des fonctionnalités multiclusters avancées

Les fonctionnalités puissantes suivantes réduisent les coûts opérationnels liés à la gestion de plusieurs clusters. Toutefois, vous devez faire preuve de plus de prudence avec ces fonctionnalités, car elles nécessitent toutes l'hypothèse d'un ou de plusieurs types d'identité pour fonctionner. Leur activation ou leur désactivation peut affecter plusieurs clusters et leurs charges de travail.

Par exemple, si vous disposez d'espaces de noms Kubernetes 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 les fonctionnalités qui reposent sur cette hypothèse. De même, si vous souhaitez utiliser Cloud Service Mesh, vous devez identifier les points de terminaison de service qui seront fusionnés entre vos clusters et vous assurer que c'est le comportement souhaité.

Auditer 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. Vérifiez en particulier l'utilisation ad hoc de l'espace de noms par défaut. Par exemple, si vous avez un espace de noms appelé default dans un cluster et un autre 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 s'appliquent et l'espace de noms des principaux est autorisé à y accéder.
  • 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 l'uniformité d'espace de noms, vous pouvez activer les fonctionnalités qui l'utilisent.

Vérifier l'uniformité du service

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é de Cloud Service Mesh) : si namespace1/service1 est autorisé à effectuer une action, les charges de travail associées à cette identité 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/nom de service sur 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é d'espace de noms/nom de service est également supposée par l'objet Ingress multicluster 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 l'identité de la charge de travail

La fédération d'identité de charge de travail à l'échelle de votre parc constitue une fonctionnalité puissante de parc. 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 des clés de compte de service Google Cloud. À la place, 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 entre les 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 sont dans différents projets, avec une uniformité implicite pour les identités du parc, ainsi que l'uniformité d'espace de noms et de service. Cela facilite la configuration de l'authentification pour vos applications entre projets, mais peut avoir des considérations supérieures au niveau du contrôle des accès pour la fédération d'identité de charge de travail pour GKE standard si vous choisissez de l'utiliser dans des parcs multiprojets, en particulier si le projet hôte de parc dispose une combinaison de clusters avec parc et hors 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 Enterprise permet de définir des valeurs par défaut au niveau du parc pour certaines fonctionnalités d'entreprise, y compris Cloud Service Mesh, Config Sync et Policy Controller. Cela vous permet de configurer des clusters pour qu'ils utilisent 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 au moment de leur création. 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 les ajoutez après avoir configuré les valeurs 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.

Fonctionnalités requises

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 Enterprise Aucun Aucun
Policy Controller Tous les clusters compatibles avec GKE Enterprise Aucun Aucun
Cloud Service Mesh Consultez 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 un VPC partagé.
Entrée multicluster 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 nécessitent une configuration supplémentaire. 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
Stratégie de conformité GKE sur Google Cloud Aucun Aucun
Métriques d'utilisation des ressources de parc GKE sur Google Cloud Aucun Aucun
Journalisation de parc Tous Aucun Aucun
Passerelle Connect Tous Aucun Aucun
Gestion des équipes de parc Tous Aucun Aucun
Règles de réseau FQDN du pod 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 concernant le 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, il est courant qu'une organisation dispose de plusieurs projets, chacun avec son propre VPC par défaut. Il peut s'agir de connexions d'appairage existantes. Si vous n'utilisez pas de fonctionnalité nécessitant un VPC unique, vous pouvez les placer toutes dans un seul 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 parcs multiprojets, ou revoir votre architecture et déplacer des charges de travail, le cas échéant.

Exigences concernant la mise en réseau multicluster

Si vous souhaitez utiliser l'objet Ingress multicluster ou des passerelles multiclusters pour la gestion du 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 de plusieurs projets, vous pouvez utiliser des passerelles de cluster uniques et rediriger le trafic vers la bonne passerelle d'une autre manière (par exemple, à l'aide de DNS). Les clusters qui utilisent ces fonctionnalités doivent également se trouver sur le même réseau VPC.

Étape suivante