ElasticSearch Operatorとは

ElasticSearch Operatorとは、ElasticSearch向けのKubernetes Operatorであり、OpenshiftのClusterLoggingの機能の一部として動作するOperatorである。

ElasticSearchを自動運用するためのOperationがこのOperatorとして実装されている。

openshift/elasticsearch-operatorというGithubリポジトリのためOpenshiftコミュニティによりメンテされているようである。

openshift/elasticsearch-operator

【補足】elasticsearch-operatorのコード量

Goのファイルが2500強あり、コードが1000k lineにも及ぶ

❯ cloc .
    3297 text files.
    3170 unique files.                                          
     367 files ignored.

github.com/AlDanial/cloc v 1.80  T=10.38 s (283.8 files/s, 117872.8 lines/s)
--------------------------------------------------------------------------------
Language                      files          blank        comment           code
--------------------------------------------------------------------------------
Go                             2539          81218         112652         974429
~
--------------------------------------------------------------------------------
SUM:                           2945          89341         127274        1006349
--------------------------------------------------------------------------------

vendorディレクトリ内で同様に見てみると、950 k lineはvendor関連コードという風に取れるため、実質20 k lineくらいがelasticsearch-operatorのコードといえそう。

❯ cloc .
    3070 text files.
    2948 unique files.                                          
     343 files ignored.

github.com/AlDanial/cloc v 1.80  T=7.37 s (371.4 files/s, 161408.3 lines/s)
--------------------------------------------------------------------------------
Language                      files          blank        comment           code
--------------------------------------------------------------------------------
Go                             2411          77974         111744         956992
~
--------------------------------------------------------------------------------
SUM:                           2738          85146         124716         980068
--------------------------------------------------------------------------------

ElasticSearchのReconcile処理詳解

Reconcile処理概要

• elasticsearchのNode(Elasticsearchクラスタのメンバ)ごとに、正常性確認を行う

• Elasticsearch nodeごとにdeploymentを持っていて、そのdeploymentごとにreconcileを行う

• deployment内のpodステータスを確認する際に、コンテナのステータスも確認しreconcileを行っている。

Reconcile処理に関連するコードの呼び出しフロー

主な処理の流れとしては

• controller/erlasticsearch packageのadd()関数
• controller packageのreconcileHandler経由でReconcile()関数が呼ばれ
• さらにk8shandler内のReconcile()が呼ばれ
• KubernetesのDeployment, Pod, ContainerレベルのReconcileが行われる

となっている。(図1 下記の黒矢印部分)

図1. Reconcile処理に関連するコードの呼び出しフロー図

上記のコールグラフは下記のツールを使用して描画した。インタラクティブに処理を追えるが処理が重いため上記1枚に留めた。

処理の入り口 elasticsearch package内のadd()により、Controllerを登録

add()のコード(図2)をみると、reconcilerを与えることで新しくcontrollerを追加する、という関数である。

ここでElasticSearchをReconcileするためのcontrollerが生成される。

図2. add()の定義

このadd()によって追加されたcontrollerのReconcileが、いわゆるReconcilation Loopと呼ばれる、KubernetesならびにKubernetes Operatorの主な役割である。

Reconcillation Loop

Reconcile()の定義は以下に記載されている。

openshift/elasticsearch-operator

図1で示した通り、Reconcile()からk8shandler package内のReconcile()を呼び出している。(図3)

図3. Reconcile()の実装の一部抜粋

このk8shandler.Reconcile()では、主にKubernetesリソースレベルでのReconcileを行う。

具体的には、

• ServiceAccount
• RBAC
• ConfigMaps
• Prometheus向けのServiceMonitor, PrometheusRule

などがある。

また、これに加えて

• Elasticsearch Cluster
• IndexManagement

についてのReconcile処理が定義されている。

これらについて、CreateOrUpdateHoge()という関数が用意されており、該当のリソースがなければ作り、理想状態じゃなければ更新をかける処理(Reconcilation Loop)が実装されていることになる。

