Elastic Cloud on Kubernetes, vereinfacht: Zonenbewusstsein, Neustarts und mTLS

ECK 3.4 vereinfacht die Bedienung des Elastic Stack auf Kubernetes. Zonenbewusste Hochverfügbarkeit, sichere rollierende Neustarts und Kibana↔Elasticsearch mTLS werden jeweils zu einer einzeiligen Antwort in Ihrem Manifest.

Wenn Sie Elastic Cloud on Kubernetes (ECK) betreiben, geht es in dieser Version darum, die Reibung bei den Dingen, die Sie täglich tun, zu verringern.

Einfacher zu bedienen, einfacher zu verstehen

ECK 3.4 ist eine Version, die darauf abzielt, den Aufwand beim Ausführen des Elastic Stack auf Kubernetes zu reduzieren. Jede Überschriftenänderung wählt eine mehrstufige Aufgabe aus und verwandelt sie in eine einzige deklarative Antwort:

• Vereinfachte Zonenwahrnehmung. Die ECK-Anweisung, dass ein Cluster über verschiedene Verfügbarkeitszonen verteilt werden soll, erfolgt nun über ein einziges Feld im NodeSet. Der Operator kümmert sich in Ihrem Namen um die Topologie, die Zeitplanung und die Elasticsearch-seitige Konfiguration. Ihre Manifeste spiegeln wider, was Sie meinen, nicht, wie es aufgebaut ist.
• Starten Sie einen Cluster auf die gleiche Weise neu wie alles andere. Das Auslösen eines rollierenden Neustarts ist jetzt eine Anmerkung zur Elasticsearch-Ressource. Es ist deklarativ, passt zu GitOps und hinterlässt einen Prüfpfad. Kein Force-Edit auf einem nicht verwandten Feld, um ein Rollout zu erhalten.
• mTLS wird automatisch vom Betreiber konfiguriert. Die manuelle Einrichtung einer gegenseitigen TLS-Verschlüsselung zwischen Kibana und Elasticsearch erfordert die Verwaltung von Zertifizierungsstellen, clientseitigen Zertifikaten pro Komponente, Mounts, Rotation und Konfigurationen auf beiden Seiten. ECK 3.4 kümmert sich um all das: Setzen Sie einen Flag auf Elasticsearch, richten Sie Kibana darauf aus und der Operator verwaltet den Rest.

Diese Version soll den täglichen ECK-Betrieb langweilig machen, im besten Sinne: weniger Felder zum Merken, weniger Abstecher, um synchron zu bleiben, und einfacher zu verstehende Manifeste.

Vereinfachtes Zonenbewusstsein

Machen Sie einen Elasticsearch-Cluster über Verfügbarkeitszonen hinweg hochverfügbar, indem Sie ein Feld im NodeSet festlegen. ECK 3.4 übernimmt für Sie die Topologieverteilung, die Pod-Planung und die Konfiguration der Elasticsearch-seitigen Erkennung.

Früher musste man all dies von Hand über vier verschiedene Objekte verdrahten: eine Annotation in der Elasticsearch-Ressource für nach unten gerichtete Node-Labels, Awareness-Attribute in der NodeSet-Konfiguration, eine fieldRef-env var in der Pod-Vorlage zur Oberfläche der Zone sowie einen passenden topologySpreadConstraints-Block plus eine nodeAffinity-Regel, die den Cluster an bestimmte Zonen festnagelt. Etwa vierzig Zeilen YAML-Code, leicht falsch zu konfigurieren.

In ECK 3.4 besteht derselbe zonenbewusste Cluster aus vier Zeilen.

Um eine bestimmte Gruppe von Zonen zuzuordnen, benennen Sie diese, und ECK fügt die entsprechenden erforderlichen Knotenaffinitätsregeln hinzu:

Wenn Sie maxSkew oder whenUnsatisfiable anpassen müssen, gewinnt immer noch eine übereinstimmende Topologie-Spread-Einschränkung mit demselben topologyKey in podTemplate. Ihre Überschreibung bleibt eine Überschreibung.

Ein Hinweis zu Upgrades: Das Aktivieren von zoneAwareness auf einem bestehenden NodeSet ändert die StatefulSet-Pod-Vorlage (neue Topologie-Spread-Constraints, ZONE-env var, Node-Affinität, node.attr.zone), was einen einmaligen rollierenden Neustart des betroffenen NodeSet auslöst. Planen Sie entsprechend.

Um mehr über das vereinfachte Zonenmanagement zu erfahren, können Sie diese Seite in den Elastic-Dokumenten lesen.

Deklarative rollierende Neustarts

Das Neustarten eines Elasticsearch-Clusters ohne Änderung seiner Spezifikation ist nun ein erstklassiger Workflow in 3.4. Zwei neue Annotationen auf der Elasticsearch-Ressource erledigen die Arbeit:

