Elastic Cloud en Kubernetes, simplificado: conciencia de zona, reinicios y MTL

ECK 3.4 hace que el Elastic Stack en Kubernetes sea más fácil de operar. La alta disponibilidad con reconocimiento de zonas, los reinicios progresivos seguros y el mTLS entre Kibana y Elasticsearch se configuran con una sola línea en tu manifiesto.

Si operas Elastic Cloud en Kubernetes (ECK), este lanzamiento trata de reducir la fricción en las cosas que haces todos los días.

Más fácil de operar, más fácil de entender

ECK 3.4 es una versión centrada en reducir las cosas en las que tienes que pensar cuando ejecutas The Elastic Stack en Kubernetes. Cada cambio de titular toma una tarea de varios pasos y la convierte en una única respuesta declarativa:

• Conciencia simplificada de zonas. Decirle a ECK que un clúster debe estar distribuido entre zonas de disponibilidad ahora equivale a un solo campo en el NodeSet. El operador se encarga de la topología, la programación y la configuración de la integración con Elasticsearch por ti. Tus manifiestos reflejan lo que quieres decir, no cómo se conecta.
• Reinicia un clúster igual que haces con todo lo demás. Ahora, la activación de un reinicio progresivo se indica mediante una anotación en el recurso de Elasticsearch Es declarativo, encaja con GitOps y deja un rastro de auditoría. No hay que forzar la edición en un campo no relacionado para obtener un lanzamiento.
• El operador configura mTLS automáticamente. La conexión mutua de TLS entre Kibana y Elasticsearch requiere administrar CA, certificados de cliente por componente, montajes, rotación y configuraciones en ambos extremos. ECK 3.4 se encarga de todo eso: activa una opción en Elasticsearch, configura Kibana para que la utilice, y el operador se encarga del resto.

Esta versión es para hacer que las operaciones diarias de ECK sean aburridas, en el mejor sentido: menos campos para recordar, menos digresiones para mantener sincronizadas y manifiestos más fáciles de entender.

Conciencia simplificada de zonas

Haz que un clúster de Elasticsearch tenga disponibilidad alta en todas las zonas de disponibilidad al configurar un campo en el NodeSet. ECK 3.4 se encarga por ti de la distribución de la topología, la programación de pods y la configuración de la integración con Elasticsearch.

Antes, tenías que conectar todo esto a mano a través de cuatro objetos separados: una anotación en el recurso de Elasticsearch para etiquetas de Node descendentes, atributos de conciencia en la configuración de NodeSet, una fieldRef variable de entorno en la plantilla del pod para mostrar la zona, y un bloque topologySpreadConstraints coincidente más una regla nodeAffinity de fijación del clúster a zonas específicas. Aproximadamente cuarenta líneas de YAML, fácil de configurar mal.

En ECK 3.4, el mismo clúster optimizado para zonas tiene cuatro líneas:

Para fijar un conjunto específico de zonas, nómbralas, y ECK agrega las reglas de afinidad de nodos necesarias que correspondan:

Si necesitas personalizar maxSkew o whenUnsatisfiable, proporcionar una restricción de distribución de topología coincidente con el mismo topologyKey en podTemplate aún tiene prioridad. Tu anulación sigue siendo una anulación.

Una nota para las actualizaciones: habilitar zoneAwareness en un NodeSet existente cambia la plantilla del pod StatefulSet (nuevas restricciones de propagación de topología, ZONE variable de entorno, afinidad de nodo, node.attr.zone), lo que desencadena un reinicio progresivo de una sola vez del NodeSet afectado. Planifica en consecuencia.

Para saber más sobre la gestión simplificada de zonas, puedes leer esta página en Elastic Docs.

Reinicio progresivo declarativo

Reiniciar un clúster de Elasticsearch sin cambiar sus especificaciones es ahora un flujo de trabajo estándar en la versión 3.4. Dos nuevas anotaciones en el recurso Elasticsearch hacen el trabajo:

