ユースケース

CloudNativePGは、完全なクラウドネイティブエクスペリエンスのために、同じKubernetesクラスターにあるアプリケーションで動作するように設計されています。

ただし、データベースはKubernetesクラスター内でホストできますが、アプリケーションを同時にコンテナー化できず、VMなどの従来の環境で実行する必要がある場合があります。

ケース1：Kubernetes内のアプリケーション

一般的な状況では、アプリケーションとデータベースは Kubernetes クラスター内の同じ名前空間で実行されます。

Application and Database inside Kubernetes

アプリケーションは、通常はステートレスで、標準のDeployment として管理され、複数のレプリカが異なるKubernetesノードに分散され、 ClusterIP サービスを介して内部的に公開されます。

サービスは、 Ingress およびプロバイダーのロードバランサー機能を介してHTTPSを介してエンドユーザーに外部に公開されます。

アプリケーションはバックエンドのPostgreSQLデータベースを使用して、信頼できる永続的な方法で状態を追跡します。アプリケーションは、TLS接続を介して、現在のプライマリインスタンスをポイントする、CloudNativePGによって定義されたCluster リソースによって公開された読み取り/書き込みサービスを参照します。 Cluster リソースには、単一のプライマリおよびマルチプルのスタンバイアーキテクチャのロジックが組み込まれ、Postgresでの高可用性クラスターの管理の複雑さが隠されています。

Close-up view of application and database inside Kubernetes

ケース2：Kubernetes外部のアプリケーション

別のユースケースは、アプリケーションを外部（仮想化環境など）にしながら、PostgreSQLデータベースをKubernetes内で管理することです。この場合、PostgreSQLは、Kubernetesで定義されたIngressリソースに対応するIPアドレス（またはホスト名）とTCPポートで表されます。

アプリケーションは、PostgreSQLへのTLS接続を引き続き活用できます。

Application outside Kubernetes