よくある質問（FAQ）¶
KubernetesでPostgreSQLを実行する¶
PostgreSQLのようなステートフルなワークロードはKubernetesで実行できないことは誰もが知っています。なぜ反対のことを言うのですか?
2021年9月のindependentresearchsurveycommissionedbytheDataonKubernetesCommunityにより、回答者の半数が本番ワークロードのほとんどを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* 」を定義しています。ただし、2ndQuadrantでクラウドネイティブPostgreSQL / CloudNativePGオペレーターが開始されて以来、開発チームはクラウドネイティブを3つの主要な概念として解釈してきました。
1.人々、原則とプロセスに基づいた、既存の健全で本物の繁栄したDevOps文化。より安全で、より効率的で、より魅力的な方法でビジネスに価値を
Immutable Application Containersに基づくマイクロサービスアーキテクチャ
3.これらのコンテナ（Kubernetesなど）を管理およびオーケストレーションする方法
現在、コンテナオーケストレーションの事実上の標準はKubernetesであり、クラウドネイティブアプリケーションの展開、管理、およびスケーラビリティを自動化します。
私たちの共感を呼ぶクラウドネイティブの別の定義は、 *"Kubernetes Patterns", published by O'Reilly* でIbryamとHußによって定義されたものです。
コンテナ化されたマイクロサービスを大規模に自動化するための原則、パターン、ツール
ベアメタルKubernetesでCloudNativePGを実行できますか?
はい、間違いなく。ベアメタルでKubernetesを実行できます。また、ローカルに接続されたストレージを備えた1つ以上のフィジカルワーカーノードをPostgreSQLワークロード専用にして、最大かつ予測可能なI / Oパフォーマンスを実現できます。
CloudNativePGが由来する実際のクラウドネイティブPostgreSQLプロジェクトは、2019年のパイロットプロジェクトの後に生まれました。 同じベアメタルサーバー上のストレージとPostgreSQLを、最初はLinuxで直接、次にKubernetes内でベンチマークしました。予想通り、実験では、ローカル永続ボリュームを介してKubernetesで実行されているコンテナによって導入されたパフォーマンスへの影響は無視できる程度であることを示し、クラウドネイティブイニシアチブを続行できました。
ファイルシステムレプリケーションの代わりにPostgreSQLレプリケーションを使用する必要があるのはなぜですか?
セクション。
PostgreSQLをコンテナとして実行する代わりに演算子を使用する必要があるのはなぜですか?
KubernetesでPostgreSQLを実行するための最も基本的なアプローチは、Kubernetesでの展開の最小単位であるポッドを用意し、レプリカのないPostgresコンテナを実行することです。 Postgresデータディレクトリをホストするボリュームはポッドにマウントされ、通常はネットワークストレージにあります。この場合、Kubernetesは問題が発生した場合にポッドを再起動するか、ポッドを別のKubernetesノードに移動します。
最も洗練されたアプローチは、演算子を使用してPostgreSQLを実行することです。オペレーターはKubernetesコントローラーの拡張機能であり、複雑なアプリケーションがビジネス継続性コンテキストでどのように機能するかを定義します。オペレーターパターンは、この目的のための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管理者と対話できるときです。
Cloud Native PostgreSQLを最大限に活用して、CNCF認定プログラムから「Certified Kubernetes Administrator（CKA）」ステータスを取得したいすべての人へのアドバイスです。
CloudNativePGがStatefulSetを使用しないのはなぜですか?
CloudNativePGはStatefulSet
リソースに依存せず、代わりに、動的プロビジョニング用に選択されたストレージクラスを活用することにより、基になるPVCを直接管理します。この決定の詳細と理由については、
カスタムポッドコントローラー セクションを参照してください。
高可用性¶
オペレーターポッドが停止した場合、または一定時間利用できなくなった場合、PostgreSQLクラスターはどうなりますか?
CloudNativePGオペレーターは、とりわけ、自己修復機能を担当します。そのため、オペレーターの停止中には利用できない場合があります。
- ただし、停止がPostgreSQLクラスターが実行されているノードに影響しないと仮定すると、データベースは関連するKubernetesサービスを介して、通常のオペレーションを提供し続けます。さらに、各PostgreSQLポッド内で実行される
は引き続き機能し、ロギング、メトリックのエクスポート、WALファイルの継続的なアーカイブなどのアクセサリサービスを含む、データベースサーバーが起動していることを確認します。
要約すると：
オペレーターの停止は、必ずしもPostgreSQLデータベースの停止を意味するものではありません。 DBAやシステム管理者なしでデータベースを実行するようなものです。
CloudNativePGがPatroni、repmgr、Stolonなどのフェイルオーバー管理ツールに依存しない理由は何ですか?
CloudNativePGを開発するチームの一部は過去にrepmgrに大きく関与していましたが、別のアプローチを取り、Kubernetesコントローラーを直接拡張し、Kubernetes APIサーバーに依存してPostgresクラスターのステータスを保持し、使用することにしました。唯一の真実の情報源として：
主に自動フェイルオーバーとスイッチオーバーを介してPostgresクラスターの高可用性を制御し、 インスタンスマネージャーのインプレース更新 と自分自身を調整します
アプリケーションのエントリポイントであるKubernetesサービスを制御します
