Elastic Cloud sur Kubernetes, simplifié : prise en charge des zones, redémarrages et mTLS

ECK 3.4 simplifie l’exploitation de la Suite Elastic sur Kubernetes. La haute disponibilité multizone, les redémarrages progressifs sécurisés et le mTLS entre Kibana↔Elasticsearch se configurent désormais chacun en une seule ligne dans votre manifeste.

Si vous utilisez Elastic Cloud on Kubernetes (ECK), cette version vise à simplifier les tâches que vous effectuez au quotidien.

Plus facile à utiliser, plus facile à comprendre

ECK 3.4 est une version conçue pour réduire la complexité liée à l’exécution de la Suite Elastic sur Kubernetes. Chaque amélioration majeure transforme une tâche en plusieurs étapes en une configuration déclarative unique :

• Simplification de la gestion multizone. Indiquer à ECK qu’un cluster doit être réparti entre plusieurs zones de disponibilité se résume désormais à un seul champ dans le NodeSet. L’opérateur gère pour vous la topologie, l’ordonnancement et la configuration de l’awareness côté Elasticsearch. Vos manifestes décrivent désormais l’intention, sans exposer les détails d’implémentation.
• Redémarrez un cluster comme vous gérez déjà le reste. Le déclenchement d’un redémarrage progressif se fait désormais via une annotation sur la ressource Elasticsearch. Cette approche est déclarative, compatible avec GitOps et laisse une trace d’audit. Plus besoin de modifier de force un champ sans rapport pour déclencher un déploiement.
• Le mTLS est automatiquement configuré par l’opérateur. Configurer manuellement le TLS mutuel entre Kibana et Elasticsearch implique de gérer les autorités de certification (CA), les certificats clients pour chaque composant, les montages, la rotation des certificats et les configurations des deux côtés. ECK 3.4 prend tout cela en charge : activez simplement une option dans Elasticsearch, connectez-y Kibana et l’opérateur s’occupe du reste.

Cette version vise à rendre les opérations quotidiennes d’ECK simples et prévisibles, dans le meilleur sens du terme : moins de champs à mémoriser, moins d’éléments à synchroniser et des manifestes plus faciles à comprendre.

Simplification de la gestion multizone

Rendez un cluster Elasticsearch hautement disponible entre plusieurs zones de disponibilité en définissant un seul champ dans le NodeSet. ECK 3.4 gère automatiquement la répartition de la topologie, l’ordonnancement des pods et la configuration de l’awareness côté Elasticsearch.

Auparavant, vous deviez câbler tout cela manuellement à travers quatre objets distincts : une annotation sur la ressource Elasticsearch pour les étiquettes de node descendantes, des attributs de sensibilisation dans la configuration NodeSet, une fieldRef env var dans le modèle de pod pour faire apparaître la zone, et un bloc topologySpreadConstraints correspondant plus une règle nodeAffinity épinglant le cluster à des zones spécifiques. Environ quarante lignes de YAML, facile à mal configurer.

Dans ECK 3.4, le même cluster multizone tient en quatre lignes :

Pour cibler un ensemble précis de zones, il suffit de les nommer et ECK ajoute automatiquement les règles d’affinité de nœuds requises :

Si vous devez personnaliser maxSkew ou whenUnsatisfiable, fournir une contrainte d'étalement de la topologie correspondante avec le même topologyKey dans podTemplate reste toujours la meilleure option. Votre modification reste une modification.

Une note pour les mises à jour : activer zoneAwareness sur un NodeSet existant modifie le modèle de pod StatefulSet (nouvelles contraintes d’étalement topologique, ZONE var env, affinité de nœuds, node.attr.zone), ce qui déclenche un redémarrage roulant unique du NodeSet affecté. Planifiez en conséquence.

Pour en savoir plus sur la gestion simplifiée des zones, vous pouvez consulter cette page dans la documentation Elastic Docs.

Redémarrages progressifs déclaratifs

Redémarrer un cluster Elasticsearch sans modifier sa spécification devient désormais un workflow natif dans la version 3.4. Deux nouvelles annotations sur la ressource Elasticsearch effectuent l’opération :

