¿Qué es etcd?

Al igual que 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 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 del estado en todos los clústeres, que pueden ejecutarse en varias máquinas en varias ubicaciones.

Pero para lograr esta coordinación, Kubernetes necesita un almacén 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 la aplicación dentro de ellos, en un momento dado. etcd es el almacenar de datos empleado 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, 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 “/etc”; “d” significa “distribuido”.

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á diseñado para la tarea, diseñado desde cero para las siguientes cualidades:

• Totalmente replicado: cada nodo en un clúster etcd tiene acceso al almacén de datos completo.
  
  
• Alta disponibilidad: etcd está diseñado para no tener un único punto de falla y tolerar con gracia las fallas de hardware y las particiones de red.
  
  
• Consistente de manera confiable: cada 'lectura' de datos devuelve la última 'escritura' de datos en todos los clústeres.
  
  
• Rápido: etcd fue evaluado a 10 000 escrituras por segundo.
  
  
• Seguro: etcd admite la seguridad automática de la capa de transporte (TLS) y la autenticación opcional de certificado de cliente de capa de sockets seguros (SSL). Debido a que etcd almacena datos de configuración vitales y altamente confidenciales, los administradores deben implementar controles de acceso basados en roles dentro del despliegue y asegurarse de que los miembros del equipo que interactúan con etcd estén limitados al nivel de acceso menos privilegiado necesario para realizar su trabajo.
  
  
• Sencillo: Cualquier aplicación, desde simples apps sitio web hasta motores de orquestación de contenedores altamente complejos como Kubernetes, puede leer o escribir datos en etcd empleando herramientas HTTP/JSON estándar.

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 los almacenes de datos en todos los nodos de un cluster-table stakes para un sistema distribuido tolerante a fallos.

Raft logra esta coherencia a través de un nodo líder elegido que gestiona la replicación para los otros nodos del clúster, llamados seguidores. El líder acepta las peticiones de los clientes, que reenvía a los nodos seguidores. Una vez que el líder se cercioró de que la mayoría de los nodos seguidores almacenaron 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 paquetes de red, el líder vuelve a intentarlo hasta que todos los seguidores almacenaron 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 específico, 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 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 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 principal almacenar de valores clave para crear un clúster de Kubernetes en funcionamiento y tolerante a fallas. El servidor API de Kubernetes almacena los datos de estado de cada clúster en etcd. Kubernetes utiliza la función “watch” de etcd para monitorear estos datos y reconfigurarse cuando se producen cambios. La función “watch” almacena valores que representan el estado real e ideal del cluster y puede iniciar una respuesta cuando divergen.

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

etcd fue creado por el mismo equipo responsable de diseñar CoreOS Linux, un sistema operativo de contenedores ampliamente empleado que se puede ejecutar y gestionar de manera eficiente a gran escala. Originalmente construyeron etcd en Raft para coordinar múltiples copias de Linux en contenedores simultáneamente, para garantizar un tiempo de actividad ininterrumpido de las aplicaciones.

En diciembre de 2018, el equipo donó etcd a la 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 fusionó con Red Hat.

Se han desarrollado otras bases de datos para gestionar la información coordinada 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 en los clústeres de Apache Hadoop. (Apache Hadoop es un marco de código abierto, o colección de aplicaciones, para almacenar y procesar grandes volúmenes de datos en clústeres 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:

• Permiten la reconfiguración dinámica de los miembros del clúster.
  
  
• Permanezca estable mientras realiza operaciones de lectura/escritura bajo cargas elevadas.
  
  
• Mantener un modelo de datos de control de simultaneidad de varias versiones.
  
  
• Ofrezca una supervisión fiable de las teclas que nunca abandone eventos sin dar una notificación.
  
  
• Utilice primitivas de concurrencia que desacoplen las conexiones de las sesiones.
  
  
• Admitir una amplia gama de lenguajes y infraestructuras (ZooKeeper tiene su propio protocolo RPC de yute personalizado que admite enlaces de idioma limitados).

Consul es una solución de networking para sistemas distribuidos, cuyas capacidades se encuentran 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 de valores clave distribuido basado en el algoritmo Raft y admite interfaces de programación de aplicaciones (API) HTTP/JSON. Ambos ofrecen una configuración dinámica de membresía de clúster, pero Consul no controla tan fuertemente contra múltiples versiones simultáneas 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.

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, una conmutación por error más estable y capacidades de disponibilidad de datos continuas y, lo que es más importante, etcd conserva todos los datos almacenados en el disco, esencialmente sacrificando la velocidad por una mayor confiabilidad y consistencia garantizada. Por estos motivos, Redis es más adecuado para servir como un sistema de almacenamiento en caché de memoria distribuida que para almacenar información de configuración del sistema distribuido.