Connectivity#

PGDクラスター内の安全なネットワーク通信に関する情報には次のものが含まれます。

サービス#

PGDクラスター内のリソースは、Kubernetesサービスを介してアクセスできます。すべてのPGDグループは、それらのいくつかを管理します。つまり

  • ノードごとに1つのサービス、内部通信に使用されます ノードサービス

  • グループ内の任意のノードに到達する グループサービス 。主にEDB Postgres Distributed for Kubernetesがクラスター内の新しいグループを検出するために使用します

  • PGDプロキシを使用して、アプリケーションが透過的にグループの書き込みリーダーに到達できるようにする プロキシサービス

  • アプリケーションがPGDプロキシを透過的に使用して、グループの読み取りノードに到達できるようにする プロキシ-rサービス 。このサービスはデフォルトで無効になっており、.spec.proxySettings.enableReadNodeRouting 設定によって制御されます

これらのサービスを使用する例については、 アプリケーションからPGDクラスターに接続する を参照してください。

Basic architecture of an EDB Postgres Distributed for Kubernetes PGD group

Basic architecture of an EDB Postgres Distributed for Kubernetes PGD group#

各サービスは、マニフェストの.spec.connectivity セクションのカスタマイズ可能なテンプレートから生成されます。

すべてのサービスは、すべてのKubernetesクラスターのすべてのPGDノードからFQDNを使用して到達可能である必要があります。 ドメイン名解決 を参照してください。

EDB Postgres Distributed for Kubernetesは、次の3つのレベルでサービスを簡単にカスタマイズできる可用性を提供するサービステンプレートフレームワークを提供します。

ノードサービステンプレート 各PGDノードは、 .spec.connectivity.nodeServiceTemplate セクションで構成できるサービスを使用して到達可能です。

グループサービステンプレート 各PGDグループには、グループ全体の単一のエントリポイントであり、 .spec.connectivity.groupServiceTemplate セクションで構成できるグループサービスがあります。

プロキシサービステンプレート 各PGDグループには、PGDプロキシを介してグループ書き込みリーダーに到達するプロキシサービスがあり、 .spec.connectivity.proxyServiceTemplate セクションで構成できます。これは、アプリケーションのエントリーポイントサービスです。

プロキシ読み取りサービステンプレート 各PGDグループには、PGDプロキシを介してグループ読み取りノードに到達するプロキシサービスがあり、 .spec.proxySettings.enableReadNodeRouting で有効にでき、.spec.connectivity.proxyReadServiceTemplate セクションで構成できます。これは、アプリケーションのエントリーポイントサービスです。

テンプレートを使用して、LoadBalancerサービスを作成したり、任意のアノテーションとラベルをサービスに追加して、Kubernetesシステムで使用可能な他のコンポーネントと統合したり、外部DNS名を作成したり、生成されたロードバランサーを調整したりできます。

ドメイン名解決#

KubernetesのEDB Postgres Distributedは、 PGDグループ名をすべてのプレフィックスとして使用する規則を採用することにより、 PGDグループ内のすべてのリソースがFQDNを持つことを保証します。

その結果、 PGDグループのドメイン名を定義することが想定されます。これは、 .spec.connectivity.dns セクションを介して行うことができます。このセクションは、2つのフィールドでリソースのFQDNを生成する方法を制御します。

  • domain —使用するPGDグループ内のすべてのオブジェクトのドメイン名必須。

  • hostSuffix — PGDグループの各サービスに追加するサフィックスオプショナル。

TLS構成#

EDB Postgres Distributed for Kubernetesでは、PGDクラスター内のリソースが安全な接続を介して通信する必要があります。 PostgreSQLの SSL connections のネイティブサポートに依存しています

セキュリティを向上させるためにTLSプロトコルを使用してクライアント/サーバー通信を暗号化します。

現在、 EDB Postgres Distributed for Kubernetesでは、

cert-manager をインストールする必要があります。

Cert-managerは、Kubernetes環境の標準として広く認識されているため、動的証明書をプロビジョニングするツールとして選択されました。

spec.connectivity.tls セクションでは、ノード間の通信がどのように発生するかを説明します。

  • mode は、PGDグループノードの通信中にサーバー証明書が検証される方法を説明する列挙体です。 SSL Support に記載されているように、次の値を受け入れます。

PostgreSQLドキュメント内

  • verify-full

  • verify-ca

  • required

  • serverCert は、 PGDグループノードが要求を受け入れるために使用するサーバー証明書を定義します。クライアントは、渡されたTLSモードに応じてこの証明書を検証します。 mode と同じ値を受け入れます。

  • clientCert は、ノードが相互に認証するために使用するstreaming_replica ユーザー証明書を定義します。

サーバーTLS構成#

サーバー証明書構成は、 PGDGroup カスタムリソースの.spec.connectivity.tls.serverCert.certManager セクションで指定されます。

