Principe de l'architecture etcd

table des matières

La terminologie de base d'etcd

• Raft : l'algorithme utilisé par etcd pour assurer une forte cohérence des données du système distribué.
• Node : une instance de la machine d'état Raft.
• Membre : une instance etcd, qui gère un nœud et peut fournir des services pour les demandes des clients.
• Cluster : un cluster etcd qui peut fonctionner ensemble est formé par plusieurs membres.
• Homologue : nom d'un autre membre dans le même cluster etcd.
• Client : le client qui envoie des requêtes HTTP au cluster etcd.
• WAL : journal à écriture anticipée, le format de journal utilisé par etcd pour le stockage persistant.
• Snapshot : Snapshot défini par etcd pour éviter un trop grand nombre de fichiers WAL et stocker l'état des données etcd.
• Entrée : Une entrée dans le journal dans l'algorithme Raft.
• Proxy : un mode de etcd qui fournit des services de proxy inverse pour les clusters etcd.
• Leader : Le nœud qui traite toutes les soumissions de données générées par élection dans l'algorithme Raft.
• Suiveur : le nœud qui échoue à l'élection dans l'algorithme Raft est utilisé comme nœud subordonné pour fournir une solide garantie de cohérence pour l'algorithme.
• Candidat : Lorsque l'adepte ne reçoit pas le rythme cardiaque du leader pendant plus d'une certaine période de temps (on considère que le leader a mal fonctionné), il passera à un candidat et commencera l'élection.
• Terme : Le moment où un nœud devient le chef de la prochaine élection est appelé un terme.
• Vote : Un vote lors de l'élection.
• Index : numéro de l'élément de données. Dans Raft, utilisez Terme et Index pour localiser les données.
• Commit : un commit, les données persistantes sont écrites dans le journal.
• Proposer : une proposition demandant que la plupart des nœuds acceptent d'écrire des données.

architecture logicielle etcd

• Serveur HTTP : accepte les demandes d'API des clients et les demandes d'informations de synchronisation et de pulsation provenant d'autres nœuds etcd.

• Store : Utilisé pour traiter diverses fonctions prises en charge par etcd, y compris l'indexation des données, les changements d'état des nœuds, la surveillance et la rétroaction, le traitement et l'exécution des événements, etc. C'est l'implémentation spécifique de la plupart des fonctions API fournies par les utilisateurs par etcd.

• Raft : L'implémentation spécifique de l'algorithme de cohérence forte est l'algorithme de base d'etcd.

• WAL (Write Ahead Log) : C'est la méthode de stockage des données de etcd. Etcd stockera l'état de toutes les données et l'index du nœud en mémoire. De plus, etcd effectuera également un stockage persistant via WAL. Dans WAL, toutes les données seront enregistrées à l'avance avant la soumission.

  • Snapshot est un instantané d'état pour éviter des données excessives;
  • L'entrée représente le contenu de journal spécifique stocké.

Habituellement, la demande d'un utilisateur est envoyée et elle sera transmise au magasin via le serveur HTTP pour un traitement de transaction spécifique. Si cela implique la modification des données du nœud, elle sera transmise au module Raft pour les changements d'état et les enregistrements de journal, puis synchronisée avec d'autres. Le nœud etcd confirme la soumission des données, puis soumet finalement les données et se synchronise à nouveau.

Radeau

Pour la nouvelle version d'etcd, le package Raft est l'implémentation spécifique de l'algorithme de consensus Raft.

Que signifie un terme dans Raft?

Dans l'algorithme Raft, en termes de temps, un terme (terme) va du début d'une élection au début de l'élection suivante. D'un point de vue fonctionnel, si l'adepte ne reçoit pas les informations de battement de cœur du leader, il mettra fin au mandat en cours, deviendra candidat puis lancera une campagne, puis aidera à la récupération du cluster lorsque le leader échouera. Lorsque le vote pour les élections est lancé, les nœuds avec une faible valeur de terme ne réussiront pas. Si le cluster n'échoue pas, un terme se poursuivra indéfiniment. En outre, les conflits de vote peuvent également entrer directement dans l'élection suivante.

Comment la machine d'état Raft change-t-elle?

