データベース クラスターを管理するための Kubernetes のオペレーター。 ウラジスラフ・クリメンコ (アルティニティ、2019)

このレポートは、Kubernetes でのオペレーターの開発、そのアーキテクチャーおよび基本的な動作原理の設計に関する実践的な問題に焦点を当てています。

レポートの最初の部分では、次のことを検討します。

• Kubernetes のオペレーターとは何ですか?なぜ必要ですか。
• オペレーターが複雑なシステムの管理をいかに正確に簡素化するか。
• オペレーターができること、できないこと。

次に、オペレーターの内部構造について説明します。 オペレーターのアーキテクチャと操作を段階的に見てみましょう。 詳しく見てみましょう:

• オペレーターと Kubernetes の間の対話。
• オペレーターが引き受ける機能と、Kubernetes に委任する機能。

Kubernetes でのシャードとデータベース レプリカの管理を見てみましょう。
次に、データ ストレージの問題について説明します。

• オペレーターの観点から永続ストレージをどのように扱うか。
• ローカル ストレージを使用する場合の落とし穴。

レポートの最後の部分では、実際の応用例を検討します。 クリックハウスオペレーター Amazon または Google クラウド サービスを使用します。 このレポートは、ClickHouse のオペレーターの開発および運用経験の例に基づいています。

ビデオ：

私の名前はウラジスラフ・クリメンコです。 今日は、データベースクラスターを管理するための専門オペレーターであるオペレーターの開発と運用の経験について話したいと思います。 例えば ClickHouse オペレーター ClickHouse クラスターを管理します。

なぜ運営者とClickHouseについて話す機会があるのでしょうか?

• 私たちはClickHouseをサポートし、開発しています。
• 現在、私たちは ClickHouse の開発に少しずつ貢献しようとしています。 また、ClickHouse に加えられた変更の量に関しては、Yandex に次いで XNUMX 位です。
• 私たちは、ClickHouse エコシステムのための追加プロジェクトを実行しようとしています。

そのうちの一つのプロジェクトについてお話ししたいと思います。 これは、Kubernetes の ClickHouse オペレーターについてです。

私のレポートでは、次の XNUMX つのトピックについて触れたいと思います。

• 最初のトピックは、ClickHouse データベース管理オペレーターが Kubernetes でどのように機能するかです。
• XNUMX 番目のトピックは、オペレーターがどのように機能するか、つまりオペレーターがどのように Kubernetes と対話するかです。

ただし、これら XNUMX つの質問は私のレポート全体で交差します。

私の言おうとしていることに興味を持って聞く人がいるだろうか？

• オペレータを運用する人にとっては最も興味深いことでしょう。
• または、内部でどのように動作するか、オペレーターが Kubernetes とどのように対話するか、どのような落とし穴が現れるかを理解するために独自に作成したいと考えている人向けです。

今日説明する内容を最もよく理解するには、Kubernetes がどのように機能するかを理解し、基本的なクラウド トレーニングを受けることをお勧めします。

クリックハウスとは何ですか？ これは、分析クエリのオンライン処理のための特定の機能を備えた列指向データベースです。 そしてそれは完全にオープンソースです。

そして、私たちにとって重要なことは XNUMX つだけです。 これはデータベースであることを理解しておく必要があるため、ここで説明する内容はほぼすべてのデータベースに当てはまります。 また、ClickHouse DBMS は非常にうまく拡張できるため、ほぼ直線的な拡張性が得られます。 したがって、クラスターの状態は ClickHouse にとって自然な状態です。 そして、私たちが最も興味を持っているのは、Kubernetes で ClickHouse クラスターを提供する方法について議論することです。

なぜ彼がそこで必要とされるのでしょうか？ なぜ自分たちだけで運営を続けられないのでしょうか？ そしてその答えは、部分的には技術的なものであり、部分的には組織的なものです。

• 実際、大企業ではほぼすべてのコンポーネントがすでに Kubernetes にあるという状況に遭遇することが増えています。 データベースは外部に残ります。
• そして、「これを屋内に設置できるのか？」という疑問がますます高まっています。 したがって、大企業はデータ ウェアハウスを迅速に管理できるようにするために、管理の最大限の統合を実現しようとしています。
• これは、新しい場所で同じことを繰り返す最大限の機会、つまり最大限の移植性が必要な場合に特に役立ちます。

どれくらい簡単ですか、それとも難しいですか? もちろん、これは手作業で行うこともできます。 しかし、これはそれほど単純ではありません。Kubernetes 自体の管理がさらに複雑になり、同時に ClickHouse の詳細も重ね合わされるためです。 そして、このような集計結果が得られます。

これらをすべて合わせると、かなり大規模なテクノロジのセットが得られますが、Kubernetes は日常の運用に独自の問題をもたらし、ClickHouse は日常の運用に独自の問題をもたらすため、管理が非常に困難になります。 特に、複数の ClickHouse があり、それらに対して常に何かを行う必要がある場合は特にそうです。

動的構成の場合、ClickHouse には、DevOps に一定の負荷をもたらす非常に多くの問題があります。

• たとえば、レプリカやシャードを追加するなど、ClickHouse で何かを変更したい場合は、構成を管理する必要があります。
• ClickHouse には特定のシャーディング方法があるため、データ スキーマを変更します。 そこではデータ図をレイアウトし、構成をレイアウトする必要があります。
• 監視を設定する必要があります。
• 新しいシャード、新しいレプリカのログを収集します。
• 復元に気をつけてください。
• そして再起動。

