Ce guide décrit les bonnes pratiques, les aspects pratiques et les recommandations pour la mise en œuvre de parcs dans votre organisation.
Avant de lire ce guide, vous devez vous familiariser avec les concepts de la page Fonctionnement des parcs. Nous vous recommandons de lire ce guide avant de consulter nos exemples.
Configuration requise
Certaines limites sont à prendre en compte lors de la mise en œuvre de parcs basés sur les composants GKE Enterprise et Google Cloud compatibles avec le parc que votre organisation souhaite utiliser. Par exemple, certains composants peuvent ne pas encore être compatibles avec les clusters qui ne font pas partie du projet hôte du parc.
Le tableau suivant indique les exigences et les limites actuelles de chaque composant. Le tableau répertorie également les fonctionnalités incluses dans GKE Enterprise, mais qui ne sont pas configurées à l'aide de l'API Fleet.
| Composant |
Types de clusters |
Exigences du projet |
Exigences en matière de VPC |
|---|---|---|---|
| Config Sync | Tous les clusters compatibles avec GKE Enterprise | Aucune | Aucune |
| Policy Controller | Tous les clusters compatibles avec GKE Enterprise | Aucune | Aucune |
| Anthos Service Mesh | Consultez la page Plates-formes compatibles. | Le cluster doit être enregistré sur un parc, et tous les clusters d'un même projet doivent être enregistrés dans le même parc. Pour en savoir plus, consultez les exigences du parc d'Anthos Service Mesh. | Les clusters GKE doivent se trouver sur le même réseau VPC. |
| Objet Ingress multicluster et passerelle multicluster | Clusters GKE sur Google Cloud | Les ressources Ingress/de passerelle, les clusters GKE et le parc doivent partager 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 Enterprise, GKE sur Google Cloud et GKE sur VMware. Avec GKE Enterprise, d'autres clusters Kubernetes sont compatibles, mais une configuration manuelle est nécessaire. | Aucune | Aucune |
| Autorisation binaire | Clusters GKE sur Google Cloud, GKE sur solution Bare Metal, GKE sur VMware | Aucune | Aucune |
| Advanced Vulnerability Insights | Clusters GKE sur Google Cloud | Aucune | Aucune |
| Stratégie de sécurité GKE | Clusters GKE sur Google Cloud | Aucune | Aucune |
| Stratégie de sécurité GKE | Clusters GKE sur Google Cloud | Aucune | Aucune |
| Stratégie de conformité | Clusters GKE sur Google Cloud | Aucune | Aucune |
| Métriques d'utilisation des ressources de parc | Clusters GKE sur Google Cloud | Aucune | Aucune |
| Journalisation de parc | Tous | Aucune | Aucune |
| passerelle connect | Tous | Aucune | Aucune |
| Gestion d'équipes de parc | Tous | Aucune | Aucune |
| Règles de réseau FQDN des pods | Clusters GKE sur Google Cloud | Aucune | Aucune |
| Chiffrement transparent entre les nœuds | Clusters GKE sur Google Cloud | Aucune | Aucune |
| Config Controller | Non applicable | Aucune | Aucune |
| Séquençage du déploiement | Clusters GKE sur Google Cloud | Aucune | Aucune |
Organiser des projets et des réseaux VPC pour les parcs
Lors de la conception de parcs, vous devez prendre en compte deux ressources fondamentales : les projets Google Cloud et les réseaux cloud privés virtuels (VPC).
Comme indiqué dans la section Fonctionnement des parcs, chaque parc est créé dans un seul projet. Toutefois, (avec les limites mentionnées dans le tableau précédent), les parcs sont conçus pour fonctionner avec des ressources compatibles, comme le projet hôte du parc, un autre projet Google Cloud, d'autres fournisseurs cloud ou une infrastructure sur site.
Bien que cela ne soit pas explicitement évité dans la plupart des cas, nous vous recommandons également d'ajouter les ressources compatibles avec le parc d'un même projet au même parc. Elles ne doivent pas être réparties entre différents parcs. La répartition des ressources d'un même projet entre différents parcs est considérée comme un anti-modèle, car la délimitation du projet fournit des protections plus strictes à des fins de stratégie et de gouvernance.
Lorsque nous décidons de placer des ressources compatibles avec le parc dans plusieurs projets, nous supposons que de nombreuses organisations auront des exigences d'architecture différentes. Tenez compte des deux éléments suivants :
- Certaines organisations peuvent choisir de placer toutes les ressources du parc dans des projets contrôlés de manière centralisée afin d'allouer des espaces de noms aux équipes.
- D'autres organisations peuvent choisir d'attribuer à leurs équipes leurs clusters dédiés dans leurs propres projets.
Dans le premier cas, il est plus facile de maintenir un contrôle centralisé sur les ressources, mais une tâche supplémentaire peut être nécessaire pour atteindre l'isolation souhaitée. Dans le deuxième cas, ces compromis sont inversés. Dans certains cas complexes, votre organisation peut combiner des ressources d'infrastructure partagées et des ressources dédiées, isolées dans des projets distincts. Quel que soit l'endroit où vous finissez, comme évoqué dans notre section Confiance élevée, il est important de maintenir la confiance mutuelle entre les ressources enregistrées dans un parc pour maintenir l'intégrité du parc.
L'organisation du réseau est étroitement liée à l'organisation du projet. Plusieurs composants du parc, comme indiqué dans le tableau de la configuration requise, nécessitent une connectivité spécifique entre les ressources enregistrées dans le parc. Au fil du temps, certaines de ces exigences peuvent être assouplies. Cependant, par exemple, l'objet Ingress multicluster exige actuellement que les pods se trouvent sur le même réseau VPC, les clusters eux-mêmes se trouvant dans le même projet que le parc.
Lorsque les composants peuvent assouplir ces exigences initiales en matière de projet et de réseau VPC, nous pensons que l'adoption d'un modèle de VPC partagé deviendra une bonne pratique lorsque vous aurez besoin de plusieurs projets. Dans un tel modèle, le parc peut être instancié dans le projet hôte du réseau VPC avec des ressources enregistrées à partir de leurs projets de service respectifs. Si vous avez besoin de plusieurs parcs avec un VPC partagé, vous pouvez désigner des projets comme projet hôte du parc.
Ajouter/Supprimer des ressources de parc (clusters)
Des ressources de parc existantes peuvent être ajoutées à un parc, mais il est nécessaire de prendre des précautions particulières pour s'assurer que les services ne soient pas interrompus en raison de leur ajout. En particulier, il est important de vous assurer que les propriétés d'uniformité et de confiance sont prises en compte avant d'ajouter la ressource au parc. L'administrateur du parc doit accorder une attention particulière à la façon dont sont utilisés les composants actifs du parc. Cela peut nécessiter la migration vers des pratiques de dénomination cohérentes, l'établissement d'un contrôle de la ressource ou éventuellement d'autres actions avant de l'ajouter au parc.
Supprimer des ressources d'un parc nécessite également une attention particulière. Par exemple, les ressources faisant activement partie d'un maillage de services ou ciblées dans le cadre d'un équilibreur de charge multi-cluster sont concernées. Pour vous préparer à la suppression de la ressource, nous vous recommandons d'examiner chaque composant que vous avez activé sur votre parc et de prendre les mesures nécessaires pour drainer le trafic du maillage de service actif ou le trafic externe.
Au fur et à mesure de l'évolution des parcs, nous fournirons davantage de conseils en bande lors de l'ajout et de la suppression de ressources de parc.
Activer ou reconfigurer des composants du parc
Activer ou reconfigurer des composants Google Cloud ou GKE Enterprise utilisant des parcs nécessite également une attention particulière. Lors de l'activation de nouveaux composants, soyez attentif aux potentiels effets secondaires de l'activation du composant sur tous les clusters. Par exemple, avant d'activer Anthos Service Mesh, identifiez les points de terminaison de service qui sont fusionnés entre les ressources, puis assurez-vous qu'il s'agit du résultat souhaité.
Nous vous fournirons davantage d'informations en bande lors de la configuration des composants compatibles avec le parc et à mesure que nous modifions le concept de parc.
Étape suivante
- Pour obtenir des scénarios hypothétiques qui illustrent les considérations décrites dans ce guide, consultez la section Exemples de parcs.