etcd es un almacén de valores clave distribuido de código abierto que se utiliza para almacenar y administrar la información crítica que los sistemas distribuidos necesitan para seguir funcionando. En concreto, administra 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 la carga de trabajo escala. Kubernetes simplifica el proceso de gestión de estas cargas de trabajo coordinando tareas como la configuración, la implementación, el descubrimiento de servicios, el equilibrio de carga, la programación de trabajos y la monitorización de la salud en todos los clústeres, que pueden ejecutarse en varias máquinas en varias ubicaciones.
Pero para lograr esta coordinación, Kubernetes necesita un almacenar que proporcione una fuente única y coherente de la verdad sobre el estado del sistema (todos sus clústeres y los pods y las instancias de aplicación dentro de ellos) en cualquier momento. etcd es el almacenar de datos utilizado para crear y mantener esta versión de la verdad.
etcd cumple una función similar para Cloud Foundry, la plataforma como servicio (PaaS) multinube de código abierto, y es una opción viable para coordinar sistemas y metadatos críticos en 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 "/etcd"; "d" significa "distribuido".
Manténgase al día sobre las tendencias más importantes e intrigantes del sector en materia de IA, automatización, datos y mucho más con el boletín Think. Consulte la Declaración de privacidad de IBM.
Servir como columna vertebral de datos que mantiene en funcionamiento una carga de trabajo distribuida no es tarea fácil. Pero etcd está diseñado para la tarea, diseñado desde cero para las siguientes cualidades:
Tenga en cuenta que, dado que el rendimiento de etcd depende en gran medida de la velocidad del disco de almacenamiento, se recomienda encarecidamente utilizar SSD en entornos de etcd.
etcd se basa en el algoritmo de consenso Raft para garantizar la coherencia de almacenar datos en todos los nodos de un clúster, lo que es fundamental para un sistema distribuido tolerante a fallos.
Raft logra esta coherencia a través de un nodo líder elegido que administra la replicación para los otros nodos del clúster, llamados seguidores. El líder acepta las solicitudes de los clientes, que luego reenvía a los nodos seguidores. Una vez que el líder se ha asegurado de que la mayoría de los nodos seguidores han almacenado cada nueva solicitud como una entrada de registro, aplica la entrada a su máquina de estado local y devuelve el resultado de esa ejecución, una 'escritura', al cliente. Si los seguidores se bloquean o se pierden los paquetes de red, el líder vuelve a intentarlo hasta que todos los seguidores hayan almacenado todas las entradas de registro de forma coherente.
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 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, comienza a gestionar la replicación y el proceso se repite. Este proceso permite a todos los nodos de etcd mantener copias del almacén de datos altamente disponibles y replicadas de forma coherente.
etcd se incluye entre los componentes principales de Kubernetes y sirve como almacén principal de claves y valores para crear un clúster Kubernetes funcional y tolerante a fallos. El servidor de API de Kubernetes almacena los datos de estado de cada clúster en etcd. Kubernetes utiliza la función “watch” de etcd para monitorizar estos datos y reconfigurarse cuando ocurren cambios. La función "vigilar" almacena valores que representan el estado real y el estado ideal de la agrupación 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 vídeo "Explicación de Kubernetes":
etcd fue creado por el mismo equipo responsable del diseño de CoreOS Linux, un sistema operativo de contenedores ampliamente utilizado que puede ejecutarse y gestionarse eficazmente a escala masiva. Originalmente se construyó etcd en Raft para coordinar varias copias de contenedor Linux simultáneamente, con el fin de garantizar un tiempo de actividad ininterrumpido de las aplicaciones.
En diciembre de 2018, el equipo donó etcd a la Fundación de Computación Nativa de la Nube (CNCF), una organización neutral sin ánimo 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 de nube basada en contenedores. CoreOS se ha fusionado con Red Hat.
Se han desarrollado otras bases de datos para gestionar la información de coordenadas entre clústeres de aplicaciones distribuidas. Los dos más comúnmente comparados con etcd son ZooKeeper y Consul.
ZooKeeper se creó originalmente para coordinar los datos de configuración y los metadatos entre los clusters Apache Hadoop. (Apache Hadoop es un marco, o colección de aplicaciones, de código abierto para almacenar y procesar grandes volúmenes de datos en clusters 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 capacidades importantes que ZooKeeper no tiene. Por ejemplo, a diferencia de ZooKeeper, etcd puede hacer lo siguiente:
Consul es una solución de red de servicios para sistemas distribuidos, cuyas capacidades se sitúan en algún lugar entre las de etcd y la malla de servicios de Istio para Kubernetes. Al igual que etcd, Consul incluye un almacén distribuido de valores clave basado en el algoritmo Raft y admite interfaces de programación de aplicaciones (API) HTTP/JSON. Ambos ofrecen una configuración dinámica de los miembros del clúster, pero Consul no controla tan fuertemente las múltiples versiones concurrentes de los datos de configuración, y el tamaño máximo de la base de datos con la que trabajará de forma fiable es menor.
Al igual que 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 agente de mensajes. Redis admite una variedad más amplia de tipos y estructuras de datos que etcd y tiene un rendimiento de lectura/escritura mucho más rápido.
Pero etcd tiene una tolerancia a fallos superior, mayores capacidades de conmutación por error y disponibilidad continua de datos y, lo que es más importante, etcd persiste todos los datos almacenados en disco, sacrificando esencialmente la velocidad a cambio de una mayor fiabilidad 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.
Cree y gestione canalizaciones de datos de streaming inteligentes a través de una interfaz gráfica intuitiva, y facilite una integración de datos fluida en entornos híbridos y multinube.
Watsonx.data le permite escalar la analítica y la IA con todos sus datos, residan donde residan, a través de un almacén de datos abierto, híbrido y gobernado.
Desbloquee el valor de los datos empresariales con IBM Consulting, y construya una organización impulsada por conocimientos que ofrezca ventajas empresariales.