このセクションが機能するためには、次の前提条件が作成されました。

  • 発行者.spec.connectivity.tls.serverCert.certManager.issuerRef は、ドメイン.spec.connectivity.dns.domain および.spec.connectivity.tls.serverCert.certManager.altDnsNames が使用するその他のドメインで利用できます。

  • 発行者.spec.connectivity.tls.serverCert.caCertSecret が使用するCAのパブリック証明書を含むシークレットがあります。

.spec.connectivity.tls.serverCert.certManager は、ノードごとのcert-manager証明書要求を作成するために使用されます。結果の証明書は、基になるPostgresインスタンスがTLS接続を終了するために使用されます。

オペレーターは、次のaltDnsNamesを証明書に追加します。

  • $node$hostSuffix.$domain

  • $groupName$hostSuffix.$domain

重要

基になるネットワークアーキテクチャ、たとえば、ユーザーがノードに到達するために使用するロードバランサーから必要な名前を`.spec.connectivity.tls.serverCert.certManager.altDnsNames` に追加するのは自分の責任です。

クライアントTLS構成#

オペレーターは、cert-manager推奨アプローチを使用してクライアント証明書を動的にプロビジョニングするか、シークレットを使用して事前プロビジョニングを必要とします。

cert-managerを介した動的プロビジョニング#

クライアント証明書構成は、 PGDGroup カスタムリソースの.spec.connectivity.tls.clientCert.certManager セクションで管理されます。このセクションが機能するためには、次の前提条件が作成されました。

  • 発行者.spec.connectivity.tls.clientCert.certManager.issuerRef が利用でき、一般名streaming_replica で証明書に署名します。

  • 発行者.spec.connectivity.tls.clientCert.caCertSecret が使用するCAのパブリック証明書を含むシークレットがあります。

オペレーターは、.spec.connectivity.tls.clientCert.certManager の下の構成を使用して、streaming_replica Postgresユーザーごとに証明書要求を作成します。結果の証明書は、ノード間の通信を保護するために使用されます。

シークレットを介した事前プロビジョニングされた証明書#

または、 .spec.connectivity.tls.clientCert.preProvisioned.streamingReplica.secretRef オプションを使用して、ストリーミングレプリケーションユーザーの事前プロビジョニングされたクライアント証明書を含むシークレットを指定できます。この場合の証明書ライフサイクルは、シークレットの内容を更新することにより、サードパーティが手動または自動で完全に管理します。

アプリケーションからPGDクラスターに接続する#

同じKubernetesクラスター内またはクラスターの外部から実行されているアプリケーションからPGDグループに接続するのは、簡単な手順です。どちらの場合も、 app ユーザーとしてPGDグループのプロキシサービスに接続します。プロキシサービスは、どのプロキシサービスが接続しているかに応じて、PGDグループの書き込みリーダーまたは読み取りノードに接続をルーティングするLoadBalancerサービスです。

クラスター内からの接続#

クラスター内から接続する場合、プロキシサービス名を使用してPGDグループに接続できます。プロキシサービス名は、 PGDグループ名と、PGDGroup カスタムリソースの.spec.connectivity.dns セクションで定義されたオプションのホストサフィックスで構成されています。

たとえば、 PGDグループ名がmy-group で、ホストサフィックスが.my-domain.com の場合、プロキシサービス名はmy-group.my-domain.com になります。

接続する前に、アプリユーザーのシークレットからアプリユーザーのパスワードを取得する必要があります。シークレットの命名形式は、 my-group という名前のPGDグループの場合 my-group-app です。

次のコマンドを使用して、シークレットからユーザー名とパスワードを取得できます。

kubectl get secret my-group-app -o jsonpath={.data.username} | base64 --decode
kubectl get secret my-group-app -o jsonpath={.data.password} | base64 --decode

これにより、 PGDグループへの接続文字列のすべての部分が揃います。

postgresql://<app-user>:<app-password>@<proxy-service-name>:5432/<database>

または、 psql 呼び出しの場合

psql -U <app-user> -h <proxy-service-name> <database>

app-user およびapp-password はシークレットから取得した値であり、 database は接続するデータベースの名前です。アプリユーザーのデフォルトはapp です。

Kubernetesクラスターの外部からの接続#

Kubernetesクラスターの外部から接続する場合、一般的には、

Ingress リソースまたは load balancer が必要です。環境での動作の詳細については、クラウドプロバイダーまたはローカルインストールを確認してください。

イングレスとロードバランサーでは、接続をPGDプロキシに転送するためにポッドセレクターが必要です。それらを構成するときは、次のラベルを使用することをお勧めします。

  • k8s.pgd.enterprisedb.io/group — PGDグループ名を設定します。

  • k8s.pgd.enterprisedb.io/workloadType — pgd-proxy に設定します。

ローカル開発にKindまたは他のソリューションを使用している場合、外部からPGDグループにアクセスする最も簡単な方法は、プロキシサービスへのポート転送を使用することです。次のコマンドを使用して、ローカルマシンのポート5432をプロキシサービスに転送できます。

kubectl port-forward svc/my-group.my-domain.com 5432:5432

my-group.my-domain.com は、前の例のプロキシサービス名です。