Frequently Asked Questions (FAQ)

KubernetesでPostgreSQLを実行する

PostgreSQLのようなステートフルワークロードはinKubernetesで実行できないことは誰もが知っています。なぜあなたは反対を言うのですか？

2021年9月のindependent research survey commissioned by the Data on KubernetesCommunityは、回答者の半数がKubernetesで本番ワークロードのほとんどを実行していることを明らかにしました。 90％がKubernetesがステートフルワークロードに対応していると考えており、70％がPostgresのような稼動データベースでデータベースを実行しています。しかし、彼らによると、知識のギャップ（一般にKubernetesとCloudNativeは急勾配の学習曲線を持っています）やKubernetes演算子の品質など、重要な課題が残っています。後者は、CloudNativePGのようなanoperatorがプロジェクトの成功に大きく貢献すると信じる理由です。

私たちのようなデータベースの狂信者にとって、本当のゲームチェンジャーは *Kubernetes 1.14 in April 2019* のローカル永続ボリュームのサポートの導入です。

CloudNativePGは不変のアプリケーションコンテナ上に構築されています。それはどういう意味ですか？

マイクロサービスのアーキテクチャパターン、コンテナは単一のアプリケーションまたはプロセスを実行するように設計されています。その結果、このようなコンテナイメージは、メインアプリケーションを単一のエントリーポイントとして実行するように構築されます（いわゆるPID 1プロセス）。

Kubernetesの用語では、アプリケーションはワークロードと呼ばれます。ワークロードは、Webアプリケーションサーバーのようなステートレスまたはデータベースのようなステートフルです。この概念をPostgreSQLにマッピングすると、不変のアプリケーションコンテナーは、単一の特定のバージョン（immutablecontainerイメージにあるもの）に関連付けられて実行される単一の “postgres”プロセスです。

SSHやsystemd、syslogなどの他のプロセスは許可されません。

不変のアプリケーションコンテナは、コンテナを解釈して使用する非常に一般的な方法であるミュータブルSystemContainerとは対照的です。

不変とは、コンテナがその存続期間中に変更されないことを意味します：noupdates、no patch、no configuration changes。アプリケーションコードを更新するか、パッチを適用する必要がある場合は、新しいイメージをビルドして再デプロイします。不変性は、展開をより安全で再現性の高いものにします。

詳細については、 *"Why EDB chose immutable application containers"* を参照してください。

CloudNativeの意味

Cloud Native Computing Foundationは *Cloud Native* という用語を定義しています。ただし、2ndQuadrantでCloud Native PostgreSQL / CloudNativePGオペレーターがスタートされて以来、開発チームはCloud Nativeasの3つの主要な概念を解釈しています。

1.人々に根ざした既存の健全で本物の繁栄したDevOps文化、およびチームと組織（チームのチームとして）が継続的に変化し、成果と成果の提供を革新および加速できるようにする原則とプロセスより安全で、より効率的で、より魅力的な方法でのビジネスの価値2。 Immutable Application Containers3に基づくマイクロサービスアーキテクチャ。 Kubernetesなど、これらのコンテナーを管理および編成する方法

現在、コンテナオーケストレーションの標準デファクトは、クラウドネイティブアプリケーションの展開、管理、およびスケーラビリティを自動化するKubernetesです。

私たちに共鳴するCloud Nativeの別の定義は、 *"Kubernetes Patterns", published by O'Reilly* でIbryamとHußによって定義されたものです。

大規模なコンテナ化されたマイクロサービスを自動化するための原則、パターン、ツール

<！- ベアメタルKubernetesでCloudNativePGを実行できますか？

TODO

ファイルシステムレプリケーションの代わりにPostgreSQLレプリケーションを使用する必要があるのはなぜですか？

TODO>

コンテナとしてPostgreSQLを実行する代わりに演算子を使用する必要があるのはなぜですか

KubernetesでPostgreSQLを実行する最も基本的な方法は、Apodを使用することです。これはKubernetesでの展開の最小単位であり、レプリカなしでPostgresコンテナを実行します。 Postgresデータディレクトリをホスティングするボリュームはポッドにマウントされ、通常はネットワークストレージに存在します。この場合、Kubernetesは問題が発生した場合にポッドを再起動するか、別のKubernetesノードに移動します。

最も洗練されたアプローチは、演算子を使用してPostgreSQLを実行することです。演算子はKubernetesコントローラの拡張機能であり、ビジネス継続性コンテキストでの複雑なアプリケーションの動作を定義します。 Theoperatorパターンは現在、この目的のために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とKubernetesskillsの両方が必要です。最高の体験は、データベース管理者がKubernetesのコア概念に精通し、Kubernetes管理者とやり取りできるようになることです。

私たちのアドバイスは、Cloud NativePostgreSQLを完全に活用してCNCF認定プログラムから「Certified Kubernetes Administrator（CKA）」ステータスを取得したいすべての人に対するものです。

<！-

高可用性

Patroni、repmgr、Stolonなどのフェールオーバー管理ツールに依存しないCloudNativePGの背後にある理由は何ですか？

TODO

フェイルオーバー（計画外）およびスイッチオーバー（計画）時間が年間99.995％のSLA内であることを保証にはどうすればよいですか？

TODO

