etcd è un archivio di chiavi-valori distribuito open source utilizzato per contenere e gestire le informazioni fondamentali di cui i sistemi distribuiti hanno bisogno per continuare a funzionare. In particolare, gestisce i dati di configurazione, i dati di stato e i metadati per Kubernetes, la diffusa piattaforma di orchestrazione dei container.

Come tutti i carichi di lavoro distribuiti, i carichi di lavoro containerizzati hanno requisiti di gestione complessi che diventano più complessi man mano che si esegue la scalabilità del carico di lavoro. Kubernetes semplifica il processo di gestione di questi carichi di lavoro coordinando attività quali configurazione, implementazione, rilevamento dei servizi, bilanciamento del carico, pianificazione dei lavori e monitoraggio dello stato di integrità in tutti i cluster, che possono essere eseguiti su più macchine in più ubicazioni.

Per raggiungere però questa coordinazione, Kubernetes ha bisogno di un archivio dati che fornisca una singola fonte attendibile coerente sullo stato del sistema - tutti i cluster e i pod e le istanze dell'applicazione al loro interno - in un qualsiasi dato momento. etcd è l'archivio dati utilizzato per creare e mantenere questa versione dell'attendibilità.

etcd ha un ruolo simile per Cloud Foundry (link esterno a ibm.com) - la piattaforma PaaS (Platform-as-a-Service) open-source, multicloud - ed è una valida opzione per coordinare sistema critici e metadati nei cluster di qualsiasi applicazione distribuita. l nome "etcd" deriva da una convenzione di denominazione nella struttura delle directory di Linux: in UNIX, tutti i file di configurazione di sistema per un singolo sistema sono contenuti in una cartella chiamata "/etc"; "d" sta invece per "distributed".

Per un approfondimento, guarda il video "What is etcd?" (6:09):

Non è un compito da poco essere la struttura portante dei dati che mantiene un carico di lavoro distribuito in esecuzione. Ma etcd è costruito per questo compito, progettato da zero per presentare le seguenti qualità:

• Completamente replicato: ogni nodo in un cluster etcd ha accesso all'archivio dati completo.
  
  
• Altamente disponibile: etcd è progettato per non avere alcun singolo punto di guasto e per tollerare senza problemi i malfunzionamenti hardware e le partizioni di rete.
  
  
• Coerente in modo affidabile: ogni "lettura" di dati restituisce la "scrittura" di dati più recente in tutti i cluster.
  
  
• Veloce: etcd è stato parametrato a 10.000 scritture al secondo.
  
  
• Sicuro: etcd supporta TLS (Transport Layer Security) automatico e autenticazione del certificato client SSL (Secure Socket Layer) facoltativa. Poiché etcd memorizza dati di configurazione vitali e altamente sensibili, gli amministratori devono implementare controlli di accesso basati sui ruoli all'interno dell'implementazione e garantire che i membri del team che interagiscono con etcd siano limitati al livello di accesso con privilegi minimi necessario per svolgere il loro lavoro.
  
  
• Semplice: qualsiasi applicazione, dalle applicazioni web semplici ai motori di orchestrazione di container altamente complessi come Kubernetes, può leggere o scrivere dati su etcd utilizzando strumenti HTTP/JSON standard.

Poiché le prestazioni di etcd dipendono molto dalla velocità del disco di storage, è altamente consigliato l'uso di SSD negli ambienti etcd. Per maggiori informazioni su questo e altri requisiti di storage di etcd, consulta l'articolo sull'utilizzo di Fio per verificare se il tuo storage è abbastanza veloce per Etcd.

etcd è costruito sull'algoritmo di consenso Raft per assicurare la coerenza dell'archivio dati su tutti i nodi in un cluster, il che lo rende un sistema distribuito a tolleranza di errore.

Raft raggiunge questa coerenza tramite un nodo leader eletto che gestisce la replica per gli altri nodi del cluster, chiamati follower. Il leader accetta le richieste dei client, che poi inoltra ai nodi follower. Dopo essersi accertato che la maggior parte dei nodi follower abbia memorizzato ogni nuova richiesta come voce di log, il leader applica la voce alla macchina di stato locale e restituisce il risultato di tale esecuzione - una "scrittura" - al client. Se i follower si arrestano in modo anomalo o i pacchetti di rete vengono persi, il leader riprova fino a quando tutti i follower hanno memorizzato tutte le voci di log in modo coerente.

