Consignes concernant la segmentation de Config Controller

Ce document fournit des recommandations sur la manière de segmenter votre utilisation de Config Controller. La segmentation est le processus de division des ressources Google Cloud gérées par Config Controller sur plusieurs espaces de noms, clusters ou projets.

La segmentation présente les avantages suivants :

  • Réduction de l'impact des modifications : si un seul shard cesse de fonctionner, les autres shards ne sont pas affectés.
  • Aide à gérer la sécurité : chaque segment peut avoir des configurations IAM et RBAC dédiées. Les pirates informatiques malveillants qui compromettent un segment ne peuvent pas accéder aux autres. Les erreurs de configuration d'un segment ne peuvent pas affecter les autres.
  • Meilleure évolutivité : un segment unique peut présenter des goulots d'étranglement pour l'évolutivité, tels que le nombre d'objets gérés ou les quotas d'API. Le fait de disposer de plusieurs segments augmente l'évolutivité globale de votre utilisation de Config Controller.

Utiliser la segmentation avec Config Controller

Il existe plusieurs façons d'implémenter le partitionnement. La meilleure approche pour vous dépendra de vos besoins et exigences spécifiques.

Modèles de segmentation

Il existe deux principaux modèles de segmentation :

  • Par branche d'activité ou par équipe de développement : ce modèle est généralement utilisé lorsque Config Controller est partagé par différentes équipes. Dans ce modèle, chaque équipe possède son propre shard.
  • Par environnement : ce modèle est généralement utilisé lorsque Config Controller est employé dans différents environnements. Par exemple, vous pouvez avoir un shard pour votre environnement de développement, un shard pour votre environnement QA et un shard pour votre environnement de production.

Réduire la nécessité des références croisées entre segments

Lorsque vous segmentez votre utilisation de Config Controller, vous devez réduire la nécessité des références croisées. Les références inter-shards peuvent rendre votre configuration plus complexe et difficile à gérer. Pour en savoir plus, consultez Références aux ressources dans les instances.

Mécanismes de segmentation

Il existe trois mécanismes de segmentation principaux :

Mises en garde concernant la segmentation

Lorsque vous mettez en œuvre la segmentation pour votre utilisation de Config Controller, vous devez connaître certains problèmes potentiels et prévoir leur résolution.

Références de ressources entre les instances

L'un des défis de la segmentation de Config Controller consiste à gérer les références de ressources entre les instances. Par exemple, l'équipe chargée de la plate-forme peut créer des projets dans une instance, puis les équipes chargées des applications peuvent créer des ressources faisant référence à ces projets dans d'autres instances. Cela peut entraîner les problèmes suivants :

  • Complexité accrue : la gestion des références de ressources entre les clusters peut rendre votre configuration plus complexe et difficile à gérer.
  • Risque accru : si une ressource est supprimée dans un fragment, elle peut toujours être référencée par des ressources dans d'autres fragments. Cela peut entraîner un comportement inattendu et une perte de données.
  • Dégradation des performances : les références de ressources entre les clusters peuvent augmenter la latence de vos modifications de configuration.

Il existe plusieurs façons de contourner les problèmes liés aux références croisées :

  • Segmenter de manière à ce qu'aucune référence entre les segments ne soit nécessaire. Pour ce faire, vous pouvez segmenter par environnement ou par équipe.
  • Utiliser des références externes. Cela signifie que l'objet référencé n'est pas réellement géré par Config Controller. Cette option peut être intéressante si l'objet ne change pas souvent.
  • Avoir le même objet disponible dans tous les shards. Il s'agit d'une option plus complexe, mais elle peut être la meilleure si l'objet change fréquemment. Les objets doivent partager la même source de vérité pour éviter les conflits de rapprochement entre ces objets dans différents segments. Vous devez définir la règle de prévention des conflits sur none pour ces objets.

Il est important d'examiner attentivement les avantages et les inconvénients de chaque approche avant d'en choisir une.

Quotas d'API

Le sharding peut augmenter vos quotas d'API. Vous devez en tenir compte et planifier en conséquence. Consultez la page Gérer les limites de quota des API pour connaître les bonnes pratiques associées.

Étapes suivantes