これらは日常的なタスクなので、もっと使いやすくしたいと思っています。

Kubernetes 自体は運用には役立ちますが、基本的なシステムに関しては役に立ちます。

Kubernetes は、次のようなことの促進と自動化に優れています。

• 回復。
• 再起動。
• ストレージ システムの管理。

それは良いことです。それは正しい方向ですが、彼はデータベース クラスターの運用方法についてはまったくの無知です。

私たちはさらに多くのことを望み、データベース全体を Kubernetes で動作させたいと考えています。

私は、大きな魔法の赤いボタンのようなものを手に入れたいと考えています。これを押すと、解決する必要がある日常的なタスクを含むクラスターがデプロイされ、ライフサイクル全体にわたって維持されます。 Kubernetes の ClickHouse クラスター。

そして、作業を容易にするソリューションを作成しようとしました。 これは、Altinity の Kubernetes 用 ClickHouse オペレーターです。

オペレーターは、他のプログラムを管理することを主なタスクとするプログラム、つまりマネージャーです。

そしてそこには行動パターンも含まれています。 これは、主題分野に関する体系化された知識と呼ぶことができます。

そして、彼の主なタスクは、DevOps の生活を容易にし、マイクロマネジメントを減らすことです。そうすることで、彼 (DevOps) は既に高レベルの観点から考えるようになります。つまり、彼 (DevOps) がマイクロマネジメントに従事しないように、つまり、設定を行わないようにすることです。すべての詳細は手動で行います。

そして、オペレーターだけが、マイクロタスクを処理し、DevOps を支援するロボットアシスタントです。

なぜオペレーターが必要なのでしょうか? 彼は次の XNUMX つの分野で特に優れたパフォーマンスを発揮します。

• ClickHouse を扱う専門家が十分な経験を持っていないが、すでに ClickHouse を操作する必要がある場合、オペレーターは操作を容易にし、すべての仕組みについてあまり詳しく説明することなく、かなり複雑な構成で ClickHouse クラスターを操作できるようにします。内部。 彼に高度なタスクを与えるだけで、うまくいきます。
• そして、最も効果を発揮する XNUMX 番目のタスクは、多数の一般的なタスクを自動化する必要がある場合です。 システム管理者からマイクロタスクを削除します。

これは、旅を始めたばかりの人、または多くの自動化を行う必要がある人のいずれかに最も必要とされます。

オペレーターベースのアプローチは他のシステムとどう違うのですか? ヘルムがいる。 また、ClickHouse のインストールにも役立ち、ClickHouse クラスター全体をインストールするヘルム チャートを描画することもできます。 では、オペレーターと同じもの (例えば Helm) との違いは何でしょうか?

主な基本的な違いは、Helm がパッケージ管理であり、Operator がさらに一歩進んでいることです。 これはライフサイクル全体のサポートです。 これは単なるインストールではなく、スケーリング、シャーディング、つまりライフサイクル中に実行する必要があるすべての作業 (必要に応じて削除も) を含む日常的なタスクであり、これらはすべてオペレーターによって決定されます。 ソフトウェアのライフサイクル全体を自動化して維持しようとします。 これが、提示されている他のソリューションとの基本的な違いです。

ここまでが導入部分でした。次に進みましょう。

オペレーターを構築するにはどうすればよいでしょうか? 私たちは、ClickHouse クラスターを単一のリソースとして管理するという問題にアプローチしようとしています。

ここでは、図の左側に入力データがあります。 これはクラスター仕様を含む YAML であり、kubectl を介した従来の方法で Kubernetes に渡されます。 そこでオペレーターがそれを手に取り、魔法を実行します。 そして出力では次のスキームが得られます。 これは、Kubernetes での ClickHouse の実装です。

次に、オペレーターがどのように正確に機能するか、どのような典型的なタスクを解決できるかをゆっくりと見ていきます。 時間が限られているため、代表的なタスクのみを検討します。 また、運営者が決定できるすべてのことが議論されるわけではありません。

まずは練習から始めましょう。 私たちのプロジェクトは完全にオープンソースなので、GitHub でどのように動作するかを確認できます。 そして、単に起動したいだけであれば、クイック スタート ガイドから始めることができるという検討から進めることができます。

詳細を理解したい場合は、多かれ少なかれまともな形式でドキュメントを維持するよう努めます。

実践的な問題から始めましょう。 最初のタスクは、誰もが始めたいと思うところですが、最初の例を何らかの方法で実行することです。 仕組みがよくわからない場合でも、オペレーターを使用して ClickHouse を起動するにはどうすればよいですか? 私たちはマニフェストを書いているので... k8s とのすべての通信はマニフェストを介した通信です。

これは非常に複雑なマニフェストです。 赤で強調表示されているものは、焦点を当てる必要があるものです。 オペレーターに、demo という名前のクラスターを作成するように依頼します。

これらは現時点では基本的な例です。 ストレージについてはまだ説明されていませんが、少し後でストレージについて説明します。 今のところ、クラスターの発展のダイナミクスを観察します。

私たちはこのマニフェストを作成しました。 それをオペレーターにフィードします。 彼は働き、魔法を作りました。

