Use cases

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

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

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

通常、アプリケーションとデータベースは、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

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

もう1つの考えられるユースケースは、Kubernetes内でPostgreSQLデータベースを管理し、アプリケーションをその外部たとえば仮想化環境に持たせることです。この場合、PostgreSQLは、Kubernetesで定義されたIngressリソース通常は Service management ページで説明しているLoadBalancer サービスタイプに対応するIPアドレスまたはホスト名とTCPポートで表されます。

アプリケーションは、PostgreSQLへのTLS接続の恩恵を引き続き受けられます。