Cette page explique comment utiliser Config Controller lors de l'exécution de services hautement disponibles ou de la gestion de ressources dans plusieurs régions Google Cloud.
Config Controller s'exécute dans une seule région. Il peut donc tolérer la défaillance d'une zone de disponibilité, mais il ne sera pas disponible en cas de défaillance de la région entière. Il existe deux stratégies différentes en cas de défaillance régionale, et votre choix dépend de ce que vous feriez en cas de défaillance d'une région :
Si votre réaction à une défaillance régionale est de mettre en œuvre des modifications de configuration, créez une deuxième instance de Config Controller.
Si vous n'effectuez pas de modifications de configuration, utiliser une seule instance de Config Controller devrait suffire.
Comprendre les scénarios de défaillance
Config Controller utilise un cluster GKE régional. Bien que le cluster régional puisse tolérer la défaillance d'une seule zone d'une région, il devient indisponible en cas de défaillance de plusieurs zones de la région.
Si votre instance Config Controller échoue, vos ressources Google Cloud existantes restent dans leur état actuel. Toutefois, même si vos applications sont toujours en cours d'exécution, vous ne pourrez pas modifier leur configuration si Config Controller n'est pas disponible. Cela s'applique aux ressources de la même région et aux ressources d'autres régions que vous gérez à partir du Config Controller situé dans la région indisponible.
Étant donné que vous ne pouvez pas reconfigurer les ressources dans la même région, si une défaillance régionale affecte les ressources Google Cloud existantes dans la région Config Controller, vous ne pourrez pas les réparer.
Étant donné que vous ne pouvez pas reconfigurer les ressources dans d'autres régions, une défaillance régionale affecte votre capacité à mettre en œuvre des modifications dans une autre région.
D'autres scénarios de défaillance sont également possibles. Par exemple, si vous configurez Config Sync pour extraire des données d'un fournisseur Git externe, vous devez prendre en compte les modes de défaillance de ce fournisseur. Vous ne pourrez peut-être pas modifier la configuration s'il s'avère impossible de transmettre des modifications à ce fournisseur Git. Si Config Sync ne peut pas lire les données à partir de Git, les modifications Git ne seront pas appliquées au cluster et Config Connector ne les appliquera pas. Cependant, la défaillance régionale est souvent le scénario de défaillance le plus important, car d'autres scénarios de défaillance ne sont généralement pas corrélés avec la défaillance de Config Controller.
Utiliser un seul cluster pour la disponibilité régionale
Dans de nombreux scénarios, aucune reconfiguration n'est effectuée en cas de défaillance d'une région. Dans ce cas, vous pouvez choisir d'accepter l'indisponibilité d'un plan de contrôle de configuration si une défaillance régionale se produit.
Par exemple, si vous n'opérez que dans une seule région, il peut être inutile de mettre en œuvre une reconfiguration en cas de défaillance de cette région. De même, si une base de données constitue un point de défaillance unique situé dans une seule région, vous ne pourrez peut-être pas y avoir accès tant qu'une défaillance régionale n'est pas corrigée. Pour les applications qui n'ont pas besoin de la disponibilité la plus élevée, cette situation peut être un compromis raisonnable en termes de coût et de complexité.
La localisation de l'instance Config Controller dans la même région vous donne un accès partagé : Config Controller est disponible tant que votre région principale est disponible. La localisation de l'instance Config Controller dans une région différente peut également constituer un bon choix. Bien que vous deviez maintenant réfléchir aux défaillances potentielles dans deux régions, vous évitez la défaillance corrélée de votre plan de contrôle de configuration avec la défaillance de votre région principale.
Si vous disposez d'une configuration multirégionale redondante, votre système peut éviter automatiquement les régions subissant une défaillance. Dans ce cas, vous pouvez également souhaiter éviter une reconfiguration en cas de défaillance régionale. Dans cette situation, vous pouvez choisir d'utiliser une seule instance Config Controller.
Basculement manuel vers une deuxième instance Config Controller
Vous pouvez effectuer une reconfiguration pour corriger le problème en cas de défaillance d'une région. Vous pouvez également continuer à configurer des ressources dans d'autres régions, même si votre instance Config Controller se trouve dans une région défaillante. Dans ce cas, nous vous recommandons d'utiliser une deuxième instance Config Controller dans une deuxième région.
Bien que cela ne soit pas recommandé, deux instances de Config Controller peuvent s'exécuter avec des configurations identiques. Les deux instances seront en concurrence pour lire le même dépôt Git et appliquer les mêmes modifications à Google Cloud. Cependant, de nombreux cas spéciaux rendent une telle configuration peu fiable. Les deux instances Config Controller observeront le dépôt Git à des moments légèrement différents et peuvent donc tenter d'appliquer des versions légèrement différentes de votre configuration Google Cloud. Le fait d'avoir plusieurs auteurs actifs pour Google Cloud augmente également les chances d'atteindre vos quotas ou limites de débit. Un petit nombre de ressources Config Connector ne sont également pas idempotentes et nécessitent une attention supplémentaire, comme indiqué dans le reste de cette section. Par conséquent, il est déconseillé d'utiliser simultanément deux clusters de Config Controller pour le rapprochement.
Si la région qui exécute Config Controller échoue, nous vous recommandons plutôt un autre contrôleur dans une autre région. La nouvelle instance Config Controller doit être configurée de manière identique à la première, en lisant depuis le même dépôt Git. Il peut être utile de préparer un script pour afficher et configurer votre instance Config Controller dans ce scénario. Lorsque vous créez votre instance Config Controller, Config Sync lit et applique l'état souhaité de Git à Kubernetes. Config Connector synchronise l'état souhaité avec Google Cloud.
Deux points sont à prendre en compte dans cette situation :
Si le premier cluster Config Controller est toujours en cours d'exécution ou commence à s'exécuter lorsque la première région est rétablie, il peut tenter d'appliquer l'ancien état à Google Cloud. Si vous pouvez arrêter le cluster Config Controller dans la première région avant de démarrer un deuxième cluster, vous pouvez éviter ce conflit potentiel.
Certaines ressources Config Connector ne peuvent pas être facilement réappliquées depuis Git. Pour obtenir la liste des ressources nécessitant une attention particulière, consultez la section Ressources avec restrictions concernant l'acquisition. En particulier, nous vous recommandons de faire attention aux ressources
Folderet d'éviter les ressourcesIAMServiceAccountKey(par exemple, en utilisant GKE Workload Identity à la place).
Une instance Config Controller par région
Si vous souhaitez éviter qu'une instance Config Controller d'une région affecte une autre région, vous pouvez également envisager d'exécuter une instance Config Controller par région, où chaque instance Config Controller gère les ressources de cette région.
Cette configuration peut fonctionner, mais il ne s'agit pas de l'une des options recommandées pour les raisons suivantes :
Certaines ressources couvrent plusieurs régions (telles que Cloud DNS). Cette stratégie n'est donc pas exhaustive.
En règle générale, disposer d'un cluster Config Controller dans la même région entraîne le problème de défaillance corrélée : vous souhaitez reconfigurer les ressources au moment exact où une défaillance régionale affecte le contrôleur Config Controller de cette région.
Vous devez répartir vos ressources Config Connector par région.
Config Controller n'est actuellement pas disponible dans toutes les régions.
Configurer directement des ressources Google Cloud
Dans des circonstances exceptionnelles, vous pouvez apporter des modifications directement aux ressources Google Cloud sous-jacentes, sans passer par Git ou Config Connector. Config Connector tente de corriger toutes les "dérives". Ainsi, si votre instance Config Controller est toujours en cours d'exécution, Config Connector considère toutes les modifications que vous apportez manuellement comme étant des dérives et tente de les annuler.
Toutefois, si vous arrêtez votre instance Config Controller ou si la région est hors connexion, cette mesure palliative peut être utile.
Lorsque votre instance Config Controller sera rétablie, Config Connector tentera probablement d'annuler vos modifications manuelles. Pour éviter cette situation, vous pouvez effectuer des modifications dans Git pour que cela corresponde à toutes les modifications que vous apportez manuellement.