コンソールを見てみます。 XNUMX つのコンポーネント (Pod、XNUMX つの Services、および StatefulSet) が重要です。

オペレーターは作業を行っており、彼が正確に何を作成したかを見ることができます。

彼はこのようなものを作成します。 StatefulSet、Pod、各レプリカの ConfigMap、クラスター全体の ConfigMap があります。 サービスはクラスターへのエントリーポイントとして必要です。

サービスは中央のロード バランサー サービスであり、各レプリカや各シャードに使用することもできます。

基本的なクラスターは次のようになります。 それは XNUMX つの単一ノードからのものです。

さらに話を複雑にしてみましょう。 クラスターをシャーディングする必要があります。

私たちの任務は増大しており、ダイナミクスが始まっています。 シャードを追加したいと考えています。 私たちはその発展を追っていきます。 仕様を変更させていただきます。 XNUMX つのシャードが必要であることを示します。

これは、システムの成長に応じて動的に開発される同じファイルです。 ストレージ いいえ、ストレージについてはさらに詳しく説明します。これは別のトピックです。

YAML オペレーターにフィードして、何が起こるかを確認します。

オペレーターは以下のエンティティを考えて作成しました。 すでに 2 つの Pod、2 つの Service、そして突然 XNUMX つの StatefulSet があります。 なぜ XNUMX つの StatefulSet があるのでしょうか?

図では次のようになりました。これは、ポッドが XNUMX つあったときの初期状態です。

このようになりました。 ここまではすべて単純であり、複製されています。

そして、なぜ StatefulSet が XNUMX つになったのでしょうか? ここで話が逸れ、Kubernetes でポッドがどのように管理されるかという問題について議論する必要があります。

StatefulSet というオブジェクトがあり、これを使用してテンプレートから Pod のセットを作成できます。 ここで重要な要素はテンプレートです。 また、XNUMX つの StatefulSet 内の XNUMX つのテンプレートを使用して、多数の Pod を起動できます。 そして、ここでのキーワードは「XNUMX つのテンプレートに多数の Pod」です。

そして、クラスター全体を XNUMX つの StatefulSet に詰め込んで作成したいという大きな誘惑がありました。 動作します、問題ありません。 ただし、注意点が XNUMX つあります。 異種クラスター、つまり ClickHouse の複数のバージョンからクラスターを組み立てたい場合、疑問が生じ始めます。 はい、StatefulSet はローリング アップデートを実行でき、そこで新しいバージョンをロールアウトできます。同時に試行する必要があるノードの数はそれほど多くないことを説明します。

しかし、タスクを推定して、完全に異種のクラスターを作成したいが、ローリング アップデートを使用して古いバージョンから新しいバージョンに変更するのではなく、単に両方の点で異種のクラスターを作成したいとするとします。 ClickHouse のさまざまなバージョンとさまざまなストレージの観点から。 たとえば、一般に、異種クラスタを完全に構築するために、低速ディスク上にいくつかのレプリカを作成したいと考えています。 また、StatefulSet は XNUMX つのテンプレートから標準化されたソリューションを作成するため、これを行う方法はありません。

いろいろ考えた結果、この方法でやることに決まりました。 各レプリカは独自の StatefulSet 内にあります。 このソリューションにはいくつかの欠点がありますが、実際には、オペレータによってすべて完全にカプセル化されます。 そして、多くの利点があります。 たとえば、完全に異種混合のクラスターなど、必要なクラスターを正確に構築できます。 したがって、2 つのレプリカを持つ 2 つのシャードがあるクラスターでは、異種クラスターを構築できるようにするために上記の理由でこのアプローチを選択したため、XNUMX つの StatefulSet と XNUMX つの Pod が存在します。

実際的な問題に戻りましょう。 私たちのクラスターでは、ユーザーを構成する必要があります。 Kubernetes で ClickHouse の構成を行う必要があります。 オペレーターは、これに対するあらゆる可能性を提供します。

YAML で直接必要なものを書くことができます。 すべての構成オプションは、この YAML から ClickHouse 構成に直接マッピングされ、クラスター全体に分散されます。

このように書くことができます。 これは例えばです。 パスワードは暗号化することができます。 完全にすべての ClickHouse 構成オプションがサポートされています。 ここではほんの一例を示します。

クラスター構成は ConfigMap として配布されます。 実際には、ConfigMap の更新は即座には行われないため、クラスターが大きい場合、構成をプッシュするプロセスには時間がかかります。 しかし、これはすべて非常に便利に使用できます。

タスクを複雑にしてみましょう。 クラスターが発達しています。 データを複製したいと考えています。 つまり、すでに XNUMX つのシャード (それぞれ XNUMX つのレプリカ) があり、ユーザーが構成されています。 私たちは成長しているので、複製を行いたいと考えています。

レプリケーションには何が必要ですか?

ZooKeeper が必要です。 ClickHouse では、ZooKeeper を使用してレプリケーションが構築されます。 ZooKeeper は、さまざまな ClickHouse レプリカがどのデータ ブロックがどの ClickHouse にあるかについて合意を得るために必要です。

ZooKeeper は誰でも使用できます。 企業に外部の ZooKeeper がある場合は、それを使用できます。 そうでない場合は、リポジトリからインストールできます。 この作業全体を簡単にするインストーラーがあります。

