データベースとKubernetes（レビューおよびビデオレポート）

11月8日、 HighLoad ++ 2018会議のメインホールで、DevOps and Operationsセクションのフレームワーク内で、Databases and Kubernetesというタイトルのレポートが作成されました。 データベースの高可用性とKubernetesのフォールトトレランスへのアプローチ、およびKubernetesクラスターにDBMSを配置するための実用的なオプションと、このための既存のソリューション（Stolon for PostgreSQLを含む）について説明します。







伝統的に、私たちはレポート （約1時間、記事よりもはるかに有益）とテキスト形式での主な絞り込みのビデオを提示して喜んでいます。 行こう！

理論

このレポートは、過去数年にわたってさまざまな場所でたゆまぬように求められてきた最も人気のある質問の1つ、HabrまたはYouTubeのコメント、ソーシャルネットワークなどへの回答として登場しました。 「Kubernetesで拠点を運営することは可能ですか？」、そして、通常「はい、しかし...」と答えた場合、これらの「一般的」および「しかし」について十分な説明はありませんでした。短いメッセージで成功しませんでした。



ただし、まず、「データベース[データ]」から全体としてステートフルまでの問題を要約します。 DBMSは、ステートフルな決定の特別な場合に過ぎず、より完全なリストは次のように表すことができます。







特定のケースを見る前に、Kubernetesの動作/使用の3つの重要な機能について説明します。

1. Kubernetesの高可用性の哲学

「ペットと牛 」の類推を誰もが知っており、Kubernetesが群れの世界の物語である場合、古典的なDBMSは単なるペットであることを理解しています。



また、「ペット」のアーキテクチャは、「伝統的な」バージョンではどのように見えましたか？ MySQLをインストールする典型的な例は、冗長電源を備えた2台の鉄製サーバー、ディスク、ネットワーク...、およびその他すべて（エンジニアおよびさまざまな補助ツールを含む）でのレプリケーションです。これにより、MySQLプロセスが失敗しないことを確認できます。 ITコンポーネントの場合、フォールトトレランスが考慮されます。







Kubernetesでも同じように見えますか？ ここでは、通常、より多くの鉄製サーバーがあり、よりシンプルで、冗長な電源とネットワークはありません（1台のマシンの損失が何にも影響しないという意味で）-これらはすべてクラスターに結合されます。 そのフォールトトレランスはソフトウェアによって提供されます。ノードに何かが発生した場合、Kubernetesは他のノードで必要なインスタンスを検出して起動します。



K8の高可用性のメカニズムは何ですか？

1. コントローラー 多数ありますが、2つの主なものがあります。 Deployment
   
   
   
   （ステートレスアプリケーション用）とStatefulSet
   
   
   
   （ステートフルアプリケーション用）です。 これらは、ノードがクラッシュした場合に実行されるアクションのすべてのロジックを保存します（ポッドへのアクセス不能）。
2. PodAntiAffinity
   
   
   
   特定のポッドが同じノード上にないように指定する機能。
3. PodDisruptionBudgets
   
   
   
   スケジュールされた作業の場合に同時にオフにできるポッドインスタンスの数の制限。

2. Kubernetesの一貫性の保証

使い慣れたシングルマスターフォールトトレランススキームはどのように機能しますか？ 2つのサーバー（マスターとスタンバイ）。そのうちの1つはアプリケーションによって常にアクセスされ、ロードバランサーを介して使用されます。 ネットワークに問題がある場合はどうなりますか？







従来のスプリットブレイン ：アプリケーションは、DBMSの両方のインスタンスへのアクセスを開始します。各インスタンスは、それ自体をメインインスタンスと見なします。 これを回避するために、keepalivedは3つのインスタンスを持つcorosyncに置き換えられ、マスターに投票するときに定足数を達成しました。 ただし、この場合でも問題があります：倒れたDBMSインスタンスが「自殺」するために最善を尽くす（IPアドレスを削除し、データベースを読み取り専用に変換するなど）場合、クラスターの他の部分はウィザードに何が起こったのかわかりません-そのノードは実際にまだ機能しており、リクエストがそこに到達すること、つまりウィザードを切り替えることができないことを意味します。



この状況を解決するために、誤った操作からクラスター全体を保護するためにノードを分離するメカニズムがあります。このプロセスはフェンシングと呼ばれます。 実用的な本質は、私たちが落ちた車を「殺す」ために何らかの外部手段によって試みているという事実に要約されます。 アプローチは異なる場合があります。IPMIを介してマシンをオフにしてスイッチのポートをブロックすることから、クラウドプロバイダーのAPIにアクセスすることなどです。 そして、この操作の後のみ、ウィザードを切り替えることができます。 したがって、 最大1回の保証が達成され、 一貫性が保証されます。







Kubernetesで同じことを達成する方法は？ これを行うために、すでに言及されているコントローラーがあり、ノードのアクセス不能の場合の動作は異なります：

1. Deployment
   
   
   
   ：「3つのポッドがあるはずだと言われましたが、現在は2つのポッドしかありません-新しいポッドを作成します」;
