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

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

Sin embargo, para lograr esta coordinación, Kubernetes necesita un almacén de datos que proporcione un origen único y coherente de la verdad sobre el estado del sistema; todos sus clústeres y pods, y las instancias de aplicación que los componen, en cualquier punto en el tiempo. etcd es el almacén de datos utilizado para crear y mantener esta versión de la verdad.

etcd desempeña un rol similar para Cloud Foundry (enlace externo a ibm.com), la plataforma como servicio (PaaS) multicloud de código abierto, y es una opción viable para coordinar sistema cruciales y metadatos entre clústeres de cualquier aplicación distribuida. El nombre "etcd" proviene de un convenio de denominación dentro de la estructura de directorios de Linux: en UNIX, todos los archivos de configuración del sistema para un único sistema están contenidos en una carpeta llamada "/etc;" la "d" es de "distribuida".

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

No es tarea fácil servir como eje central de datos que mantiene en funcionamiento una carga de trabajo distribuida, pero etcd está hecho específicamente para esta tarea, diseñado desde cero para ofrecer las siguientes ventajas:

• Completamente replicado: cada nodo en un clúster de etcd tiene acceso al almacén de datos completo.
  
  
• Altamente disponible: etcd está diseñado para no tener ningún punto único de anomalía y tolerar correctamente errores de hardware y las particiones de red.
  
  
• Coherente y fiable: todas las "lecturas" de datos devuelven las últimas "escrituras" de datos en todos los clústeres.
  
  
• Rápido: etcd ha sido 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 sensibles, los administradores deben implementar controles de acceso basados en roles en el despliegue y garantizar que los miembros del equipo que interactúan con etcd estén limitados al nivel de acceso menos privilegiado 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 mediante 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, se recomienda encarecidamente el uso de SSD en entornos de etcd. Para obtener más información sobre 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 coherencia del almacén de datos en todos los nodos de un clúster, elementos esenciales para un sistema distribuido tolerante a errores.

Raft logra esta coherencia a través de un nodo líder elegido que gestiona la réplica para los demás nodos del clúster, llamados 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 se detienen o los paquetes de red se pierden, el líder vuelve a intentarlo hasta que todos los seguidores hayan almacenado todas las entradas de registro de manera coherente.

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

etcd se incluye entre los componentes principales de Kubernetes y sirve como almacén primario de clave-valor para crear un clúster de Kubernetes funcional y tolerante a errores. El servidor de la API de Kubernetes almacena datos de estado de cada clúster en etcd. Kubernetes utiliza la función de "observador" de etcd para supervisar estos datos y volver a configurarse cuando se producen cambios. La función "observador" almacena valores representativos del estado real e ideal del clúster y puede iniciar una respuesta cuando divergen.

Para obtener una visión general de alto nivel de cómo gestiona Kubernetes los clústeres, servicios y nodos de trabajador, vea nuestro vídeo "En qué consiste Kubernetes":

etcd fue creado por el mismo equipo responsable de diseñar CoreOS Container Linux, un sistema operativo de contenedores ampliamente utilizado que se puede ejecutar y gestionar de forma eficiente a gran escala. Originalmente crearon etcd en Raft para coordinar varias copias de Container Linux simultáneamente, para asegurar el funcionamiento ininterrumpido de la aplicación.

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

Se han desarrollado otras bases de datos para gestionar y coordinar información entre clústeres de aplicaciones distribuidas. Las dos que más se suelen comparar con etcd son ZooKeeper y Consul.

ZooKeeper

ZooKeeper se creó originalmente para coordinar datos de configuración y metadatos en clústeres Apache Hadoop (Apache Hadoop [enlace externo a ibm.com] es un marco de código abierto, o recopilación de aplicaciones, para almacenar y procesar grandes volúmenes de datos en clústeres de hardware genérico). ZooKeeper es más antiguo que etcd, y las conclusiones extraídas del uso de ZooKeeper influyeron en el diseño de etcd.

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

• Permitir la reconfiguración dinámica de pertenencia al clúster.
  
  
• Permanecer estable mientras se realizan operaciones de lectura/escritura bajo cargas altas.
  
  
• Mantener un modelo de datos de control de simultaneidad en múltiples versiones.
  
  
• Ofrecer supervisión clave fiable que nunca descarta sucesos sin dar una notificación.
  
  
• Utilizar primitivos de simultaneidad que desacoplan conexiones de sesiones.
  
  
• Admitir una amplia gama de lenguajes y marcos (ZooKeeper tiene su propio protocolo Jute RPC personalizado que admite vinculaciones de lenguajes limitadas).

Consul

Consul es una solución de redes de servicio para sistemas distribuidos que incluye prestaciones que se sitúan 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 programación de aplicaciones (API) HTTP/JSON. Ambas ofrecen configuración de pertenencia al clúster dinámica, pero Consul no tiene tanto control ante varias versiones simultáneas de datos de configuración, y el tamaño máximo de la base de datos con la que trabaja de forma fiable es menor.

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

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

Sin embargo, etcd tiene una tolerancia a errores superior, prestaciones más potentes de disponibilidad de datos continua y migración tras error y, lo que es más importante, etcd persiste todos los datos almacenados en disco, básicamente sacrificando velocidad por una mayor fiabilidad y coherencia garantizada. Por estas razones, Redis es más adecuado para funcionar como un sistema de almacenamiento en caché de memoria distribuida que para almacenar información de configuración de sistema distribuido.