そして、システム全体の相互作用図は次のようになります。 プラットフォームとして Kubernetes を採用しています。 ClickHouse オペレーターを実行します。 ここでZooKeeperをイメージしました。 そして、オペレーターは ClickHouse と ZooKeeper の両方と対話します。 つまり、相互作用の結果です。

ClickHouse が k8s でデータを正常に複製するには、これらすべてが必要です。

次に、タスク自体、レプリケーションのマニフェストがどのようになるかを見てみましょう。

マニフェストに 4 つのセクションを追加します。 XNUMX つ目は、ZooKeeper を入手する場所です。これは、Kubernetes の内部または外部にあります。 これは単なる説明です。 そしてレプリカを注文します。 それらの。 レプリカが XNUMX つ必要です。 合計で、出力には XNUMX つのポッドが必要になります。 ストレージについては覚えていますが、少し後で戻ってきます。 ストレージは別の話です。

こんな感じでした。

このようになります。 レプリカが追加されます。 4 番目は適合しませんでしたが、多くのものがそこにある可能性があると考えられます。 そしてサイドにZooKeeperが追加されます。 計画はますます複雑になっています。

そして、次のタスクを追加するときが来ました。 永続ストレージを追加します。

永続ストレージにはさまざまなオプションがあります。

たとえば、Amazon や Google などのクラウド プロバイダーで実行している場合、クラウド ストレージを使用したいという大きな誘惑があります。 すごく便利ですよ、いいですね。

そして XNUMX 番目のオプションもあります。 これは、各ノードにローカル ディスクがある場合のローカル ストレージ用です。 このオプションは実装がはるかに困難ですが、同時に生産性も高くなります。

クラウド ストレージに関する情報を見てみましょう。

利点があります。 設定はとても簡単です。 私たちはクラウド プロバイダーに、これこれの容量、これこれのクラスのストレージを提供してくださいと注文するだけです。 クラスはプロバイダーによって独自にスケジュールされます。

そして欠点があります。 一部の人にとって、これは重大な欠点ではありません。 もちろん、パフォーマンス上の問題もいくつかあります。 非常に使いやすく信頼性がありますが、パフォーマンスに潜在的な欠点がいくつかあります。

そして、なぜならClickHouse は生産性を特に重視しており、できる限りすべてを絞り出しているとさえ言えるかもしれません。そのため、多くのクライアントは生産性を最大限に絞り出そうとしています。

それを最大限に活用するには、ローカル ストレージが必要です。

Kubernetes は、Kubernetes でローカル ストレージを使用するための XNUMX つの抽象化を提供します。 これ：

• 空のディレクトリ
• ホストパス。
• ローカル

それらがどのように異なり、どのように類似しているかを見てみましょう。

まず、8 つのアプローチすべてにストレージがあります。これらは同じ物理 kXNUMXs ノード上にあるローカル ディスクです。 しかし、それらにはいくつかの違いがあります。

最も単純なもの、つまり emptyDir から始めましょう。 これは実際には何でしょうか? 私たちの仕様では、コンテナ化システム (ほとんどの場合 Docker) に、ローカル ディスク上のフォルダーへのアクセスを提供するように要求します。

実際には、Docker は独自のパス上のどこかに一時フォルダーを作成し、それをロング ハッシュと呼びます。 そしてそれにアクセスするためのインターフェースを提供します。

これはパフォーマンスの点でどのように機能しますか? これはローカルディスク速度で動作します。つまり、 これはネジへの完全なアクセスです。

しかし、このケースには欠点があります。 この点に関しては、Persistent はかなり疑わしいです。 初めて Docker がコンテナーと一緒に移動すると、Persistent は失われます。 Kubernetes が何らかの理由でこのポッドを別のディスクに移動したい場合、データは失われます。

このアプローチは、すでに通常の速度が示されているため、テストには適していますが、重大なものにはこのオプションは適していません。

したがって、XNUMX 番目のアプローチがあります。 これはホストパスです。 前のスライドとこのスライドを見ると、違いが XNUMX つだけわかります。 フォルダーは Docker から Kubernetes ノードに直接移動されました。 ここではもう少し簡単です。 データを保存するローカル ファイル システム上のパスを直接指定します。

この方法には利点があります。 これはすでに本物の Persistent であり、その点では古典的なものです。 データはディスクの特定のアドレスに記録されます。

デメリットもあります。 これが管理の複雑さです。 Kubernetes は、Pod を別の物理ノードに移動したい場合があります。 ここで DevOps が登場します。 これらのポッドは、これらのパスに沿って何かがマウントされているノードにのみ移動でき、一度に XNUMX つのノードしか移動できないことを、システム全体に正しく説明する必要があります。 なかなか難しいですね。

特にこれらの目的のために、この複雑さをすべて隠すためにオペレーターにテンプレートを作成しました。 そして、単に「物理ノードごとに、これこれのパスに沿って ClickHouse のインスタンスを XNUMX つずつ持ちたい」と言うことができます。

しかし、このニーズを必要としているのは私たちだけではないため、Kubernetes 自体の担当者も、人々が物理ディスクにアクセスしたいと考えていることを理解しているため、第 XNUMX 層を提供しています。

