Tâche on PIG.CENTER

Usage : pgbouncer commande

Mon, 01 Jan 0001 00:00:00 +0000

Synopsis

pgbouncer [-d][-R][-v][-u user] <pgbouncer.ini>
pgbouncer -V|-h

Sous Windows, les options sont :

pgbouncer.exe [-v][-u user] <pgbouncer.ini>
pgbouncer.exe -V|-h

Options supplémentaires pour la configuration d’un service Windows :

pgbouncer.exe --regservice <pgbouncer.ini>
pgbouncer.exe --unregservice <pgbouncer.ini>

Description

pgbouncer est un pooler de connexions PostgreSQL. Toute application cliente peut se connecter à pgbouncer comme s’il était un serveur PostgreSQL, et pgbouncer établira une connexion vers le serveur réel, ou réutilisera l’une de ses connexions existantes.

Configuration de journalisation de PostgreSQL

Mon, 01 Jan 0001 00:00:00 +0000

pgBadger ne peut rapporter que les informations écrites par PostgreSQL dans les journaux. Commencez par un préfixe analysable et une politique de journalisation explicite des requêtes, puis ajoutez les événements opérationnels que vous souhaitez analyser.

Journalisation minimale des requêtes

Pour inclure le texte et la durée de la requête, activez la journalisation des instructions basée sur la durée :

log_min_duration_statement = 0

0 enregistre chaque instruction terminée. Sur un serveur très sollicité, sélectionnez une valeur plus élevée en millisecondes afin de contrôler le volume des journaux. Mesurez la surcharge et la croissance du stockage avant d’activer une seuil faible en production.

Traitement parallèle

Mon, 01 Jan 0001 00:00:00 +0000

pgBadger dispose de deux modes de traitement parallèle complémentaires. Choisissez selon la forme de l’entrée, et non simplement selon le nombre de processeurs.

Option	Unité parallèle	Meilleur ajustement	Contrainte principale
`-j N` / `--jobs N`	tronçons d’un fichier journal	un seul fichier journal volumineux et accessible par recherche	les limites des tronçons peuvent dupliquer ou omettre un petit nombre de requêtes
`-J N` / `--Jobs N`	fichiers journaux entiers	plusieurs fichiers journaux indépendants	utile uniquement lorsque suffisamment de fichiers sont disponibles pour garder les workers occupés

Découper un grand fichier avec `-j`

$ pgbadger -j 8 /var/log/postgresql/postgresql.log

L’algorithme upstream divise chaque fichier en plages de N octets, lance un parseur par plage, écrit des statistiques binaires temporaires, puis fusionne ces statistiques pour produire le rapport final.

Imagerie de réplique et amorçage

Mon, 01 Jan 0001 00:00:00 +0000

Patroni permet de personnaliser la création d’une nouvelle réplique. Il prend également en charge la définition des actions à effectuer lors de l’amorçage d’un nouveau cluster vide. La distinction entre les deux est clairement établie : Patroni crée des répliques uniquement si la clé initialize est présente dans le DCS pour le cluster. Si la clé initialize est absente, Patroni lance l’amorçage exclusivement sur le premier nœud qui obtient le verrou de la clé initialize.

Rapports incrémentiels

Mon, 01 Jan 0001 00:00:00 +0000

Le mode incrémentiel stocke les statistiques analysées sous forme binaire, puis génère un rapport HTML par jour, un rapport cumulatif par semaine et un index au format calendrier reliant ces rapports. Il est destiné à un traitement répété des journaux tournés sans compter deux fois les mêmes entrées.

Générer des rapports quotidiens et hebdomadaires

Exécutez pgBadger après la rotation quotidienne des journaux et spécifiez un répertoire de sortie persistant :

cluster de secours

Mon, 01 Jan 0001 00:00:00 +0000

Patroni prend également en charge l’exécution d’une réplication en cascade vers un centre de données distant (région) à l’aide d’une fonctionnalité appelée « stand-by cluster ». Ce type de cluster présente les caractéristiques suivantes :

« leader en veille », qui se comporte presque comme un leader de cluster régulier, à ceci près qu’il effectue la réplication à partir d’un nœud distant.
répliques en cascade, qui effectuent la réplication à partir d’un leader en veille.

Le leader de secours détient et met à jour un verrou de leader dans le DCS. Si le verrou de leader expire, les répliques en cascade effectueront une élection afin de choisir un autre leader parmi les serveurs de secours.

Versions, Paquets et Mises à jour

Mon, 01 Jan 0001 00:00:00 +0000

HAProxy est un projet open source soumis à la licence GPLv2, ce qui signifie que toute personne est autorisée à le redistribuer à condition de fournir l’accès au code source sur demande, notamment si des modifications ont été apportées.

HAProxy évolue via une branche de développement principale appelée « master » ou « mainline », à partir de laquelle de nouvelles branches sont créées une fois que le code est jugé stable. De nombreux sites web exécutent des branches de développement en production de manière volontaire, soit pour participer au projet, soit parce qu’ils ont besoin d’une fonctionnalité de pointe, et leurs retours sont précieux pour corriger les bogues et évaluer la qualité et la stabilité globales de la version en développement.

Tâches

Mon, 01 Jan 0001 00:00:00 +0000

Tâches de l'opérateur

Mon, 01 Jan 0001 00:00:00 +0000

Comment configurer un cluster étcd de démonstration

Mon, 01 Jan 0001 00:00:00 +0000

Sur chaque nœud etcd, précisez les membres du cluster :

TOKEN=token-01
CLUSTER_STATE=new
NAME_1=machine-1
NAME_2=machine-2
NAME_3=machine-3
HOST_1=10.240.0.17
HOST_2=10.240.0.18
HOST_3=10.240.0.19
CLUSTER=${NAME_1}=http://${HOST_1}:2380,${NAME_2}=http://${HOST_2}:2380,${NAME_3}=http://${HOST_3}:2380

Exécutez ceci sur chaque machine :

# For machine 1
THIS_NAME=${NAME_1}
THIS_IP=${HOST_1}
etcd --data-dir=data.etcd --name ${THIS_NAME} \
	--initial-advertise-peer-urls http://${THIS_IP}:2380 --listen-peer-urls http://${THIS_IP}:2380 \
	--advertise-client-urls http://${THIS_IP}:2379 --listen-client-urls http://${THIS_IP}:2379 \
	--initial-cluster ${CLUSTER} \
	--initial-cluster-state ${CLUSTER_STATE} --initial-cluster-token ${TOKEN}

# For machine 2
THIS_NAME=${NAME_2}
THIS_IP=${HOST_2}
etcd --data-dir=data.etcd --name ${THIS_NAME} \
	--initial-advertise-peer-urls http://${THIS_IP}:2380 --listen-peer-urls http://${THIS_IP}:2380 \
	--advertise-client-urls http://${THIS_IP}:2379 --listen-client-urls http://${THIS_IP}:2379 \
	--initial-cluster ${CLUSTER} \
	--initial-cluster-state ${CLUSTER_STATE} --initial-cluster-token ${TOKEN}

# For machine 3
THIS_NAME=${NAME_3}
THIS_IP=${HOST_3}
etcd --data-dir=data.etcd --name ${THIS_NAME} \
	--initial-advertise-peer-urls http://${THIS_IP}:2380 --listen-peer-urls http://${THIS_IP}:2380 \
	--advertise-client-urls http://${THIS_IP}:2379 --listen-client-urls http://${THIS_IP}:2379 \
	--initial-cluster ${CLUSTER} \
	--initial-cluster-state ${CLUSTER_STATE} --initial-cluster-token ${TOKEN}