• eck.k8s.elastic.co/restart-trigger: définissez ou modifiez cette valeur (un horodatage est généralement utilisé) pour lancer un redémarrage progressif. Modifier la valeur déclenche un nouveau redémarrage ultérieurement ; supprimer l’annotation ne le fait pas.
• eck.k8s.elastic.co/restart-allocation-delay: chaîne de durée optionnelle (e.g. « 20m ») est transmis à l’API d’arrêt du node Elasticsearch comme délai d’allocation lors du redémarrage, vous pouvez donc retarder le rééquilibrage pendant qu’un pod se recycle.

En arrière-plan, ECK propage la valeur du déclencheur aux annotations des pods, ce qui modifie le hash du modèle StatefulSet et fait passer chaque pod par le processus existant de mise à niveau progressive (API d’arrêt de nœud, prédicats, suppression d’un pod à la fois). Aucun nouveau mécanisme de redémarrage n’est nécessaire, et les messages d’état ainsi que les fonctionnalités d’observabilité déjà disponibles pour les mises à niveau progressives restent inchangés.

Pour les utilisateurs GitOps, cela signifie qu’un pipeline Flux/ArgoCD peut demander un redémarrage en modifiant une seule annotation : aucune dérive de spécification, aucun bruit dans les différences et aucune modification forcée d’un champ sans rapport.

Gestion de mTLS pour Kibana ↔ Elasticsearch

L’orchestration Mutual TLS entre Kibana et Elasticsearch arrive avec cette version. Le CRD Elasticsearch accepte un seul nouveau champ, spec.http.tls.client.authentication: true, qui indique au cluster d’exiger des certificats clients sur son interface HTTPS. ECK fait le reste : il construit un trust bundle à partir de n’importe quel secret intitulé eck.k8s.elastic.co/client-certificate: true, le monte dans les pods Elasticsearch, définit xpack.security.http.ssl.client_authentication: required, et émet un certificat client côté opérateur afin de pouvoir continuer à communiquer avec le cluster tout au long du déploiement.

Cela simplifie considérablement l’activation et la configuration du mTLS pour la stack (Elasticsearch et Kibana uniquement dans cette version).

Activation de mTLS sur Elasticsearch :

Côté client, le contrôleur d'association de Kibana détecte désormais l'annotation client-authentication-required sur l'Elasticsearch référencé et génère automatiquement un certificat client pour Kibana. Aucune configuration supplémentaire n'est nécessaire. Si vous souhaitez apporter votre propre certificat (cert-manager, une PKI interne), pointez vers le secret que vous avez déjà provisionné :

ECK fait pivoter le certificat, insère le secret dans le module Kibana et connecte elasticsearch.ssl.certificate et elasticsearch.ssl.key. Le nettoyage des ressources mTLS est différé jusqu'à ce que tous les pods aient roulé, de sorte que la connectivité est maintenue tout au long de la transition.

Kibana est le premier composant Stack à bénéficier de ce traitement de premier ordre dans la version 3.4. Le support pour APM Server, Beats, Fleet Server, Elastic Agent, Logstash, Maps et Enterprise Search sera disponible dans un avenir proche. Dans l'intervalle, une nouvelle recette explique comment configurer manuellement mTLS pour ces composants à l'aide de cert-manager.

Autres améliorations notables

Cette version inclut également d’autres améliorations notables. Voici une liste avec leurs demandes d'intégration associées.