• eck.k8s.elastic.co/restart-trigger: establecer o cambiar este valor (una marca de tiempo es la opción convencional) para iniciar un reinicio progresivo. Si cambias el valor, se activará otro reinicio más adelante; si eliminas la anotación, no.
• eck.k8s.elastic.co/restart-allocation-delay: texto de duración opcional (por ejemplo, "20m") pasado al API de apagado de nodo de Elasticsearch como el retraso de asignación durante el reinicio, para que puedas retrasar el reequilibrio mientras un pod se recicla.

Detrás de escena, ECK propaga el valor del disparador a las anotaciones de los pods, lo que cambia el hash de la plantilla StatefulSet y alimenta cada pod a través de la ruta de actualización progresivo existente (API de apagado de Node, predicados, eliminación de un pod a la vez). No hay un nuevo mecanismo de reinicio que aprender, y los mensajes de estado y la observabilidad que ya tienes en las actualizaciones progresivos se mantienen.

Para los usuarios de GitOps, esto significa que un pipeline de Flux/ArgoCD puede solicitar un reinicio al parchear una anotación: sin desviación de especificaciones, sin cambios diferenciales y sin edición forzada en un campo no relacionado.

mTLS gestionado para Kibana ↔ Elasticsearch

Con esta versión llega la orquestación de TLS mutua entre Kibana y Elasticsearch. El CRD de Elasticsearch acepta un único campo nuevo, spec.http.tls.client.authentication: true, que indica al clúster que requiera certificados de cliente en su interfaz HTTPs. ECK hace el resto: construye un paquete de confianza a partir de cualquier secreto etiquetado como eck.k8s.elastic.co/client-certificate: true, lo monta en los pods de Elasticsearch, establece xpack.security.http.ssl.client_authentication: required, y emite un certificado cliente del lado del operador para que pueda seguir comunicándose con el clúster durante todo el despliegue.

Esto hace que habilitar y configurar mTLS para la pila (solo Elasticsearch y Kibana, en esta versión) sea una tarea mucho más sencilla.

Cómo habilitar mTLS en Elasticsearch:

En el lado del cliente, el controlador de asociación de Kibana detecta ahora la anotación client-authentication-required en el Elasticsearch referenciado y genera automáticamente un certificado cliente para Kibana, sin necesidad de configuración adicional. Si quieres llevar tu propio certificado (gestor de certificaciones, una PKI interna), señala el secreto que ya has provisionado:

ECK rota el certificado, monta el secreto en el pod de Kibana y conecta elasticsearch.ssl.certificate y elasticsearch.ssl.key. La limpieza de los recursos mTLS se pospone hasta que todos los pods se hayan actualizado, por lo que la conectividad se mantiene durante toda la transición.

Kibana es el primer componente de Stack en recibir este trato de primera clase en la versión 3.4. Próximamente se agregará compatibilidad con APM Server, Beats, Fleet Server, Elastic Agent, Logstash, Maps y Búsqueda empresarial. Mientras tanto, una nueva receta guía a través de mTLS manual para esos componentes mediante cert-manager.

Otras mejoras notables

Esta versión incluye otras mejoras que vale la pena destacar. Aquí tienes una lista con sus pull requests relacionadas.