• eck.k8s.elastic.co/restart-trigger: diesen Wert setzen oder ändern (ein Zeitstempel ist die übliche Wahl), um einen rollierenden Neustart zu starten. Das Ändern des Wertes löst später einen weiteren Neustart aus, das Entfernen der Anmerkung hingegen nicht.
• eck.k8s.elastic.co/restart-allocation-delay: optionale Dauer-Zeichenfolge (z.B. "20m") wurde als Zuweisungsverzögerung während des Neustarts an die Elasticsearch-Node-Shutdown-API übergeben, sodass Sie das Rebalancing aufschieben können, während ein Pod recycelt wird.

Im Hintergrund propagiert ECK den Triggerwert an Pod-Annotationen, wodurch sich der StatefulSet-Template-Hash ändert und jeder Pod den bestehenden Pfad des rollierenden Upgrades durchläuft (Node-Shutdown-API, Prädikate, Löschung eines Pods nach dem anderen). Sie müssen keinen neuen Neustart-Mechanismus erlernen, und die Statusmeldungen und die Beobachtbarkeit, die Sie bereits bei rollierenden Upgrades haben, werden übernommen.

Für GitOps-Anwender bedeutet dies, dass eine Flux/ArgoCD-Pipeline einen Neustart anfordern kann, indem sie eine einzige Anmerkung ändert: keine Abweichung von der Spezifikation, kein ständiges Erstellen von Diff-Dateien, keine erzwungene Bearbeitung eines nicht relevanten Feldes.

Managed mTLS für Kibana ↔ Elasticsearch

Mutual TLS-Orchestrierung zwischen Kibana und Elasticsearch ist mit dieser Version verfügbar. Das Elasticsearch-CRD akzeptiert ein einziges neues Feld, spec.http.tls.client.authentication: true, das dem Cluster signalisiert, dass es Client-Zertifikate auf seiner HTTPS-Schnittstelle verlangen soll. ECK erledigt den Rest: Es baut ein Vertrauenspaket aus jedem Geheimnis mit der Bezeichnung eck.k8s.elastic.co/client-certificate: true, bindet es in die Elasticsearch-Pods ein, setzt xpack.security.http.ssl.client_authentication: required und stellt ein Operator-seitiges Client-Zertifikat aus, damit es während des gesamten Rollouts mit dem Cluster kommunizieren kann.

Dadurch wird das Aktivieren und Konfigurieren von mTLS für den Stack (in dieser Version nur Elasticsearch und Kibana) deutlich vereinfacht.

mTLS auf Elasticsearch aktivieren:

Auf der Client-Seite erkennt Kibanas Assoziationscontroller jetzt die Annotation client-authentication-required auf dem referenzierten Elasticsearch und generiert automatisch ein Client-Zertifikat für Kibana – keine zusätzliche Konfiguration erforderlich. Wenn Sie Ihr eigenes Zertifikat mitbringen möchten (Cert-Manager, eine interne PKI), zeigen Sie auf das Geheimnis, das Sie bereits bereitgestellt haben:

ECK rotiert das Zertifikat, montiert das Geheimnis in den Kibana-Pod und verdrahtet elasticsearch.ssl.certificate und elasticsearch.ssl.key. Die Bereinigung der mTLS-Ressourcen wird aufgeschoben, bis alle Pods ausgerollt sind, so dass die Konnektivität während des Übergangs erhalten bleibt.

Kibana ist die erste Stack-Komponente, die in Version 3.4 diese erstklassige Behandlung erhält. Unterstützung für APM Server, Beats, Fleet Server, Elastic Agent, Logstash, Maps und Enterprise Search werden in naher Zukunft verfügbar. In der Zwischenzeit führt ein neues Rezept durch manuelles mTLS für diese Komponenten unter Verwendung von cert-manager.

Weitere bemerkenswerte Verbesserungen

Diese Version enthält weitere erwähnenswerte Verbesserungen. Hier ist eine Liste mit den zugehörigen Pull-Anfragen.

