よくある質問（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* “という用語を定義しています。ただし、2ndQuadrantでクラウドネイティブPostgreSQL / CloudNativePGオペレーターが開始されて以来、開発チームはクラウドネイティブを3つの主な概念として解釈しています。
1.人々、原則とプロセスに基づいた、既存の健全で本物の繁栄したDevOps文化。より安全で効率的で魅力的な方法でビジネスに価値を
2.イミュータブルアプリケーションコンテナに基づくマイクロサービスアーキテクチャ
3.これらのコンテナ（Kubernetesなど）を管理およびオーケストレーションする方法
現在、コンテナオーケストレーションの事実上の標準は、クラウドネイティブアプリケーションの展開、管理、スケーラビリティを自動化するKubernetesです。
私たちの共感を呼ぶクラウドネイティブの別の定義は、 *"Kubernetes Patterns", published by O'Reilly* でIbryamとHußによって定義されたものです。
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 管理者と対話できるときです。
クラウドネイティブPostgreSQLを最大限に活用して、CNCF認定プログラムから「Certified Kubernetes Administrator（CKA）」ステータスを取得したいと考えているすべての人へのアドバイスです。
データベース管理¶
なぜPostgreSQLを使用する必要があるのですか?
PostgreSQLは、Linuxがオペレーティングシステム空間で表すものとデータベース領域で同等であると考えています。 Postgresの現在の最新メジャーバージョンはバージョン14で、すぐに出荷されます。
ネイティブストリーミングレプリケーション、物理的および論理的
継続的なホットバックアップとポイントインタイムリカバリ
単一インスタンスの垂直スケーラビリティを向上させるためのデータベース分野で非常によく知られている技術である、水平方向のテーブルパーティショニングの宣言的パーティショニング
拡張性、地理データベース用の PostGISクラスター のような拡張機能
垂直スケーラビリティのための並列クエリ
JSONサポート、標準SQLを介して照会される構造化データと非構造化データの両方のマルチモデルハイブリッドデータベースを解き放ちます
などなど…
単一のPostgreSQLインスタンスでホストするデータベースはいくつですか?
単一のマイクロサービスアプリケーションで完全に管理される単一のデータベース専用に、単一のPostgreSQLクラスター（プライマリサーバーとマルチプルのスタンバイサーバー）を使用することをお勧めします。ただし、「postgres」スーパーユーザーを活用することにより、必要な数のユーザーとデータベースを作成できます（使用可能なリソースによります）。
この推奨の理由は、マイクロサービスに基づくクラウドネイティブの概念にあります。純粋なマイクロサービス アーキテクチャでは、マイクロサービス自分自身が管理するデータを排他的に所有する必要があります。これらは、フラットファイル、キュー、キーバリューストア、またはこの場合は構造化データと非構造化データの両方を含むPostgreSQLリレーショナルデータベースです。一般的な考え方は、スキーマ管理と移行を含め、マイクロサービスのみがデータベースにアクセスできるということです。
CloudNativePGは、このようにすぐに動作するように設計されており、デフォルトでは、アプリケーションユーザーと、前述のアプリケーションユーザーが所有するアプリケーションデータベースを作成します。
PostgreSQLインスタンスを単一のマイクロサービス所有データベースに予約すると、以下が強化されます。
リソース管理：PostgreSQLでは、CPU、およびメモリの制約のあるリソースは一般的にデータベースレベルではなくインスタンスレベルで処理されるため、プードレベルでのKubernetesリソース管理ポリシーとの統合が簡単になります
物理的連続バックアップとポイントインタイムリカバリ（PITR）：PostgreSQLがインスタンスレベルで継続的なバックアップとリカバリを処理することを考えると、インスタンスごとに1つのデータベースを持つことでPITR操作が簡素化され、保持ポリシー管理が差別化され、バックアップのデータ保護が向上します
アプリケーションの更新：各アプリケーションは、異なるアプリケーションが所有する他のデータベースに影響を与えることなく、更新ポリシーを決定できます
データベースの更新：各アプリケーションは、使用するPostgreSQLのバージョンを独立して、PostgreSQLの別のメジャーバージョンにアップグレードするタイミングと条件（カットオーバー時間など）を決定できます
Kubernetesを考慮しない場合のデータベースサイズに上限はありますか?
いいえ、これに関する限り、Kubernetesは仮想マシンやベアメタルと同じです。ただし、実際には、Kubernetesクラスターで使用可能なリソースによって異なります。非常に大規模なデータベース（ ワーカー ）でのアドバイスは、専用ストレージを備えた単一のPostgresインスタンス専用のシェアードナッシングアーキテクチャを検討することです。 running PostgreSQL on bare metal Kubernetes with local persistent volumesをベンチマークしたときに、この極端なアーキテクチャパターンが機能することが証明されました。将来のリリースで克服されるCloudNativePGの現在の制限は、水平パーティション化を簡単に実装できるようにテーブルスペースがサポートされていないことです。
PostgreSQLクラスターでタイムゾーンを指定するにはどうすればよいですか?
公式ドキュメントで説明されているように、PostgreSQLはタイムゾーンを幅広くサポートしています。
タイムゾーンはセッション、トランザクション、さらにはPostgreSQLのクエリの一部としても使用できますが、非常に一般的な方法はそれらをグローバルに設定することです。
CloudNativePGを使用すると、次の例のように、
spec.postgresql.parameters
セクションでクラスターレベルのタイムゾーンを構成できます。
apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
name: pg-italy
spec:
instances: 1
postgresql:
parameters:
timezone: "Europe/Rome"
storage:
size: 1Gi
タイムゾーンは次で確認できます。
$ kubectl exec -ti pg-italy-1 -c postgres -- psql -x -c "SHOW timezone"
- [ RECORD 1 ]---------
TimeZone | Europe/Rome