• Native Go FIPS 140-3 en el operador habilitado para FIPS (imagen separada). La imagen ECK compatible con FIPS (docker.elastic.co/eck/eck-operator-fips:3.4.0, además de una variante UBI eck-operator-ubi-fips:3.4.0) ahora viene con soporte nativo Go FIPS 140-3, fijado en el módulo GOFIPS140=v1.0.0 certificado y aplicado en tiempo de ejecución. La imagen estándar de eck-operator permanece sin cambios. Para Elasticsearch 9.4.0 o posteriores, el operador también genera y monta automáticamente una contraseña de almacenamiento de claves compatible con FIPS cuando se configura xpack.security.fips_mode.enabled: true (#9263, #9287).
• Mejoras de fiabilidad que vale la pena destacar:
  • Las CA obsoletas en la cadena de certificados ahora son detectadas y desencadenan una reemisión (#9197).
  • Las fallas de generación de secretos Remote-CA no son bloqueantes (#9271).
  • La etiqueta de selector de espacio de nombres de NetworkPolicy está fijada para configuraciones de multi-tenencia blanda (#9153).
  • El controlador de Elasticsearch omite su PVC predeterminado si ya existe un volumen con el mismo nombre (#9199).
  • El reconciliador de DaemonSet maneja el caché obsoleto de la misma manera que lo hace el reconciliador de despliegue (#9256).

Primeros pasos

Si ya estás usando ECK, actualiza a la versión 3.4.0. con Helm:

O aplica el último manifiesto del operador directamente:

Si eres nuevo en ECK, comienza con la guía de inicio rápido para poner en marcha un clúster de Elasticsearch en Kubernetes en cuestión de minutos.

Para la lista completa de cambios, consulta las notas de lanzamiento de ECK 3.4.0 en GitHub.

Para empezar a usar Elastic Cloud hoy mismo, inicia sesión en la consola de Elastic Cloud o regístrate para una prueba gratis.

Preguntas frecuentes

¿Cómo hago que un clúster de Elasticsearch sea consciente de zonas en ECK sin escribir restricciones de distribución por topología?

Configura spec.nodeSets[].zoneAwareness: {} en el recurso de Elasticsearch. ECK deriva la topología, adjunta node.attr.zone, establece restricciones de distribución por topología maxSkew=1 e inyecta las etiquetas descendentes para ti. Proporciona zones: [...] si quieres fijar a un conjunto específico de zonas de disponibilidad. Si activas esto en un NodeSet ya existente, se producirá un reinicio progresivo único.

¿Puedo iniciar un reinicio progresivo de un clúster de Elasticsearch en Kubernetes sin modificar la especificación?

Sí. ECK 3.4 introduce dos anotaciones en el recurso Elasticsearch: eck.k8s.elastic.co/restart-trigger (establecer o cambiar el valor, por ejemplo, una marca de tiempo, para iniciar un reinicio progresivo) y eck.k8s.elastic.co/restart-allocation-delay (texto de duración opcional pasado a la API de apagado de Node de Elasticsearch). Eliminar la anotación del disparador no activa un nuevo reinicio.

¿Cómo puedo activar el TLS mutuo entre Kibana y Elasticsearch en Kubernetes?

Con ECK 3.4, establece spec.http.tls.client.authentication: true en el CRD de Elasticsearch y haz referencia a él desde Kibana a través de elasticsearchRef. ECK genera automáticamente un certificado de cliente para Kibana, crea un paquete de confianza a partir de cualquier secreto etiquetado como eck.k8s.elastic.co/client-certificate: true y configura xpack.security.http.ssl.client_authentication: required por ti. mTLS para Kibana ↔ Elasticsearch es una vista previa técnica en la versión 3.4.

¿La compatibilidad con ECK 3.4 mTLS abarca todos los componentes de Stack, como Beats y Fleet?

Todavía no. Kibana es el primer componente de Stack en recibir soporte mTLS de primera clase en la versión 3.4: el operador genera automáticamente su certificado de cliente. La compatibilidad con APM Server, Beats, Fleet Server, Elastic Agent, Logstash, Maps y Búsqueda Empresarial estará disponible en la próxima versión. Una nueva receta te guía paso a paso por la configuración manual de mTLS para aquellos componentes que, por el momento, utilizan cert-manager.

¿ECK es compatible con FIPS 140-3?

Sí, en una imagen de operador separada. ECK 3.4 publica una compilación con estilo FIPS (docker.elastic.co/eck/eck-operator-fips:3.4.0, más una variante UBI) con soporte nativo para Go FIPS 140-3. La imagen estándar eck-operator no ha cambiado. Para Elasticsearch 9.4.0 o posteriores, ECK también genera y monta automáticamente una contraseña de almacenamiento de claves compatible con FIPS cuando se configura xpack.security.fips_mode.enabled: true .