O que é o etcd?

Assim como todas as cargas de trabalho distribuídas, as cargas de trabalho conteinerizadas têm requisitos de gerenciamento complexos, que se tornam mais complexos à medida que a carga de trabalho escala. O Kubernetes simplifica o processo de gerenciamento dessas cargas de trabalho, ao coordenar tarefas como configuração, implementação, descoberta de serviços, balanceamento de carga, agendamento de trabalhos e monitoramento de integridade em todos os clusters, que podem ser executados em várias máquinas em vários locais.

Mas, para alcançar essa coordenação, o Kubernetes precisa de um armazenamento de dados que forneça uma fonte única e consistente da verdade sobre o status do sistema (todos os seus clusters e os pods e as instâncias de aplicações dentro deles) a qualquer momento. O etcd é o armazenamento de dados usado para criar e manter essa versão da verdade.

O etcd desempenha uma função semelhante para o Cloud Foundry(a plataforma como serviço (PaaS)de multinuvem de código aberto) e é uma opção viável para coordenar sistemas e metadados críticos em clusters de qualquer aplicação distribuída. O nome "etcd" vem de uma convenção de nomenclatura dentro da estrutura de diretórios do Linux: no UNIX, todos os arquivos de configuração do sistema para um único sistema estão contidos em uma pasta chamada "/etc;" "d" significa "distribuído".

Não é uma tarefa pequena servir como a espinha dorsal de dados que mantém uma carga de trabalho distribuída em execução. Mas o etcd foi desenvolvido para a tarefa, projetado desde o início para as seguintes qualidades:

• Totalmente replicado: todos os nós em um cluster do etcd têm acesso ao armazenamento de dados completo.
  
  
• 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 "gravação" mais recente de dados em todos os clusters.
  
  
• Rápido: o etcd foi comparado com 10.000 gravações por segundo.
  
  
• Seguro: o etcd é compatível com autenticação automática de certificado de cliente Transport Layer Security (TLS) e Secure Socket Layer (SSL) opcional. Como o etcd armazena dados de configuração vitais e altamente confidenciais, os administradores devem implementar controles de acesso baseados em funções dentro da implementação e garantir que os membros da equipe que interagem com o etcd sejam limitados ao nível de acesso menos privilegiado necessário para executar seus trabalhos.
  
  
• Simples: qualquer aplicação, desde aplicativos da web simples até mecanismos de orquestração de contêineres altamente complexos, como o Kubernetes, pode ler ou gravar dados no etcd usando ferramentas HTTP/JSON padrão.

Observe que, como o desempenho do etcd depende muito da velocidade do disco de armazenamento, é altamente recomendável usar SSDs em ambientes do etcd.

O etcd é construído com base no algoritmo de consenso Raft para garantir a consistência do armazenamento de dados em todos os nós em um cluster, algo essencial para um sistema distribuído tolerante a falhas.

O Raft alcança essa consistência por meio de um nó líder que gerencia a replicação para os outros nós no cluster, chamados de seguidores. O líder aceita solicitações dos clientes, que, então, encaminha para os nós seguidores. Depois que o líder verifica que a maioria dos nós seguidores armazenou cada nova solicitação como uma entrada de log, ele aplica a entrada à sua máquina de estado local e retorna o resultado dessa execução (uma “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 de forma consistente.

Se um nó seguidor não receber uma mensagem do líder dentro de um intervalo de tempo especificado, é realizada uma eleição para escolher um novo líder. O seguidor declara-se candidato, e os outros seguidores votam nele ou em qualquer outro nó com base em sua disponibilidade. Depois que o novo líder é eleito, começa a gerenciar a replicação, e o processo se repete. Esse processo permite que todos os nós do etcd mantenham cópias do armazenamento de dados altamente disponíveis e de forma consistente.

O etcd está incluído entre os principais componentes do Kubernetes e serve como o principal armazenamento de chaves-valores para criar um cluster do Kubernetes funcional e tolerante a falhas. O servidor de APIs do Kubernetes armazena os dados de estado de cada cluster no etcd. O Kubernetes usa a função "watch" do etcd para monitorar esses dados e se reconfigurar quando ocorrem alterações. A função "watch" armazena valores que representam o estado real e ideal do cluster e pode iniciar uma resposta quando eles divergirem.

Para ter uma visão geral de alto nível de como o Kubernetes gerencia clusters, serviços e nós de trabalho, confira nosso vídeo "Kubernetes explicado":

O etcd foi criado pela mesma equipe responsável por projetar o CoreOS Container Linux, um sistema operacional de contêineres amplamente usado, que pode ser executado e gerenciado de forma eficiente em escala maciça. Originalmente, eles criaram o etcd no Raft para coordenar várias cópias do Container Linux simultaneamente, para garantir o tempo de atividade ininterrupto das aplicações.

Em dezembro de 2018, a equipe doou o etcd para a Cloud Native Computing Foundation (CNCF), uma organização sem fins lucrativos neutra que mantém o código fonte, domínios, serviços hospedados, infraestrutura de nuvem e outras propriedades do projeto do etcd como recursos de código aberto para a comunidade de desenvolvimento de nuvem baseada em contêineres. CoreOS se fundiu com o Red Hat.

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

O ZooKeeper foi originalmente criado para coordenar dados e metadados de configuração nos clusters do Apache Hadoop. (O Apache Hadoop é uma framework de código aberto, ou coleção de aplicações, para armazenar e processar grandes volumes de dados em clusters de hardware comum.) O ZooKeeper é mais antigo que o etcd, e as lições aprendidas no trabalho com o ZooKeeper influenciaram o projeto do etcd.

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

• Permite a reconfiguração dinâmica dos membros do cluster.
  
  
• Permanece estável ao executar operações de leitura/gravação sob cargas elevadas.
  
  
• Mantém um modelo de dados de controle de concorrência de várias versões.
  
  
• Oferece monitoramento de chaves confiável que nunca descarta eventos sem emitir uma notificação.
  
  
• Usa primitivas de concorrência que separam conexões de sessões.
  
  
• É compatível com uma ampla variedade de linguagens e frameworks (o ZooKeeper tem seu próprio protocolo Jute RPC personalizado, compatível com ligações de linguagem limitadas).

O Consul é uma solução de rede de serviços para sistemas distribuídos, cujos recursos estão em algum lugar entre os do etcd e a malha de serviços do Istio para Kubernetes. Assim como o etcd, o Consul inclui um armazenamento de chaves-valores distribuído com base no algoritmo Raft e é compatível com interfaces de programação de aplicativos em HTTP/JSON. Ambos oferecem configuração dinâmica de associação ao 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.

Assim como o etcd, o Redis é uma ferramenta de código aberto, mas suas funcionalidades básicas são diferentes.

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

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