Elastic Cloud on Kubernetes, simplificado: reconhecimento de zona, reinicializações e mTLS

O ECK 3.4 torna o Elastic Stack no Kubernetes mais simples de operar. O HA com reconhecimento de zonas, as reinicializações contínuas seguras e o mTLS do Kibana↔Elasticsearch passam a ser configurações de uma única linha no manifesto.

Se você opera Elastic Cloud no Kubernetes (ECK), esta versão tem como objetivo reduzir o atrito nas tarefas que você realiza diariamente.

Mais fácil de operar, mais fácil de entender

O ECK 3.4 é uma versão focada em reduzir a complexidade do que você precisa considerar ao executar o Elastic Stack no Kubernetes. Cada uma das principais mudanças pega uma tarefa com várias etapas e a transforma em uma única configuração declarativa:

• Reconhecimento simplificado de zonas. Informar ao ECK que um cluster deve ser distribuído pelas zonas de disponibilidade agora é um único campo no NodeSet. O operador gerencia a topologia, o agendamento e a configuração de reconhecimento do lado do Elasticsearch em seu nome. Seus manifestos refletem a intenção da configuração, e não como ela foi implementada.
• Reinicie um cluster do mesmo jeito que faz todo o resto. Disparar um reinício contínuo agora é uma anotação no recurso Elasticsearch. É declarativo, se encaixa no GitOps e deixa um rastro de auditoria. Nada de forçar a edição de um campo não relacionado para iniciar uma implantação.
• O mTLS é configurado automaticamente pelo operador. A conexão manual de TLS mútuo entre o Kibana e o Elasticsearch exige o gerenciamento manual de CAs, certificados de cliente por componente, montagens, rotação e configurações em ambas as extremidades. O ECK 3.4 cuida de tudo isso: ative um sinalizador no Elasticsearch, aponte o Kibana para ele e o operador gerencia o restante.

Esta versão tem o objetivo de tornar as operações diárias do ECK monótonas, no melhor sentido: menos campos para lembrar, menos etapas secundárias para manter a sincronia e manifestos mais simples de entender.

Reconhecimento simplificado de zonas

Torne um cluster Elasticsearch altamente disponível entre as zonas de disponibilidade definindo um campo no NodeSet. O ECK 3.4 cuida da dispersão da topologia, do escalonamento dos pods e da configuração de reconhecimento do lado do Elasticsearch para você.

Antes, era necessário conectar tudo isso manualmente a quatro objetos separados: uma anotação no recurso Elasticsearch para rótulos de Node descendentes, atributos de reconhecimento na configuração do NodeSet, uma variável fieldRef .env no modelo do pod para revelar a zona e um bloco topologySpreadConstraints correspondente mais uma regra nodeAffinity fixando o cluster em zonas específicas. Aproximadamente quarenta linhas de YAML, fáceis de configurar incorretamente.

No ECK 3.4, o mesmo cluster com reconhecimento de zonas ocupa quatro linhas:

Para fixar um conjunto específico de zonas, nomeie-as, e o ECK adicionará as regras de afinidade de Node correspondentes necessárias:

Se você precisar personalizar maxSkew ou whenUnsatisfiable, fornecer uma restrição de dispersão de topologia correspondente com o mesmo topologyKey em podTemplate ainda será a melhor opção. Sua substituição personalizada continua sendo aplicada.

Uma observação para atualizações: ativar zoneAwareness em um NodeSet existente altera o modelo do pod StatefulSet (novas restrições de espalhamento de topologia, variável de ambiente ZONE, afinidade de nó, node.attr.zone), o que desencadeia uma reinicialização contínua única do NodeSet afetado. Planeje adequadamente.

Para saber mais sobre gestão simplificada de zonas, você pode ler esta página no Elastic Docs.

Reinicializações contínuas declarativas

Reiniciar um cluster do Elasticsearch sem alterar sua especificação agora é um fluxo de trabalho de primeira classe na versão 3.4. Duas novas anotações no recurso Elasticsearch fazem o trabalho:

• eck.k8s.elastic.co/restart-trigger: defina ou altere esse valor (um carimbo de tempo é a escolha convencional) para iniciar um reinício contínuo. Mudar o valor aciona outro reinício depois; remover a anotação não o faz.
• eck.k8s.elastic.co/restart-allocation-delay: string de duração opcional (por exemplo, "20m") passado para a API de desligamento de Node do Elasticsearch como o atraso de alocação durante a reinicialização, para que você possa adiar o rebalanceamento enquanto um pod é recriado.

Por baixo, o ECK propaga o valor do gatilho para anotações de pod, o que altera o hash do template StatefulSet e alimenta cada pod pelo caminho existente de atualização contínua (API de desligamento de Node, predicados, exclusão um pod por vez). Não há um novo mecanismo de reinício para aprender, e as mensagens de status e a observabilidade que você já tem nas atualizações contínuas continuam sendo mantidas.

Para usuários do GitOps, isso significa que um pipeline Flux/ArgoCD pode solicitar uma reinicialização corrigindo uma anotação: sem desvio de especificação, sem ruído no diff, sem edição forçada em um campo não relacionado.

mTLS gerenciado para Kibana ↔ Elasticsearch

A orquestração mútua de TLS entre Kibana e Elasticsearch chega com esse lançamento. O CRD Elasticsearch aceita um único campo novo, spec.http.tls.client.authentication: true, que orienta o cluster a exigir certificados de cliente em sua interface HTTPS. O ECK faz o restante: cria uma cadeia de confiança a partir de qualquer segredo rotulado eck.k8s.elastic.co/client-certificate: true, monta o pacote nos pods do Elasticsearch, define xpack.security.http.ssl.client_authentication: required, e emite um certificado cliente do lado do operador para que ele possa continuar se comunicando com o cluster durante toda a implantação.

Isso torna habilitar e configurar mTLS para a pilha (somente Elasticsearch e Kibana, nesta versão) uma tarefa muito mais simples.

Habilitando o mTLS no Elasticsearch:

No lado do cliente, o controlador de associação do Kibana agora detecta a anotação client-authentication-required no Elasticsearch referenciado e gera automaticamente um certificado de cliente para o Kibana — sem necessidade de configuração extra. Se quiser usar seu próprio certificado (cert-manager, um PKI interno), aponte para o segredo que você já providenciou:

O ECK faz a rotação do certificado, monta o segredo no pod do Kibana e configura elasticsearch.ssl.certificate e elasticsearch.ssl.key. A limpeza dos recursos mTLS é adiada até que todos os pods tenham concluído a atualização contínua, então a conectividade se mantém durante toda a transição.

O Kibana é o primeiro componente do Stack a receber esse tratamento de primeira classe na versão 3.4. O suporte para APM Server, Beats, Fleet Server, Elastic Agent, Logstash, Maps e Enterprise Search chegará em breve. Entretanto, uma nova receita orienta o usuário no processo de configuração manual do mTLS para esses componentes usando o cert-manager.

Outras melhorias notáveis

Esta versão inclui outros aprimoramentos que merecem destaque. Aqui está uma lista com os pull requests relacionados.