Lorsque Raft a commencé à fonctionner pour la première fois, Node entrait par défaut dans l'état suiveur, en attendant que le chef envoie des informations sur les pulsations. Si le délai d'attente expire, le statut passera de Suiveur à Candidat et entrera dans le prochain tour de Mandat pour lancer l'élection. Lorsque le vote du «nœud majoritaire» du Cluster est reçu, le Nœud sera changé en Leader. Le chef peut avoir des pannes de réseau, ce qui oblige d'autres nœuds à voter pour devenir le chef du nouveau mandat. À ce moment-là, l'ancien chef d'origine sera remplacé par suiveur. Le candidat passera en suiveur s'il constate qu'un chef a été élu avec succès en attendant que d'autres nœuds votent.

Comment s'assurer que le chef est élu dans les plus brefs délais et éviter les conflits lors des élections?

Sur l'image de la machine à états Raft, vous pouvez voir que dans l'état Candidat, il y a un temps mort, où le temps de temporisation est une valeur aléatoire, c'est-à-dire qu'après que chaque nœud est devenu un candidat, le délai est le temps de lancer un nouveau tour d'élections. Chacun est différent, il y aura un décalage horaire. Dans le décalage horaire, si les informations sur le candidat reçues par Candidat1 sont supérieures à la valeur du terme des informations initiées par le candidat (c'est-à-dire que l'autre parti est un nouveau tour de mandat), et que le candidat 2 qui souhaite devenir le chef de la nouvelle ronde contient toutes les données soumises, alors Candidate1 Votera pour Candidat2. Cela garantit qu'il n'y a qu'une faible probabilité qu'il y ait des conflits électoraux.

Comment empêcher d'autres candidats de lancer un vote pour devenir leader lorsque certaines données manquent?

Dans le mécanisme d'élection de radeau, une valeur aléatoire est utilisée pour déterminer les délais. Le premier nœud qui expire augmentera le numéro du mandat pour lancer un nouveau tour de vote. En général, les autres nœuds voteront lorsqu'ils recevront l'avis d'élection. Cependant, si les données soumises enregistrées par le Node qui a initié l'élection sont incomplètes au cours de la Période précédente, Node refusera de voter pour elle. Grâce à ce mécanisme, il est possible d'empêcher le nœud qui a manqué des données de devenir le leader.

Que se passe-t-il si un nœud de Raft tombe en panne?

Normalement, si le suiveur tombe en panne, si le nombre de nœuds disponibles restants dépasse la moitié, le cluster peut fonctionner normalement sans aucun impact. Si le leader est en panne, le suiveur ne recevra pas le battement de cœur et les heures supplémentaires, ne lancera pas une campagne pour obtenir des votes, deviendra un nouveau tour de leader du mandat et continuera à fournir des services pour le cluster.

Il convient de noter qu'actuellement, etcd ne dispose d'aucun mécanisme pour changer automatiquement les instances (nombre total de nœuds) de l'ensemble du cluster, c'est-à-dire: s'il n'y a pas d'appel artificiel à l'API, le nœud après le temps d'arrêt etcd est toujours compté comme le nombre total de nœuds, toute demande Le nombre de votes à confirmer représente plus de la moitié de ce total.

Pourquoi l'algorithme Raft n'a-t-il pas besoin de prendre en compte le problème des généraux byzantins pour déterminer le nombre de nœuds disponibles?

Dans le problème byzantin, une architecture distribuée qui permet à n nœuds d'être en panne et fournit toujours des services normaux nécessite un nombre total de nœuds de 3n + 1. Raft n'a besoin que de 2n + 1. La raison principale est qu'il y a une fraude de données dans le problème Byzantine Generals, alors que etcd suppose que tous les nœuds sont honnêtes. Avant l'élection, etcd doit indiquer aux autres nœuds son propre numéro de terme et la valeur de l'indice à la fin du tour de session précédent. Ces données sont exactes et les autres nœuds peuvent décider de voter en fonction de ces valeurs. En outre, etcd restreint strictement le flux de données du leader au suiveur pour garantir que les données sont cohérentes et sans erreur.

Sur quel nœud du cluster le client lit et écrit-il des données?

Afin d'assurer une forte cohérence des données, le flux de données dans le cluster etcd va du leader au suiveur, c'est-à-dire que toutes les données du suiveur doivent être cohérentes avec le leader, si elles sont incohérentes, elles seront écrasées.

