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 gérées par Config Controller Google Cloud sur plusieurs espaces de noms, clusters ou projets.

La segmentation présente les avantages suivants :

  • Réduit l'impact des modifications: si un seul fragment cesse de fonctionner, les autres fragments 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 segments. 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 sharding. La meilleure approche dépend 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 dispose de son propre segment.
  • 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 fragment pour votre environnement de développement, un fragment pour votre environnement de test et un fragment 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-shard peuvent rendre votre configuration plus complexe et difficile à gérer. Pour en savoir plus, consultez la section Références de ressources entre 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 les ressources 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 fragments. 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 fractionnement 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