Elasticsearch on Kubernetesがシンプルに：ゾーン認識、再起動、mTLS

ECK 3.4はElastic Stack on Kubernetesの運用をより簡単にします。ゾーン認識型HA、安全なローリング再起動、Kibana↔Elasticsearch mTLSは、それぞれマニフェスト内で1行で記述できます。

今回のリリースは、Elastic Cloud on Kubernetes (ECK) を運用されている方の日々の業務における摩擦を軽減することを目的としています。

操作が簡単で、理解しやすく

ECK 3.4は、Kubernetes上でElastic Stackを実行する際に考慮すべき点を減らすことに焦点を当てたリリースです。見出しの変更はそれぞれ、複数のステップからなるタスクを選択し、それを単一の明確な回答に変換します。

• ゾーン認識の簡素化。クラスターを複数の可用性ゾーンに分散させる必要があることをECKに伝えるための設定をNodeSet上の単一のフィールドで行えるようになりました。オペレーターが、トポロジー、スケジューリング、Elasticsearch側の認識設定をユーザーに代わって処理します。マニフェストは、構成方法ではなく、ユーザーが意図する内容を反映します。
• クラスターの再起動は他の操作と同じ手順で行います。ローリング再起動のトリガーは、Elasticsearchリソース上のアノテーションとして機能しています。宣言型であり、GitOpsに適合し、監査証跡を残します。無関係なフィールドで強制編集してロールアウトする必要はありません。
• mTLSはオペレーターにより自動設定されます。KibanaとElasticsearch間の相互TLSを手作業で配線するには、CA、コンポーネントごとのクライアント証明書、マウント、ローテーション、設定を両端で管理する必要があります。ECK 3.4はそのすべてを処理します。Elasticsearchでフラグを立て、Kibanaに向けると、あとはオペレーターが管理します。

今回のリリースは、ECKの日常的な操作を良い意味で退屈なものにすることを目的としています。覚えておくべき項目が減り、同期を維持するための余計な作業が減り、マニフェストがより分かりやすくなります。

ゾーン認識の簡素化

NodeSetにフィールドを1つ設定することで、Elasticsearchクラスターを可用性ゾーン全体で高可用性にすることができます。ECK 3.4は、トポロジーのスプレッド、ポッドのスケジューリング、Elasticsearch側の認識設定を自動的に処理します。

以前は、下位ノードラベル用のElasticsearchリソースのアノテーション、NodeSet設定の認識属性、ゾーンを表示するためのポッドテンプレートのfieldRef環境変数、クラスターを特定のゾーンに固定する対応するtopologySpreadConstraintsブロックとnodeAffinityルールという4つの別々のオブジェクトにわたって、これらすべてを手動で接続する必要がありました。約40行のYAMLで、設定を間違えやすいです。

ECK 3.4では、同じゾーン対応クラスターは4行で構成されています。

特定のゾーンセットにピン留めするには、ゾーンに名前を付けると、ECKが対応する必要なノードアフィニティルールを追加します。

maxSkewまたはwhenUnsatisfiableカスタマイズする必要がある場合は、 podTemplateで同じtopologyKeyを持つ一致するトポロジースプレッド制約を提供することが依然として最善です。オーバーライドはオーバーライドのままとなります。

アップグレードに関する注意点：既存のNodeSetでzoneAwareness有効にすると、StatefulSetのポッドテンプレートが変更され（新しいトポロジーのスプレッド制約、 ZONE環境変数、ノード アフィニティ、 node.attr.zone）、影響を受けるNodeSetが一度だけローリング再起動されます。適切に計画を立ててください。

ゾーン管理の簡素化についてさらに詳しく知りたい場合は、Elasticドキュメントのこちらのページをご覧ください。

宣言的ローリング再起動

3.4では、仕様を変更せずにElasticsearchクラスターを再起動することがファーストクラスのワークフローとなりました。Elasticsearchリソースに追加された2つの新しいアノテーションがその役割を果たします。

