Saltar al contenido principal

Capítulo 2.3 - etcd

Objetivos de Aprendizaje​

Al final de este capítulo, usted será capaz de:

  • Comprender el rol de etcd en Kubernetes
  • Explicar cómo etcd almacena el estado del clúster
  • Comprender la replicación y la alta disponibilidad
  • Identificar las buenas prácticas de respaldo

¿Qué es etcd?​

etcd es una base de datos clave-valor distribuida, coherente y altamente disponible utilizada como fuente única de la verdad para Kubernetes. Toda la configuración y el estado del clúster se almacenan en etcd.

Rol en Kubernetes​

Fuente Única de la Verdad​

etcd almacena:

  • Todos los recursos (Pods, Services, Deployments, etc.)
  • Configuración del clúster
  • Estado actual de todos los recursos
  • Metadatos y anotaciones

Sin Acceso Directo​

Importante: Los usuarios y componentes NUNCA acceden directamente a etcd. Todas las interacciones pasan por el API Server.

Estructura de los Datos​

Formato Clave-Valor​

Los datos se organizan jerárquicamente:

/registry/pods/default/my-pod
/registry/services/default/my-service
/registry/deployments/default/my-deployment

Ejemplo de Datos Almacenados​

{
  "kind": "Pod",
  "apiVersion": "v1",
  "metadata": {
    "name": "my-pod",
    "namespace": "default",
    "uid": "123-456-789"
  },
  "spec": {
    "containers": [...]
  },
  "status": {
    "phase": "Running"
  }
}

Alta Disponibilidad​

Replicación​

Para producción, etcd debe ser replicado (generalmente 3 o 5 nodos):

Ventajas:

  • Tolerancia a fallos (puede fallar 1 nodo)
  • Rendimiento mejorado (lecturas distribuidas)
  • Coherencia garantizada

Consenso: Raft​

etcd utiliza el algoritmo de consenso Raft:

Características:

  • Un líder elegido
  • Replicación hacia los seguidores
  • Consenso por mayoría
  • Coherencia fuerte garantizada

Respaldo y Restauración​

Importancia Crítica​

⚠️ etcd contiene TODO el estado del clúster. ¡Su pérdida = pérdida del clúster!

Respaldo Regular​

# Respaldar etcd
ETCDCTL_API=3 etcdctl snapshot save /backup/etcd-snapshot.db \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key

# Restaurar desde un respaldo
ETCDCTL_API=3 etcdctl snapshot restore /backup/etcd-snapshot.db

Buenas Prácticas​

  • Respaldos automáticos diarios
  • Almacenamiento fuera del sitio
  • Pruebas regulares de restauración
  • Documentación del proceso

Rendimiento​

Factores que Impactan el Rendimiento​

  1. Tamaño del clúster: Más recursos = más datos
  2. Frecuencia de los cambios: Actualizaciones frecuentes
  3. Tamaño de los objetos: ConfigMaps/Secrets grandes
  4. Compaction: Limpieza de versiones antiguas

Optimizaciones​

  • Compaction regular de los datos
  • Desfragmentación del disco
  • SSD para mejor rendimiento
  • Monitoreo de métricas

Seguridad​

Cifrado​

  • En tránsito: TLS entre API Server y etcd
  • En reposo: Cifrado opcional de los datos

Acceso Restringido​

  • Solo el API Server accede a etcd
  • Certificados de cliente requeridos
  • Sin acceso de red público

Monitoreo​

Métricas Importantes​

  • Tamaño de la base de datos
  • Latencia de las operaciones
  • Tasa de errores
  • Estado del líder
  • Espacio de disco disponible

Comandos Útiles​

# Verificar el estado de etcd
kubectl get componentstatuses

# Ver métricas (si el monitoreo está configurado)
# Vía Prometheus u otras herramientas similares

Resumen​

En este capítulo, usted ha aprendido:

etcd: Base de datos distribuida, fuente única de la verdad
Almacenamiento: Todos los recursos y configuración del clúster
Alta Disponibilidad: Replicación con consenso Raft
Respaldo: Crítico para la continuidad del clúster
Seguridad: Acceso restringido, cifrado en tránsito

Próximos Pasos​

Ahora que usted comprende etcd:

Capítulo 2.4: Controller Manager - Mantenimiento del Estado Deseado
Capítulo 2.5: Scheduler - Planificación de Pods

Capítulo creado el: diciembre 2024