ローカルといいます。 前のスライドとほとんど違いはありません。 以前は、これらのポッドは何らかのパスに沿ってローカルの物理ディスクに接続する必要があるため、ノードからノードに転送できないことを手動で確認する必要がありましたが、現在では、このすべての知識が Kubernetes 自体にカプセル化されています。 そして、設定がはるかに簡単であることがわかりました。

実際の問題に戻りましょう。 YAML テンプレートに戻りましょう。 ここに実際のストレージがあります。 元に戻りました。 k8s と同様に、クラシックな VolumeClaim テンプレートを設定します。 そして、どのような種類のストレージが必要かを説明します。

この後、k8s はストレージを要求します。 それを StatefulSet に割り当てます。 そして最終的にはClickHouseが自由に使えるようになるでしょう。

こんな計画がありました。 永続ストレージは赤で、それを実行する必要があることを示唆しているようでした。

そして緑色に変わります。 これで、k8s クラスタ スキーム上の ClickHouse が完全に完成しました。 シャード、レプリカ、ZooKeeper があり、何らかの方法で実装された実際の Persistent があります。 この計画はすでに完全に運用されています。

私たちは生き続けます。 私たちのクラスターは発展中です。 そして、Alexey は ClickHouse の新しいバージョンを試してリリースしました。

実際のタスクが発生します。それは、クラスター上で ClickHouse の新しいバージョンをテストすることです。 そして、当然のことながら、すべてを展開するのではなく、隅っこにある XNUMX つのレプリカに新しいバージョンを置き、頻繁にリリースされるため、新しいバージョンを XNUMX つではなく、一度に XNUMX つ入れたいと考えます。

これについては何と言えますか?

ここにまさにそのような機会があります。 これらはポッド テンプレートです。 私たちのオペレーターが異種クラスターの構築を完全に許可すると書くことができます。 それらの。 束内のすべてのレプリカから始まり、各個人レプリカで終わります。ClickHouse のどのバージョンが必要か、どのバージョンのストレージが必要か、を設定します。 必要な構成でクラスターを完全に構成できます。

もう少し奥へ進んでみましょう。 この前に、ClickHouse の詳細に関連して ClickHouse-operator がどのように機能するかについて説明しました。

ここで、オペレーターが一般的にどのように機能するか、またオペレーターが K8 とどのように相互作用するかについて少しお話したいと思います。

まず、K8 とのやり取りを見てみましょう。 kubectl を適用すると何が起こるでしょうか? オブジェクトは API を通じて etcd に表示されます。

たとえば、基本的な Kubernetes オブジェクト: ポッド、StatefulSet、サービスなど、リストの下にあります。

同時に、物理的なことはまだ何も起こっていません。 これらのオブジェクトはクラスター内で実体化する必要があります。

この目的のために、コントローラーが表示されます。 コントローラーは、これらの記述を具体化できる特別な k8s コンポーネントです。 彼は物理的に何をどのようにすべきかを知っています。 彼は、コンテナーの実行方法、サーバーが動作するためにコンテナーで何を構成する必要があるかを知っています。

そして、それは私たちのオブジェクトをK8sで実体化します。

しかし、ポッドと StatefulSet だけで操作するのではなく、ClickHouse Installation (つまり ClickHouse タイプのオブジェクト) を作成して、それを XNUMX つの全体として操作したいと考えています。 今のところそのような可能性はありません。

しかし、K8sには次のような優れた点があります。 ポッドと StatefulSet からクラスターが組み立てられる、この複雑なエンティティのような場所が必要です。

そして、そのためには何をする必要があるのでしょうか? まず、カスタム リソース定義が登場します。 それは何ですか？ これは K8 の説明で、もう XNUMX つのデータ型があり、内部が複雑になるカスタム リソース StatefulSet をポッドに追加する必要があるということです。 データ構造の説明です。

また、kubectl apply を介してそこに送信します。 Kubernetes は喜んでそれを受け入れました。

そして今、私たちのストレージでは、etcd のオブジェクトが ClickHouseinstallation と呼ばれるカスタム リソースを記録する機会を持ちます。

しかし今のところ、それ以上何も起こらないでしょう。 つまり、シャードとレプリカを記述した YAML ファイルを作成し、「kubectl apply」と言うと、Kubernetes はそれを受け入れて etcd に入れて、「素晴らしいですが、何をすればよいかわかりません」と言います。それと。 ClickHouse Installation の保守方法がわかりません。」

したがって、Kubernetes が新しいデータ型を提供できるように支援してくれる人が必要です。 左側には、ネイティブ データ型を処理するネイティブ Kubernetes コントローラーがあります。 そして右側には、カスタム データ型を処理できるカスタム コントローラーがあるはずです。

別の言い方では演算子と呼ばれます。 K8s の外部でも実行できるため、ここでは特に Kubernetes として含めました。 もちろん、ほとんどの場合、すべてのオペレーターは Kubernetes 内で実行されますが、外に置くことを妨げるものがないため、ここでは特別に外に移動します。

そして、オペレーターとも呼ばれるカスタム コントローラーが API 経由で Kubernetes と対話します。 API と対話する方法をすでに知っています。 そして彼は、カスタム リソースから作成したい複雑な回路を具体化する方法をすでに知っています。 これはまさにオペレーターが行うことです。

