Kubernetes オペレーターを構築するための原則

著者 |シルヴァン・カラシュ

翻訳者 |張野貴

Kubernetes (略して K8s)上のデータサービスの自動化がますます普及しています。 K8s上でステートフルワークロードを実行するには、 Operatorを使用する必要があります。しかし、現在では進化して非常に複雑になっており、 Operatorなどのアプリケーションパターンや拡張メソッドが開発者やオペレーターの間でますます人気が高まっています。

しかしエンジニアはK8を書くことが多い Operatorの複雑さは非常に大きく、エンドユーザーに影響を与えます。 2021年のK8sデータレポートによると、 K8s Operatorの品質が原因で、同社はK8s のプレゼンスをさらに拡大することができませんでした。

Anynines の CEO である Julian Fischer 氏は、ほぼ 10 年にわたって自動化ツールを構築しており、クラウドネイティブプラットフォームやK8sなどの分散インフラストラクチャで状態管理を扱う複雑さをよく理解しています。

Julian 氏はまず、オペレーターを構築する際に従うべきアプローチについて説明しました。これは、彼が「運用モデル」と呼んでいるもので、次の 4 つの部分に分かれています。

レベル1:システムオペレーターまたはDBが行うこと
レベル 2: コンテナ化、YAML + kubectl
レベル 3:演算子の記述
レベル4:オペレータライフサイクル管理

彼の共有を通じて、データサービスの自動化における一般的な落とし穴とその回避方法を理解し、技術的および方法論的観点からより優れたK8 を記述できるようになります。オペレーター。

データサービスの自動化

これは、データサービスの自動化とK8sの一般的なトピックの間を少し飛び越えています。一般的に言えば、データサービスの自動化について話す場合、最初に行う必要があるのは、範囲、つまりデータサービスの自動化が実際に何を意味するのかを明確にすることです。私たちの使命は、さまざまなデータサービスのライフサイクル全体を完全に自動化し、インフラストラクチャ全体にわたるクラウドネイティブプラットフォーム上で大規模に実行することです。

これはマーケティングの策略ではなく、データサービスの自動化の範囲を定める方法の例です。たとえば、複数のデータサービスを自動化するには、 Operatar SDK 以外のデータサービスなどの共有効果を自動化フレームワークに組み込む必要があります。したがって、タスクのコンテキストが大きな影響を与える可能性があります。たとえば、単純なK8sクラスターには、アプリケーションを実行する小さなユニットがあります。 Postgres データベースを想定します。 Postgres は常に私のお気に入りの例です。ご存知のとおり、1 つのK8sクラスターは 1 つの Operator と 1 つのサービスインスタンスに対応し、アプリケーションはそのデータベースに接続します。それは今日ここで話したいこととは別の話です。オンデマンドでサービスインスタンスをプロビジョニングすると仮定すると、Postgres データベースはステートフルセットとして表されます。演算子を使用すると、複数のインスタンスを作成できます。処理しなければならないデータサービスインスタンスが増えるため、状況は複雑になります。その後、さらに多くのデータサービスを導入し、たとえば、RabbitMQ、MongoDB、またはその他のデータベースを Operator のコレクションに追加すると、課題はさらに大きくなります。

私たちが協力している組織には、数百から数千人の従業員、数千から 1 万人の開発者、そして信じられないほど多くのエンジニアがおり、また、多くのK8sクラスターも存在します。数十または数百のK8sクラスターが私たちの経験のテストになると考えています。たとえば、仮想マシンベースのデータサービスの自動化では、クラスターの形成方法に応じて、数千の仮想マシンで数千のサービスインスタンスが実行されることがよくあります。 3 つのポッドを持つ 1 つのサービスインスタンスがあり、次のような小さなクラスターインスタンスを実行していると想定できます。現在の規模では、自動化の要件は頻繁に変更されるため、規模に大きな影響を与えます。

ソーセージの製造や配布などの単純なタスクを解決する場合、より大きなユーザーベースにサービスを提供するには、スタックテクノロジソリューションを適応させる必要があることは想像に難くありません。データサービスの自動化もほぼ同じです。したがって、大規模なアプリケーションシナリオについて考えると、このようなサービスインスタンスが多数存在し、各データサービスインスタンスは一部のユーザーにとって重要です。したがって、自動化は一定の基準を満たす必要があります。自動化の基準が満たされていない場合、自動化は使用されず、組織的および技術的な採用は行われません。

K8sデータサービスの使用

