Service management

PostgreSQLクラスターには、CloudNativePGによって直接管理される標準のKubernetesネットワークサービスを介してのみアクセスする必要があります。詳細については、 Service を参照してください。

CloudNativePGは、Cluster リソースごとに3種類のサービスを定義します。

  • rw クラスターのプライマリインスタンスへのポイント読み取り/書き込み。

  • ro レプリカを指します使用可能な場合読み取り専用。

  • r クラスター内のPostgreSQLインスタンスを指します読み取り。

デフォルトでは、CloudNativePGは次の規則でCluster リソースの上記のすべてのサービスを作成します。

  • サービスの名前は、<CLUSTER_NAME>-<SERVICE_NAME> の形式に従います。

  • すべてのサービスはClusterIP タイプです。

  • ro および/またはr デフォルトサービスの作成を無効にします。

  • Kubernetesが提供する標準のService APIを使用して、独自のサービスを定義します。

これら2つのオプションを組み合わせることができます。

一般的なシナリオは、Kubernetesクラスターの外部からデータベースへのアクセスが必要なDBaaSコンテキストでCloudNativePGを使用する場合に発生します。このような場合、Kubernetes環境で使用可能な場合、タイプLoadBalancer の独自のサービスを作成できます。

デフォルトサービスの無効化

managed.services.disabledDefaultServices を介して、 ro およびr デフォルトサービスの一部またはすべてを無効にできます。

#  <snip>

managed:
  services:
    disabledDefaultServices: ["ro", "r"]

独自のサービスの追加

selectorType フィールドでサービスタイプrw などを指定し、オプションでupdateStrategy を指定します。

serviceTemplate フィールドは、ネットワークService リソースの標準のKubernetes APIにアクセスし、必要に応じて metadata およびspec セクションの両方を定義できます。

name をサービスに提供し、selector フィールドはオペレーターによって管理されるため、定義しないでください。

警告

サービステンプレートは、PostgreSQLデータベースへのネットワークアクセスの構成という点で無限の可能性を提供します。これは、サービスが期待どおりに動作することを保証するための、あなたの側の責任の増大を意味します。 CloudNativePGは、セレクターを尊重することを除き、サービス構成を制御できません。 updateStrategy フィールドを使用すると、オペレーターがサービス定義を更新する方法を制御できます。デフォルトでは、オペレーターは`patch` ストラテジーを使用し、変更をサービスに直接適用します。または、 replace ストラテジーは、既存のサービスを削除し、テンプレートから再作成します。

警告

replace ストラテジーは、変更されるたびにサービスの中断を発生させます。 ただし、サービスの作成中にのみ設定できる特定のパラメーターを変更するために必要になる場合があります。たとえば、PostgreSQLデータベースプライマリに単一の`LoadBalancer` サービスを使用する場合、次の抜粋を使用できます。

#  <snip>

managed:
  services:
    additional:
      - selectorType: rw
        serviceTemplate:
          metadata:
            name: "mydb-lb"
            labels:
              test-label: "true"
            annotations:
              test-annotation: "true"
          spec:
            type: LoadBalancer

上記の例は、作成したサービスのアノテーションやラベルなどのメタデータを設定する方法も示しています。

Postgresサービスの公開について

PostgreSQLサービスをKubernetesクラスターの外部に公開するには、主に3つのユースケースがあります。

  • 一時的に、テスト用。

  • 永続的に、 DBaaS目的 。

  • 長期/永久 簡単または持続的にコンテナ化できず、Kubernetesの外部の仮想マシンまたは物理マシンに存在する必要がある 古いアプリケーション の場合。この使用例はDBaaSに非常に似ています。

パブリックネットワークからデータベースへのアクセスを許可すると、データベースが悪意のあるユーザーからの潜在的な攻撃にさらされる可能性があることに注意してください。

警告

外部アクセスを許可する前にデータベースを保護していることを確認するか、Kubernetesクラスターがプライベートネットワークからのみ到達可能であることを確認してください。