etcd es un almacén de clave-valor distribuido de código abierto que se utiliza para almacenar y gestionar la información fundamental que los sistemas distribuidos necesitan para seguir funcionando. En particular, gestiona los datos de configuración, los datos de estado y los metadatos de Kubernetes, la popular plataforma de orquestación de contenedores.

Como todas las cargas de trabajo distribuidas, las cargas de trabajo en contenedores tienen requisitos de gestión complejos que se vuelven más complejos a medida que aumenta la carga de trabajo. Kubernetes simplifica el proceso de gestión de estas cargas de trabajo mediante la coordinación de tareas como la configuración, la implementación, el descubrimiento de servicios, el equilibrio de carga, la programación de trabajos y la supervisión del estado en todos los clústeres, que pueden ejecutarse en varias máquinas en varias ubicaciones.

Sin embargo, para lograr esta coordinación, Kubernetes necesita un almacén de datos que proporcione una fuente única y consistente de la verdad sobre el estado del sistema, todos sus clústeres y pods y las instancias de aplicación dentro de ellos, en cualquier punto en el tiempo. etcd es el almacén de datos que se utiliza para crear y mantener esta versión de la verdad.

etcd cumple una función similar a Cloud Foundry (enlace externo a ibm.com), la Plataforma como servicio (PaaS) multinube y de código abierto, y es una opción viable para coordinar sistemas críticos y metadatos entre clústeres de cualquier aplicación distribuida. El nombre "etcd" proviene de una convención de nomenclatura dentro de la estructura de directorios de Linux: en UNIX, todos los archivos de configuración del sistema para un solo sistema están contenidos en una carpeta llamada "/etc". La "d" significa "distribuido".

Vea el video "¿Qué es etcd?" para obtener información más detallada (6:09):

No es una tarea fácil servir como la columna vertebral de datos que mantiene en funcionamiento una carga de trabajo distribuida, pero etcd está hecho para eso, diseñado desde cero para las siguientes cualidades:

• Totalmente replicado: todos los nodos de un clúster de etcd tienen acceso al almacén de datos completo.
  
  
• Altamente disponible: etcd está diseñado para no tener un solo punto de falla y tolerar fácilmente fallas de hardware y particiones de red.
  
  
• Consistente y confiable: cada "lectura" de datos devuelve la última "escritura" de datos en todos los clústeres.
  
  
• Rápido: etcd se ha evaluado a 10,000 escrituras por segundo.
  
  
• Seguro: etcd admite TLS (Transport Layer Security) automático y autenticación de certificado de cliente SSL (Secure Socket Layer) opcional. Debido a que etcd almacena datos de configuración vitales y altamente confidenciales, los administradores deben implementar controles de acceso basados en roles dentro de la implementación y garantizar que los miembros del equipo que interactúan con etcd estén limitados al nivel de acceso con menos privilegios necesario para realizar sus trabajos.
  
  
• Simple: cualquier aplicación, desde aplicaciones web simples hasta motores de orquestación de contenedores altamente complejos, como Kubernetes, puede leer o escribir datos en etcd usando herramientas HTTP/JSON estándar.

Tenga en cuenta que, debido a que el rendimiento de etcd depende en gran medida de la velocidad del disco de almacenamiento, es muy recomendable utilizar SSD en entornos de etcd. Para obtener más información acerca de este y otros requisitos de almacenamiento de etcd, consulte "Using Fio to Tell Whether Your Storage is Fast Enough for etcd."

etcd se basa en el algoritmo de consenso Raft para garantizar la consistencia del almacenamiento de datos en todos los nodos de un clúster: lo que está en juego para un sistema distribuido tolerante a fallas.

Raft logra esta consistencia a través de un nodo electo como líder, que gestiona la réplica de los demás nodos del clúster, denominados seguidores. El líder acepta solicitudes de los clientes, que luego reenvía a los nodos seguidores. Una vez que el líder ha comprobado que una mayoría de los nodos seguidores ha almacenado cada nueva solicitud como una entrada de registro, aplica la entrada a su máquina de estados local y devuelve el resultado de esa ejecución (una "escritura") al cliente. Si los seguidores fallan o se pierden los paquetes de red, el líder vuelve a intentarlo hasta que todos los seguidores hayan almacenado todas las entradas del registro de forma consistente.

Si un nodo seguidor no recibe un mensaje del líder dentro de un intervalo de tiempo especificado, se lleva a cabo una elección para elegir un nuevo líder. El seguidor se declara un candidato y los demás seguidores votan por él o cualquier otro nodo en función de su disponibilidad. Una vez que se elige al nuevo líder, comienza a gestionar la réplica y el proceso se repite. Este proceso permite que todos los nodos de etcd mantengan copias del almacén de datos altamente disponibles y replicadas constantemente.

