Skip to main content

¿Podría kubernetes usar ETCD en vez de REDIS?

ETCD es la base de datos que almacena el estado de kubernetes. Sabemos que es una base de datos de tipo clave-valor. Yo, antes de usar kubernetes, hice muchos proyectos con REDIS, y por tanto me he preguntado: ¿por qué usa k8s ETCD y no REDIS?

La respuesta es que técnicamente podría usar REDIS. Sin embargo se eligió ETCD porque está optimizada de manera distinta. Vamos allá:

  • Consistencia fuerte (CP en CAP, no AP)

ETCD es fuertemente consistente mientras que Redis puede ser inconsistente ante operaciones intensas de base de datos. ETCD usa el algoritmo RAFT de búsqueda de consenso que garantiza Lineriality, esto es, cada lectura confirma el último write confirmado mediante el quorum. Si no hay Quorum, ETCD rechaza las escrituras hasta poder formar el consenso. Esto es: prefiere tardar en escribir antes de liarla.

Redis en modo cluster usa replicación asíncrona. Esto quiere decir que si en algun momento el lider muere puede perder writes el cluster y cometer errores con el estado, por ejemplo puede considerar que un pod sigue corriendo cuando ya ha acabado etc.

Otra razón es el watch semántico nativo: etcd tiene un mecanismo de watch que notifica cambios en claves con semántica de eventos ordenados y sin huecos. El informer/watch loop del API server de Kubernetes está construido directamente sobre esto. Redis tiene WATCH/MULTI/EXE, más frágil.

etcd mantiene un historial de revisiones del store. Esto permite que un cliente que se reconecta diga “dame todos los cambios desde la revisión 4821” y reconstruya su estado sin hacer un full re-list. Fundamental para la eficiencia del watch loop del API server. Redis no tiene este concepto. Streams (XREAD) se aproximan, pero no es lo mismo que un KV store con historial versionado integrado

Bueno todo este rollazo se resume así: etcd sacrifica disponibilidad y throughput por correctitud. Redis es exactamente lo contrario, optimizado para latencia baja y alto throughput con consistencia eventual.

En kubernetes no te puedes permitir esa inconsistencia.