Ou utilisez notre service de découverte public :

Mode Pause/Reprise pour le cluster

Mon, 01 Jan 0001 00:00:00 +0000

Objectif

Dans certains cas, Patroni doit pouvoir se retirer temporairement de la gestion du cluster tout en conservant l’état du cluster dans le DCS. Les cas d’utilisation possibles concernent des activités inhabituelles sur le cluster, telles que les mises à jour majeures de version ou la récupération après corruption. Pendant ces opérations, les nœuds sont souvent démarrés et arrêtés pour des raisons inconnues de Patroni, certains nœuds pouvant même être temporairement promus, ce qui contrevient à l’hypothèse d’un seul nœud primaire en cours d’exécution. Par conséquent, Patroni doit pouvoir se « déconnecter » du cluster en cours, en implémentant une fonctionnalité équivalente au mode maintenance de Pacemaker.

Prise en charge et contribution

Mon, 01 Jan 0001 00:00:00 +0000

pgBadger est maintenu dans le cadre d’un projet open source. Les rapports de bogues, les propositions de fonctionnalités, les corrections de documentation et les correctifs sont gérés via le dépôt GitHub principal.

Signalements de bogues et demandes de fonctionnalités

Passez à la dernière version publiée et vérifiez que le comportement persiste.
Recherchez dans les problèmes ouverts et les problèmes fermés une réponse existante.
Réduisez le problème à l’échantillon de journal le plus petit possible, qui reproduit encore le comportement.
Supprimez les identifiants, les requêtes SQL sensibles, les valeurs liées, les noms d’hôtes, les adresses et les données métier.
Ouvrez un nouveau problème avec la version de pgBadger, le système d’exploitation, le format d’entrée, les options exactes, le résultat observé et le résultat attendu.

En cas de plantage ou d’erreur de parsing, inclure uniquement les lignes de journalisation minimales et nettoyées nécessaires à la reproduction de la limite. Un journal de production complet ou un rapport généré est rarement adapté à une issue publique.

Utilisation de Patroni avec Kubernetes

Mon, 01 Jan 0001 00:00:00 +0000

Patroni peut utiliser des objets Kubernetes afin de stocker l’état du cluster et gérer la clé du leader. Cela lui permet de fonctionner avec PostgreSQL dans un environnement Kubernetes sans nécessiter de magasin de cohérence, c’est-à-dire qu’il n’est pas nécessaire de déployer un Étcd supplémentaire. Patroni peut utiliser deux types d’objets Kubernetes pour stocker la clé du leader et les clés de configuration, configurés via les variables d’environnement kubernetes.use_endpoints ou PATRONI_KUBERNETES_USE_ENDPOINTS.

Convertir un nœud autonome en cluster Patroni

Mon, 01 Jan 0001 00:00:00 +0000

Cette section décrit le processus de conversion d’une instance PostgreSQL autonome en cluster Patroni.

Pour déployer un cluster Patroni sans utiliser d’instance PostgreSQL préexistante, consultez plutôt Exécution et configuration .

Procédure

Vous trouverez ci-dessous un aperçu des étapes permettant de convertir un cluster Postgres existant en cluster géré par Patroni. Dans ces étapes, nous supposons que tous les nœuds faisant partie du cluster existant sont actuellement en fonctionnement, et que vous ne prévoyez pas de modifier la configuration de Postgres pendant la migration. Les étapes :

Tâches de développement

Mon, 01 Jan 0001 00:00:00 +0000

8. Journalisation

Mon, 01 Jan 0001 00:00:00 +0000

L’un des points forts d’HAProxy réside certainement dans ses journaux précis. Il fournit probablement le niveau d’information le plus poussé disponible pour un tel produit, ce qui est essentiel pour le dépannage des environnements complexes. Les informations standard fournies dans les journaux incluent les ports clients, les compteurs d’état TCP/HTTP, l’état précis du flux à la terminaison et la cause précise de la terminaison, des informations sur les décisions visant à acheminer le trafic vers un serveur, ainsi que, bien entendu, la capacité à capturer des en-têtes arbitraires.

Guidelines pour les contributions

Mon, 01 Jan 0001 00:00:00 +0000

Discussion

Si vous avez une question, recherchez une aide interactive pour dépanner ou souhaitez discuter avec d’autres utilisateurs Patroni, rejoignez-nous sur le canal #patroni dans PostgreSQL Slack .

Signalement de bogues

Avant de signaler un bogue, assurez-vous d’en reproduire l’incident avec la dernière version de Patroni ! Veuillez également vérifier soigneusement si le problème n’existe pas déjà dans notre Suivi des problèmes .

Lecture depuis etcd

Mon, 01 Jan 0001 00:00:00 +0000

Prérequis

Installer etcdctl

Procédure

Utilisez la sous-commande get pour lire depuis etcd :

$ etcdctl --endpoints=$ENDPOINTS get foo
foo
Hello World!
$

où :

foo est la clé demandée
Hello World! est la valeur récupérée

Or, pour une sortie formatée :

$ etcdctl --endpoints=$ENDPOINTS --write-out="json" get foo
{"header":{"cluster_id":289318470931837780,"member_id":14947050114012957595,"revision":3,"raft_term":4,
"kvs":[{"key":"Zm9v","create_revision":2,"mod_revision":3,"version":2,"value":"SGVsbG8gV29ybGQh"}]}}
$

où write-out="json" fait que la valeur est sortie au format JSON (notez que la clé n’est pas renvoyée).

1. Prérequis

Mon, 01 Jan 0001 00:00:00 +0000

Ce document décrit comment démarrer, arrêter, gérer et dépanner HAProxy, ainsi que certaines limitations connues et pièges à éviter. Il ne décrit pas comment le configurer (pour cela, veuillez consulter configuration.txt ).

Dans ce document, il est supposé que le lecteur possède des compétences suffisantes en administration sur un système d’exploitation de type UNIX, utilise quotidiennement l’interpréteur de commandes et maîtrise les outils de dépannage tels que strace et tcpdump.

Écriture dans etcd

Mon, 01 Jan 0001 00:00:00 +0000

Prérequis

Installer etcdctl

Procédure

Utilisez la sous-commande put pour écrire une paire clé-valeur :

etcdctl --endpoints=$ENDPOINTS put foo "Hello World!"

où :

foo est le nom de la clé
"Hello World!" est la valeur délimitée par des guillemets

3. Démarrage de HAProxy

Mon, 01 Jan 0001 00:00:00 +0000

HAProxy est lancé en exécutant le programme « HAProxy » avec un certain nombre d’arguments passés en ligne de commande. La syntaxe réelle est :

$ haproxy [<options>]*

où [<options>]* est un nombre quelconque d’options. Une option commence toujours par ‘-’ suivi d’une ou plusieurs lettres, et peut être suivie d’un ou plusieurs arguments supplémentaires. Sans option, HAProxy affiche la page d’aide avec un rappel des options prises en charge. Les options disponibles peuvent varier légèrement selon le système d’exploitation. Un nombre important de ces options se chevauchent avec une option équivalente dans la section « global ». Dans ce cas, la ligne de commande a toujours priorité sur le fichier de configuration, de sorte que la ligne de commande peut être utilisée pour imposer rapidement certains paramètres sans modifier les fichiers de configuration. La liste actuelle des options est :