CreateOrUpdateHoge郡の該当のコードは下記である。

openshift/elasticsearch-operator

ここでは、メインのReconcile処理であるCreateOrUpdateElasticsearchCluster()についてさらにDeep Diveすることにする。

ElasticSearchのReconcile処理であるCreateOrUpdateElasticsearchCluster()の実装確認

ここまで説明した通り、CreateOrUpdateElasticsearchCluster()とはElasticSearchを理想状態に保つための関数である。

実際にはDeploymentとして動作するためElasticSearch Deploymentを理想状態にすることをReconcileといっても大きな齟齬はないと思われる。

具体的な処理が気になる場合は、下記の処理から追うことができる。

openshift/elasticsearch-operator

ここでは、ElasticSearchに不具合が起きた場合にどのようにPodに対してReconcileを行うのかについて注目する。

k8shandler package内のcluster.goにて、ScheduledForUpgradeを監視することで、更新が必要なノード(elasticsearchクラスタのメンバの意でありk8s nodeではない)をupgradeNodesとして記憶している。(ScheduledForUpgradeの更新のされ方は後述して補足する)

openshift/elasticsearch-operator

上記でupgradeNodeとして認識されたNodeはk8shandler.UpgradeStatus()にて、Reconcile処理が適用される。

Reconcile処理内における、具体的な実装を確認

UpdateClusterStatus() 内にて、status.go内のupdateNodeConditions()を呼ぶことで、いよいよelasticsearch Nodeごとのreconcile処理に入る

openshift/elasticsearch-operator

Podの正常性を確認

Podがスケジュールされているかを確認

「Podがscheduleされていつつ、podのConditionがFalse」となっている場合に、podをunschedulableとしてフラグ付する。

unschedulableフラグがたった場合は後続処理である、Pod内のコンテナステータスを確認していく。

該当コードは下記

openshift/elasticsearch-operator

Pod内コンテナのステータスを確認

Pod内のelasticsearchコンテナの、StateがWaitingかTerminatedかをまず確認する

この場合は、updatePodNotReadyCondition()を呼ぶことで、Podが壊れている正確なReasonとMessageを付加している。

もう１つのproxyコンテナについても同様に確認をしている。

openshift/elasticsearch-operator

ディスク使用率観点での正常性確認

コンテナの正常性確認が終わるとディスク使用量観点の確認を行う

ディスク使用量が閾値を超えているかどうかを確認し、Disk Watermark Highもしくは、Disk Watermark Lowなどに引っかかっているかを確認する。

openshift/elasticsearch-operator

まとめ

• Openshiftで用いられるElastichSearch Operatorの役割について、PodのReconcile部分に焦点を当てて実装を確認した。

• 実際のReconcile部分に限っていうとElasticsearch特有という部分は余り目立たず、他のOperatorのコードを読む上でも同様に読み進めるための材料として読むことは有用と感じる。

• Operatorhub.ioにおいてelasticsearch-operatorは公開されておらず、"Elastic Cloud on Kubernetes" Operatorが公開されているため、こちらとの関連やその差分などについても考察の余地があるが、OperatorHub.ioに登録されている方がよりデファクトであると現時点では考えられる。そのため、本記事で紹介したelasticsearch-operatorはOpenshiftに特化した内容になっていると考えるのが妥当である。

参考資料

• Elasticsearch OperatorのGoDoc

elasticsearch-operator - GoDoc

• openshift/elasticsearch-operator Github

• openshiftのcluster-loggingのリポジトリ

【補足】ScheduledForUpgradeの更新のされ方

まずk8shandler package内のdeployment.goでdeploymentの状態を監視している

openshift/elasticsearch-operator

node.isChanged()にて、純粋にdeploymentのdesiredとcurrentを比較することで、更新が必要かを判断している。

node.isChanged()がtrueとなった場合に、api.ElasticsearchNodeStatus.UpgradeStatus.ScheduledForUpgradeというフラグを立てることで、reconcilationLoop内で再起動処理をフックする仕組みになっている。