では、 K8sデータサービスをどのように使用すればよいのでしょうか?まず、コミュニティが知っておくべきだと思うのですが、Operator をどのように実装するのでしょうか?最も簡単な方法は、 K8s 、CRD、カスタムリソース定義を使用して、新しいデータ構造をK8sに転送することです。たとえば、Postgres インスタンスを記述する場合、オンデマンドでプロビジョニングしており、インスタンスの管理を担当するコントローラーがあるため、複数の Postgres インスタンスを作成します。コントローラーは、指定したオブジェクトの仕様を取得し、それを実行可能なプログラムに変換します。したがって、基本的に Operator が行うことは、Postgres 12.2 バージョンのプライマリオブジェクト (Postgres インスタンスなど) の仕様をセカンダリリソースに変換することです。私の知る限り、Operator SDK は CRD の構築、CRD の生成、コントローラーのテンプレートコードの提供を行う主流のツールです。これらは、 K8s関連のデータサービスの自動化について議論する際に私たちが考えた 2 つのことです。一方、KUDOがいる。

これに興味がある方は、数週間前に DoK コミュニティミーティングでデータサービス自動化について講演しました。とても興味深い内容でしたが、今日ここでプロトタイプについてさらに詳しく説明することはできません。

開発フェーズで Operator を開発する場合、この作業をどのように体系的に処理するかが課題の 1 つになります。最初に紹介されたデータサービスの自動化に取り組むのに役立つ、運用モデルと呼ばれる 4 つのレベルに分かれたシンプルなモデルがあります。

建設的なフィードバックを与え、タスクに集中し続けてください。たとえば、最初のレベルで Postgres を自動化することをお勧めします。まず最初に理解する必要があるのは、アシスタントまたは DBA が何をするのかということです。特に、これはアプリケーション開発者にどのような影響を与えるのでしょうか?彼らは何を望んでいるのでしょうか?

たとえば、平均的なアプリケーション開発者は Postgres に何を期待しているのでしょうか?自動フェイルオーバー機能を備えたクラスター化されたインスタンスが必要ですか?この場合、同期レプリケーションと非同期レプリケーションのどちらが優先されますか?どのフェイルオーバーおよびクラスターマネージャーを使用しますか、または優先するリポジトリマネージャー (より正確には Prometheus) を使用しますか?

そして、基本的には、構成ファイルの構成方法を理解し、運用モデルレベルである Postgres の基本的なセットアップを行う必要があります。仮想マシンがあり、パッケージのインストール、データベースの構成など、何でもできると仮定します。そのため、それを実行し、構成ファイルがどのようになるかがわかれば、これらすべてを Operator で実行できます。コンテナ化について考えてみましょう。これは、既存のコンテナイメージを取得し、それらをステートフルなサービスセットのK8s仕様に組み立て、運用モデルの第 2 レベルの YAML 部分である独自のテンプレートを作成するものです。したがって、運用モデルのレベル 2 の最終操作では、既存のコンテナイメージを選択した場合でも、自分で作成した場合でも、 kubectl で使用できるK8s仕様を使用して、独自のサービスインスタンスを手動で作成できます。これを実行すると、基本的に、たとえば 3 つのレプリカと同期ストリーミングレプリケーションを備えた Postgres インスタンスを作成できます (手動で行う方法が既にわかっている場合)。その後、問題について考え、gde を記述し、特定の機密データを処理するためのヘッドレスサービスの特定のステートフルセットアップを作成することで、このようなオペレーターをより簡単に実装できます。

ここで、私たちが話しているのは、何千ものデータサービスインスタンス、つまり多数のK8sクラスターにわたる複数のデータサービスが含まれる可能性がある環境であることを思い出してください。この文脈では、Operator ライフサイクル管理自体がツールチェーンの重要な部分であることも認識する必要があります。したがって、Operator 自体のライフサイクルを管理するための自動化も必要です。

Operator Lifecycle Manager であろうと、その他のテクノロジであろうと、この時点では関係ありません。最も重要なことは、これが全体的なデータサービス自動化の課題の一部であることを理解するということです。さて、 K8s Operatorについて考えてみると、カスタムリソース定義について言及すると、このような YAML 構造は、 K8s API に渡すことができる新しいデータ型を記述し、ノードをプロビジョニングして、仕様を etcd に永続的に保存します。ここでのフォーマットはあまり良くありません。ただし、ここでは特定のリソース定義のカスタムリソースがどのようになるかを確認でき、 K8s にそのようなオブジェクトを作成する方法を教えます。