etcd se incluye entre los componentes principales de Kubernetes y sirve como el almacén de clave-valor principal para crear un clúster de Kubernetes funcional y tolerante a fallas. El servidor de la API de Kubernetes almacena los datos de estado de cada clúster en etcd. Kubernetes usa la función de "observador" de etcd para supervisar estos datos y reconfigurarse cuando ocurren cambios. La función "observador" almacena valores que representan el estado real e ideal del grupo y puede iniciar una respuesta cuando divergen.

Para obtener una visión general de alto nivel de cómo Kubernetes gestiona los clústeres, los servicios y los nodos de trabajo, consulte nuestro video "Explicación de Kubernetes":

etcd fue creado por el mismo equipo responsable del diseño de CoreOS Container Linux, un sistema operativo de contenedores que se puede ejecutar y gestionar de manera eficiente a gran escala. Originalmente crearon etcd en Raft para coordinar múltiples copias de Container Linux simultáneamente, para garantizar un tiempo de actividad ininterrumpido de la aplicación.

En diciembre de 2018, el equipo donó etcd a Cloud Native Computing Foundation (CNCF), una organización neutral sin fines de lucro que mantiene el código fuente, los dominios, los servicios alojados, la infraestructura en la nube y otras propiedades del proyecto de etcd como recursos de código abierto para la comunidad de desarrollo en la nube basada en contenedores. CoreOS se ha fusionado con Red Hat.

Se han desarrollado otras bases de datos para gestionar la información coordinada entre grupos de aplicaciones distribuidas. Las dos más comúnmente comparadas con etcd son ZooKeeper y Consul.

ZooKeeper

ZooKeeper se creó originalmente para coordinar los datos de configuración y los metadatos en los clústeres de Apache Hadoop. (Apache Hadoop (enlace externo a ibm.com) es una estructura de código abierto, o colección de aplicaciones, para almacenar y procesar grandes volúmenes de datos en grupos de hardware básico). ZooKeeper es más antiguo que etcd, y las lecciones aprendidas al trabajar con ZooKeeper influyeron en el diseño de etcd.

Como resultado, etcd tiene algunas funcionalidades importantes que ZooKeeper no tiene. Por ejemplo, a diferencia de ZooKeeper, etcd puede hacer lo siguiente:

• Permitir la reconfiguración dinámica de la membresía del clúster.
  
  
• Permanecer estable mientras realiza operaciones de lectura/escritura bajo cargas elevadas.
  
  
• Mantener un modelo de datos de control de simultaneidad de múltiples versiones.
  
  
• Ofrecer supervisión de claves confiable que nunca descarte eventos sin dar una notificación.
  
  
• Utilizar primitivas de simultaneidad que desacoplan las conexiones de las sesiones.
  
  
• Admitir una amplia variedad de lenguajes y estructuras (ZooKeeper tiene su propio protocolo RPC Jute personalizado que admite enlaces de lenguajes limitados).

Consul

Consul es una solución de redes de servicio para sistemas distribuidos, cuyas funcionalidades se encuentran en algún lugar entre las de etcd y la malla de servicio de Istio para Kubernetes. Al igual que etcd, Consul (enlace externo de ibm.com) incluye un almacén de clave-valor distribuido basado en el algoritmo Raft y admite interfaces de programación de aplicaciones (API) HTTP/JSON. Ambos ofrecen una configuración de membresía de clúster dinámica, pero Consul no realiza un control tan fuerte contra múltiples versiones concurrentes de datos de configuración, y el tamaño máximo de la base de datos con el que funcionará de manera confiable es menor.

Como etcd, Redis es una herramienta de código abierto, pero sus funcionalidades básicas son diferentes.

Redis es un almacén de datos en memoria y puede funcionar como base de datos, caché o message broker. Redis admite una variedad más amplia de tipos de datos y estructuras que etcd y tiene un rendimiento de lectura/escritura mucho más rápido.

Pero etcd tiene una tolerancia a fallas superior, una conmutación por error más sólida y funcionalidades de disponibilidad continua de datos y, lo que es más importante, etcd conserva todos los datos almacenados en el disco, sacrificando velocidad por una mayor confiabilidad y consistencia garantizada. Por estas razones, Redis es más adecuado para servir como un sistema de almacenamiento en caché de memoria distribuida que para almacenar y distribuir información de configuración del sistema.