2. StatefulSet
   
   
   
   ：「ポッドはなくなった？」 待ちます：このノードが戻るか、殺すように言われます」 コンテナー自体（オペレーターのアクションなし）は再作成されません。 これは、同じ最大1回の保証が達成される方法です。

ただし、ここでは、後者の場合、フェンシングが必要です。このノードが確実にもうないことを確認するメカニズムが必要です。 自動化することは、第一に非常に難しく（多くの実装が必要です）、第二にさらに悪いことに、通常はノードをゆっくりと殺します（IPMIへのアクセスには数秒から数十秒、さらには数分かかります）。 ベースを新しいマスターに切り替えるのに数分待つ人はほとんどいません。 しかし、フェンシングメカニズムを必要としない別のアプローチがあります...



Kubernetes外で彼の説明を始めます。 バックエンドがDBMSにアクセスするための特別なロードバランサーを使用します。 その特異性は、一貫性の特性を持っているという事実にあります。 ネットワーク障害とスプリットブレインに対する保護。現在のマスターへのすべての接続を削除し、別のノードで同期（レプリカ）を待ってから切り替えることができるためです。 私はこのアプローチの確立された用語を見つけられず、 Consistent Switchoverと呼んでいました。







彼との主な質問は、クラウドプロバイダーとプライベートインストールの両方にサポートを提供し、それをユニバーサルにする方法です。 このため、プロキシがアプリケーションに追加されます。 それらのそれぞれは、そのアプリケーションからの要求を受け入れ（そしてそれらをDBMSに転送し）、それらすべてから定足数が収集されます。 クラスタの一部に障害が発生すると、クォーラムを失ったプロキシはすぐにDBMSへの接続を削除します。

3.データストレージとKubernetes

主なメカニズムは、必要なクラウドオプションまたはベアメタル用のさまざまな実装のネットワークブロックデバイス （別名SAN）ネットワークドライブです。 ただし、ロードされたデータベース（たとえば、50000 IOPSを必要とするMySQL）をクラウド（AWS EBS）に配置することは、 待ち時間のために機能しません。







このような場合のKubernetesには、ローカルハードドライブ（ ローカルストレージ）を接続する機能があります。 障害が発生した場合（ポッドでディスクが使用できなくなった場合）、このマシンを修復する必要があります。これは、1つの信頼できるサーバーに障害が発生した場合の従来のスキームと同様です。



両方のオプション（ ネットワークブロックデバイスとローカルストレージ ）はReadWriteOnceカテゴリに属します：ストレージを2か所（ポッド）にマウントすることは不可能です-このスケーリングでは、新しいディスクを作成して新しいポッドに接続する必要があります（このための組み込みのK8メカニズムがあります） 、そして必要なデータを入力します（すでに軍隊によって行われています）。



ReadWriteManyモードが必要な場合は、パブリッククラウド用のAzureFile



とAWSElasticFileSystem



、分散システムのファン用のCephFSとGlusterfs、およびインストール用のNFSのNetwork File System （またはNAS）実装が利用可能です。

練習する

1.スタンドアロン

このオプションは、ローカルストレージを使用して個別のサーバーモードでDBMSを起動することを妨げるものが何もない場合についてです。 これは高可用性に関するものではありません...ただし、鉄レベルである程度（つまり、このアプリケーションに十分）実装できます。 このアプリケーションには多くのケースがあります。 まず第一に、これらはあらゆる種類のステージング環境と開発環境ですが、それだけではありません。セカンダリサービスもここに落ち、15分間それらを無効にすることは重要ではありません。 Kubernetesでは、これは1つのポッドを持つStatefulSet



によって実装されます。







一般に、これは実行可能なオプションであり、私の観点からは、別の仮想マシンにDBMSをインストールする場合と比べてマイナスはありません。

2.手動切り替えによる複製ペア

StatefulSet



再び使用されますが、一般的なスキームは次のようになります。







ノードの1つが失敗した場合（ mysql-a-0



）、奇跡は発生しませんが、トラフィックを切り替えることができるレプリカ（ mysql-b-0



）があります。 この場合、トラフィックを切り替える前でも、 mysql



サービスからDBMSリクエストを削除するだけでなく、DBMSに手動でログインし、すべての接続が完了していることを確認して（kill）、DBMSから2番目のノードに移動してレプリカを再構成することも忘れないでください反対方向に。



現在、自動フェールオーバーなしの2つのサーバー（マスター+スタンバイ）でクラシックバージョンを使用している場合、このソリューションはKubernetesで同等です。 MySQL、PostgreSQL、Redisなどの製品に適しています。

3.読み込み負荷のスケーリング

実際、このケースはステートフルではありません。なぜなら、私たちは読書についてだけ話しているからです。 ここで、メインDBMSサーバーは考慮されたスキームの外側にあり、Kubernetesのフレームワーク内に、読み取り専用の「スレーブサーバーのファーム」が作成されます。 一般的なメカニズム-このファームの新しい各ポッドでDBMSデータを入力するためのinitコンテナの使用（ホットダンプまたは追加のアクションなどを含む通常のポッドの使用-使用されるDBMSによって異なります）。 各インスタンスがマスターから離れすぎないようにするために、活性テストを使用できます。