オペレーターはどのように働いていますか? 右側を見て、彼がどのようにそれを行うかを見てみましょう。 オペレーターがこれらすべてをどのように具体化するのか、そして K8 とのさらなる相互作用がどのように発生するのかを見てみましょう。

演算子はプログラムです。 彼女はイベント志向です。 オペレーターは、Kubernetes API を使用してイベントをサブスクライブします。 Kubernetes API には、イベントをサブスクライブできるエントリ ポイントがあります。 そして、K8 で何かが変更されると、Kubernetes は全員にイベントを送信します。 この API ポイントをサブスクライブした人は誰でも通知を受け取ります。

オペレーターはイベントをサブスクライブし、何らかの反応を行う必要があります。 その任務は、新たな出来事に対応することです。

イベントは特定の更新によって生成されます。 ClickHouse Installation の説明を含む YAML ファイルが到着します。 彼は kubectl apply を通じて etcd にアクセスしました。 そこでイベントがトリガーされ、その結果、このイベントが ClickHouse オペレーターに届きました。 オペレーターはこの説明を受けました。 そして彼は何かをしなければなりません。 ClickHouse Installation オブジェクトの更新が到着した場合は、クラスターを更新する必要があります。 そして、オペレーターのタスクはクラスターを更新することです。

彼は何をしているの？ まず、このアップデートで何を行うかについてのアクションプランを作成する必要があります。 更新は非常に小さい場合があります。 YAML の実行では小さな変更ですが、クラスター上では非常に大きな変更を伴う可能性があります。 したがって、オペレーターは計画を作成し、それを実行します。

この計画に従って、彼はポッド、サービス、つまり彼の主な仕事をする。 これは、Kubernetes で ClickHouse クラスターを構築する方法です。

さて、そんな興味深いことに触れてみましょう。 これは、Kubernetes とオペレーターの間の責任分担です。 Kubernetes が何をするのか、オペレーターが何をするのか、そしてそれらがどのように相互作用するのか。

Kubernetes はシステムに関することを担当します。 システムスコープとして解釈できるオブジェクトの基本セット用。 Kubernetes は、ポッドの起動方法、コンテナの再起動方法、ボリュームのマウント方法、ConfigMap の操作方法を知っています。 システムと呼べるものすべて。

オペレーターはドメイン内で動作します。 各演算子は、独自の対象領域用に作成されています。 私たちはClickHouseのためにそれを行いました。

また、オペレーターは、レプリカの追加、図の作成、監視の設定など、対象領域に関して正確に対話します。 この結果、分裂が生じます。

レプリカの追加アクションを実行するときに、この責任の分割がどのように行われるかを示す実際の例を見てみましょう。

オペレーターは、レプリカを追加するというタスクを受け取ります。 オペレーターは何をするのですか? オペレーターは、新しい StatefulSet を作成する必要があることを計算します。その中に、これこれのテンプレート、ボリューム要求を記述する必要があります。

彼はすべてを準備し、それを K8 に渡しました。 彼は、ConfigMap、StatefulSet、Vol が必要だと言います。 Kubernetes が動作しています。 彼は、操作に使用する基本単位を具体化します。

そして、ClickHouse オペレーターが再び登場します。 彼はすでに何かを実行できる物理的なポッドをすでに持っています。 そして、ClickHouse-operator は再びドメイン用語で動作します。 それらの。 特に ClickHouse では、クラスターにレプリカを含めるには、まず、このクラスターに存在するデータ スキーマを構成する必要があります。 そして第二に、このレプリカを明確に追跡できるように監視に含める必要があります。 オペレータはすでにこれを設定しています。

そしてその後になって初めて、ClickHouse 自体が機能します。 別のより高いレベルのエンティティ。 これはすでにデータベースになっています。 これには独自のインスタンス、つまりクラスターに参加する準備ができている別の構成済みレプリカがあります。

レプリカを追加する際の実行と責任の分担のチェーンは非常に長いことがわかります。

実践的な作業を続けます。 すでにクラスターがある場合は、構成を移行できます。

ClickHouse が理解できる既存の XML に直接貼り付けることができるようにしました。

ClickHouseを微調整できます。 ジャストゾーン展開については、hostPath (ローカル ストレージ) について説明したときに説明しました。 これはゾーン化されたデプロイメントを正しく行う方法です。

次の実際的なタスクはモニタリングです。

クラスターが変更された場合は、定期的に監視を構成する必要があります。

図を見てみましょう。 ここで緑色の矢印についてはすでに見てきました。 次に、赤い矢印を見てみましょう。 これがクラスターを監視する方法です。 ClickHouse クラスターからのメトリクスが Prometheus に取り込まれ、次に Grafana に取り込まれる方法。

モニタリングの難しさは何ですか？ なぜこれが何らかの成果として提示されるのでしょうか? 難しさはダイナミクスにあります。 クラスターが XNUMX つあり、それが静的であれば、監視を一度設定すれば、もう面倒な設定は必要ありません。

しかし、クラスターが多数ある場合、または何かが常に変化している場合、プロセスは動的になります。 また、監視を常に再構成することはリソースと時間の無駄です。 単なる怠惰であっても。 これは自動化する必要があります。 難しさはプロセスのダイナミクスにあります。 そして、オペレーターはこれを非常にうまく自動化します。

私たちのクラスターはどのようにして発達したのでしょうか? 初めは彼もそんな感じでした。

すると彼はこうなった。