• eck.k8s.elastic.co/restart-triggerローリング再起動を開始するには、この値（タイムスタンプが一般的な選択肢です）を設定または変更します。値を変更すると後で別の再起動がトリガーされますが、アノテーションを削除するとトリガーされません。
• eck.k8s.elastic.co/restart-allocation-delay: オプションの期間文字列（例："20m"）は、再起動時の割り当て遅延としてElasticsearchノードシャットダウンAPIに渡され、ポッドがリサイクルされている間はリバランスを保留できます。

ECKの内部では、トリガー値がポッドアノテーションに伝播され、StatefulSetテンプレートハッシュが変更され、既存のローリングアップグレードパス（NodeシャットダウンAPI、述語、一度に1つのポッド削除）を通じてすべてのポッドにフィードされます。新たに覚えるべき再起動メカニズムはなく、ローリングアップグレードで既に利用しているステータスメッセージや監視機能はそのまま引き継がれます。

GitOpsユーザーにとって、これはFlux/ArgoCDパイプラインが1つのアノテーションにパッチを当てるだけで再起動を要求できることを意味します。スペックドリフトなし、差分チャーンなし、無関係なフィールドでの強制編集はありません。

Kibana ↔ ElasticsearchのためのマネージドmTLS

今回のリリースで、KibanaとElasticsearch間の相互TLSオーケストレーション機能が追加されました。Elasticsearch CRDは、クラスターにHTTPsインターフェースでクライアント証明書を要求するように指示する単一の新しいフィールドspec.http.tls.client.authentication: trueを受け入れます。ECKは残りの処理を行います。ラベルeck.k8s.elastic.co/client-certificate: trueが付いた任意のシークレットからトラストバンドルを作成し、それをElasticsearchポッドにマウントし、 xpack.security.http.ssl.client_authentication: requiredを設定し、ロールアウト全体を通してクラスターと通信できるようにオペレーター側のクライアント証明書を発行します。

これにより、スタック（このリリースではElasticsearchとKibanaのみ）のmTLSを有効にして設定する作業がはるかに簡単になります。

ElasticsearchでmTLSを有効にする方法：

クライアント側では、Kibanaのアソシエーションコントローラーが参照先のElasticsearch上のclient-authentication-requiredアノテーションを検出し、Kibana用のクライアント証明書を自動的に生成します。追加の設定は不要です。独自の証明書（cert-manager、内部PKIなど）を使用する場合は、すでにプロビジョニング済みのシークレットを指定してください。

ECKは証明書をローテーションし、シークレットをKibanaポッドにマウントし、 elasticsearch.ssl.certificateとelasticsearch.ssl.keyを接続します。mTLSリソースのクリーンアップは、すべてのポッドがロールアウトするまで延期されるため、移行中も接続は維持されます。

Kibanaは、3.4でこのファーストクラスとして扱われる最初のスタックコンポーネントです。APM Server、Beats、Fleet Server、Elastic Agent、Logstash、Maps、Enterprise Searchのサポートが近日中に提供されます。それまでの間、新しいレシピでcert-managerを使用するコンポーネントに対して、手動でmTLSを設定する方法を解説しています。

その他の特筆すべき改善点

このリリースには、他にも特筆すべき改善点があります。以下は、関連するプルリクエストの一覧です。

