O etcd é um armazenamento de chave-valor distribuído em software livre usado para reter e gerenciar as informações críticas que sistemas distribuídos precisam para continuar em funcionamento. Mais importante, ele gerencia os dados de configuração, os dados do estado e os metadados do Kubernetes, a plataforma bastante conhecida de orquestração de contêineres.

Como todas as cargas de trabalho distribuídas, as cargas de trabalho conteinerizadas têm requisitos de gerenciamento que se tornam mais complexos à medida que a carga de trabalho aumenta. O Kubernetes simplifica o processo de gerenciar estas cargas de trabalho ao coordenar tarefas como configuração, implementação, descoberta de serviço, balanceamento de carga, planejamento de tarefas e monitoramento de funcionamento em todos os clusters, que podem ser executados em diversas máquinas e em múltiplos locais.

Mas para alcançar esse nível de coordenação, o Kubernetes precisa de um armazenamento de dados que forneça uma fonte única e consistente de informações sobre o status do sistema, ou seja, todos os seus clusters e pods, além das instâncias de aplicativos contidos nele a qualquer momento. O etcd é o armazenamento de dados usado para criar e manter esta versão confiável.

O etcd desempenha um papel semelhante para o Cloud Foundry  (link externo à ibm.com), a plataforma como serviço (PaaS) multicloud e de software livre que é uma opção viável para coordenar sistemas críticos e metadados em todos os clusters de qualquer aplicativo distribuído. O nome "etcd" surgiu de uma convenção de nomenclatura da estrutura de diretórios do Linux: no UNIX, todos os arquivos de configuração de sistema de um único sistema ficam armazenados em uma pasta chamada "/etc;" e o "d" refere-se a "distributed".

Assista ao vídeo "O que é etcd?" para uma análise mais aprofundada (6:09):

Não é uma tarefa fácil servir como a espinha dorsal dos dados que mantém uma carga de trabalho distribuída em execução. Mas o etcd foi criado com esse propósito, sendo projetado desde o início com as características a seguir:

• Totalmente replicado: cada nó em um cluster do etcd tem acesso completo ao armazenamento de dados.
  
  
• Altamente disponível: o etcd foi projetado para não ter um único ponto de falha e tolerar facilmente falhas de hardware e partições de rede.
  
  
• Consistentemente confiável: cada "leitura" de dados retorna a última "gravação" de dados em todos os clusters.
  
  
• Rápido: o etcd foi referenciado a 10.000 gravações por segundo.
  
  
• Seguro: o etcd oferece suporte à autenticação automática do certificado do cliente TLS (Transport Layer Security) e SSL (Secure Socket Layer) opcional. Como o etcd armazena dados de configuração essenciais e altamente confidenciais, os administradores devem implementar controles de acesso baseados em função na implementação e assegurar que os membros da equipe que interagem com o etcd sejam limitados ao nível de acesso de privilégio de mínimo para executar suas tarefas.
  
  
• Simples: qualquer aplicativo, desde aplicativos da web simples até mecanismos altamente complexos de orquestração de contêineres como Kubernetes, pode ler ou gravar dados no etcd usando ferramentas HTTP/JSON  padrão.

Observe que, como o desempenho do etcd é altamente dependente da velocidade do armazenamento em disco, é altamente recomendável usar SSDs em ambientes etcd. Para obter mais informações sobre este e outros requisitos de armazenamento do etcd, acesse "Usando o Fio para saber se o seu armazenamento é rápido o suficiente para o etcd."

O etcd foi desenvolvido com base no algoritmo de consenso Raft para assegurar consistência do armazenamento de dados entre todos os nós em um cluster, condição básica para um sistema distribuído tolerante a falhas.

O Raft alcança esta consistência por meio de um nó líder escolhido que gerencia a replicação para os demais nós do cluster, chamados de seguidores. O líder aceita as solicitações dos clientes e, em seguida, as encaminha para os nós seguidores. Após o líder verificar se a maioria dos nós seguidores armazenaram as novas solicitações como uma entrada de log, ele aplicará a entrada à sua máquina de estado local e retornará o resultado dessa execução, a "gravação", ao cliente. Se os seguidores travarem ou os pacotes de rede forem perdidos, o líder tentará novamente até que todos os seguidores tenham armazenado todas as entradas de log consistentemente.

Se um nó seguidor não receber uma mensagem do líder dentro de um intervalo de tempo especificado, será feita uma eleição para escolher um novo líder. O seguidor se declara um candidato e os demais seguidores votam nele ou em qualquer outro nó com base em sua disponibilidade. Após o novo líder ser eleito, ele começa a gerenciar a replicação e o processo se repete. Este processo permite que todos os nós do etcd mantenham cópias altamente disponíveis e consistentemente replicadas do armazenamento de dados.

