Use cases
=========


.. raw:: html

   <!-- SPDX-License-Identifier: CC-BY-4.0 -->

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

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

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

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

.. figure:: /images/apps-in-k8s.png
   :width: 30% 
   :alt: Application and Database inside Kubernetes

   Application and Database inside Kubernetes

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

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

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

.. figure:: /images/architecture-in-k8s.png
   :width: 40% 
   :alt: Close-up view of application and database inside Kubernetes

   Close-up view of application and database inside Kubernetes

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

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

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

.. figure:: /images/apps-outside-k8s.png
   :width: 50% 
   :alt: Application outside Kubernetes

   Application outside Kubernetes