フェールオーバー後、以前のプライマリを新しいプライマリと手動で再同期する必要がありますか？

TODO

PostgreSQLのすべてのノードに障害が発生するとどうなりますか？

TODO

バックアップと復元

CloudNativePGはpg_dumpを使用したロジカルバックアップをサポートしていますか？

TODO

災害復旧に関して最良の結果を得るための推奨設定は何ですか？

TODO

PostgreSQLを実行していたKubernetesクラスターが永久になくなった場合はどうなりますか？

TODO

その他

CloudNativePGがサポートするKubernetesディストリビューションとは何ですか？この決定の根拠は何ですか？

TODO

ラージ環境（>4TB/256ギガバイト/64コアなど）のパフォーマンステストまたは値はありますか？

TODO

LDAP/ActiveDirectoryサポートに関する質問

TODO

CloudNativePGデータベースのプロビジョニングはどのように自動化できますか？

TODO

CloudNativePGのプロビジョニング解除はどのように自動化できますか？

TODO

CloudNativePGは、クラスターが削除されたときにPostgreSQLのデータディレクトリを消去しますか？

TODO

ランタイム中にデータベースインスタンスに対してリソース（ストレージ/ CPU /メモリ）の変更はどのように行われますか？

TODO

PostgreSQLクラスターが正常に作成された後、接続に関する詳細をメールで通知するにはどうすればよいですか？

TODO

アップデート

基盤となるKubernetesノードで更新を実行するにはどうすればよいですか？

TODO

PostgreSQLのマイナーバージョン更新をダウンタイムなしで実行できますか？

TODO

PostgreSQLのメジャーバージョンアップグレードをダウンタイムなしで実行できますか？

TODO

データベース管理

PostgreSQLを使用する理由は？

PostgreSQLは、オペレーティングシステムの分野でLinuxが表すデータベーススペースではPostgreSQLに相当すると考えています。 Postgresの現在の最新のメジャーバージョンはバージョン14で、そのまま出荷されます。

  • 物理的およびロジカルなネイティブストリーミングレプリケーション

  • 継続的なホットバックアップとポイントインタイムリカバリ

  • 水平テーブルパーティショニングの宣言的パーティショニング 垂直性を改善するためのデータベース分野で非常によく知られた手法 単一インスタンスでのスケーラビリティ

  • 拡張性、地理用のPostGISなどの拡張機能 データベース

  • 垂直スケーラビリティのための並列クエリ JSONサポート、両方のマルチモデルハイブリッドデータベースの解放 標準SQLを介してクエリされる構造化 非構造化データ

などなど…

単一のPostgreSQLインスタンスでいくつのデータベースをホストする必要がありますか？

単一のマイクロサービスアプリケーションによって完全に管理される単一のデータベースに、単一のPostgreSQLクラスター（プライマリサーバーとマルチプルのスタンバイサーバとして使用）を割り当てることをお勧めします。ただし、「postgres」スーパーユーザを活用することにより、必要な数のユーザーとデータベースを作成することができます（利用サブジェクトなリソースに依存します）。

この推奨事項の理由は、マイクロサービスに基づくクラウドネイティブコンセプトにあります。純粋なマイクロサービスアーキテクチャでは、マイクロサービス自分自身が管理するデータを独占的に所有する必要があります。これらは、フラットファイル、キュー、キーバリューストア、またはこの場合、構造化データと非構造化データの両方を含むPostgreSQLリレーショナルデータベースです。一般的な考え方は、スキーマ管理や移行を含め、マイクロサービスのみがデータベースにアクセスできるということです。

CloudNativePGは、デフォルトでアプリケーションユーザと前述のアプリケーションユーザが所有するアプリケーションデータベースを作成することで、この方法ですぐに使用できるように設計されています。

PostgreSQLインスタンスを単一のマイクロサービス所有データベースに予約すると、次の機能が強化されます。

  • リソース管理： PostgreSQL、CPU、およびメモリの制約 通常、リソースはインスタンスレベルで処理され、 データベースレベル、Kubernetesとの統合を容易にする Poodレベルのリソース管理ポリシー

  • 物理的連続バックアップとポイントインタイムリカバリ（PITR）：指定 PostgreSQLは、 インスタンスレベル、インスタンスごとに1つのデータベースを持つことにより、PITRが簡素化されます 運用、保持ポリシー管理の差別化、および バックアップのデータ保護を強化

  • アプリケーションの更新：各アプリケーションが更新を決定できるようにします 異なる所有者が所有する他のデータベースに影響を与えないポリシー 用途

  • データベースの更新：各アプリケーションがどのPostgreSQLを決定できるか 使用するバージョン、および別のバージョンにアップグレードするタイミング PostgreSQLのメジャーバージョンとその条件（カットオーバーなど） 時間）

<！- 最高のビジネス継続性成果のために推奨されるアーキテクチャは何ですか？

TODO

CloudNativePGによって自動的に作成されるロールやデータベースなどのグローバルオブジェクトは何ですか？

TODO

Q：宣言的な設定によるPostgresロールの管理のサポート

TODO

Q：表領域のサポート

TODO

Q：GUI

TODO

Q：モニタリング

TODO

Q：ロギング

TODO

インスタンスを停止または開始するにはどうすればよいですか？

TODO>