ただし、オブジェクトの作成など、コードを通じてイベントの監視を実装するコントローラーが必要であるため、CRD だけでは効果がありません。コントローラーは、この特定のサービスインスタンスが既に存在するかどうかを確認し、アクセスするためにサービスキーを必要とする補助リソースと、作成する必要があるステートフルセットを識別できます。前に述べたように、 K8sコントローラーは基本的にプライマリリソースをセカンダリリソースの組み合わせに変換します。これまでの例では、これらのリソースはK8s内部のものでしたが、必ずしもそうである必要はありません。これについては後で議論しましょう。

それでもオペレーターの作成を開始したい場合は、Operator SDK によってオペレーターの成熟度レベルに関する提案が行われ、オペレーターは 5 つの異なるレベルに分けられます。皆さんがこれらのレベルの違いを理解しているかどうか、私にはよく分かりません。しかし、今から始めれば、これは間違いなく良いスタートです。適切な質問をする方法を学びましょう。適切な質問はドキュメントにも記載されています。 Operator を構築する場合は、バックアップなしでパッチを更新する機能や、バックアップおよび復元機能など、いくつかのコア機能を使用する必要があります。多くの場合、これらは必須ですが、ユーザーがソリューションを拒否したり、ソリューションを持っていなかったりする場合があります。しかし、遅かれ早かれこれを実行しなければならないことはわかっているので、これは役に立つでしょう。したがって、分散システムにはプログラミングの問題によって引き起こされる一般的な落とし穴やバグが多数存在し、それらをどれだけ排除できるかにかかっていることを覚えておいてください。

たとえば、企業でのGitの使用によって発生する問題などです。私の経験では、データサービスの自動化全般における最大の問題は、基本的なライフサイクル操作のカバー範囲が不十分であったり、堅牢性や可観測性などの品質特性が低いという形で、データサービスの自動化に必要な複雑さと労力を過小評価していることである可能性が高いです。これを踏まえて、使用の閾値を理解する必要があります。ターゲットユーザーに受け入れられるためには、自動化で何を行う必要があるかを把握する必要があります。対象とするオーディエンス自体に大きく依存しますが、大規模なクライアントにとって重要だが、現時点では時間が足りないため少し時間がかかるため、完了できないことを私が学んだことのいくつかを今では共有できます。

アプリケーション開発者は自動構成を通じてデータベースとアプリケーションを使用できるため、構成の更新を受け入れることは重要です。アプリケーションに特別な要件がある場合は、データベース構成を少し調整する必要があるかもしれません。リソースを可能な限り最大限に活用することが本当に必要です。したがって、ターゲットユーザーにインタビューして、これらの構成オプションが自動化ドキュメントにすでに含まれているかどうかを把握する必要があります。自動化を特定のニーズに合わせて適応させる能力が必要です。組織内にさらに多くの開発者がいることがわかっている場合は、フレンドリーな可観測性、インフラストラクチャの透過的な使用など、クラウドネイティブの要件がすべて揃っています。 K8s では、ある程度はすでにそれが実現されています。しかし、バックアップのコンテキストでは、バックアップをどこかに保存する必要がある場合、通常はバックアップをオブジェクトストレージに書き込む必要があります。ここで、S3 API の存在について人々が仮定を立てます。例:基礎となるオブジェクトストレージを非表示にする抽象化ライブラリを選択する必要があります。

サービスインスタンスの水平スケーラビリティ

たとえば、サービスインスタンスが必要な場合は、ポッドを備えた単一の Postgres、または非同期ストリーミングレプリケーションを備えたクラスター化された Postgres を検討できます。レプリカを 1 つから 3 つに水平方向に拡張しようとすると、自動化に多くの複雑さが生じます。 Postgres は自動化がそれほど簡単ではないため、例として使用されることが多いです。したがって、障害検出を実行するにはクラスターマネージャーを追加する必要があり、これを実現するためにマスターノードの選択とマスターノードの昇格のロジックが必要です。

さらに、複数のアベイラビリティゾーンを持つデータセンターがある場合は、単一のK8sノードが存在しないように、ポッドを分散してそれらを使用できます。利用可能なゾーンであり、 K8sクラスターが確立されている限り、ほぼ 100% がこの方法で使用されます。一般的に、状態セットは、計画、切り替え、アップグレード、またはポッドを大きくするための垂直スケーリングなど、ライフサイクル全体を通じて何度も再構築され、データがマージされます。バックアップとリカバリの問題に戻りますが、これは明らかに非常に重要です。なぜなら、アプリケーション開発者は、アプリケーションを復元するためにプラットフォームオペレーターの手動介入を待つ必要がなくなるためです。これは通常、最後の手段です。