Autrement dit, toutes les demandes des utilisateurs pour mettre à jour les données sont d'abord obtenues par Leader, puis les autres nœuds sont notifiés pour également mettre à jour, et lorsque le "plus de nœuds" retourne, les données seront soumises immédiatement. Un élément de données soumis est l'élément de données que Raft a réellement stocké de manière stable et ne sera plus modifié.Enfin, les données soumises seront synchronisées avec d'autres abonnés. Étant donné que chaque nœud dispose d'une sauvegarde précise des données soumises par Raft (le pire des cas est que les données soumises n'ont pas été entièrement synchronisées), n'importe quel nœud peut traiter la demande de lecture.

En fait, les utilisateurs peuvent lire et écrire sur n'importe quel nœud du cluster etcd:

• Lecture : vous pouvez lire à partir de n'importe quel nœud car les données enregistrées par chaque nœud sont fortement cohérentes.
• Ecrire : etcd Le cluster élira d'abord le chef de file. Si la demande d'écriture provient du chef de file, elle peut être écrite directement, puis le chef de file distribuera l'écriture à tous les abonnés; si la demande d'écriture provient d'autres nœuds suiveurs, la demande d'écriture sera transmise à Le nœud Leader est écrit par le nœud Leader, puis distribué à tous les autres nœuds du cluster.

Comment assurer la cohérence des données?

etcd utilise le protocole Raft pour maintenir la cohérence de l'état de chaque nœud du cluster. En termes simples, etcd Cluster est un système distribué. Plusieurs nœuds communiquent entre eux pour former un service externe global. Chaque nœud stocke des données complètes et le protocole Raft garantit la cohérence des données maintenues par chaque nœud.

Chaque nœud du cluster etcd maintient une machine à états et, à tout moment, il existe au plus un nœud maître effectif dans le cluster, à savoir: le nœud leader. Le leader gère toutes les opérations d'écriture depuis le client et le protocole Raft garantit que les modifications apportées à la machine d'état par l'opération d'écriture seront synchronisées de manière fiable avec d'autres nœuds suiveurs.

Comment élire le nœud Leader?

Supposons qu'il y ait 3 nœuds dans le cluster etcd, et qu'aucun chef ne soit élu au démarrage du cluster. À ce stade, l'algorithme Raft utilise une minuterie aléatoire pour initialiser le processus d'élection du chef. Par exemple, les 3 nœuds ci-dessus exécutent la minuterie (la durée de chaque minuterie est aléatoire) et Node1 est le premier à terminer la minuterie, puis il enverra une demande pour devenir leader aux deux autres nœuds, et les autres nœuds recevront la demande Plus tard, il répondra par un vote et le premier nœud sera élu comme chef.

Après être devenu le leader, le nœud enverra des notifications aux autres nœuds à intervalles réguliers pour s'assurer qu'il est toujours le leader. Dans certains cas, lorsque les abonnés ne reçoivent pas la notification du leader, par exemple, le nœud leader est en panne ou perd la connexion, d'autres nœuds répéteront le processus d'élection précédent et rééliront un nouveau leader.

Comment juger si l'écriture est réussie?

etcd pense qu'après que la demande d'écriture est traitée par le leader et distribuée à d'autres "nœuds majoritaires", c'est une écriture réussie. La formule pour calculer le nombre de "nœuds majoritaires" est Quorum = N / 2 + 1, où N est le nombre de points de résumé. En d'autres termes, etcd écrit simultanément des données sur tous les nœuds en une seule écriture, mais écrit sur des «nœuds majoritaires».

Comment déterminer le nombre de nœuds dans etcd Cluster?

Le côté gauche de la figure ci-dessus montre la relation entre le quorum (nombre de quorums) et les instances (nombre total de nœuds) dans le cluster. Instances-Quorom obtient le nombre de nœuds tolérants aux pannes (nœuds qui peuvent tolérer une défaillance) dans le cluster.

Par conséquent, le nombre minimum de nœuds recommandé dans le cluster etcd est 3, car le nombre de nœuds tolérants aux pannes pour les instances 1 et 2 est de 0. Une fois qu'un nœud tombe en panne, l'ensemble du cluster ne fonctionnera pas correctement.

De plus, lorsque nous devons déterminer le nombre d'instances dans le cluster etcd, nous recommandons fortement un nombre impair de nœuds, tel que 3, 5, 7, ..., car la tolérance aux pannes d'un cluster à 6 nœuds n'est pas meilleure que celle de 5 nœuds , Leur nombre de nœuds tolérants aux pannes est le même. Une fois que le nombre de nœuds tolérants aux pannes dépasse 2, car le nombre de nœuds Quorum est inférieur à 4, l'ensemble du cluster devient indisponible.

Quelles sont les performances de l'algorithme Raft implémenté par etcd?

Un seul nœud d'instance prend en charge 2000 écritures de données par seconde. Plus le nombre de nœuds est élevé, plus la synchronisation des données est lente et lente, en fonction de la situation réelle, et plus les performances de lecture sont élevées, car chaque nœud peut traiter les demandes des utilisateurs.

Boutique

Store, comme son nom l'indique, est la logique sous-jacente implémentée par etcd et fournit le support API correspondant. Pour comprendre Store, il vous suffit de commencer avec l'API d'etcd. Les appels d'API CURD les plus courants sont répertoriés ci-dessous.

• Attribuez des valeurs aux clés stockées par etcd:

curl http://127.0.0.1:2379/v2/keys/message -X PUT -d value="Hello world"

{
    "action":"set",                     # 执行的操作
    "node":{
        "createdIndex":2,           # etcd Node 每次有变化时都会自增的一个值
        "key":"/message",          # 请求路径
        "modifiedIndex":2,          # 类似 node.createdIndex，能引起 modifiedIndex 变化的操作包括 set, delete, update, create, compareAndSwap and compareAndDelete
        "value":"Hello world"      # 存储的内容
    }
}

• Interrogez la valeur stockée par une clé dans etcd:

curl http://127.0.0.1:2379/v2/keys/message -X GET

• Modifier la valeur de la clé:

curl http://127.0.0.1:2379/v2/keys/message -XPUT -d value="Hello etcd"

• Supprimer la valeur de clé:

curl http://127.0.0.1:2379/v2/keys/message -XDELETE

WAL

Le stockage des données d'etcd est divisé en deux parties:

• Stockage en mémoire : en plus des enregistrements séquentiels de toutes les modifications apportées par les utilisateurs aux données du nœud, le stockage dans la mémoire effectuera également des opérations telles que l'indexation et l'empilement des données utilisateur pour une interrogation facile.
• Stockage persistant (disque dur) : la persistance utilise WAL (journal d'écriture anticipée, journal d'écriture anticipée) pour le stockage des enregistrements.

Le journal WAL est binaire et la structure de données ci-dessus LogEntry est analysée. parmi eux:

Le premier type de champ, il n'y en a que deux types:

1. 0 signifie normal
2. 1 signifie ConfChange et ConfChange signifie la synchronisation des modifications de configuration d'etcd, telles que la connexion de nouveaux nœuds.

Le deuxième champ est le terme, chaque terme représente le terme d'un leader, et il changera chaque fois que le leader change le terme.

Le troisième champ est index. Ce numéro de série est strictement et séquentiellement croissant, représentant le numéro de série de modification.

Le quatrième champ est des données binaires, qui sauvegardent toute la structure pb de l'objet Raft Request.

Il existe un outil de script tools / etcd-dump-logs sous le code source etcd, qui peut vider les journaux WAL dans du texte pour les visualiser, et peut aider à analyser le protocole Raft.

Le protocole Raft lui-même ne se soucie pas des données d'application, c'est-à-dire de la partie des données. La cohérence est obtenue en synchronisant le journal WAL. Chaque nœud applique les données reçues du leader au stockage local. Raft ne se soucie que de l'état de synchronisation du journal. Il existe des bogues dans l'implémentation du stockage local, tels que le fait de ne pas appliquer correctement les données localement, ce qui peut également entraîner une incohérence des données.

Dans le système WAL, toutes les données seront enregistrées avant la soumission. Dans le répertoire de stockage persistant de etcd, il y a deux sous-répertoires:

1. L'un est WAL: stocke les enregistrements de modification de toutes les transactions;
2. L'autre est Snapshot: il stocke les données de tous les répertoires dans etcd à un certain moment.

Grâce à la combinaison de WAL et de snapshot, etcd peut effectuer efficacement des opérations telles que le stockage de données et la récupération en cas de panne de nœud.

Pourquoi ai-je besoin de Snapshot?

Parce qu'avec l'augmentation de l'utilisation, les données stockées par WAL augmenteront fortement. Afin d'éviter que le disque ne se remplisse rapidement, etcd prend un instantané tous les 10 000 enregistrements par défaut, et les fichiers WAL après l'instantané peuvent être supprimés. Par conséquent, les enregistrements d'historique des opérations par défaut qui peuvent être interrogés via l'API sont 1000.

Au premier démarrage, etcd stockera les informations de configuration de démarrage dans le chemin du répertoire spécifié par l'élément de configuration data-dir. Les informations de configuration incluent l'ID de nœud local, l'ID de cluster et les informations de cluster initial. Les utilisateurs doivent éviter de redémarrer etcd à partir d'un répertoire de données expiré, car un nœud démarré avec un répertoire de données expiré ne sera pas cohérent avec les autres nœuds du cluster. Par exemple, il a été enregistré et convenu que le nœud leader stockera certaines informations avant de redémarrer. Demandez à nouveau ces informations à Leader Node. Par conséquent, afin de maximiser la sécurité du cluster, une fois qu'il existe une possibilité de corruption ou de perte de données, vous devez supprimer ce nœud du cluster, puis ajouter un nouveau nœud sans répertoire de données.

La plus grande fonction de WAL (Write Ahead Log) est d'enregistrer l'historique complet de l'ensemble de la modification des données. Dans etcd, toutes les modifications de données doivent être écrites dans WAL avant la soumission. L'utilisation de WAL pour le stockage de données permet à etcd d'avoir deux fonctions importantes:

1. Récupération rapide après une panne : lorsque vos données sont endommagées, vous pouvez récupérer rapidement les données d'origine à l'état avant que les données ne soient endommagées en effectuant toutes les opérations de modification enregistrées dans le WAL.
2. Annulation (annulation) ou rétablissement (rétablissement) des données : étant donné que toutes les opérations de modification sont enregistrées dans le WAL, une annulation ou une restauration est nécessaire. Il vous suffit d'effectuer les opérations dans le journal dans le sens ou dans le sens avant.

Quelles sont les règles de dénomination pour WAL et Snapshot?

, Fichiers WAL dans le répertoire $seq-$index.walformat de stockage de données etcd . Le fichier WAL initial est 0000000000000000-0000000000000000.wal, ce qui signifie qu'il s'agit du 0e parmi tous les fichiers WAL et que le numéro d'état initial du radeau est 0. Après avoir exécuté pendant un certain temps, il peut être nécessaire d'effectuer une segmentation du journal et de placer de nouvelles entrées dans un nouveau fichier WAL.

Supposons que, lorsque le cluster s'exécute à l'état Raft de 20, lorsque le fichier WAL doit être segmenté, le fichier WAL suivant deviendra 0000000000000001-0000000000000021.wal. Si une autre segmentation du journal est effectuée après 10 opérations, le nom de fichier WAL de la prochaine fois deviendra 0000000000000002-0000000000000031.wal. On peut voir que le nombre devant le symbole "-" est incrémenté de 1 après chaque segmentation, et le nombre après le symbole "-" est déterminé en fonction de l'état initial réel du Raft stocké.

Stockage instantané et nommé plus facile à comprendre, pour $term-$index.walformater le stockage nommé. Le terme et l'index représentent l'état du nœud Raft où les données sont stockées lorsque l'instantané est stocké, le numéro du terme actuel et l'emplacement de l'élément de données.

modèle de données etcd

etcd est conçu pour stocker des données rarement mises à jour et fournir un plug-in Watch fiable, qui expose la version historique des paires clé-valeur pour prendre en charge des instantanés à faible coût et surveiller les événements historiques. Ces objectifs de conception exigent qu'il utilise un modèle de données persistant, multi-version et simultané.

Lorsque la nouvelle version de la paire clé-valeur etcd est enregistrée, la version précédente existe toujours. En effet, les paires clé-valeur sont immuables et etcd n'effectuera pas d'opérations de mise à jour sur place sur elles, mais générera toujours une nouvelle structure de données. Afin d'éviter une augmentation illimitée des versions historiques, le stockage etcd prend en charge la compression (Compact) et supprime les anciennes versions.

Vue logique

D'un point de vue logique, le stockage d'etcd est un espace clé binaire plat, et l'espace clé a un index lexicographique pour la clé (chaîne d'octets), de sorte que le coût de la requête de plage est plus faible.