• Native Go FIPS 140-3 dans l'opérateur FIPS (image séparée). L’image ECK à saveur FIPS (docker.elastic.co/eck/eck-operator-fips:3.4.0, plus une variante UBI eck-operator-ubi-fips:3.4.0) est désormais livrée avec le support natif Go FIPS 140-3, épinglée au module GOFIPS140=v1.0.0 certifié et appliquée à l’exécution. L’image standard eck-operator reste inchangée. Pour Elasticsearch 9.4.0 ou une version ultérieure, l'opérateur génère et monte également automatiquement un mot de passe de keystore conforme FIPS lorsque xpack.security.fips_mode.enabled: true est défini (#9263, #9287).
• Les correctifs de fiabilité à souligner :
  • Les AC périmées dans la chaîne de certificats sont maintenant détectées et déclenchent une réémission(#9197).
  • Les échecs de génération du secret de la CA à distance ne sont pas bloquants(#9271).
  • L'étiquette du sélecteur d'espace de noms NetworkPolicy est corrigée pour les configurations multi-tenances douces(#9153).
  • Le contrôleur Elasticsearch saute son PVC par défaut si un volume du même nom existe déjà (#9199).
  • Le réconciliateur DaemonSet gère le cache périmé de la même manière que le réconciliateur déploiement(#9256).

Premiers pas

Si vous utilisez déjà ECK, passez à la version 3.4.0 avec Helm :

Ou appliquez directement le dernier manifeste de l'opérateur :

Si vous débutez avec ECK, commencez par le guide de démarrage rapide pour mettre en place un cluster Elasticsearch sur Kubernetes en quelques minutes.

Pour la liste complète des modifications, consultez les notes de publication d'ECK 3.4.0 sur GitHub.

Pour commencer à utiliser Elastic Cloud dès aujourd’hui, connectez-vous à la console Elastic Cloud ou inscrivez-vous à un essai gratuit.

Questions fréquentes

Comment rendre un cluster Elasticsearch multizone dans ECK sans écrire de contraintes de répartition de topologie ?

Définir spec.nodeSets[].zoneAwareness: {} sur la ressource Elasticsearch. ECK dérive la topologie, associe node.attr.zone, définit les contraintes de répartition topologique maxSkew=1 et vous injecte les étiquettes descendantes. Fournissez zones: [...] si vous souhaitez épingler un ensemble spécifique de zones de disponibilité. L'activation de cette fonction sur un NodeSet existant provoque un redémarrage progressif unique.

Puis-je déclencher un redémarrage progressif d’un cluster Elasticsearch sur Kubernetes sans modifier la spécification ?

Oui. ECK 3.4 introduit deux annotations sur la ressource Elasticsearch : eck.k8s.elastic.co/restart-trigger (définir ou modifier la valeur, par exemple un horodatage, pour démarrer un redémarrage progressif) et eck.k8s.elastic.co/restart-allocation-delay (chaîne de durée facultative transmise à l’API d’arrêt du Node Elasticsearch). La suppression de l'annotation de déclenchement n'entraîne pas de nouveau redémarrage.

Comment activer le TLS mutuel entre Kibana et Elasticsearch sur Kubernetes ?

Avec ECK 3.4, définissez spec.http.tls.client.authentication: true sur le CRD Elasticsearch et référencez-le depuis Kibana via elasticsearchRef. ECK génère automatiquement un certificat client pour Kibana, crée un ensemble de confiance à partir de n'importe quel secret étiqueté eck.k8s.elastic.co/client-certificate: true et configure xpack.security.http.ssl.client_authentication: required pour vous. mTLS pour Kibana ↔ Elasticsearch est une version préliminaire technique dans 3.4.

La prise en charge mTLS d’ECK 3.4 couvre-t-elle tous les composants de la Suite Elastic, comme Beats et Fleet ?

Pas encore. Kibana est le premier composant de la Suite Elastic à bénéficier d’une prise en charge mTLS native dans la version 3.4 : l’opérateur génère automatiquement son certificat client. La prise en charge d’APM Server, Beats, Fleet Server, Elastic Agent, Logstash, Maps et Enterprise Search arrivera dans la prochaine version. En attendant, un nouveau guide explique comment configurer manuellement le mTLS pour ces composants à l’aide de cert-manager.

ECK prend-il en charge la norme FIPS 140-3 ?

Oui, dans une image d'opérateur séparée. ECK 3.4 publie une version inspirée de FIPS (docker.elastic.co/eck/eck-operator-fips:3.4.0, plus une variante UBI) avec un support natif Go FIPS 140-3. L’image standard eck-operator reste inchangée. Pour Elasticsearch 9.4.0 ou ultérieure, ECK génère et monte automatiquement un mot de passe de stockage de clés conforme à FIPS lorsque xpack.security.fips_mode.enabled: true est activé.