4. Arrêt et redémarrage de HAProxy

Mon, 01 Jan 0001 00:00:00 +0000

HAProxy prend en charge une interruption douce et une interruption brutale. L’interruption brutale est simple : lorsqu’un signal SIGTERM est envoyé au processus HAProxy, celui-ci quitte immédiatement et toutes les connexions établies sont fermées. L’interruption douce est déclenchée lorsqu’un signal SIGUSR1 est envoyé au processus HAProxy. Elle consiste à ne plus se lier aux ports d’écoute, tout en continuant à traiter les connexions existantes jusqu’à leur fermeture. Une fois la dernière connexion fermée, le processus se termine.

5. Limites des descripteurs de fichiers

Mon, 01 Jan 0001 00:00:00 +0000

Afin de garantir que toutes les connexions entrantes soient correctement servies, HAProxy calcule au moment du chargement le nombre total de descripteurs de fichiers nécessaires durant la durée de vie du processus. Un processus Unix classique reçoit généralement 1024 descripteurs de fichiers par défaut, et un processus privilégié peut augmenter lui-même cette limite. C’est une des raisons de lancer HAProxy en tant que root et de lui permettre d’ajuster cette limite. La limite par défaut de 1024 descripteurs de fichiers permet approximativement 500 connexions simultanées. Ce calcul repose sur le paramètre global maxconn, qui limite le nombre total de connexions par processus, le nombre d’écouteurs, le nombre de serveurs ayant un contrôle d’état activé, les vérifications d’agent, les pairs, les enregistreurs et éventuellement quelques autres exigences techniques. Une estimation simple de ce nombre consiste à doubler la valeur de maxconn et à ajouter quelques dizaines pour obtenir une approximation du nombre de descripteurs de fichiers nécessaires.

6. Gestion de la mémoire

Mon, 01 Jan 0001 00:00:00 +0000

HAProxy utilise une gestion mémoire basée sur des pools, simple et rapide. Étant donné qu’il repose sur un nombre réduit de types d’objets différents, il est bien plus efficace de tirer de nouveaux objets depuis un pool déjà contenant des objets de la taille appropriée que d’appeler malloc() pour chaque taille différente. Les pools sont organisés selon une structure de pile ou LIFO, de sorte que les objets nouvellement alloués proviennent d’objets récemment libérés, encore présents dans les caches CPU. Les pools de tailles similaires sont regroupés afin de limiter la fragmentation mémoire.

Comment obtenir des clés par préfixe

Mon, 01 Jan 0001 00:00:00 +0000

Prérequis

Obtenir les clés par préfixe

$ etcdctl --endpoints=$ENDPOINTS get PREFIX --prefix

Options globales

--endpoints=[127.0.0.1:2379], gRPC endpoints

Options

--prefix, get a range of keys with matching prefix

Exemple

etcdctl --endpoints=$ENDPOINTS put web1 value1
etcdctl --endpoints=$ENDPOINTS put web2 value2
etcdctl --endpoints=$ENDPOINTS put web3 value3

etcdctl --endpoints=$ENDPOINTS get web --prefix

7. Utilisation du CPU

Mon, 01 Jan 0001 00:00:00 +0000

HAProxy passe normalement la majeure partie de son temps en mode noyau et une part plus faible en mode utilisateur. Un processeur 3,5 GHz correctement optimisé peut supporter un débit d’environ 80 000 établissements et fermetures de connexions bout-en-bout par seconde à 100 % d’utilisation sur un seul cœur. Lorsqu’un cœur est saturé, les valeurs typiques sont :

95 % système, 5 % utilisateur pour des connexions TCP longues ou de grands objets HTTP
85 % système et 15 % utilisateur pour des connexions TCP courtes ou de petits objets HTTP en mode fermé
70 % système et 30 % utilisateur pour de petits objets HTTP en mode keep-alive

Le nombre de règles traitées et d’expressions régulières augmente la partie en espace utilisateur. La présence de règles de pare-feu, du suivi des connexions et de tables de routage complexes dans le système augmente quant à elle la partie noyau.

8. Journalisation

Mon, 01 Jan 0001 00:00:00 +0000

Pour la journalisation, HAProxy s’appuie toujours sur un serveur syslog, car il ne réalise aucune opération sur le système de fichiers. La méthode standard consiste à envoyer les journaux via UDP vers le serveur de journalisation (par défaut sur le port 514). Il est très courant de le configurer sur 127.0.0.1, où s’exécute le démon syslog local, mais il peut aussi être utilisé sur le réseau pour journaliser sur un serveur central. Ce dernier offre des avantages supplémentaires, notamment dans les scénarios actif-actif où il est souhaitable de conserver les journaux fusionnés dans l’ordre d’arrivée. HAProxy peut également utiliser une socket UNIX pour envoyer ses journaux au démon syslog local, mais cela n’est pas recommandé, car si le serveur syslog est redémarré pendant que HAProxy est en cours d’exécution, la socket sera remplacée et les nouveaux journaux seront perdus. Étant donné que HAProxy sera isolé dans une prison chroot, il ne pourra pas se reconnecter à la nouvelle socket. Des observations sur le terrain ont également montré que les tampons utilisés sur les sockets UNIX sont très petits et entraînent la perte de messages même à des charges très faibles. Cela peut toutefois convenir pour les tests.

9. Statistiques et surveillance

Mon, 01 Jan 0001 00:00:00 +0000

Il est possible de consulter l’état de HAProxy. Le mécanisme le plus couramment utilisé est la page de statistiques HTTP. Cette page expose également un format de sortie CSV alternatif destiné aux outils de surveillance. Le même format est disponible via le socket Unix.

Les statistiques sont regroupées par catégories désignées sous le nom de domaines, correspondant aux différents composants d’HAProxy. Deux domaines sont disponibles : proxy et resolvers. Si aucun domaine n’est précisé, le domaine proxy est sélectionné. Notez que seules les statistiques du proxy sont affichées sur la page HTTP.

10. Gestion de configuration simplifiée

Mon, 01 Jan 0001 00:00:00 +0000

Il est très courant que deux nœuds HAProxy constituant un cluster partagent exactement la même configuration, à l’exception de quelques adresses. Au lieu de devoir maintenir une configuration dupliquée pour chaque nœud, ce qui entraînera inévitablement une divergence, il est possible d’inclure des variables d’environnement dans la configuration. Ainsi, plusieurs configurations peuvent partager exactement le même fichier, en ne modifiant que quelques variables d’environnement système. Cette fonctionnalité a été introduite à partir de la version 1.5, où seules les adresses pouvaient inclure des variables d’environnement, et la version 1.6 va plus loin en permettant l’utilisation de variables d’environnement partout. La syntaxe est identique à celle du shell UNIX : une variable commence par un signe dollar (’$’), suivi d’une accolade ouvrante (’{’), puis le nom de la variable, terminé par une accolade fermante (’}’). À l’exception des adresses, les variables d’environnement ne sont interprétées que dans les arguments entourés de guillemets doubles (ce qui était nécessaire pour ne pas rompre les configurations existantes utilisant des expressions régulières impliquant le symbole dollar).

11. Pièges courants à éviter

Mon, 01 Jan 0001 00:00:00 +0000