結局彼はこうなった。

また、監視はオペレータによって自動的に行われます。 単一のエントリポイント。

そして出口で Grafana ダッシュボードを見て、内部でクラスターの活力がどのように沸騰しているかを確認します。

ちなみに、Grafana ダッシュボードは、オペレーターとともにソース コード内で直接配布されます。 接続して使用することができます。 私たちの DevOps がこのスクリーンショットを提供してくれました。

次はどこに行きたいですか？ これ：

• テスト自動化を開発します。 主なタスクは、新しいバージョンの自動テストです。
• また、ZooKeeper との統合を自動化したいと考えています。 また、ZooKeeper-operator と統合する計画もあります。 それらの。 オペレーターは ZooKeeper 用に作成されており、より便利なソリューションを構築するために XNUMX つのオペレーターが統合され始めるのは論理的です。
• 私たちは、より複雑なバイタルサインを実行したいと考えています。
• 緑色で強調表示したのは、テンプレートの継承 - 完了に近づいていることです。つまり、オペレーターの次のリリースでは、すでにテンプレートの継承が行われる予定です。 これは、複雑な構成を部品から構築できる強力なツールです。
• そして、複雑なタスクの自動化も必要です。 主なものは再シャーディングです。

いくつかの中間結果を見てみましょう。

その結果、何が得られるでしょうか? そして、やる価値があるのか​​、ないのか？ データベースを Kubernetes にドラッグし、一般的にはオペレーター、特に Alitnity オペレーターを使用する必要があるでしょうか?

出力では次のものが得られます。

• 構成、導入、メンテナンスが大幅に簡素化され、自動化されます。
• すぐにモニタリングが組み込まれます。
• また、複雑な状況に対応する、すぐに使用できる体系化されたテンプレートも用意されています。 レプリカの追加などのアクションを手動で行う必要はありません。 オペレーターがこれを行います。

最後の質問が XNUMX つだけ残っています。 すでに Kubernetes のデータベースと仮想化が行われています。 特に ClickHouse はパフォーマンスが最適化されているため、このようなソリューションのパフォーマンスはどうでしょうか?

答えは「すべて大丈夫です！」です。 これについては別のレポートで取り上げますので、詳細には触れません。

しかし、TSBSのようなプロジェクトがあります。 その主な任務は何ですか? これはデータベースのパフォーマンス テストです。 これは、温かいものと暖かいもの、柔らかいものと柔らかいものを比較する試みです。

彼はどのように働いていますか? XNUMX つのデータセットが生成されます。 次に、このデータ セットは、同じテスト セットを使用して異なるデータベースで実行されます。 そして、各データベースは、それぞれが知っている方法で XNUMX つの問題を解決します。 そして結果を比較できます。

すでに大量のデータベースをサポートしています。 主なものを XNUMX つ特定しました。 これ：

• タイムスケールDB。
• 流入DB。
• 「ハウス」をクリックします。

別の同様のソリューションとの比較も行われました。 RedShiftとの比較。 Amazonで比較してみました。 この点でも、ClickHouse は誰よりもはるかに先を行っています。

私の言ったことからどのような結論が導き出せるでしょうか?

• KubernetesでのDBも可能です。 おそらくどれも可能ですが、全体的には可能であるように見えます。 Kubernetes での ClickHouse は、当社のオペレーターの助けがあれば確実に実現できます。
• オペレーターはプロセスの自動化を支援し、作業を本当に楽にします。
• 性能は普通です。
• そして、これは使用できるし、使用すべきであると私たちには思われます。

オープンソース – 参加しましょう!

すでに述べたように、オペレーターは完全なオープンソース製品であるため、最大数の人が使用できるのは非常に良いことです。 参加しませんか！ 皆様をお待ちしております！

ありがとうございました！

質問

ご報告ありがとうございます！ 私の名前はアントンです。 SEMrushから来ました。 ロギングはどうなっているのか気になります。 クラスター全体について話すと、モニタリングについてはよく聞きますが、ロギングについては何も聞きません。 たとえば、ハードウェア上にクラスターを構築しました。 また、集中ログを使用し、標準的な手段を使用してそれらを共通のヒープに収集します。 そしてそこから興味のあるデータを取得します。

良い質問です。つまり、ToDo リストにログインします。 私たちのオペレーターはこれをまだ自動化していません。 このプロジェクトはまだ発展途上であり、まだ若いです。 私たちはログの必要性を理解しています。 これも非常に重要なテーマです。 そしてそれはおそらくモニタリングと同じくらい重要です。 しかし、実装リストの最初は監視でした。 ログ記録が行われます。 当然のことながら、私たちはクラスターの生活のあらゆる側面を自動化しようとします。 したがって、残念ながら、現時点ではオペレーターはこれを行う方法を知りませんが、それは計画にあるため、実行する予定です、というのが答えです。 参加したい場合はプルリクエストをしてください。

こんにちは！ ご報告ありがとうございます！ 永続ボリュームに関する一般的な質問があります。 このオペレーターを使用して構成を作成する場合、オペレーターはどのノードに特定のディスクまたはフォルダーが接続されているかをどのように判断するのでしょうか? まず彼に、ディスクのあるこれらのノードに ClickHouse を配置してくださいと説明しなければなりません。