• Go FIPS 140-3 nativo no operador habilitado para FIPS (imagem separada). A imagem ECK com FIPS (docker.elastic.co/eck/eck-operator-fips:3.4.0, além de uma variante UBI eck-operator-ubi-fips:3.4.0) agora inclui suporte nativo ao Go FIPS 140-3, fixada no módulo GOFIPS140=v1.0.0 certificado e aplicada em tempo de execução. A imagem padrão eck-operator não foi alterada. Para o Elasticsearch 9.4.0 ou posterior, o operador também gera e monta automaticamente uma senha de keystore compatível com FIPS quando xpack.security.fips_mode.enabled: true é definido (#9263, #9287).
• Correções de confiabilidade que valem a pena mencionar:
  • Agora, as CAs obsoletas na cadeia de certificados são detectadas e acionam a reemissão (#9197).
  • As falhas na geração de segredos de CA remoto não bloqueiam o processo (#9271).
  • O rótulo do seletor de namespace do NetworkPolicy foi corrigido para configurações de multilocação flexível (#9153).
  • O controlador Elasticsearch pula seu PVC padrão se já existir um volume com o mesmo nome (#9199).
  • O reconciliador do DaemonSet lida com o cache obsoleto da mesma forma que o reconciliador da implantação (#9256).

Para começar

Se você já estiver usando o ECK, atualize para a versão 3.4.0. com o Helm:

Ou aplique diretamente o manifesto mais recente do operador:

Se você é novo no ECK, comece com o guia de início rápido para obter um cluster do Elasticsearch em execução no Kubernetes em minutos.

Para ver a lista completa de mudanças, consulte as notas de lançamento do ECK 3.4.0 no GitHub.

Para começar a usar o Elastic Cloud hoje, faça login no console do Elastic Cloud ou inscreva-se para uma avaliação gratuita.

Perguntas frequentes

Como faço para tornar um cluster Elasticsearch ciente de zonas no ECK sem escrever restrições de dispersão de topologia?

Defina spec.nodeSets[].zoneAwareness: {} no recurso Elasticsearch. ECK deriva a topologia, associa node.attr.zone, estabelece maxSkew=1 restrições de espalhamento topológico e injeta os rótulos descendentes para você. Forneça zones: [...] se você quiser fixar em um conjunto específico de zonas de disponibilidade. Ativar isso em um NodeSet existente desencadeia uma reinicialização contínua única.

Posso acionar uma reinicialização contínua de um cluster Elasticsearch no Kubernetes sem editar a especificação?

Sim. O ECK 3.4 introduz duas anotações no recurso Elasticsearch: eck.k8s.elastic.co/restart-trigger (definir ou alterar o valor, por exemplo, um carimbo de data, para iniciar um reinício contínuo) e eck.k8s.elastic.co/restart-allocation-delay (string opcional de duração passada para a API de desligamento do Node Elasticsearch). Remover a anotação do gatilho não inicia um novo reinício.

Como habilitar o TLS mútuo entre Kibana e Elasticsearch no Kubernetes?

Com ECK 3.4, defina spec.http.tls.client.authentication: true no CRD Elasticsearch e faça referência a partir de Kibana via elasticsearchRef. O ECK gera automaticamente um certificado de cliente para o Kibana, constrói uma cadeia de confiança a partir de qualquer segredo rotulado eck.k8s.elastic.co/client-certificate: true, e configura xpack.security.http.ssl.client_authentication: required para você. mTLS para Kibana ↔ Elasticsearch é uma prévia técnica em 3.4.

O suporte ao ECK 3.4 mTLS cobre todos os componentes do Stack, como Beats e Fleet?

Ainda não. O Kibana é o primeiro componente da Stack a receber suporte de primeira classe a mTLS na versão 3.4 — o operador gera automaticamente seu certificado de cliente. O suporte para APM Server, Beats, Fleet Server, Elastic Agent, Logstash, Maps e Enterprise Search chegará na próxima versão. Uma nova receita explica o mTLS manual para esses componentes usando o cert-manager enquanto isso.

O ECK é compatível com FIPS 140-3?

Sim, em uma imagem de operador separada. O ECK 3.4 publica uma versão FIPS (docker.elastic.co/eck/eck-operator-fips:3.4.0, além de uma variante UBI) com suporte nativo ao Go FIPS 140-3. A imagem padrão eck-operator não foi alterada. Para o Elasticsearch 9.4.0 ou posterior, o ECK também gera e monta automaticamente uma senha de keystore compatível com FIPS quando xpack.security.fips_mode.enabled: true é definida.