5.14. Configuration de l'élection du chef de file
Au cours du cycle de vie d'un opérateur, il est possible que plusieurs instances fonctionnent à un moment donné, par exemple lors du déploiement d'une mise à niveau de l'opérateur. Dans un tel scénario, il est nécessaire d'éviter les conflits entre les multiples instances de l'opérateur en utilisant l'élection d'un chef de file. Cela permet de s'assurer qu'une seule instance leader s'occupe de la réconciliation tandis que les autres instances sont inactives mais prêtes à prendre le relais lorsque le leader se retire.
Il est possible de choisir entre deux implémentations différentes de l'élection du chef, chacune ayant ses propres avantages :
- Leader pour la vie
-
Le pod leader n'abandonne son rôle de leader que lorsqu'il est supprimé, en utilisant le ramassage des ordures. Cette implémentation exclut la possibilité que deux instances fonctionnent par erreur en tant que leaders, un état également connu sous le nom de "split brain" (cerveau divisé). Toutefois, cette méthode peut entraîner un retard dans l'élection d'un nouveau leader. Par exemple, lorsque le pod leader se trouve sur un nœud qui ne répond pas ou qui est partitionné, le système de gestion de l'instance peut être modifié
pod-eviction-timeoutdicte le temps nécessaire pour que le pod leader soit supprimé du nœud et se retire, avec une valeur par défaut de5m. Voir la documentation Leader-for-life Go pour plus d'informations. - Chef de file avec bail
- Le pod leader renouvelle périodiquement le bail du leader et abandonne le leadership lorsqu'il ne peut pas renouveler le bail. Cette implémentation permet une transition plus rapide vers un nouveau leader lorsque le leader existant est isolé, mais il y a une possibilité de "split brain" dans certaines situations. Voir la documentation Leader-with-lease Go pour plus d'informations.
Par défaut, le SDK Operator active l'implémentation Leader-for-life. Consultez la documentation Go relative aux deux approches afin de déterminer les compromis les plus judicieux pour votre cas d'utilisation.
5.14.1. Exemples d'élections de chefs d'opérateurs
Les exemples suivants illustrent la manière d'utiliser les deux options d'élection du chef de file pour un opérateur, le chef de file à vie et le chef de file avec bail.
5.14.1.1. Élection du leader à vie
Avec l'implémentation de l'élection Leader-for-life, un appel à leader.Become() bloque l'Opérateur qui retente sa chance jusqu'à ce qu'il puisse devenir le leader en créant la carte de configuration nommée memcached-operator-lock:
import (
...
"github.com/operator-framework/operator-sdk/pkg/leader"
)
func main() {
...
err = leader.Become(context.TODO(), "memcached-operator-lock")
if err != nil {
log.Error(err, "Failed to retry for leader lock")
os.Exit(1)
}
...
}
Si l'opérateur n'est pas en cours d'exécution dans un cluster, leader.Become() renvoie simplement sans erreur pour sauter l'élection du leader puisqu'il ne peut pas détecter le nom de l'opérateur.
5.14.1.2. Élection du chef de file avec bail
La mise en œuvre de l'option Leader-with-lease peut être activée à l'aide des options du gestionnaire pour l'élection du leader :
import (
...
"sigs.k8s.io/controller-runtime/pkg/manager"
)
func main() {
...
opts := manager.Options{
...
LeaderElection: true,
LeaderElectionID: "memcached-operator-lock"
}
mgr, err := manager.New(cfg, opts)
...
}
Lorsque l'opérateur n'est pas exécuté dans un cluster, le gestionnaire renvoie une erreur au démarrage car il ne peut pas détecter l'espace de noms de l'opérateur pour créer la carte de configuration pour l'élection du chef. Vous pouvez remplacer cet espace de noms en définissant l'option LeaderElectionNamespace pour le gestionnaire.