4.スマートクライアント

3つのmemcachedのStatefulSet



を作成すると、Kubernetesは要求のバランスをとらない特別なサービスを提供しますが、独自のドメインの各ポッドを作成します。 クライアントは、彼自身がシャーディングと複製ができる場合、それらと連携することができます。



例に目を向ける必要はありません。これは、そのままでPHPでセッションストレージが機能する方法です。 セッション要求ごとに、すべてのサーバーに対して同時に要求が行われ、その後、サーバーから最も関連性の高い回答が選択されます（レコードと同様）。

5.クラウドネイティブソリューション

最初はノードの障害に焦点を当てた多くのソリューションがあります。 それら自体がノードのフェイルオーバーとリカバリを行い、 一貫性を保証します。 これはそれらの完全なリストではなく、一般的な例の一部にすぎません。







それらはすべてStatefulSet



単純に配置され、その後、ノードはお互いを見つけてクラスターを形成します。 製品自体は、次の3つのことを実装する方法が異なります。

1. ノードはお互いをどのように学習しますか？ Kubernetes API、DNSレコード、静的構成、特殊ノード（シード）、サードパーティのサービス検出などのメソッドがあります...
2. クライアントはどのように接続しますか？ ホストに分散するロードバランサーを介して、またはクライアントはすべてのホストについて知る必要があり、処理方法を決定します。
3. 水平スケーリングはどのように行われますか？ まさか、完全または困難/制限付き。

これらの問題に対して選択されたソリューションに関係なく、これらの製品はすべて「 牛」として作成されたため、Kubernetesでうまく機能します。

6. Stolon PostgreSQL

Stolonは実際に、 ペットとして作成されたPostgreSQLを牛に変えることができます。 これはどのように達成されますか？

• 最初に、 etcd （他のオプションが利用可能）の役割のサービス発見が必要です-それらのクラスターはStatefulSet
  
  
  
  配置されます。
• もう1つのインフラストラクチャは、PostgreSQLインスタンスを備えたStatefulSet
  
  
  
  です。 適切なDBMSに加えて、各インストールの横には、DBMS構成を実行するkeeperというコンポーネントもあります。
• 別のコンポーネントであるセンチネルは、 Deployment
  
  
  
  としてデプロイされ、クラスター構成を監視します。 誰がマスターとスタンバイになるかを決定し、この情報をetcdに書き込みます。 また、キーパーはetcdからデータを読み取り、PostgreSQLのインスタンスを使用して現在のステータスに対応するアクションを実行します。
• Deployment
  
  
  
  、PostgreSQLインスタンスに対面するもう1つのコンポーネントであるプロキシは、前述のConsistent Switchoverパターンの実装です。 これらのコンポーネントはetcdに接続されており、この接続が失われた場合、プロキシはすぐに発信接続を強制終了します。その時点から、サーバーの役割（マスターまたはスタンバイのどちらなのか）を知らないためです。
• 最後に、プロキシインスタンスは通常のLoadBalancer
  
  
  
  LoadBalancerに直面します。

結論

Kubernetesに拠点を置くことは可能ですか？ はい、もちろん、場合によっては可能です...そして、適切な場合は、このように行われます（Stolonワークフローを参照）...



技術は波のように進化していることを誰もが知っています。 最初は、新しいデバイスを使用するのは非常に難しい場合がありますが、時間が経つにつれて、すべてが変わります。テクノロジーが利用可能になります。 どこへ行くの？ はい、内部はこのままですが、どのように機能するかはわかりません。 Kubernetesは、 オペレーターを積極的に開発しています 。 これまでのところ、それほど多くはなく、あまり良くありませんが、この方向に動きがあります。

ビデオとスライド

パフォーマンスからのビデオ（約1時間）：







レポートのプレゼンテーション：







PSネット上で、このレポートからの非常に短い（！）短いテキストの絞り込みも見つけました。ニコライヴォルキンキンに感謝します。

PPS

ブログの他のレポート：

• “ モニタリングとKubernetes ”; （Dmitry Stolyarov; 2018年5月28日RootConf） ;
• “ KubernetesとGitLabを使用したベストCI / CDプラクティス ”; （Dmitry Stolyarov; 2017年11月7日HighLoad ++） ;
• “ 小さなプロジェクトでのKubernetesでの経験 ”; （Dmitry Stolyarov; 2017年6月6日RootConf） ;
• 「 CI / CDのDockerイメージをdappで迅速かつ便利に収集します 」 （Dmitry Stolyarov、2016年11月8日、HighLoad ++） 。
• 「 Dockerによる継続的デリバリーの実践 」 （Dmitry Stolyarov、2016年5月31日、RootConf） 。

次の出版物にも興味があるかもしれません。

• 「 Kubernetesのヒントとコツ：大規模データベースのブートストラップを高速化する 」;
• 「 KubernetesでのCockroachDB DBMSオーケストレーション 」