Parfois, une personne signale que, après un redémarrage du système, le service HAProxy n’est pas démarré automatiquement, et qu’une fois lancé manuellement, il fonctionne correctement. La plupart de ces utilisateurs exécutent un mécanisme d’adresse IP regroupée, comme keepalived, afin d’attribuer l’adresse IP du service uniquement au nœud principal, et alors qu’il fonctionnait auparavant lorsqu’ils liaient HAProxy à l’adresse 0.0.0.0, il a cessé de fonctionner après avoir lié celui-ci à l’adresse IP virtuelle. Ce qui se produit ici, c’est que, lors du démarrage du service, l’adresse IP virtuelle n’est pas encore détenu par le nœud local, si bien que lorsque HAProxy tente de se lier à cette adresse, le système la rejette car elle n’est pas une adresse locale. La solution ne consiste pas à retarder le démarrage du service HAProxy (car cela ne résisterait pas à un redémarrage), mais plutôt à configurer correctement le système afin de permettre la liaison à des adresses non locales. Cela peut être facilement réalisé sous Linux en définissant le paramètre sysctl net.ipv4.ip_nonlocal_bind à 1. Cette configuration est également nécessaire pour intercepter de manière transparente le trafic IP qui traverse HAProxy pour une adresse cible spécifique.

12. Problèmes de débogage et de performance

Mon, 01 Jan 0001 00:00:00 +0000

Lorsque HAProxy est lancé avec l’option “-d”, il reste en premier plan et affiche une ligne par événement, tel qu’une connexion entrante, la fin d’une connexion, ou chaque ligne d’en-tête de requête ou de réponse observée. Cette sortie de débogage est émise avant le traitement des contenus, aussi ne tiennent-elles pas compte des modifications locales. Son usage principal consiste à afficher les requêtes et réponses sans avoir à exécuter un analyseur réseau. La lecture de la sortie devient moins aisée lorsque plusieurs connexions sont gérées en parallèle, mais les scripts “debug2ansi” et “debug2html” présents dans le répertoire examples/ aident certainement dans ce cas en colorant la sortie.

13. Considérations de sécurité

Mon, 01 Jan 0001 00:00:00 +0000

HAProxy est conçu pour s’exécuter avec des privilèges très limités. La méthode standard consiste à l’isoler dans une prison chroot et à supprimer ses privilèges pour qu’il s’exécute en tant qu’utilisateur non root, sans aucun droit à l’intérieur de cette prison, afin qu’en cas de découverte d’une vulnérabilité future, son compromis n’affecte pas le reste du système.

Pour effectuer un chroot, il est d’abord nécessaire de le lancer en tant qu’utilisateur root. Il est inutile de créer manuellement des chroots afin de lancer le processus à l’intérieur ; ces environnements sont difficiles à mettre en place, jamais correctement maintenus et contiennent toujours bien plus de bogues que le système de fichiers principal. En cas de compromission, l’attaquant peut exploiter le système de fichiers spécifiquement conçu à cet effet. Malheureusement, de nombreux administrateurs confondent « lancer en tant que root » et « s’exécuter en tant que root », ce qui entraîne le changement d’UID avant le démarrage d’HAProxy, réduisant ainsi les restrictions de sécurité effectives.

Comment supprimer des clés

Mon, 01 Jan 0001 00:00:00 +0000

Prérequis

Installer etcd et etcdctl

Ajouter ou supprimer des clés

del pour supprimer la clé spécifiée ou la plage de clés :

etcdctl del $KEY [$END_KEY]

Options

--prefix[=false]: delete keys with matching prefix
--prev-kv[=false]: return deleted key-value pairs
--from-key[=false]: delete keys that are greater than or equal to the given key using byte compare
--range[=false]: delete range of keys without delay

Options héritées des commandes parentes

--endpoints="127.0.0.1:2379": gRPC endpoints

Exemples

etcdctl --endpoints=$ENDPOINTS put key myvalue
etcdctl --endpoints=$ENDPOINTS del key

etcdctl --endpoints=$ENDPOINTS put k1 value1
etcdctl --endpoints=$ENDPOINTS put k2 value2
etcdctl --endpoints=$ENDPOINTS del k --prefix

Comment effectuer plusieurs écritures dans une transaction

Mon, 01 Jan 0001 00:00:00 +0000

Prérequis

Installer etcd et etcdctl .
Un cluster etcd en cours d’exécution.

Terminologie

Voici les définitions de quelques termes clés utilisés dans l’exemple Example ci-dessous.

Termes	Définition
etcdctl	Outil en ligne de commande pour interagir avec le serveur etcd.
`txn` command	`txn` command est une abréviation de « transaction ». Il lit plusieurs requêtes etcd depuis l’entrée standard et les applique comme une transaction atomique unique. Une transaction se compose d’une liste de conditions, d’une liste de requêtes à appliquer si toutes les conditions sont vraies, et d’une liste de requêtes à appliquer si au moins une condition est fausse. Consultez etcdctl key-value commands pour plus d’informations.
`compare`	La clause `compare` au sein d’une transaction (`txn`) sert de vérification conditionnelle déterminant si les opérations de la transaction doivent s’exécuter. Elle garantit que les modifications ne sont appliquées que si l’état actuel du magasin clé-valeur correspond aux conditions attendues, assurant ainsi la cohérence des données et évitant les conflits dans les environnements concurrents. Pour voir la structure de la commande, consultez la section Effectuer une transaction ci-dessous.

Transactions

txn pour traiter toutes les requêtes dans une seule transaction :

Comment surveiller des clés

Mon, 01 Jan 0001 00:00:00 +0000

Prérequis

Installer etcd et etcdctl

Surveillance des clés

watch pour être notifié des modifications futures :

etcdctl watch $KEY [$END_KEY]

Options

-i, --interactive[=false]: interactive mode
--prefix[=false]: watch on a prefix if prefix is set
--rev=0: Revision to start watching
--prev-kv[=false]: get the previous key-value pair before the event happens
--progress-notify[=false]: get periodic watch progress notification from server

Options héritées des commandes parentes

--endpoints="127.0.0.1:2379": gRPC endpoints

Exemples

etcdctl --endpoints=$ENDPOINTS watch stock1
etcdctl --endpoints=$ENDPOINTS put stock1 1000

etcdctl --endpoints=$ENDPOINTS watch stock --prefix
etcdctl --endpoints=$ENDPOINTS put stock1 10
etcdctl --endpoints=$ENDPOINTS put stock2 20

Comment créer un bail

Mon, 01 Jan 0001 00:00:00 +0000

lease pour écrire avec un TTL :

etcdctl --endpoints=$ENDPOINTS lease grant 300
# lease 2be7547fbc6a5afa granted with TTL(300s)

etcdctl --endpoints=$ENDPOINTS put sample value --lease=2be7547fbc6a5afa
etcdctl --endpoints=$ENDPOINTS get sample

etcdctl --endpoints=$ENDPOINTS lease keep-alive 2be7547fbc6a5afa
etcdctl --endpoints=$ENDPOINTS lease revoke 2be7547fbc6a5afa
# or after 300 seconds
etcdctl --endpoints=$ENDPOINTS get sample

Comment créer des verrous

Mon, 01 Jan 0001 00:00:00 +0000

LOCK acquiert un verrou distribué portant un nom donné. Une fois le verrou acquis, il reste détenu jusqu’à la terminaison d’etcdctl.

Prérequis

Installer etcd et etcdctl

Création d’un verrou

lock pour verrouillage distribué :

etcdctl --endpoints=$ENDPOINTS lock mutex1

Options

