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

片づけないオペレータ

カスタムリソースを片づけないオペレータとは

ここではユーザーがカスタムリソースを削除したにも関わらず、それを制御するコントローラが作成したリソースが残ってしまうということに起因する問題点を、実例を挙げて説明している。

そして不要となったリソースを片づける方法について解説し、リソースの親子関係を定義できるOwner Referenceを利用して不要なリソースを削除する方法であるFinalizerを使う方法を紹介した。

リソース削除の方法を紹介

Finalizerはkubectlコマンドでカスタムオブジェクトを削除する前に、一旦Finalizationという状態にアップデートした後で、実際のオブジェクトを削除するという動きをするものであると公式ドキュメントには記述されている。ここでは「Owner Referenceで削除できないものを削除する」という解説がなされている。

Finalizerについては以下の公式ドキュメントも参照されたい。

Owner ReferenceやFinalizerの使い方：Using Finalizers to Control Deletion

またデータベースなどのステートフルなアプリケーションを削除する場合の経験則を解説したのが次のスライドだ。

ステートフルアプリケーションの削除に関する経験則

ここではサイボウズが開発し、公開しているオペレータであるMOCOを例にとって解説している。MOCOはMySQLを運用するためのオペレータだ。

Mocoを紹介するブログ：MOCO - Kubernetes 用 MySQL クラスタ運用ソフトウェア

このブログ記事ではサイボウズがメインに利用しているMySQLのためのオペレータを自社で開発した理由が記されている。それは、Oracleが開発するオペレータや、Perconaが開発するオペレータなどを比較検討した結果、どれもサイボウズが必要とする機能を満たしていなかったからだ。2021年6月の時点のブログだが、最後の部分に「MOCO は現時点で最も機能が充実している MySQL オペレータの一つです」と書かれており、MySQLをKubernetesの上で利用している企業は要チェックだろう。

MOCOのGitHubレポジトリ：https://github.com/cybozu-go/moco

身勝手なリソースの更新

次のアンチパターンは、オペレータが他のコントローラやユーザーなどによる操作を考慮せずにリソースを更新してしまうことに関わるトラブルだ。

身勝手なリソースの更新を行うのはアンチパターン

ここではリソースに関する更新合戦が起きることで、予期しない不具合が起きることを解説。例としてArgoCDとRookに関する問題を紹介している。Rookは、2020年にCNCFのインキュベーションプロジェクトからGraduateした、ストレージのためのソフトウェアだ。サイボウズもコントリビューターとして名前が挙げられている。

ArgoCDとRookの更新合戦の概要を説明

このスライドではRookがカスタムリソースを更新した後にArgoCDがラベルを追加するが、その後にRookが上書きすることでArgoCDが追加したラベルがなくなってしまうというバグを解説している。

更新合戦を抑止するSSA（Server-Side Apply）を紹介

このように複数のコントローラがリソースを更新し合う競合状態を避けるための仕組みとして、Server-side Apply（SSA）を紹介。SSAはKubernetes 1.22でGAになった新しい機能だ。

SSA公式ドキュメント：@<href>https://kubernetes.io/docs/reference/using-api/server-side-apply/}

無口なオペレータ

またオペレータが必要な情報を出力しないことで運用が難しくなる事例も紹介し、運用担当者にとって適正な運用を行うための情報を確認した上で、ステータス、ログ、メトリクスなどを出力しようと説明した。

運用側に必要な情報を出力することがベストプラクティス

エラーケースを考慮していないテスト

そして、障害が起こることを想定してテストを作成することが必要であると解説。オペレータは運用を楽にするためのものだが、実際に運用面で何が必要になるのか？ については運用経験者の意見を聞くことを推奨した。

カオスエンジニアリングを実行してみるのも良い

開発者や運用担当者が想定したテストだけでは起こり得る障害には対応できない可能性があるため、池添氏はカオスエンジニアリングを使ってみるのも良い方法論であると解説。実際にサイボウズでは毎週、ステージング環境で全サーバーを再起動するというゲームディを実施しているという。運用の習慣としてカオスエンジニアリングを組み込むことで、想定できない現象に対応できると説明した。

サイボウズが本番で活用するMySQL運用の知見が盛り込まれたセッションとして、非常に参考になる情報が盛り込まれていると思われる。最後にカオスエンジニアリングを推奨することでクラウドネイティブなシステムを運用する際の「障害を恐れない」というスタンスが垣間見ることができたのは、クラウドネイティブを目指すエンジニアには参考になったのでないだろうか。

池添氏のGitHubページに補足資料も公開されているので参考にして欲しい。

補足資料のページ：Kubernetesオペレータのアンチパターン＆ベストプラクティス 補足資料