O etcd é considerado um dos principais componentes do Kubernetes e atua como o armazenamento de valor-chave primário para a criação de um cluster de Kubernetes com bom desempenho e tolerante a falhas. O servidor API Kubernetes armazena dados do estado de cada cluster no etcd. O Kubernetes usa a função de "observação" do etcd para monitorar esses dados e se reconfigurar quando ocorrem alterações. A função "observação" armazena valores que representam o estado ideal e o real do cluster e pode iniciar uma resposta quando eles divergirem.

Para obter uma visão geral de alto nível de como o Kubernetes gerencia clusters, serviços e nós do trabalhador, assista ao vídeo "Conceitos básicos do Kubernetes":

O etcd foi criado pela mesma equipe responsável por projetar o CoreOS Container Linux, um sistema operacional decontêineresamplamente utilizado que pode ser executado e gerenciado de forma eficiente em grande escala. Eles originalmente construíram o etcd com base no Raft para coordenar simultaneamente diversas cópias do Container Linux para assegurar o tempo de atividade ininterrupto do aplicativo.

Em dezembro de 2018, a equipe doou o etcd para a Cloud Native Computing Foundation (CNCF), uma organização neutra sem fins lucrativos que mantém o código-fonte, os domínios, os serviços hospedados, a infraestrutura em cloud e outras propriedades do projeto como recursos de software livre para a comunidade de desenvolvimento de cloud baseado em contêineres. O CoreOS foi incorporado à Red Hat.

Outros bancos de dados foram desenvolvidos para gerenciar informações coordenadas entre clusters de aplicativos distribuídos. Os dois produtos mais comumente comparados ao etcd são o ZooKeeper e o Consul.

ZooKeeper

O ZooKeeper foi originalmente criado para coordenar dados de configuração e metadados em clusters do Apache Hadoop. (O Apache Hadoop (link externo à ibm.com) é um framework de software livre, ou coleção de aplicativos, para armazenar e processar grandes volumes de dados em clusters de hardware de commodity). O ZooKeeper é mais antigo que o etcd e as lições aprendidas ao trabalhar com o ZooKeeper influenciaram o design do etcd.

Como resultado, o etcd tem alguns recursos importantes que o ZooKeeper não tem. Por exemplo, diferentemente do ZooKeeper, o etcd pode fazer o seguinte:

• Permite a reconfiguração dinâmica da associação de cluster.
  
  
• Permanece estável durante a execução de operações de leitura/gravação sob altas cargas.
  
  
• Mantém um modelo de dados de controle de simultaneidade de diversas versões.
  
  
• Oferece monitoramento importante confiável que nunca descarta eventos sem antes enviar uma notificação.
  
  
• Usa primitivas de simultaneidade que desacoplam as conexões das sessões.
  
  
• Oferece suporte uma ampla variedade de linguagens e frameworks (o ZooKeeper tem seu próprio protocolo RPC Jute customizado que oferece suporte a vinculações de linguagem limitadas).

Consul

Consul é uma solução de serviços de rede para sistemas distribuídos, cujos recursos são semelhantes aos do etcd e da malha de serviços do Istio do Kubernetes. Como o etcd, a Consul (link externo à ibm.com) inclui um armazenamento de chave-valor distribuído com base no algoritmo Raft e é compatível com as interfaces de programação de aplicativos (APIs) HTTP/JSON. Ambos oferecem configuração de associação dinâmica de cluster, mas o Consul não faz um controle tão forte contra várias versões simultâneas de dados de configuração, e o tamanho máximo do banco de dados com o qual ele trabalhará de forma confiável é menor.

Como o etcd, o Redis é uma ferramenta de software livre, mas suas funcionalidades básicas são diferentes.

O Redis é um armazenamento de dados em memória e pode atuar como um banco de dados, cache ou broker de mensagens. O Redis é compatível com uma variedade mais ampla de tipos e estruturas de dados do que o etcd e tem desempenho mais rápido de leitura/gravação.

Mas o etcd tem tolerância a falhas superior, recursos mais robustos de failover e disponibilidade de dados contínua e, o mais importante, o etcd persiste todos os dados armazenados no disco, basicamente sacrificando a velocidade para proporcionar maior confiabilidade e consistência garantida. Por esses motivos, o uso do Redis é mais adequado como um sistema de armazenamento em cache de memória distribuída do que para armazenamento e para informações de configuração de sistemas distribuídos.