CNDT2021、Kubernetesをカスタマイズするカスタムコントローラーのベスト／ワーストプラクティスを紹介

CNDT2021から、Kubernetesをカスタマイズするための仕組み、カスタムリソースのベストプラクティス、アンチパターンを解説するセッションを紹介する。これはサイボウズ株式会社の池添明宏氏によるもので、「Kubernetesオペレータのアンチパターン＆ベストプラクティス」と題されたセッションだ。

動画：Kubernetesオペレータのアンチパターン＆ベストプラクティス

Kubernetesカスタマイズのやるべきこと、やってはいけないことを解説

最初にKubernetesがそもそもどういう原理で実行されているのか？ に触れ、それを踏まえた上でカスタマイズするための仕組みであるカスタムリソースとそれを制御するカスタムコントローラーであると説明した。

カスタムコントローラーの解説

この原理を理解した上でカスタムコントローラーを自作する際に注意するべきことを解説するのが、このセッションのゴールとなる。先に進む前にKubernetesが「宣言的」であるということについて再確認しておこう。例えば「このサーバーでPodを3つ起動する」というのは手続き的な指示だ。一方Kubernetesに与える指示は「サーバーがどれかは指定しないが必要なPodの数は3つである」という形式だ。Kubernetesは、このような宣言的な指示を受け取ると、宣言されたあるべき姿と現状のシステムを比較して、あるべき姿にシステムの状態を変えていくように動作する。

宣言的な動作原理をイラストで解説

このイラストではUserと書かれているが、通常は開発者が実装したい内容（必要なリソース）をCRD（Custom Resource Defintion）として記述し、運用開発者がKubernetesに与え、対応したカスタムコントローラーが必要な処理を行うという形になる。対象となるのはデータベースなどさまざまな応用が考えられる。運用担当者が行う処理を、実際にはセルフサービスとして開発者が直接行う場合も有り得るだろう。

オペレータの解説

ここでは「オペレータはカスタムコントローラを利用して特定のソフトウェアの構築や運用を自動化するソフトウェア」と簡潔に説明されている。より詳細に知りたい場合は、レッドハットが公開している解説を参照するといいだろう。

レッドハットによるオペレータの解説：Kubernetes Operator とは

アンチパターンの紹介

ここから、やってはいけないことを中心にサイボウズの経験を踏まえて事例を紹介していくフェーズとなった。

宣言的ではないオペレータ

宣言的ではないオペレータとは

Kubernetes自体が宣言的に開発されているのに、オペレータを手続き的に書いてしまうという悪いパターンの解説だ。

実際のソースコードを使って解説

ここではエラー処理において適切にステータスを更新しないことで、次回の処理に不具合が起きてしまうことを例に解説。

良い実装方法を解説

ではどうしたら良いオペレータの実装が可能か？ について、どんなタイミングでエラーが起こってもリコンサイルループを実行すれば復帰ができるようにすることを説明した。またリトライはコードで実行するのではなく、KubernetesのController-runtimeに任せる方法が提案された。

スケーラブルではない実装

スケーラブルではない実装は避ける

次のアンチパターンは、カスタムコントローラがスケーラブルに実行できない実装を避けるべきという例だ。これについてはコントローラがリソースの変化を待つような実装だったり、データベースの更新に処理時間が掛かってしまったりするような実装を例に挙げて説明した。

非同期処理やキャッシュを使う

スケーラブルではないことを避けるための方法として、非同期処理やキャッシュを使って無駄なAPI Serverへのアクセスを減らすやり方を紹介した。

API Serverへのアクセスを減らすための方法を解説

特にAPI Serverへのアクセスが集中することがKubernetesにおける性能劣化の要因とも考えられているために、カスタムコントローラがAPI Serverへのアクセスを減らすことは重要だろう。ここではそのための方法論を解説した。