endpoints - définit une liste séparée par des virgules d’adresses machine du cluster.
ttl - durée d’expiration en secondes de la session de verrouillage.

Comment effectuer l'élection du leader dans un cluster etcd

Mon, 01 Jan 0001 00:00:00 +0000

Prérequis

Vérifiez que etcd et etcdctl sont installés.
Vérifiez l’état du cluster etcd actif.

Conduire l’élection du leader

La commande etcdctl est utilisée pour effectuer des élections de leader dans un cluster etcd. Elle garantit qu’un seul client peut devenir leader à la fois.

etcdctl --endpoints=$ENDPOINTS elect <election-name> [proposal]

etcdctl --endpoints=$ENDPOINTS elect election-name p1

Options

--endpoints : $ENDPOINTS

Adresse de chaque membre du cluster etcd.

Comment vérifier l'état du cluster

Mon, 01 Jan 0001 00:00:00 +0000

Prérequis

Installer etcd et etcdctl

Vérifier l’état global

endpoint status pour vérifier l’état global de chaque point de terminaison spécifié dans le drapeau --endpoints :

etcdctl endpoint status (--endpoints=$ENDPOINTS|--cluster)

Options

--cluster[=false]: use all endpoints from the cluster member list

Vérifier l’état de santé

endpoint health pour vérifier l’état de santé de chaque point de terminaison spécifié dans le drapeau --endpoints :

Comment sauvegarder la base de données

Mon, 01 Jan 0001 00:00:00 +0000

Prérequis

Effectuer un instantané d’une base de données

snapshot pour sauvegarder un instantané du stockage etcd à un instant donné :

etcdctl --endpoints=$ENDPOINT snapshot save DB_NAME

Options globales

etcdctl

--endpoints=[127.0.0.1:2379], gRPC endpoints

Un instantané ne peut être demandé qu’à un nœud etcd, donc le drapeau --endpoints ne doit contenir qu’un seul point de terminaison.

Installer

Mon, 01 Jan 0001 00:00:00 +0000

Exigences

Avant d’installer etcd, consultez les pages suivantes :

[Plateformes prises en charge][]
[Recommandations matérielles][]

Installer les binaires préconstruits

La méthode la plus simple pour installer etcd consiste à utiliser des binaires pré-construits :

Téléchargez le fichier archive compressé pour votre plateforme depuis Releases , en choisissant une version v3.7.0 ou ultérieure.
Décompressez le fichier archive. Cela crée un répertoire contenant les binaires.
Ajoutez les binaires exécutables à votre chemin d’accès. Par exemple, renommez et/ou déplacez les binaires vers un répertoire de votre chemin d’accès (comme /usr/local/bin), ou ajoutez le répertoire créé à l’étape précédente à votre chemin d’accès.

Comment ajouter et supprimer des membres

Mon, 01 Jan 0001 00:00:00 +0000

member pour ajouter, supprimer ou mettre à jour le membre :

# For each machine
TOKEN=my-etcd-token-1
CLUSTER_STATE=new
NAME_1=etcd-node-1
NAME_2=etcd-node-2
NAME_3=etcd-node-3
HOST_1=10.240.0.13
HOST_2=10.240.0.14
HOST_3=10.240.0.15
CLUSTER=${NAME_1}=http://${HOST_1}:2380,${NAME_2}=http://${HOST_2}:2380,${NAME_3}=http://${HOST_3}:2380

# For node 1
THIS_NAME=${NAME_1}
THIS_IP=${HOST_1}
etcd --data-dir=data.etcd --name ${THIS_NAME} \
	--initial-advertise-peer-urls http://${THIS_IP}:2380 \
	--listen-peer-urls http://${THIS_IP}:2380 \
	--advertise-client-urls http://${THIS_IP}:2379 \
	--listen-client-urls http://${THIS_IP}:2379 \
	--initial-cluster ${CLUSTER} \
	--initial-cluster-state ${CLUSTER_STATE} \
	--initial-cluster-token ${TOKEN}

# For node 2
THIS_NAME=${NAME_2}
THIS_IP=${HOST_2}
etcd --data-dir=data.etcd --name ${THIS_NAME} \
	--initial-advertise-peer-urls http://${THIS_IP}:2380 \
	--listen-peer-urls http://${THIS_IP}:2380 \
	--advertise-client-urls http://${THIS_IP}:2379 \
	--listen-client-urls http://${THIS_IP}:2379 \
	--initial-cluster ${CLUSTER} \
	--initial-cluster-state ${CLUSTER_STATE} \
	--initial-cluster-token ${TOKEN}

# For node 3
THIS_NAME=${NAME_3}
THIS_IP=${HOST_3}
etcd --data-dir=data.etcd --name ${THIS_NAME} \
	--initial-advertise-peer-urls http://${THIS_IP}:2380 \
	--listen-peer-urls http://${THIS_IP}:2380 \
	--advertise-client-urls http://${THIS_IP}:2379 \
	--listen-client-urls http://${THIS_IP}:2379 \
	--initial-cluster ${CLUSTER} \
	--initial-cluster-state ${CLUSTER_STATE} \
	--initial-cluster-token ${TOKEN}

Ensuite, remplacez un membre avec les commandes member remove et member add :

Signalement de bogues

Mon, 01 Jan 0001 00:00:00 +0000

Si une partie du projet etcd présente des bogues ou des erreurs de documentation, veuillez nous en informer en ouvrant une demande . Nous prenons très au sérieux les bogues et les erreurs, et considérons qu’aucun problème n’est trop petit. Avant de créer un rapport de bogue, veuillez vérifier qu’une demande signalant le même problème n’existe pas déjà.

Pour que le rapport de bogues soit précis et facile à comprendre, veuillez essayer de rédiger des rapports de bogues qui sont :

Optimisation

Mon, 01 Jan 0001 00:00:00 +0000

Les paramètres par défaut d’etcd devraient fonctionner correctement pour les installations sur un réseau local où la latence réseau moyenne est faible. Toutefois, lors de l’utilisation d’etcd sur plusieurs centres de données ou sur des réseaux à forte latence, il se peut que les paramètres d’intervalle de battement et de délai d’élection nécessitent une adaptation.

Le réseau n’est pas la seule source de latence. Chaque requête et réponse peut être affectée par des disques lents sur le leader et le suiveur. Chacun de ces délais d’attente représente le temps total écoulé entre la requête et la réponse réussie de l’autre machine.

Guide du développeur

Mon, 01 Jan 0001 00:00:00 +0000

Interaction avec etcd

Mon, 01 Jan 0001 00:00:00 +0000

Les utilisateurs interagissent généralement avec etcd en définissant ou en récupérant la valeur d’une clé. Cette section décrit comment effectuer ces opérations à l’aide d’etcdctl, un outil en ligne de commande pour interagir avec le serveur etcd. Les concepts décrits ici s’appliquent également aux API gRPC ou aux API des bibliothèques clientes.

La version de l’API utilisée par etcdctl pour communiquer avec etcd peut être définie à 2 ou 3 via la variable d’environnement ETCDCTL_API. Par défaut, etcdctl sur la branche master (3.4) utilise l’API v3, tandis que les versions antérieures (3.3 et antérieures) utilisent par défaut l’API v2.

Découverte et nommage gRPC

Mon, 01 Jan 0001 00:00:00 +0000

etcd fournit un résolveur gRPC afin de prendre en charge un système de noms alternatif qui récupère les points d’accès depuis etcd pour la découverte de services gRPC. Le mécanisme sous-jacent repose sur la surveillance des mises à jour des clés préfixées par le nom du service.