• FIPS対応オペレーターにおけるネイティブGo FIPS 140-3（別イメージ）。FIPS準拠のECKイメージ（docker.elastic.co/eck/eck-operator-fips:3.4.0、およびUBIバリアントeck-operator-ubi-fips:3.4.0）は、認証済みのGOFIPS140=v1.0.0モジュールに固定され、ランタイムで強制されるネイティブのGo FIPS 140-3サポートを搭載してシッピングするようになりました。標準の eck-operator イメージは変更されていません。Elasticsearch 9.4.0以降では、オペレーターは xpack.security.fips_mode.enabled: true 設定時に自動的にFIPS準拠のキーストアパスワードを生成・マウントします(#9263、#9287)。
• 特筆すべき信頼性改善策：
  • 期限切れのCAが証明書チェーンで検出されるようになり、再発行がトリガーされます（#9197）。
  • リモートCAのシークレット生成の失敗は非ブロッキングになりました（#9271）。
  • NetworkPolicyの名前空間セレクターラベルはソフトマルチテナンシー設定で固定されています（#9153）。
  • Elasticsearchコントローラーは、同じ名前のボリュームがすでに存在する場合は、デフォルトのPVCをスキップします（#9199）。
  • DaemonSetリコンサイラーは、Deploymentリコンサイラーと同じ方法で古いキャッシュを処理します（#9256）。

はじめに

すでにECKを実行している場合は、Helmを使用して3.4.0にアップグレードしてください。

または最新のオペレーターマニフェストを直接適用することもできます。

ECKを初めて使用する場合は、クイックスタートガイドから始めて、Kubernetes上でElasticsearchクラスターを数分で稼働させましょう。

変更点の全リストについては GitHubのECK 3.4.0リリースノートをご覧ください。

Elastic Cloudの利用を始めるには、Elastic Cloudコンソールにログインするか、無料トライアルに登録してください。

よくあるご質問

トポロジーのスプレッド制約を記述せずにECKでElasticsearchクラスターをゾーン認識型にするにはどうすればよいですか？

Elasticsearchリソースで spec.nodeSets[].zoneAwareness: {} を設定してください。ECKはトポロジーを導出、node.attr.zoneを接続、maxSkew=1トポロジー拡散制約を設定し、下方向ラベルを自動的に挿入します。特定の利用可能なゾーンにピン留めしたい場合は、 zones: [...] を用意してください。既存のNodeSetでこれを有効にすると、一度限りのローリング再起動が実行されます。

仕様を編集せずにKubernetes上のElasticsearchクラスターのローリング再起動をトリガーすることはできますか？

はい。ECK 3.4では、Elasticsearchリソースに2つのアノテーション、 eck.k8s.elastic.co/restart-trigger（値を設定または変更し、例えばタイムスタンプを指定してローリング再起動を開始）と eck.k8s.elastic.co/restart-allocation-delay（Elasticsearch Nodeのシャットダウン API に渡されるオプションの期間文字列）が導入されました。トリガーアノテーションを削除しても、新しい再起動は開始されません。

KibanaとElasticsearch on Kubernetesの間で相互TLSを有効にするにはどうすればよいですか？

ECK 3.4では、Elasticsearch CRDにspec.http.tls.client.authentication: trueを設定し、KibanaからelasticsearchRefを介して参照します。ECKはKibana用のクライアント証明書を自動生成し、eck.k8s.elastic.co/client-certificate: trueとラベル付けされた任意のシークレットからトラストバンドルを構築し、xpack.security.http.ssl.client_authentication: requiredを設定します。Kibana ↔ ElasticsearchのmTLSは3.4のテクニカルプレビューです。

ECK 3.4 mTLSのサポートは、BeatsやFleetなどのすべてのスタックコンポーネントをカバーしていますか？

まだサポートしていません。Kibanaは、3.4でファーストクラスのmTLSサポートを受けた最初のStackコンポーネントです。オペレーターがクライアント証明書を自動生成します。APM Server、Beats、Fleet Server、Elastic Agent、Logstash、Maps、Enterprise Searchのサポートが次のリリースに含まれます。それまでの間、新しいレシピでcert-managerを使用するコンポーネントに対して、手動でmTLSを設定する方法を解説しています。

ECKはFIPS 140-3をサポートしていますか？

はい、別のオペレーターイメージでサポートします。ECK 3.4は、FIPS準拠のビルド（docker.elastic.co/eck/eck-operator-fips:3.4.0、およびUBIバリアント）を公開し、ネイティブのGo FIPS 140-3サポートを提供します。標準の eck-operator イメージは変更されていません。Elasticsearch 9.4.0以降では、 xpack.security.fips_mode.enabled: trueが設定されている場合、ECKはFIPS準拠のキーストアパスワードを自動的に生成してマウントします。