Curso Kubernetes 18 — Elasticsearch/ECK na prática

Elasticsearch não é um banco transacional. É um buscador distribuído: os dados são divididos em shards, cada shard tem réplicas, e o cluster precisa de quórum para eleger o master.

Confundir isso com “um Postgres que busca” é o caminho mais rápido para um cluster vermelho.

Selo do curso: testado em Kubernetes 1.35 com ECK e Elasticsearch 8.x.

Conceitos que importam

Conceito	O que é
Índice	coleção de documentos
Shard primário	pedaço do índice onde os dados vivem
Réplica	cópia do shard para HA e leitura
Node	processo do Elasticsearch
Cluster state	metadados e alocação de shards

Saúde:

• green: todos os shards primários e réplicas alocados.
• yellow: primários ok, réplicas não alocadas (comum em nó único).
• red: algum primário não alocado — há dados indisponíveis.

ECK: o 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

O ECK cria StatefulSet, Services, secrets e configuração. Serviços típicos:

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

Heap e memória

Regra prática: heap = 50% da memória do container, com teto de ~31 GB (compressed oops). O resto é cache do sistema de arquivos.

Se o container tem 1 GiB, deixe -Xms512m -Xmx512m. Heap grande demais em container pequeno = OOMKilled.

Monitore:

• elasticsearch_jvm_memory_used_bytes
• elasticsearch_cluster_health_status
• elasticsearch_indices_search_query_time_seconds
• elasticsearch_indices_indexing_index_time_seconds

Shards: nem pouco, nem demais

• Shards pequenos demais: overhead de metadata.
• Shards grandes demais: recuperação lenta.
• Réplicas consomem espaço e CPU.

Para um índice de poucos GB, 1–3 shards primários bastam. Não copie “5 shards, 1 réplica” de tutorial antigo sem pensar.

Snapshots e restore

Snapshot é o backup do Elasticsearch. Configure um repositório 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 um índice novo:

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"
  }'

Snapshots devem ser agendados (SLM) e testados.

ILM: ciclo de vida

Índices crescem. Use ILM para:

• hot → warm → cold → delete.
• rollover por tamanho/idade.
• force merge e shrink.

Sem ILM, o disco enche e o cluster fica vermelho.

Laboratório

1. Inspecione o 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. Saúde e 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 e restore em índice novo.

4. Simule a perda de um pod e acompanhe a realocação dos shards.

Erros comuns

Sintoma	Causa
yellow	réplicas não alocadas (nó único)
red	primário não alocado; dados indisponíveis
disco cheio	watermark / sem ILM
OOMKilled	heap grande demais no container
split brain	quórum perdido (masters insuficientes)
snapshot falha	credenciais/endpoint/bucket
busca lenta	shards grandes, heap pequeno, query ruim

Checklist

• [ ] 3 nós com anti-affinity e PVCs.
• [ ] Heap dimensionado (50% da RAM, teto 31 GB).
• [ ] Saúde monitorada (green/yellow/red).
• [ ] ILM configurado.
• [ ] Snapshot repository + SLM.
• [ ] Restore testado em índice novo.
• [ ] Alertas de disco e JVM.

Glossário

• shard: divisão do índice.
• réplica: cópia do shard.
• watermark: limite de disco que bloqueia escrita.
• ILM: index lifecycle management.
• SLM: snapshot lifecycle management.
• split brain: cluster com mais de um master.

Próximo

Agora vamos fechar a Temporada 2 com backup e restore de verdade: Velero, etcd e o drill que prova que o backup funciona.

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