Cos'è Etcd?

Come tutti i workload distribuiti, i workload containerizzati hanno requisiti di gestione complessi che diventano ancora più complessi con l'aumentare delle dimensioni del workload. Kubernetes semplifica il processo di gestione di questi workload coordinando attività quali configurazione, implementazione, individuazione dei servizi, bilanciamento del carico, pianificazione dei processi e monitoraggio dello stato di salute di tutti i cluster, che possono essere eseguiti su più macchine in più sedi.

Ma per raggiungere questo coordinamento, Kubernetes ha bisogno di uno storage dei dati che fornisce un'unica e coerente fonte di verità sullo stato del sistema, tutti i suoi cluster e pod e le istanze delle applicazioni al loro interno, in un dato momento. etcd è lo storage dei dati utilizzato per creare e mantenere questa versione della verità.

etcd svolge un ruolo simile per Cloud Foundry, la Platform-as-a-Service (PaaS) open source e multicloud, ed è una valida opzione per coordinare sistemi e metadati critici tra i cluster di qualsiasi applicazione distribuita. Il nome "etcd" deriva da una convenzione di denominazione all'interno della struttura di directory di Linux: in UNIX, tutti i file di configurazione del sistema per un singolo sistema sono contenuti in una cartella chiamata "/etc"; "d" sta per "distributed".

Avere funzione di struttura portante dei dati che mantiene in esecuzione un workload distribuito è un compito di estrema importanza. Ma etcd è costruito per tale compito, progettato da zero per le seguenti qualità:

• Completamente replicato: ogni nodo di un cluster etcd ha accesso allo storage dei dati completo.
  
  
• Altamente disponibile: etcd è progettato per non avere un singolo punto di errore e tollerare agilmente i guasti hardware e le partizioni di rete.
  
  
• Costante in modo affidabile: ogni "lettura" dei dati restituisce l'ultima "scrittura" dei dati in tutti i cluster.
  
  
• Veloce: etcd è stato misurato a 10.000 scritture al secondo.
  
  
• Sicuro: etcd supporta l'autenticazione automatica dei certificati client Transport Layer Security (TLS) e Secure Socket Layer (SSL) opzionale. Poiché etcd memorizza dati di configurazione vitali e altamente sensibili, gli amministratori devono implementare controlli di accesso basati sui ruoli all'interno della distribuzione e assicurarsi che i membri del team che interagiscono con etcd siano limitati al livello di accesso con privilegi minimi necessario per svolgere i loro lavori.
  
  
• Semplice: qualsiasi applicazione, dalle semplici app web ai motori di orchestrazione di container altamente complessi come Kubernetes, può leggere o scrivere dati su etcd utilizzando strumenti HTTP/JSON standard.

Tieni presente che, dal momento che le prestazioni di etcd dipendono prevalentemente dalla velocità del disco di storage, si consiglia vivamente di utilizzare gli SSD in ambienti etcd.

etcd è basato sull'algoritmo di consenso Raft per garantire la coerenza della memorizzazione dati su tutti i nodi di un cluster, una condizione imprescindibile per un sistema distribuito a prova 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 dai client, che poi inoltra ai nodi follower. Una volta che il leader ha accertato che la maggior parte dei nodi follower hanno memorizzato ogni nuova richiesta come voce di registro, applica la voce al suo sistema di stato locale e restituisce il risultato di tale esecuzione, una "scrittura", al client. Se i follower si bloccano o i pacchetti di rete vengono persi, il leader riprova finché tutti i follower non hanno memorizzato tutte le voci di registro in modo coerente.

Se un nodo follower non riceve un messaggio dal leader entro un intervallo di tempo specificato, viene indetta un'elezione per scegliere un nuovo leader. Il follower si dichiara candidato e gli altri follower votano per lui o per qualsiasi 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 dello storage dei dati replicate in modo coerente e altamente disponibili.

etcd è incluso tra i componenti principali di Kubernetes e funge da storage chiave-valore principale per la creazione di un cluster Kubernetes funzionante e tollerante agli errori. Il server API Kubernetes memorizza i dati di stato di ciascun cluster in etcd. Kubernetes utilizza la funzione "watch" di etcd per monitorare questi dati e riconfigurarsi quando si verificano modifiche. La funzione "watch" memorizza i valori che rappresentano lo stato reale e ideale del cluster e può iniziare una risposta quando divergono.

Per una panoramica di alto livello su come Kubernetes gestisce i cluster, servizi e nodi lavoratori, guarda il nostro video "Informazioni su Kubernetes":

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 efficiente su vasta scala. Inizialmente avevano sviluppato etcd su Raft per coordinare più copie di Container Linux contemporaneamente, per garantire tempi di attività ininterrotti delle applicazioni.

Nel dicembre 2018, il team ha donato etcd alla Cloud Native Computing Foundation (CNCF), un'organizzazione neutrale senza scopo di lucro che mantiene il codice sorgente, i domini, i servizi ospitati, l'infrastruttura cloud e altre proprietà del progetto di etcd come risorse open source per la comunità 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 paragonati a etcd sono ZooKeeper e Consul.

ZooKeeper è stato originariamente creato per coordinare i metadati e i dati di configurazione tra i cluster Apache Hadoop. (Apache Hadoop è un framework open source, o raccolta di applicazioni, per memorizzare ed elaborare grandi volumi di dati su cluster di hardware di base.) ZooKeeper è più datato di etcd e le lezioni apprese lavorando con ZooKeeper hanno influenzato il design di etcd.

Di conseguenza, etcd ha alcune funzionalità importanti che ZooKeeper non ha. Ad esempio, a differenza di ZooKeeper, etcd può fare quanto segue:

• Consente la riconfigurazione dinamica dell'appartenenza al cluster.
  
  
• Rimane stabile durante l'esecuzione di operazioni di lettura/scrittura con carichi elevati.
  
  
• Mantiene un modello di dati di controllo della concorrenza multi versione.
  
  
• Offre un monitoraggio affidabile delle chiavi che non abbandona mai gli eventi senza fornire una notifica.
  
  
• Utilizza primitive di concorrenza che disaccoppiano le connessioni dalle sessioni.
  
  
• Supporta un'ampia gamma di linguaggi e framework (ZooKeeper ha il suo protocollo Jute RPC personalizzato che supporta associazioni linguistiche limitate).

Consul è una soluzione di rete di servizi per sistemi distribuiti, le cui funzionalità si collocano a metà strada tra quelle di etcd e ISTIO service mesh per Kubernetes. Come etcd, Consul include uno storage chiave-valore distribuito basato sull'algoritmo Raft e supporta le application programming interfaces (API) HTTP/JSON. Entrambi offrono una configurazione dinamica dell'appartenenza al cluster, ma Consul non controlla in modo così rigoroso più versioni simultanee dei dati di configurazione e la dimensione massima del database con cui funzionerà in modo affidabile è inferiore.

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

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

Ma etcd ha una tolleranza agli errori superiore, capacità di failover più efficaci e disponibilità continua dei dati e, cosa più importante, etcd persiste tutti i dati memorizzati su disco, sacrificando sostanzialmente la velocità in favore di una maggiore affidabilità e di una coerenza garantita. Per questi motivi, Redis è più adatto a fungere da sistema di caching a memoria distribuita che a memorizzare e distribuire informazioni di configurazione del sistema.