• Native Go FIPS 140-3 im FIPS-fähigen Operator (separates Bild). Das FIPS-inspirierte ECK-Image (docker.elastic.co/eck/eck-operator-fips:3.4.0sowie eine UBI-Variante eck-operator-ubi-fips:3.4.0) wird nun mit nativer Go FIPS 140-3-Unterstützung ausgeliefert, gepinnt am zertifizierten Modul GOFIPS140=v1.0.0 und zur Laufzeit durchgesetzt. Das Standardbild eck-operator bleibt unverändert. Bei Elasticsearch 9.4.0 oder höher generiert und mountet der Operator außerdem automatisch ein FIPS-konformes Keystore-Passwort, wenn xpack.security.fips_mode.enabled: true gesetzt ist (#9263, #9287).
• Erwähnenswerte Zuverlässigkeitskorrekturen:
  • Veraltete Zertifizierungsstellen in der Zertifikatskette werden nun erkannt und lösen eine Neuausstellung aus (#9197).
  • Remote-CA-Geheimnisgenerierungsfehler sind nicht blockierend (#9271).
  • Das NetworkPolicy-Namespace-Selector-Label ist für Soft-Multi-Tenancy-Setups festgelegt (#9153).
  • Der Elasticsearch-Controller überspringt sein Standard-PVC, falls bereits ein Volume gleichen Namens existiert (#9199).
  • Der DaemonSet Reconciler behandelt veralteten Cache genauso wie der Deployment Reconciler (#9256).

Erste Schritte

Wenn Sie ECK bereits verwenden, führen Sie ein Upgrade auf 3.4.0 mit Helm durch:

Oder wenden Sie das neueste Operator-Manifest direkt an:

Wenn Sie neu bei ECK sind, beginnen Sie mit dem Quickstart-Leitfaden, um in wenigen Minuten einen Elasticsearch-Cluster auf Kubernetes zum Laufen zu bringen.

Eine vollständige Liste der Änderungen finden Sie in den ECK 3.4.0-Versionshinweisen auf GitHub.

Um noch heute mit der Nutzung von Elastic Cloud zu beginnen, melden Sie sich in der Elastic Cloud-Konsole an oder melden Sie sich für eine kostenlose Testversion an.

Häufig gestellte Fragen

Wie kann ich einen Elasticsearch-Cluster in ECK zonenbewusst machen, ohne Topologie-Verteilungsbeschränkungen zu definieren?

Setzen Sie spec.nodeSets[].zoneAwareness: {} auf der Elasticsearch-Ressource. ECK leitet die Topologie ab, hängt node.attr.zone an, setzt Topologie-Ausbreitungsbeschränkungen maxSkew=1 und injiziert die nach unten gerichteten Labels für Sie. Geben Sie zones: [...] an, wenn Sie eine bestimmte Menge von Verfügbarkeitszonen festlegen möchten. Die Aktivierung dieser Option in einem bestehenden NodeSet verursacht einen einmaligen schrittweisen Neustart.

Kann ich einen rollierenden Neustart eines Elasticsearch-Clusters auf Kubernetes auslösen, ohne die Spezifikation zu bearbeiten?

Ja. ECK 3.4 führt zwei Annotationen für die Elasticsearch-Ressource ein: eck.k8s.elastic.co/restart-trigger (Wert setzen oder ändern, z. B. einen Zeitstempel, um einen rollierenden Neustart zu starten) und eck.k8s.elastic.co/restart-allocation-delay (optionale Dauerzeichenfolge, die an die Elasticsearch-Node-Shutdown-API übergeben wird). Das Entfernen der Trigger-Annotation führt nicht zu einem neuen Neustart.

Wie aktiviere ich gegenseitiges TLS zwischen Kibana und Elasticsearch auf Kubernetes?

Mit ECK 3.4 setzen Sie spec.http.tls.client.authentication: true auf der Elasticsearch CRD und verweisen von Kibana aus über elasticsearchRef darauf. ECK generiert automatisch ein Clientzertifikat für Kibana, erstellt ein Vertrauenspaket aus einem beliebigen Geheimnis mit der Bezeichnung eck.k8s.elastic.co/client-certificate: true und konfiguriert xpack.security.http.ssl.client_authentication: required für Sie. mTLS für Kibana ↔ Elasticsearch ist eine technische Vorschau in 3.4.

Deckt die mTLS-Unterstützung von ECK 3.4 alle Stack-Komponenten wie Beats und Fleet ab?

Noch nicht. Kibana ist die erste Stack-Komponente, die in 3.4 erstklassige mTLS-Unterstützung erhält – der Betreiber generiert automatisch sein Client-Zertifikat. Unterstützung für APM Server, Beats, Fleet Server, Elastic Agent, Logstash, Maps und Enterprise Search wird in der nächsten Version bereitgestellt. Ein neues Rezept führt in der Zwischenzeit manuelles mTLS für diese Komponenten mit Cert-Manager durch.

Unterstützt ECK FIPS 140-3?

Ja, in einem separaten Operator-Bild. ECK 3.4 veröffentlicht eine FIPS-basierte Version (docker.elastic.co/eck/eck-operator-fips:3.4.0sowie eine UBI-Variante) mit nativer Go FIPS 140-3-Unterstützung. Das Standardbild eck-operator bleibt unverändert. Für Elasticsearch 9.4.0 oder höher generiert und mountet ECK außerdem automatisch ein FIPS-konformes Keystore-Passwort, wenn xpack.security.fips_mode.enabled: true gesetzt ist.