Notez que cette fonctionnalité est expérimentale car elle dépend du paquet google.golang.org/grpc/resolver , qui reste expérimental dans grpc-go.

Utilisation de la découverte etcd avec go-grpc

Le client etcd fournit un résolveur gRPC permettant de résoudre les points d’accès gRPC à l’aide d’un backend etcd. Le résolveur est initialisé avec un client etcd :

Intégration d'etcd dans une application Go

Mon, 01 Jan 0001 00:00:00 +0000

Le paquet go etcd embed fournit un moyen simple d’intégrer un serveur etcd directement dans votre application.

Pour plus de détails, consultez la documentation du paquet embed .

Guide des opérations

Mon, 01 Jan 0001 00:00:00 +0000

Guides d'authentification

Mon, 01 Jan 0001 00:00:00 +0000

Authentification

Mon, 01 Jan 0001 00:00:00 +0000

auth,user,role pour l’authentification :

export ETCDCTL_API=3
ENDPOINTS=localhost:2379

etcdctl --endpoints=${ENDPOINTS} role add root
etcdctl --endpoints=${ENDPOINTS} role get root

etcdctl --endpoints=${ENDPOINTS} user add root
etcdctl --endpoints=${ENDPOINTS} user grant-role root root
etcdctl --endpoints=${ENDPOINTS} user get root

etcdctl --endpoints=${ENDPOINTS} role add role0
etcdctl --endpoints=${ENDPOINTS} role grant-permission role0 readwrite foo
etcdctl --endpoints=${ENDPOINTS} user add user0
etcdctl --endpoints=${ENDPOINTS} user grant-role user0 role0

etcdctl --endpoints=${ENDPOINTS} auth enable
# now all client requests go through auth

etcdctl --endpoints=${ENDPOINTS} --user=user0:123 put foo bar
etcdctl --endpoints=${ENDPOINTS} get foo
# permission denied, user name is empty because the request does not issue an authentication request
etcdctl --endpoints=${ENDPOINTS} --user=user0:123 get foo
# user0 can read the key foo
etcdctl --endpoints=${ENDPOINTS} --user=user0:123 get foo1

Note :

Il s’agit simplement d’un squelette qui doit être complété et mis à jour avec des informations supplémentaires sur l’authentification. Le texte ci-dessus n’est qu’un exemple de code.

Contrôle d'accès basé sur les rôles

Mon, 01 Jan 0001 00:00:00 +0000

Aperçu

L’authentification a été ajoutée à etcd 2.1. L’API v3 d’etcd a légèrement modifié l’API et l’interface utilisateur de la fonctionnalité d’authentification afin de mieux s’adapter au nouveau modèle de données. Ce guide vise à aider les utilisateurs à configurer une authentification basique et un contrôle d’accès basé sur les rôles dans etcd v3.

Utilisateurs et rôles spéciaux

Il existe un utilisateur spécial, root, et un rôle spécial, root.

Modèle de sécurité du transport

Mon, 01 Jan 0001 00:00:00 +0000

etcd prend en charge le chiffrement TLS automatique ainsi que l’authentification par certificats clients pour les communications clients vers serveur, ainsi que pour les communications entre pairs (serveur vers serveur / cluster). Notez qu’etcd n’active pas par défaut l’authentification basée sur RBAC ni la fonctionnalité d’authentification au niveau du transport afin de réduire les obstacles pour les utilisateurs débutants avec la base de données. En outre, modifier cette valeur par défaut constituerait une modification incompatible pour le projet, établie depuis 2013. Un cluster etcd qui n’active pas les fonctionnalités de sécurité peut exposer ses données à tout client.

Guide de clustering

Mon, 01 Jan 0001 00:00:00 +0000

Aperçu

Lancer un cluster etcd de manière statique exige que chaque membre connaisse un autre membre du cluster. Dans certains cas, les adresses IP des membres du cluster peuvent être inconnues à l’avance. Dans ces situations, le cluster etcd peut être initialisé à l’aide d’un service de découverte.

Une fois qu’un cluster etcd est en cours d’exécution, l’ajout ou la suppression de membres s’effectue via la reconfiguration en temps réel runtime reconfiguration . Pour mieux comprendre la conception sous-jacente à la reconfiguration en temps réel, nous recommandons de lire le document de conception de la configuration en temps réel .

Exécuter des clusters etcd dans des conteneurs

Mon, 01 Jan 0001 00:00:00 +0000

Le guide suivant explique comment exécuter etcd avec Docker en utilisant le processus de bootstrap statique static bootstrap process .

Docker

Afin d’exposer l’API etcd aux clients situés en dehors de l’hôte Docker, utilisez l’adresse IP hôte du conteneur. Voir docker inspect pour plus de détails sur la manière d’obtenir l’adresse IP. En alternative, spécifiez le drapeau --net=host à la commande docker run afin de passer outre la mise du conteneur dans une pile réseau séparée.

Exécuter des clusters etcd en tant que StatefulSet Kubernetes

Mon, 01 Jan 0001 00:00:00 +0000

Ci-dessous montre comment effectuer le processus de bootstrap statique comme un StatefulSet Kubernetes .

Exemple de manifeste

Ce manifeste contient un service et un statefulset pour déployer un cluster etcd statique dans Kubernetes.

Si vous copiez le contenu du manifeste dans un fichier nommé etcd.yaml, vous pouvez l’appliquer à un cluster à l’aide de cette commande.

$ kubectl apply --filename etcd.yaml

Une fois appliqué, attendez que les pods soient prêts.

Récupération après sinistre

Mon, 01 Jan 0001 00:00:00 +0000

etcd est conçu pour résister aux pannes de machines. Un cluster etcd se rétablit automatiquement après des pannes temporaires (par exemple, redémarrages de machine) et tolère jusqu’à (N-1)/2 pannes permanentes pour un cluster composé de N membres. Lorsqu’un membre subit une panne permanente, qu’elle soit due à une défaillance matérielle ou à une corruption du disque, il perd accès au cluster. Si le cluster perd définitivement plus de (N-1)/2 membres, il subit une panne catastrophique, perdant irrévocablement son quorum. Une fois le quorum perdu, le cluster ne peut plus atteindre de consensus et ne peut donc plus accepter de mises à jour.

etcd gateway

Mon, 01 Jan 0001 00:00:00 +0000

Qu’est-ce que la passerelle etcd

Le passerelle etcd est un proxy TCP simple qui achemine les données réseau vers le cluster etcd. La passerelle est sans état et transparente ; elle n’inspecte ni les requêtes clients ni les réponses du cluster. Elle ne termine pas les connexions TLS, ne réalise pas d’échanges TLS à la place de ses clients, ni ne vérifie si la connexion est sécurisée.

Proxie gRPC

Mon, 01 Jan 0001 00:00:00 +0000

Le proxy gRPC est un proxy inverse etcd sans état fonctionnant au niveau du protocole gRPC (L7). Le proxy est conçu pour réduire la charge de traitement totale imposée au cluster etcd principal. Pour assurer une évolutivité horizontale, il regroupe les requêtes d’API de surveillance et de bail. Pour protéger le cluster contre les clients abusifs, il met en mémoire tampon les requêtes portant sur des plages de clés.