つまり、オンデマンドのセルフサービスがすべてであり、現時点では、アプリケーション開発者はセルフサービスでサービスインスタンスを作成し、それを変更して再構成することができ、サービスインスタンスが異常な動作をしたり、データが誤って削除されたりした場合は、潜在的なデータ損失を防ぐために、アプリケーションの要件に従ってデータを復元する必要があります。

あまり明白ではない要件として、データサービスの最新バージョンを提供することが求められる場合があります。 Postgres の最新バージョンが優れていると仮定すると、アクティブユーザーは当然それを気に入るはずです。ただし、組織によっては、一部のアプリケーションが長期メンテナンス状態にあり、新しいバージョンがすぐに使用されない場合があります。したがって、アプリケーション開発者は、データサービスのバージョンを選択でき、バージョン番号を使用してオペレーターを管理し、すべての自動化されたバージョンのアクティブ化と非アクティブ化をサポートできる必要があります。これは自動化に必要なポリシーです。また、提供したバージョンが多すぎると、チームに多大なサポートが必要になることもあります。ただし、ドキュメントによってサポートが減少する可能性もあります。

セキュリティも非常に重要であり、通常は暗号化されたストレージと送信の暗号化が必要です。たとえば、読み取られたり使用されていないディスク上のデータや、クライアントからデータサービスインスタンスに送信されるデータを暗号化し、ステートフルな集中エンドポイントをすべて暗号化する必要があります。

サービスバインディング

これらのサービスインスタンスはすぐになくなるわけではないことに注意してください。確かにその通りかもしれませんが、長期間使用されるアプリケーションの場合、サービスインスタンスは何年も存続することがあります。ライフサイクルのユースケースとサービスインスタンスに何が起こるかを考えると、このリストよりもはるかに長いリストが得られます。しかし、これは、規模縮小と規模拡大の両方の面で、何が起きる可能性があるのかを初めて知る機会となります。さまざまなバージョンアップグレードの後、アプリケーションはサービスインスタンスにバインドされます。ここではこれをサービスバインディングと呼びます。また、ネットワークパーティションやネットワーク帯域幅および遅延の変動も処理します。

アプリケーションとデータサービスインスタンス間の接続を表すこれらすべてのサービスバインディングについて考慮する必要があります。たとえば、異なるアプリケーションのマイクロサービスが同じサービスインスタンスに接続する場合、キーが一意になるように、各アプリケーションが専用の Postgres ユーザーを持つ Postgres などのデータサービスインスタンスにアクセスできるのが最適です。

このようなサービスをバインドするには、まずストレージ資格情報領域にキーを作成し、次に実際のデータサービスユーザーを作成するという 2 つの操作を行う必要があります。

これにはいくつか複雑な点がありますが、それについては後で説明します。私の意見では、データサービスの自動化の同様の側面は CRD として表現されるべきであり、 K8s はバックアップとバックアッププランです。したがって、特定のサービスインスタンスのバックアップを作成する場合は、それを CRD として記述します。ジョブや cron ジョブと同様に、バックアッププランでは、これらのバックアップが定期的にどのように作成されるかを説明します。

さて、方法論的な観点から見ると、データサービスの自動化には、従うとメリットが得られる可能性がある原則がいくつかあります。技術的なポイントに戻る前に、考慮すべき原則として、前に見たように、対象者、要件、期待される品質を理解することが重要です。また、チームが特定のデータソースに大きく依存しているかどうかなど、何かを行うかどうかも理解する必要があります。

企業全体が 1 つ、またはいくつかの MongoDB インスタンスを中心に成長した例を私は見てきました。したがって、このケースの Operator の構築は、前に説明したコンテキストとは異なります。したがって、コンテキストは、優れたデータサービス自動化の中核要素の 1 つであることに注意してください。データサービスを賢く選択することも重要です。前にも述べたように、Postgres のようなものを自動化するには、多くの作業を行う必要があります。他のデータサービスでは、ライセンスが変更されたり、オープンソースから移行したりすることがあり、ライセンスの問題が発生する可能性があり、その問題にも対処する必要があります。したがって、通常、たとえば、オンデマンドでプロビジョニングする、オープンソースライセンスを持つ単一のベンダーによってサポートされているデータサービスは、ツールセットを変更するたびに再作成される可能性が高くなります。したがって、これは、障害が発生したインスタンスを修復するのではなく再構築することで解決される問題です。