L'espace clé conserve plusieurs révisions (révisions), et chaque opération de changement atomique (une transaction peut être composée de plusieurs sous-opérations) générera une nouvelle révision. Tout au long du cycle de vie du cluster, les révisions augmentent de manière monotone. Les révisions prennent également en charge l'indexation, de sorte que les analyses de plage basées sur les révisions sont également efficaces. L'opération de compression doit spécifier un numéro de révision et les révisions plus petites que ce dernier seront supprimées.

Le cycle de vie d'une clé (de sa création à sa suppression) est appelé "Génération", et chaque clé peut avoir plusieurs générations. Lorsqu'une clé est créée, la version de la clé (Version) est augmentée. Si la clé n'existe pas dans la version actuelle, la version est définie sur 1. La suppression d'une clé créera une pierre tombale, définira la version sur 0 et mettra fin à la génération actuelle. Chaque fois que la valeur de la clé est modifiée, son numéro de version est augmenté, c'est-à-dire que le numéro de version augmente de manière monotone dans la même génération.

Lors de la compression, toute génération qui s'est terminée avant la révision compressée sera supprimée. L'enregistrement de modification avec la valeur avant la révision (uniquement le dernier) sera supprimé.

Vue physique

etcd stocke les données dans une arborescence B + persistante. Pour des raisons d'efficacité, chaque révision ne stocke que les changements d'état des données (Delta) par rapport à la révision précédente. Une seule révision peut contenir plusieurs clés dans l'arborescence B +.

