Elasticsearch no es una base de datos transaccional. Es un buscador distribuido: los datos se dividen en shards, cada shard tiene réplicas, y el cluster necesita quórum para elegir al master.

Confundir esto con “un Postgres que busca” es el camino más rápido hacia un cluster rojo.

Sello del curso: probado en Kubernetes 1.35 con ECK y Elasticsearch 8.x.

Conceptos que importan

Concepto	Qué es
Índice	colección de documentos
Shard primario	parte del índice donde viven los datos
Réplica	copia del shard para HA y lectura
Node	proceso de Elasticsearch
Estado del cluster	metadatos y asignación de shards

Salud:

• green: todos los shards primarios y réplicas asignados.
• yellow: primarios ok, réplicas no asignadas (común en nodo único).
• red: algún primario no asignado — hay datos no disponibles.

ECK: el operador

apiVersion: elasticsearch.k8s.elastic.co/v1
kind: Elasticsearch
metadata:
  name: portal-es
spec:
  version: 8.19.0
  nodeSets:
    - name: default
      count: 3
      config:
        node.store.allow_mmap: false
      podTemplate:
        spec:
          affinity:
            podAntiAffinity:
              requiredDuringSchedulingIgnoredDuringExecution:
                - labelSelector:
                    matchLabels:
                      elasticsearch.k8s.elastic.co/cluster-name: portal-es
                  topologyKey: kubernetes.io/hostname
          containers:
            - name: elasticsearch
              resources:
                requests:
                  memory: 1Gi
                  cpu: 250m
                limits:
                  memory: 1Gi
                  cpu: "1"
      volumeClaimTemplates:
        - metadata:
            name: elasticsearch-data
          spec:
            accessModes: ["ReadWriteOnce"]
            resources:
              requests:
                storage: 10Gi

El ECK crea StatefulSet, Services, secrets y configuración. Servicios típicos:

• portal-es-es-http (9200).
• portal-es-es-transport (9300, headless).
• portal-es-es-internal-http.

Heap y memoria

Regla práctica: heap = 50% de la memoria del contenedor, con tope de ~31 GB (compressed oops). El resto es caché del sistema de archivos.

Si el contenedor tiene 1 GiB, deje -Xms512m -Xmx512m. Heap demasiado grande en contenedor pequeño = OOMKilled.

Monitoree:

• elasticsearch_jvm_memory_used_bytes
• elasticsearch_cluster_health_status
• elasticsearch_indices_search_query_time_seconds
• elasticsearch_indices_indexing_index_time_seconds

Shards: ni pocos, ni demasiados

• Shards demasiado pequeños: overhead de metadatos.
• Shards demasiado grandes: recuperación lenta.
• Réplicas consumen espacio y CPU.

Para un índice de pocos GB, 1–3 shards primarios bastan. No copie “5 shards, 1 réplica” de un tutorial antiguo sin pensar.

Snapshots y restore

Snapshot es el backup de Elasticsearch. Configure un repositorio S3/MinIO:

curl -X PUT "localhost:9200/_snapshot/portal-backup" -H 'Content-Type: application/json' -d '{
  "type": "s3",
  "settings": {
    "bucket": "portal-k8s-backup",
    "endpoint": "http://minio-s3:9000",
    "path_style_access": true
  }
}'

Snapshot manual:

curl -X PUT "localhost:9200/_snapshot/portal-backup/snap-2026-10-30?wait_for_completion=true"

Restore para un índice nuevo:

curl -X POST "localhost:9200/_snapshot/portal-backup/snap-2026-10-30/_restore" \
  -H 'Content-Type: application/json' -d '{
    "indices": "portal-tickets",
    "rename_pattern": "(.+)",
    "rename_replacement": "restored-$1"
  }'

Los snapshots deben programarse (SLM) y probarse.

ILM: ciclo de vida

Los índices crecen. Use ILM para:

• hot → warm → cold → delete.
• rollover por tamaño/edad.
• force merge y shrink.

Sin ILM, el disco se llena y el cluster se pone rojo.

Laboratorio

1. Inspeccione el cluster:

kubectl -n portal get elasticsearch
kubectl -n portal get pods -l elasticsearch.k8s.elastic.co/cluster-name=portal-es
kubectl -n portal get pvc | grep elasticsearch

2. Salud y shards:

kubectl get --raw "/api/v1/namespaces/portal/services/portal-es-es-http:9200/proxy/_cluster/health?pretty"
kubectl get --raw "/api/v1/namespaces/portal/services/portal-es-es-http:9200/proxy/_cat/shards?v"

3. Snapshot y restore en un índice nuevo.

4. Simule la pérdida de un pod y siga la reasignación de los shards.

Errores comunes

Síntoma	Causa
yellow	réplicas no asignadas (nodo único)
red	primario no asignado; datos no disponibles
disco lleno	watermark / sin ILM
OOMKilled	heap demasiado grande en el contenedor
split brain	quórum perdido (masters insuficientes)
snapshot falla	credenciales/endpoint/bucket
búsqueda lenta	shards grandes, heap pequeño, query mala

Checklist

• [ ] 3 nodos con anti-affinity y PVCs.
• [ ] Heap dimensionado (50% de la RAM, tope 31 GB).
• [ ] Salud monitoreada (green/yellow/red).
• [ ] ILM configurado.
• [ ] Snapshot repository + SLM.
• [ ] Restore probado en un índice nuevo.
• [ ] Alertas de disco y JVM.

Glosario

• shard: división del índice.
• réplica: copia del shard.
• watermark: límite de disco que bloquea la escritura.
• ILM: index lifecycle management.
• SLM: snapshot lifecycle management.
• split brain: cluster con más de un master.

Próximo

Ahora vamos a cerrar la Temporada 2 con backup y restore de verdad: Velero, etcd y el drill que prueba que el backup funciona.

Próximo: Curso Kubernetes 19 — Backup y restore: Velero, etcd y drill