よくある質問 (FAQ)¶
Kubernetes で PostgreSQL を実行する¶
誰もが、PostgreSQLのようなステートフルワークロードをKubernetesで実行できないことを知っています。なぜ反対のことを言うのですか?
2021 年 9 月の independent research survey commissioned by the Data on Kubernetes Community では、回答者の半数が本番ワークロードのほとんどを Kubernetes で実行していることが明らかになりました。彼らの 90% は、Kubernetes がステートフルなワークロードに対応できると考えており、70% が本番環境でデータベースを実行しています。 Postgres のようなデータベース。ただし、彼らによると、知識のギャップ (一般に、Kubernetes とクラウド ネイティブは学習曲線が急峻です) や Kubernetes オペレーターの質など、重大な課題が残っています。後者は、CloudNativePG のようなオペレーターがプロジェクトの成功に大きく貢献すると私たちが考える理由です。
- 私たちのようなデータベース狂信者にとって、真のゲームチェンジャーは
*Kubernetes 1.14 in April 2019* でのローカル永続ボリュームのサポートの導入でした。
CloudNativePGは不変のアプリケーションコンテナ上に構築されています。どういう意味ですか？
マイクロサービス アーキテクチャ パターンに従って、コンテナーは単一のアプリケーションまたはプロセスを実行するように設計されています。その結果、このようなコンテナー イメージは、単一のエントリ ポイント (いわゆる PID 1 プロセス) としてメイン アプリケーションを実行するように構築されます。
Kubernetes の用語では、アプリケーションはワークロードと呼ばれます。ワークロードは、Web アプリケーション サーバーのようにステートレスにすることも、データベースのようにステートフルにすることもできます。この概念を PostgreSQL に当てはめると、不変アプリケーション コンテナーは、単一の特定のバージョン (不変コンテナー イメージ内のバージョン) に関連付けられて実行される単一の “postgres” プロセスです。
SSH、systemd、syslog などの他のプロセスは許可されません。
不変アプリケーション コンテナーは、コンテナーを解釈して使用するための非常に一般的な方法である可変システム コンテナーとは対照的です。
不変とは、コンテナーがその存続期間中に変更されないことを意味します。更新、パッチ、構成の変更はありません。アプリケーション コードを更新するか、パッチを適用する必要がある場合は、新しいイメージをビルドして再デプロイします。不変性により、デプロイがより安全になり、再現性が向上します。
詳細については、 *"Why EDB chose immutable application containers"* を参照してください。
クラウドネイティブとはどういう意味ですか?
Cloud Native Computing Foundation は、「 *Cloud Native* 」という用語を定義しています。ただし、第 2 象限でクラウド ネイティブ PostgreSQL/CloudNativePG オペレーターが開始されて以来、開発チームはクラウド ネイティブを次の 3 つの主要な概念として解釈してきました。
チームと組織 (チームのチームとして) が絶え間なく変化し、成果の提供を革新し加速することを可能にする、原則とプロセスだけでなく、人々に基づいた、既存の、健全で、真正で、繁栄した DevOps 文化。より安全で効率的、かつ魅力的な方法でビジネスに価値をもたらす
Immutable Application Containers に基づくマイクロサービス アーキテクチャ
Kubernetes などのこれらのコンテナーを管理および調整する方法
現在、コンテナ オーケストレーションの事実上の標準は Kubernetes であり、クラウド ネイティブ アプリケーションの展開、管理、およびスケーラビリティを自動化します。
私たちの心に響くクラウド ネイティブの別の定義は、 *"Kubernetes Patterns", published by O'Reilly* で Ibryam と Huß によって定義されたものです。
コンテナー化されたマイクロサービスを大規模に自動化するための原則、パターン、ツール
なぜ、PostgreSQLをコンテナーとして実行する代わりにオペレーターを使用する必要があるのですか?
Kubernetes で PostgreSQL を実行するための最も基本的なアプローチは、Kubernetes での展開の最小単位であるポッドを使用して、レプリカなしで Postgres コンテナーを実行することです。 Postgres データ ディレクトリをホストするボリュームはポッドにマウントされ、通常はネットワーク ストレージに存在します。この場合、Kubernetes は、問題が発生した場合にポッドを再起動するか、別の Kubernetes ノードに移動します。
最も洗練されたアプローチは、演算子を使用して PostgreSQL を実行することです。オペレーターは Kubernetes コントローラーの拡張であり、複雑なアプリケーションがビジネス継続性のコンテキストでどのように機能するかを定義します。 operator パターンは、現在、この目的のための Kubernetes の最先端です。オペレーターは、自動化されたプログラムによる方法で人間のオペレーターの作業をシミュレートします。
Postgres は複雑なアプリケーションであり、オペレーターはクラスターをデプロイするだけでなく (最初のステップ)、予期しないイベントの後に適切に対応する必要があります。典型的な例はフェイルオーバーです。
オペレーターは、自己修復、スケーラビリティ、レプリケーション、高可用性、バックアップ、回復、更新、アクセス、リソース制御、ストレージ管理などの機能を Kubernetes に依存しています。また、ログ管理および監視インフラストラクチャでの PostgreSQL クラスターの統合も容易になります。
CloudNativePG を使用すると、宣言型構成を介して PostgreSQL クラスターの望ましい状態を定義できます。 Kubernetes は、Kubernetes コントローラーによって開始された調整ループを通じて、インフラストラクチャの現在の状態が目的の状態と一致することを継続的に確認します。望ましい状態と実際の状態が一致しない場合、調整ループが自己修復手順をトリガーします。そこで CloudNativePG のようなオペレーターの出番です。
あなたは、CloudNativePGは完全に宣言型の演算子であると言います。それはどういう意味ですか?
最も簡単な方法は、命令型構成との違いを強調する例を通して宣言型構成を説明することです。命令的なコンテキストでは、状態は、順番に実行される一連のタスクとして定義されます。したがって、最初のインスタンスを作成し、レプリケーションを構成し、2 番目のインスタンスを複製し、3 番目のインスタンスを複製することで、3 ノードの PostgreSQL クラスターを取得できます。
宣言型のアプローチでは、システムの状態は構成を使用して定義されます。つまり、2 つのレプリカを持つ PostgreSQL 13 クラスターがあります。このアプローチにより、変更管理操作が大幅に簡素化され、これらが Git などのソース管理システムに格納されると、Infrastructure as Code 機能が有効になります。そして Kubernetes は、私たちの要求がいつでも確実に満たされるようにするため、デプロイよりも先に進みます。
KubernetesでPostgreSQLを実行するために必要なスキルは何ですか?
Kubernetes で PostgreSQL を実行するには、DevOps チームに PostgreSQL と Kubernetes の両方のスキルが必要です。最高のエクスペリエンスは、データベース管理者が Kubernetes のコア コンセプトに精通し、Kubernetes 管理者とやり取りできるようになったときです。
クラウド ネイティブ PostgreSQL を最大限に活用して、CNCF 認定プログラムから「Certified Kubernetes Administrator (CKA)」ステータスを取得したいすべての人にアドバイスします。
CloudNativePGがStatefulSetsを使用しないのはなぜですか?
CloudNativePG は StatefulSet
リソースに依存せず、動的プロビジョニング用に選択されたストレージ
クラスを活用することで、基礎となる PVC
を直接管理します。この決定の背後にある詳細と理由については、 カスタム Pod コントローラー
セクションを参照してください。
高可用性¶
OperatorPodが停止した場合、または一定時間使用できなくなった場合、PostgreSQLクラスターはどうなりますか?
CloudNativePG オペレーターは、とりわけ、自己修復機能を担当します。そのため、オペレーターの停止中は使用できない場合があります。
ただし、停止が PostgreSQL クラスターが実行されているノードに影響を及ぼさないと仮定すると、データベースは関連する Kubernetes サービスを通じて通常の操作を提供し続けます。さらに、各 PostgreSQL ポッド内で実行される インスタンスマネージャーのインプレース更新 は引き続き機能し、ロギング、メトリックのエクスポート、WAL ファイルの継続的なアーカイブなどのアクセサリ サービスを含むデータベース サーバーが稼働していることを確認します。
要約する：
オペレーターの停止は、必ずしも PostgreSQL データベースの停止を意味するわけではありません。これは、 DBAやシステム管理者なしでデータベースを実行するようなものです。