Le proxy gRPC prend en charge plusieurs points d’entrée de serveur etcd. Au démarrage du proxy, il choisit aléatoirement un point d’entrée de serveur etcd à utiliser. Ce point d’entrée traite toutes les requêtes jusqu’à ce que le proxy détecte une défaillance. Si le proxy gRPC détecte une défaillance d’un point d’entrée, il bascule vers un autre point d’entrée, si disponible, afin de masquer les défaillances à ses clients. D’autres politiques de réessai, telles que le round-robin pondéré, pourraient être prises en charge à l’avenir.

Maintenance

Mon, 01 Jan 0001 00:00:00 +0000

Aperçu

Un cluster etcd nécessite une maintenance périodique pour rester fiable. Selon les besoins d’une application etcd, cette maintenance peut généralement être automatisée et effectuée sans interruption de service ni dégradation significative des performances.

Toute maintenance etcd gère les ressources de stockage consommées par l’espace de clés etcd. Une gestion insuffisante de la taille de l’espace de clés est protégée par des quotas d’espace de stockage ; si un membre etcd manque d’espace, un quota déclenchera des alarmes à l’échelle du cluster, mettant le système en mode maintenance à opérations limitées. Pour éviter de manquer d’espace pour les écritures dans l’espace de clés, l’historique de l’espace de clés etcd doit être compacté. L’espace de stockage lui-même peut être récupéré en défragmentant les membres etcd. Enfin, des sauvegardes périodiques d’instantanés de l’état des membres etcd permettent de récupérer toute perte logique de données ou corruption involontaire causée par une erreur opérationnelle.

Surveillance d’etcd

Mon, 01 Jan 0001 00:00:00 +0000

Chaque serveur etcd fournit des informations de surveillance locales sur son port client via des points de terminaison HTTP. Les données de surveillance sont utiles à la fois pour le contrôle de santé du système et le débogage du cluster.

Point d’entrée de débogage

Si --log-level=debug est défini, le serveur etcd exporte des informations de débogage sur son port client sous le chemin /debug. Prenez garde à la définition de --log-level=debug, car cela entraînera une dégradation des performances et une journalisation verbose.

Reconfiguration en cours d'exécution

Mon, 01 Jan 0001 00:00:00 +0000

etcd dispose d’un support pour la reconfiguration incrémentielle en temps d’exécution, ce qui permet aux utilisateurs de mettre à jour la composition du cluster en cours d’exécution.

Les requêtes de reconfiguration ne peuvent être traitées que lorsque la majorité des membres du cluster sont fonctionnels. Il est fortement recommandé de toujours disposer d’un cluster de taille supérieure à deux en production. Il est dangereux de supprimer un membre d’un cluster à deux membres. La majorité d’un cluster à deux membres est également de deux. En cas d’échec pendant le processus de suppression, le cluster pourrait ne pas être en mesure de progresser et nécessiterait un redémarrage suite à une défaillance de la majorité .

Corruption des données

Mon, 01 Jan 0001 00:00:00 +0000

etcd dispose d’une détection automatique des corruption de données intégrée afin d’éviter que l’état du membre ne diverge.

Activation détection corruption données

Détection de corruption de données possible à l’aide de :

Vérification initiale, activée avec le drapeau --experimental-initial-corrupt-check.
Vérification périodique de :
- Hachage de la révision compactée, activée avec le drapeau --experimental-compact-hash-check-enabled.
- Hachage de la dernière révision, activée avec le drapeau --experimental-corrupt-check-time.

La vérification initiale sera exécutée lors du démarrage du membre etcd. Le membre comparera son état persistant avec celui des autres membres et quittera l’exécution s’il détecte une incohérence.

Mise à jour

Mon, 01 Jan 0001 00:00:00 +0000

Rétrogradation

Mon, 01 Jan 0001 00:00:00 +0000

Mise à jour des clusters etcd et des applications

Mon, 01 Jan 0001 00:00:00 +0000

Cette section contient les documents spécifiques à la mise à jour des clusters etcd et des applications.

Politique de mise à jour

Avant la mise à jour, notez qu’etcd ne prend en charge que les deux cas de mise à jour suivants :

Mise à jour correctif : Mise à jour entre des versions correctives du même numéro de version mineure (par exemple, 3.7.0 → 3.7.1).
Mise à jour mineure : Mise à jour d’une version mineure à la fois (par exemple, 3.6 → 3.7). Les mises à jour qui sautent une version mineure ne sont pas prises en charge et risquent de échouer. Mettez à jour vers la dernière version correctif avant de passer à la version mineure suivante.

Mise à jour d’un cluster etcd v3.x

Mise à niveau depuis etcd v2.3

Mettre à jour un cluster v2.3 vers la v3.0

Réduction de version des clusters etcd et des applications

Mon, 01 Jan 0001 00:00:00 +0000

Cette section contient les documents spécifiques à la rétrogradation des clusters etcd et des applications.

Réduction de la version d’un cluster etcd v3.x

Mettre à jour etcd de la version v3.5 à la version v3.6

Mon, 01 Jan 0001 00:00:00 +0000

Dans le cas général, la mise à niveau de etcd v3.5 vers v3.6 peut être une mise à niveau progressive sans interruption de service :

un à un, arrêtez les processus etcd v3.5 et remplacez-les par des processus etcd v3.6
après avoir lancé tous les processus v3.6, les nouvelles fonctionnalités de la version v3.6 sont disponibles pour le cluster

Avant de lancer la mise à jour , lisez le reste du présent guide afin de vous préparer.

Rétrogradation d'etcd de la version v3.7 à la v3.6

Mon, 01 Jan 0001 00:00:00 +0000

Dans le cas général, la rétrogradation de etcd v3.7 vers v3.6 peut se faire sans interruption de service, par mise à jour progressive :

un à un, arrêtez les processus etcd v3.7 et remplacez-les par des processus etcd v3.6
après avoir activé la remontée de version, les nouvelles fonctionnalités de la v3.7 ne sont plus disponibles pour le cluster

Avant de effectuer une mise vers une version antérieure , lisez le reste du présent guide afin de vous préparer.

Mettre à jour etcd de 3.4 à 3.5

Mon, 01 Jan 0001 00:00:00 +0000

Dans le cas général, la mise à niveau de etcd 3.4 vers 3.5 peut être effectuée sans interruption de service, en mode mise à niveau progressive :

un par un, arrêtez les processus etcd v3.4 et remplacez-les par des processus etcd v3.5
après avoir lancé tous les processus v3.5, les nouvelles fonctionnalités de la version v3.5 sont disponibles pour le cluster

Avant de lancer la mise à jour , lisez le reste du présent guide afin de vous préparer.

Rétrogradation d'etcd de la version 3.5 à la 3.4

Mon, 01 Jan 0001 00:00:00 +0000

Dans le cas général, la rétrogradation de etcd 3.5 vers 3.4 peut s’effectuer sans interruption de service, en mode rolling :

un par un, arrêtez les processus etcd 3.5 et remplacez-les par des processus etcd 3.4
après avoir lancé des processus 3.4, les nouvelles fonctionnalités de 3.5 ne sont plus disponibles pour le cluster

Avant de effectuer une mise vers une version antérieure , lisez le reste du présent guide afin de vous préparer.

Rétrogradation d'etcd de la version v3.6 à la v3.5

Mon, 01 Jan 0001 00:00:00 +0000

Dans le cas général, la rétrogradation de etcd v3.6 vers v3.5 peut s’effectuer sans interruption de service, en mode rolling :