私が理解している限り、この質問はローカルストレージ、特にその hostPath 部分の継続です。 これは、システム全体に、ポッドはこれこれのノードで起動する必要があることを説明するようなもので、このノードには物理的に接続されたディスクがあり、そのパスに沿ってマウントされています。 このセクション全体は非常に表面的に触れたものであり、その答えは非常に大きいためです。

簡単に言うとこんな感じです。 当然のことながら、これらのボリュームをプロビジョニングする必要があります。 現時点では、ローカル ストレージには動的なプロビジョニングがないため、DevOps はディスク自体、つまりこれらのボリュームを切断する必要があります。 また、Kubernetes プロビジョニングについて、これこれのノード上に配置される、これこれのクラスの永続ボリュームがあることを説明する必要があります。 次に、これこれのローカル ストレージ クラスを必要とするポッドは、ラベルを使用してこれこれのノードにのみ送信する必要があることを Kubernetes に説明する必要があります。 これらの目的のために、オペレーターは、ある種のラベルをホスト インスタンスごとに XNUMX つ割り当てることができます。 そして、ポッドは Kubernetes によってルーティングされ、要件 (簡単に言えばラベル) を満たすノードでのみ実行されることがわかりました。 管理者はラベルを割り当て、ディスクを手動でプロビジョニングします。 そしてそれはスケールします。

そして、これを少し簡単にするのが XNUMX 番目のオプションであるローカルです。 すでに強調したように、これは骨の折れる調整作業であり、最終的には最大のパフォーマンスを得るのに役立ちます。

これに関連して XNUMX つ目の質問があります。 Kubernetes は、ノードが失われるかどうかが私たちにとって問題にならないように設計されています。 この場合、シャードがハングしているノードを失った場合はどうすればよいでしょうか?

はい、Kubernetes は当初、ポッドと人間の関係は牛のようなものだと位置づけていましたが、ここでは各ディスクがペットのようなものになります。 なかなか捨てられない問題があります。 そして、Kubernetes の開発は、それを完全に廃棄されたリソースであるかのように、哲学的に完全に扱うことは不可能であるという方向に進んでいます。

さて、実践的な質問です。 ディスクが存在していたノードを紛失した場合はどうすればよいですか? ここでは、問題はより高いレベルで解決されています。 ClickHouse の場合、より高いレベルで動作するレプリカがあります。 ClickHouse レベルで。

その結果生じる性質は何ですか? DevOps は、データが失われないようにする責任があります。 レプリケーションを正しく設定し、レプリケーションが実行されていることを確認する必要があります。 ClickHouse レベルのレプリカには重複したデータが必要です。 これはオペレーターが解決できる問題ではありません。 そして、Kubernetes 自体が解決する問題ではありません。 これは ClickHouse レベルです。

鉄のノードが落ちた場合はどうすればよいですか？ そして、XNUMX 番目のディスクをインストールし、その上にディスクを適切にプロビジョニングし、ラベルを適用する必要があることがわかりました。 その後、Kubernetes がその上でインスタンス ポッドを起動できるという要件を満たします。 Kubernetes が起動します。 ポッドの数が指定された数を満たすのに十分ではありません。 私が示したサイクルを経ることになります。 そして、最も高いレベルでは、ClickHouse は、レプリカを入力したこと、レプリカがまだ空であること、レプリカへのデータ転送を開始する必要があることを理解します。 それらの。 このプロセスはまだ十分に自動化されていません。

ご報告ありがとうございます！ さまざまな厄介なことが発生すると、オペレーターがクラッシュして再起動し、その瞬間にイベントが到着しますが、これをなんとか処理しますか?

オペレーターがクラッシュして再起動したらどうなりますか?

はい。 そしてその瞬間、出来事が起こりました。

この場合に何をするかというタスクは、オペレーターと Kubernetes の間で部分的に共有されます。 Kubernetes には、発生したイベントを再生する機能があります。 彼は繰り返します。 そして、オペレーターの仕事は、イベント ログが再生されたときに、これらのイベントが冪等であることを確認することです。 そして、同じイベントが繰り返し発生してもシステムが破壊されないようにします。 そして、私たちのオペレーターがこのタスクに対応します。

こんにちは！ ご報告ありがとうございます！ ドミトリー・ザビャロフ、会社 スメドバ。 haproxy を使用して構成する機能をオペレーターに追加する予定はありますか? 私は、ClickHouse が実際にそこにあることを賢明に理解できるように、標準のもの以外の他のバランサーに興味があります。

Ingressのことを言ってるの？

はい、Ingress を haproxy に置き換えます。 haproxy では、レプリカが存在するクラスターのトポロジーを指定できます。

それについてはまだ考えていません。 それが必要であり、なぜそれが必要なのかを説明できれば、特に参加したい場合は実装することが可能です。 喜んでご検討させていただきます。 簡単に言うと「いいえ」です。現在そのような機能はありません。 ご指摘ありがとうございます。この件については検討させていただきます。 また、ユースケースと、GitHub で問題を作成するなど、実際にそれが必要な理由も説明していただければ、それは素晴らしいことです。

すでに持っています。

大丈夫。 あらゆるご提案をお待ちしております。 そして、haproxy が todo リストに追加されます。 ToDo リストは増え続けていますが、まだ減っていません。 しかし、これは良いことであり、その製品に需要があることを意味します。

出所： habr.com