既知の状態の再構築は、問題解決に役立つツールとして使用できます。また、場合によっては、先に説明したように、最初に運用モデルを使用すること、自動化作業を開始する前にデータサービスを理解すること、バックアップとリカバリの消防士になることが必要かつ重要です。これは、運用呼び出し、プラットフォームオペレーターの電話が鳴る前の最後の手段であるため、回避できます。

したがって、複数のデータサービスを自動化すると、それらの間に多くの相乗効果が生まれます。これも、同じ枠組みに組み込む必要があります。フレームワークには、コントローラー間で共有できるコードベースがあるかもしれませんが、コンテナーイメージにあるスクリプトや、テストなどの構成も重要です。自動化では基本的にコードを記述し、そのコードは多くの環境に配布され、それらの環境からサービスのインスタンスが多数作成されるためです。

コードと生成されたサービスインスタンスのテストカバレッジが良好で、統合テスト (何と呼んでも構いません) を使用してユースケースを順に確認するのは、非常に楽しいことです。私の提案は、これらのシナリオ用のテストケースを用意し、自動化にまだ弱点があることがわかっている場合は、テストケースのテストリポジトリを顧客と共有し、顧客に伝えて、ローカル環境でそれらのテストを実行できるようにすることです。信頼が生まれるからです。また、問題を回避するために何を監視できるかをよりよく理解する機会も得られます。

アップストリームソースコードにパッチを適用しないというのは、私たちが採用している原則です。これは、私たちがフォークしてプルリクエスト、ホットフィックス、一時的なホットフィックスを許可しているさまざまなデータサービスが多数あるためです。マスターリリース管理とは、Postgres リリースが行われた日から自動リリースが行われる日までの遅延が最小限に抑えられることを意味します。自動化を有効にしたら、アプリケーション開発者がインスタンスをアップグレードできるように、そのリリースをターゲット環境に迅速に配信する必要があります。

例

時間が迫っているので、テクノロジーについてはあまり語りません。コントローラーを作成するときに、初めて外部リソースを呼び出す場合は、少し注意が必要です。サービスバインディングの例では、キーを作成し、Postgres データベースユーザーも作成する必要があります。

さて、これを行うにはいくつかの方法があります。しかし、全体としての課題は、これら 2 つのリソース間の一貫性をどのように確保するかということです。答えは、2 レベルのアプローチを採用することです。このアプローチでは、たとえば Postgres ユーザーをカスタムリソースとして表し、そのためのコントローラーを用意し、コントローラーを単一の目的 (これらの Postgres ユーザーをオーケストレーションすること) を持つように設定して、K8s と Postgres ユーザーがすでに認識しているセカンダリリソースであるキーを作成するときに、サービスバインディングコントローラーの複雑さを軽減できるようにします。すでに CRD として存在する場合は、K8s クラスターに認識されるリソースでもあります。主なポイントの 1 つとして、ここではアトミック性の保証はなく、トランザクションもありません。したがって、宣言的なアプローチを使用する方が慣用的であり、K8s では、最終的に K8s と一貫性があるため、データの状態が不一致であっても許容されます。 Postgres ユーザーを作成できない場合は、私たちが調整を試みることに注意してください。

ループが同じ仕様でサービスを再度呼び出す場合でも、ここでスタックしたりエラー状態になったりしないように、操作をべき等性に保ちます。したがって、ユーザーを作成する代わりに、存在しないユーザーを作成する代わりに、さらに多くのことを行うことができます。上記の例は、考えるための単純な例です。

最後に共有したいのはキャッシュです。コントローラーでリソースを変更する場合、基本的には K8s API を使用して変更することになり、ローカルキャッシュに変更が直接かつ即座に反映されない可能性があり、予期しない動作が発生することがあります。したがって、特に階層型コントローラーを扱う場合には、ローカルキャッシュの更新とK8s API 内のオブジェクトの更新の間に遅延が生じる可能性があることに注意してください。

最後に、この講演の技術的な部分は少し短く、データサービスの自動化の一般的な課題と、対象ユーザーを理解することの重要性について多くの議論がありました。また、特定の演算子を記述するときにコンテキストがタスクにどのように影響するかについても説明します。よくリクエストされるアイデアをいくつか紹介します。これは良いスタートかもしれません。独自の Operator を作成する場合は、これがアプリケーション開発者に必要なものであるかどうかを自問してみてください。そうでない場合は、彼らと話し、彼らの視点を理解するように努めてください。それでは、最初の一歩を踏み出してみてください。