La clé de la paire clé-valeur est un triple (Major, Sub, Type):

• Major: stocke la révision de la valeur clé.
• Sub: Utilisé pour distinguer différentes clés dans la même révision.
• Type: suffixe facultatif utilisé pour les valeurs spéciales, par exemple, t signifie que la valeur contient une pierre tombale

La valeur de la paire clé-valeur, y compris le delta de la révision précédente. L'arbre B +, c'est-à-dire l'ordre lexical des octets des clés, la vitesse de balayage basée sur la plage de la révision est rapide et il est pratique de trouver le changement de valeur d'une révision à une autre.

etcd maintient également un index B-tree en mémoire pour accélérer les balayages de distance pour les clés. La clé de l'index est le mappage orienté utilisateur de la clé de stockage physique, et la valeur de l'index est un pointeur vers le point de l'arborescence B +.

Mode proxy d'etcd

Mode proxy, à savoir: etcd agit comme un proxy inverse pour transmettre les demandes des clients au cluster etcd disponible. De cette façon, vous pouvez déployer un mode proxy etcd en tant que service local sur chaque machine. Si ces etcd Proxy peuvent fonctionner normalement, alors votre découverte de service doit être stable et fiable.

Par conséquent, le mode Proxy n'est pas directement ajouté au cluster etcd conformément à une cohérence forte. De même, Proxy n'augmente pas la fiabilité du cluster et ne réduit certainement pas les performances d'écriture du cluster.