Se un nodo follower non riceve un messaggio dal leader entro un intervallo di tempo specificato, viene eseguita un'elezione per scegliere un nuovo leader. Il follower si dichiara candidato e gli altri follower votano per esso o per un altro nodo in base alla sua disponibilità. Una volta eletto, il nuovo leader inizia a gestire la replica e il processo si ripete. Questo processo consente a tutti i nodi etcd di mantenere copie altamente disponibili e costantemente replicate dell'archivio dati.

etcd è incluso tra i componenti principali di Kubernetes e serve come archivio di chiavi-valori principale per creare un cluster Kubernetes funzionante e a tolleranza di errore. Il server API di Kubernetes memorizza i dati di stato di ogni cluster in etcd. Kubernetes utilizza la funzione "watch" di etcd per monitorare questi dati ed eseguire una nuova configurazione quando vengono apportate delle modifiche. La funzione "watch" memorizza i valori che rappresentano lo stato effettivo e ideale del cluster e può avviare una risposta quando gli stati divergono.

Per una panoramica di alto livello di come Kubernetes gestisce i cluster, i servizi e i nodi di lavoro, guarda il video "Kubernetes Explained":

etcd è stato creato dallo stesso team responsabile della progettazione di CoreOS Container Linux, un sistema operativo container ampiamente utilizzato che può essere eseguito e gestito in modo efficace su larga scala. etcd è stato creato originariamente su Raft per coordinare più copie di Container Linux simultaneamente, al fine di garantire un tempo di attività ininterrotto delle applicazioni.

Nel dicembre 2018, il team ha donato etcd alla CNCF (Cloud Native Computing Foundation), un'organizzazione neutrale senza scopo di lucro che mantiene il codice di origine di etcd, i domini, i servizi ospitati, l'infrastruttura cloud e altre proprietà del progetto come risorse open source per la community di sviluppo cloud basata su container. CoreOS si è fuso con Red Hat.

Altri database sono stati sviluppati per gestire le informazioni coordinate tra cluster di applicazioni distribuite. I due database più comunemente raffrontati a etcd sono ZooKeeper e Consul.

ZooKeeper

ZooKeeper è stato originariamente creato per coordinare dati di configurazione e metadati tra i cluster Apache Hadoop. (Apache Hadoop (link esterno a ibm.com) è un framework open source, o una raccolta di applicazioni, per la memorizzazione e l'elaborazione su cluster di grandi volumi di dati di hardware di largo consumo). ZooKeeper è precedente a etcd e le lezioni apprese lavorando con ZooKeeper hanno influenzato il design di etcd.

Come risultato, etcd ha alcune importanti funzionalità che ZooKeeper non possiede. Ad esempio, a differenza di ZooKeeper, etcd è in grado di:

• Consentire la riconfigurazione dinamica dell'appartenenza ai cluster.
  
  
• Rimanere stabile durante l'esecuzione di operazioni di lettura/scrittura in situazioni di carico elevato.
  
  
• Mantenere un modello di dati di controllo della simultaneità multiversione.
  
  
• Offrire un monitoraggio chiave affidabile che non elimina mai gli eventi senza fornire una notifica.
  
  
• Utilizzare primitive di simultaneità che disaccoppiano le connessioni dalle sessioni.
  
  
• Supportare una vasta gamma di linguaggi e framework (ZooKeeper ha il suo protocollo RPC Jute personalizzato che supporta binding di linguaggio limitati).

Consul

Consul è una soluzione di rete di servizi per sistemi distribuiti, le cui capacità sono a metà strada tra quelle di etcd e la rete di servizi Istio per Kubernetes. Come etcd, Consul (link esterno a ibm.com) include uno archivio di chiavi-valori distribuito basato sull'algoritmo Raft e supporta le API (application programming interface) HTTP/JSON. Entrambi offrono una configurazione dinamica dell'appartenenza ai cluster, ma Consul non controlla in modo così efficace le versioni simultanee multiple dei dati di configurazione e la dimensione massima del database con cui lavorare in modo affidabile è più piccola.

Come etcd, Redis è uno strumento open source, ma le loro funzionalità di base sono diverse.

Redis è un archivio dati in-memory e può funzionare come database, cache o broker di messaggi. Redis supporta una più ampia varietà di tipi di dati e strutture rispetto a etcd e ha prestazioni di lettura/scrittura molto più veloci.

Tuttavia, etcd ha una tolleranza di errore superiore, un failover più solido e funzionalità di disponibilità continua dei dati e, cosa più importante, etcd conserva tutti i dati memorizzati su disco, sacrificando sostanzialmente la velocità per una maggiore affidabilità e una coerenza garantita. Per questi motivi, Redis è più adatto a servire come sistema di caching della memoria distribuita che a memorizzare e distribuire le informazioni di configurazione del sistema.