un à un, arrêtez les processus etcd v3.6 et remplacez-les par des processus etcd v3.5
après avoir activé la rétrogradation, les nouvelles fonctionnalités de la version v3.6 ne sont plus disponibles pour le cluster

Avant de effectuer une mise vers une version antérieure , lisez le reste du présent guide afin de vous préparer.

Mettre à jour etcd de 3.3 à 3.4

Mon, 01 Jan 0001 00:00:00 +0000

Dans le cas général, la mise à niveau de etcd 3.3 vers 3.4 peut s’effectuer sans interruption de service, par mise à niveau progressive :

un par un, arrêtez les processus etcd v3.3 et remplacez-les par des processus etcd v3.4
après avoir lancé tous les processus v3.4, les nouvelles fonctionnalités de la version v3.4 sont disponibles pour le cluster

Avant de lancer la mise à jour , lisez le reste du présent guide afin de vous préparer.

Mettre à jour etcd de la version v3.6 à la version v3.7

Mon, 01 Jan 0001 00:00:00 +0000

Dans le cas général, la mise à niveau de etcd v3.6 vers v3.7 peut être une mise à niveau progressive sans interruption de service :

un à un, arrêtez les processus etcd v3.6 et remplacez-les par des processus etcd v3.7
après avoir lancé tous les processus v3.7, les nouvelles fonctionnalités de la version v3.7 sont disponibles pour le cluster

Avant de lancer la mise à jour , lisez le reste du présent guide afin de vous préparer.

Mettre à jour etcd de 3.2 vers 3.3

Mon, 01 Jan 0001 00:00:00 +0000

Dans le cas général, la mise à niveau de etcd 3.2 vers 3.3 peut être effectuée sans interruption de service, par mise à niveau progressive :

un par un, arrêtez les processus etcd v3.2 et remplacez-les par des processus etcd v3.3
après avoir lancé tous les processus v3.3, les nouvelles fonctionnalités de la version v3.3 sont disponibles pour le cluster

Avant de lancer la mise à jour , lisez le reste du présent guide afin de vous préparer.

Mettre à jour etcd de 3.1 vers 3.2

Mon, 01 Jan 0001 00:00:00 +0000

Dans le cas général, la mise à niveau de etcd 3.1 vers 3.2 peut être effectuée sans interruption de service, par mise à niveau progressive :

un par un, arrêtez les processus etcd v3.1 et remplacez-les par des processus etcd v3.2
après avoir lancé tous les processus v3.2, les nouvelles fonctionnalités de la version v3.2 sont disponibles pour le cluster

Avant de lancer la mise à jour , lisez le reste du présent guide afin de vous préparer.

Mettre à jour etcd de la version 3.0 à la 3.1

Mon, 01 Jan 0001 00:00:00 +0000

Dans le cas général, la mise à niveau d’etcd 3.0 vers 3.1 peut être effectuée sans interruption de service, par mise à niveau progressive :

un nœud à la fois, arrêtez les processus etcd v3.0 et remplacez-les par des processus etcd v3.1
après avoir lancé tous les processus v3.1, les nouvelles fonctionnalités de la version v3.1 sont disponibles pour le cluster

Avant de lancer la mise à jour , lisez le reste du présent guide afin de vous préparer.

Mettre à jour etcd de la version 2.3 à la 3.0

Mon, 01 Jan 0001 00:00:00 +0000

Dans le cas général, la mise à niveau de etcd 2.3 vers 3.0 peut s’effectuer sans interruption de service, par mise à niveau progressive :

un par un, arrêtez les processus etcd v2.3 et remplacez-les par des processus etcd v3.0
après avoir lancé tous les processus v3.0, les nouvelles fonctionnalités de la version 3.0 sont disponibles pour le cluster

Avant de lancer la mise à jour , lisez le reste du présent guide afin de vous préparer.

Tri

Mon, 01 Jan 0001 00:00:00 +0000

Guidelines de tri des problèmes

Mon, 01 Jan 0001 00:00:00 +0000

Objectif

Accélérer la gestion des problèmes.

Les problèmes liés à etcd sont répertoriés sur https://github.com/etcd-io/etcd/issues et sont identifiés par des étiquettes. Par exemple, un problème identifié comme un bogue sera éventuellement étiqueté area/bug . Les nouveaux problèmes apparaissent initialement sans étiquette, mais les responsables etcd et les contributeurs actifs ajoutent des étiquettes en fonction de leurs constatations. La liste détaillée des étiquettes est disponible sur https://github.com/kubernetes/kubernetes/labels

Voici quelques recherches prédéfinies sur les problèmes, pour plus de commodité :

Gestion des demandes de tirage

Mon, 01 Jan 0001 00:00:00 +0000

Objectif

Accélérer la gestion des PR.

Les demandes de fusion etcd sont listées sur https://github.com/etcd-io/etcd/pulls Une demande de fusion peut avoir divers étiquettes, un délai d’achèvement, un validateur, etc. La liste détaillée des étiquettes est disponible sur https://github.com/kubernetes/kubernetes/labels

Voici quelques exemples de recherches sur PR pour plus de commodité :

Portée

Ces directives servent de document principal pour la gestion des demandes de tirage (PR) dans etcd. Tous sont invités à aider à la gestion des PR, mais le travail et les responsabilités décrits dans ce document s’adressent principalement aux mainteneurs et contributeurs actifs de etcd.

Tâche on PIG.CENTER

Usage : pgbouncer commande

Synopsis

Description

Configuration de journalisation de PostgreSQL

Journalisation minimale des requêtes

Traitement parallèle

Découper un grand fichier avec -j

Imagerie de réplique et amorçage

Rapports incrémentiels

Générer des rapports quotidiens et hebdomadaires

cluster de secours

Versions, Paquets et Mises à jour

Tâches

Tâches de l'opérateur

Comment configurer un cluster étcd de démonstration

Mode Pause/Reprise pour le cluster

Objectif

Prise en charge et contribution

Signalements de bogues et demandes de fonctionnalités

Utilisation de Patroni avec Kubernetes

Convertir un nœud autonome en cluster Patroni

Procédure

Tâches de développement

8. Journalisation

Guidelines pour les contributions

Discussion

Signalement de bogues

Lecture depuis etcd

Prérequis

Procédure

1. Prérequis

Écriture dans etcd

Prérequis

Procédure

3. Démarrage de HAProxy

4. Arrêt et redémarrage de HAProxy

5. Limites des descripteurs de fichiers

6. Gestion de la mémoire

Comment obtenir des clés par préfixe

Prérequis

Obtenir les clés par préfixe

Options globales

Options

Exemple

7. Utilisation du CPU

8. Journalisation

9. Statistiques et surveillance

10. Gestion de configuration simplifiée

11. Pièges courants à éviter

12. Problèmes de débogage et de performance

13. Considérations de sécurité

Comment supprimer des clés

Prérequis

Ajouter ou supprimer des clés

Options

Options héritées des commandes parentes

Exemples

Comment effectuer plusieurs écritures dans une transaction

Prérequis

Terminologie

Transactions

Comment surveiller des clés

Prérequis

Surveillance des clés

Options

Options héritées des commandes parentes

Exemples

Comment créer un bail

Comment créer des verrous

Prérequis

Création d’un verrou

Options

Comment effectuer l'élection du leader dans un cluster etcd

Prérequis

Conduire l’élection du leader

Options

Comment vérifier l'état du cluster

Prérequis

Vérifier l’état global

Découper un grand fichier avec `-j`