Pourquoi le mode proxy remplace-t-il le mode veille?

En fait, chaque fois qu'etcd ajoute un nœud central (Peer), cela augmentera dans une certaine mesure la charge du leader, y compris le réseau, le processeur et le disque, car chaque changement d'informations nécessite une sauvegarde synchrone. L'augmentation des nœuds principaux d'etcd peut rendre l'ensemble du cluster plus fiable, mais lorsque le nombre atteint un certain niveau, les avantages d'une fiabilité accrue deviennent moins évidents, mais cela réduit les performances de la synchronisation d'écriture du cluster. Par conséquent, l'ajout d'un mode Proxy léger etcd Node est un remplacement efficace pour ajouter directement des nœuds principaux etcd.

Le mode proxy remplace en fait le mode veille d'origine. En plus de la fonction de l'agent de transfert, le mode veille passera du mode veille au mode nœud normal lorsque le nombre de nœuds principaux est insuffisant en raison d'une panne. Lorsque le nœud défaillant récupère, il est constaté que le nombre de nœuds principaux dans etcd a atteint la valeur prédéfinie et il passera en mode veille.

Cependant, dans la nouvelle version d'etcd, le mode Proxy est automatiquement activé uniquement lorsque le nombre de nœuds principaux répond aux exigences lors du démarrage initial du cluster etcd, et vice versa. Les principales raisons sont les suivantes:

• etcd est un composant utilisé pour assurer une haute disponibilité, de sorte que les ressources système dont il a besoin, y compris la mémoire, le disque dur et le processeur, doivent être pleinement garanties pour assurer une haute disponibilité. Laissez la transformation automatique du cluster changer le nœud central à volonté, et la machine ne peut pas garantir les performances. Par conséquent, etcd encourage officiellement tout le monde à préparer des clusters de machines dédiés pour exécuter etcd dans de grands clusters.
• Étant donné que le cluster etcd prend en charge la haute disponibilité, certaines pannes de machine n'entraîneront pas de panne fonctionnelle. Par conséquent, lorsque la machine tombe en panne, l'administrateur dispose de suffisamment de temps pour inspecter et réparer la machine.
• La conversion automatique complique les clusters etcd, surtout maintenant que etcd prend en charge la surveillance et l'interaction dans plusieurs environnements réseau. La commutation entre différents réseaux est plus sujette aux erreurs, conduisant à des clusters instables.