Add-ons ======= KubernetesのEDB Postgresは、クラスターごとに有効にできるアドオンをサポートしています。これらのアドオンは次のとおりです。 1. :ref:`外部バックアップアダプター <外部バックアップアダプター>` 2. :ref:`カステン <カステン>` 3. :ref:`ヴェレロ <ヴェレロ>` .. Note:: OpenShiftでVeleroを使用する予定がある場合は、Openshiftドキュメントの :ref:`OADP section ` を参照してください。 オペレーターはすべてのアドオンを自動的に利用できるようになり、使用するには、 ``k8s.enterprisedb.io/addons`` アノテーションを介してクラスターレベルで有効にする必要があります。 外部バックアップアダプター -------------------------- 外部バックアップアダプタアドオンは、ラベルおよび/または注釈を介して識別するカスタマイズ可能な方法を介して、バックアップ用のサードパーティツールにKubernetesのEDB Postgresを統合する汎用方法を提供します。 - どのPVCグループをバックアップするか - クラスターに1つ以上のアクティブなレプリカがある場合、どのPVCを除外するか - バックアップのために選択されたPostgreSQLインスタンスを実行しているポッドスタンバイまたは使用できない場合はプライマリ バックアップシステムのアダプターを構成できる方法のみが異なる2つのアドオンから選択できます。 - ``external-backup-adapter`` 構成マップまたはシークレットを介してオペレーターの構成レベルで動作をカスタマイズ、オペレーターの展開によって管理されるすべてのPostgresクラスターと共有する場合 :ref:`the `external-backup-adapter` section below ` を参照してください。 - ``external-backup-adapter-cluster`` 特定のアノテーションを介してPostgresクラスターレベルでアダプターの動作をカスタマイズする場合 :ref:`the `external-backup-adapter-cluster` section below ` を参照してください このようなアドオンを使用すると、オペレーターが選択したポッドでバックアップを取得する前または後に実行するコマンドを含むアノテーションの名前を定義できます。 その結果、Kubernetesのサードパーティバックアップツールは、上記に依存して、PostgreSQLクラスターまたはそのセットと自分自身を調整できます。 リカバリーは、オペレーターが既存のPVCグループからクラスターを調整することに依存するだけです。 .. Important:: 外部バックアップアダプターは、バックアップを実行するツールではありません。これは、Kubernetesスペースのサードパーティバックアップツールが使用できる汎用インターフェイスを提供するだけです。このようなツールは、PVCおよび/またはコンテンツを安全に保存し、復旧時にKubernetesクラスターに必要なすべてのリソース定義とともに利用できるようにします。 アダプターのカスタマイズ ^^^^^^^^^^^^^^^^^^^^^^^^ 前述のように、アダプターは2つの方法で構成でき、これにより、 ``Cluster`` リソースで使用する必要がある実際の\ ``add-on`` が決まります。 オペレーターによって管理されるすべてのPostgres ``Cluster`` リソースに同じ動作を定義する予定がある場合は、 ``external-backup-adapter`` アドオンを使用し、オペレーターの構成でアノテーション/ラベルを構成することをお勧めします。 所有するPostgres ``Cluster`` リソースのサブセットに異なる動作を予定している場合は、 ``external-backup-adapter-cluster`` アドオンを使用することをお勧めします。 両方のアドオンは、カスタマイズという点で同じ機能を共有します。これは、次のキーを持つYAMLオブジェクトとして定義する必要があります。 - ``electedResourcesDecorators`` - ``excludedResourcesDecorators`` - ``excludedResourcesSelector`` - ``backupInstanceDecorators`` - ``preBackupHookConfiguration`` - ``postBackupHookConfiguration`` 以下、各セクションについて説明します。さらに下には、2つのアドオンをそれぞれカスタマイズする方法と、いくつかの例があります。 ``electedResourcesDecorators`` セクション ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ このセクションでは、選択されたすべてのPVCグループに配置されるラベルおよび/またはアノテーションの配列を構成できます。 配列の各要素には、次のフィールドが必要です。 ``key`` ラベルまたはアノテーションのキーの名前 ``metadataType`` メタデータのタイプ、\ ``"label"`` または\ ``"annotation"`` のいずれか ``value`` ラベルまたは注釈に割り当てられる値 ``excludedResourcesDecorators`` セクション ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ このセクションでは、除外されたすべてのポッドおよびPVCに配置されるラベルおよび/またはアノテーションの配列を構成できます。 配列の各要素には、上記の\ ``electedResourcesDecorators`` セクションと同じフィールドが必要です。 ``excludedResourcesSelector`` セクション ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ このセクションでは、\ ``excludedResourcesDecorators`` に適用されるポッドとPVCを選択します。 `label selector rule `_ を受け入れます 値として。空の場合、すべてのポッドと選択されなかったすべてのPVCが除外されます。 ``backupInstanceDecorators`` セクション ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ このセクションでは、オペレーターによってバックアップのために選択され、実行されるフックが含まれるインスタンスに配置されるラベルおよび/またはアノテーションの配列を構成できます。 配列の各要素には、上記の\ ``electedResourcesDecorators`` セクションと同じフィールドが必要です。 ``preBackupHookConfiguration`` セクション ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ このセクションでは、オペレーターがコンテナの名前、バックアップを取る前に実行するコマンド、およびサードパーティツール側でエラー/中止が発生した場合に実行するコマンドを配置するアノテーションの名前を制御できます。 。このようなメタデータは、バックアップのためにオペレーターが選択したインスタンスに適用されます上記の\ ``backupInstanceDecorators`` を参照してください。 次のフィールドを提供する必要があります。 ``container`` バックアップ前コマンドを実行するコンテナに関する情報を配置する場所を指定します。コンテナ名は固定値であり、構成はできません。注釈に保存されます。フックでポッドを装飾するには、次を参照してください ``instanceWithHookDecorators`` ``command`` バックアップが取られる前に実行されるコマンドに関する情報を配置する場所を指定します。実行されるコマンドは固定値であり、設定はできません。注釈に保存されます。フックでポッドを装飾するには、次を参照してください ``instanceWithHookDecorators`` ``onError`` エラーが発生した場合に実行されるコマンドに関する情報を配置する場所を指定します。実行されるコマンドは固定値であり、設定はできません。注釈に保存されます。フックでポッドを装飾するには、次を参照してください ``instanceWithHookDecorators`` ``postBackupHookConfiguration`` セクション ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ このセクションでは、オペレーターがコンテナの名前とバックアップを取った後に実行するコマンドを配置するアノテーションの名前を制御できます。このようなメタデータは、バックアップのためにオペレーターが選択したインスタンスに適用されます上記の\ ``backupInstanceDecorators`` を参照してください。 次のフィールドを提供する必要があります。 ``container`` post-backupコマンドを実行するコンテナに関する情報を配置する場所を指定します。コンテナ名は固定値であり、構成はできません。注釈に保存されます。フックでポッドを装飾するには、次を参照してください ``instanceWithHookDecorators`` ``command`` バックアップが取られた後に実行されるコマンドに関する情報を配置する場所を指定します。実行されるコマンドは固定値であり、設定はできません。注釈に保存されます。フックでポッドを装飾するには、次を参照してください ``instanceWithHookDecorators`` ``external-backup-adapter`` アドオン ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``external-backup-adapter`` アドオンは、オペレーターの\ ``ConfigMap`` /``Secret`` の\ ``EXTERNAL_BACKUP_ADDON_CONFIGURATION`` フィールドを介して、オペレーターレベルで完全に設定できます。 詳細については、このセクションの最後に提供されているサンプルファイル、または以下の例を参照してください。 .. code:: yaml apiVersion: v1 kind: ConfigMap metadata: name: postgresql-operator-controller-manager-config namespace: postgresql-operator-system data: # ... EXTERNAL_BACKUP_ADDON_CONFIGURATION: |- electedResourcesDecorators: - key: "app.example.com/elected" metadataType: "label" value: "true" excludedResourcesSelector: app=xyz,env=prod excludedResourcesDecorators: - key: "app.example.com/excluded" metadataType: "label" value: "true" - key: "app.example.com/excluded-reason" metadataType: "annotation" value: "Not necessary for backup" backupInstanceDecorators: - key: "app.example.com/hasHooks" metadataType: "label" value: "true" preBackupHookConfiguration: container: key: "app.example.com/pre-backup-container" command: key: "app.example.com/pre-backup-command" onError: key: "app.example.com/pre-backup-on-error" postBackupHookConfiguration: container: key: "app.example.com/post-backup-container" command: key: "app.example.com/post-backup-command" アドオンは、次のアノテーションを\ ``Cluster`` リソースに追加することによりアクティブにできます。 .. code:: yaml k8s.enterprisedb.io/addons: ["external-backup-adapter"] ``external-backup-adapter-cluster`` アドオン ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``external-backup-adapter-cluster`` アドオンは、次の例に示すように、 ``k8s.enterprisedb.io/externalBackupAdapterClusterConfig`` アノテーション-コンテンツとしてYAMLオブジェクトを受け入れます-を介して使用する各\ ``Cluster`` リソースで構成する必要があります。 .. code:: yaml apiVersion: postgresql.k8s.enterprisedb.io/v1 kind: Cluster metadata: name: cluster-example annotations: "k8s.enterprisedb.io/addons": ["external-backup-adapter-cluster"] "k8s.enterprisedb.io/externalBackupAdapterClusterConfig": |- electedResourcesDecorators: - key: "app.example.com/elected" metadataType: "label" value: "true" excludedResourcesSelector: app=xyz,env=prod excludedResourcesDecorators: - key: "app.example.com/excluded" metadataType: "label" value: "true" - key: "app.example.com/excluded-reason" metadataType: "annotation" value: "Not necessary for backup" backupInstanceDecorators: - key: "app.example.com/hasHooks" metadataType: "label" value: "true" preBackupHookConfiguration: container: key: "app.example.com/pre-backup-container" command: key: "app.example.com/pre-backup-command" onError: key: "app.example.com/pre-backup-on-error" postBackupHookConfiguration: container: key: "app.example.com/post-backup-container" command: key: "app.example.com/post-backup-command" spec: instances: 3 storage: size: 1Gi フェンシングのアノテーションについて ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 構成された外部バックアップアダプタがアノテーションをバックアップする場合、フェンシングアノテーションはプレバックアップフックによって設定され、復元されたクラスターに持続します。クラスターを復元した後、これを修正するには、\ ``Cluster`` オブジェクトからフェンシングアノテーションを手動で削除する必要があります。 これは、kubectlの\ ``cnp`` プラグインを使用して行うことができます。 .. code:: shell kubectl cnp fencing off または、 ``cnp`` プラグインがない場合は、次のコマンドを使用してフェンシングアノテーションを手動で削除できます。 .. code:: shell kubectl annotate cluster k8s.enterprisedb.io/fencedInstances- 詳細については、 :ref:`fencing documentation ` を参照してください。 制限事項 ^^^^^^^^ バックアップ部分に関する限り、現在、KubernetesのEDB Postgresと\ ``external-backup-adapter`` および\ ``external-backup-adapter-cluster`` との統合は、 **コールドバックアップ** のみをサポートしています。これらは **オフラインバックアップ** とも呼ばれます。これは、選択したレプリカが一時的にフェンスされ、\ ``external-backup-adapter`` および\ ``external-backup-adapter-cluster`` がPVCグループ、つまり\ ``PGDATA`` ボリューム、および使用可能な場合はWALボリュームの物理的スナップショットを取得できることを意味します。 この短い時間フレームでは、スタンバイは読み取り専用の接続を受け入れることができません。使用可能なスタンバイがなく、通常は単一インスタンスのクラスターにいるため、アノテーション\ ``k8s.enterprisedb.io/snapshotAllowColdBackupOnPrimary`` がtrueに設定されている場合、\ ``external-backup-adapter`` および\ ``external-backup-adapter-cluster`` はプライマリを一時的にフェンスし、読み取り/書き込み操作の点でダウンタイムが発生します。このユースケースは、通常、開発環境に任されます。 YAMLファイルの完全な例 ^^^^^^^^^^^^^^^^^^^^^^ これは、次のいずれかに配置されるYAMLコンテンツの完全な例です。 - ``external-backup-adapter`` アドオンについて上記で説明したオペレーターの構成プロセスの一部としての\ ``EXTERNAL_BACKUP_ADDON_CONFIGURATION`` オプション、または - ``external-backup-adapter-cluster`` アドオンの\ ``k8s.enterprisedb.io/externalBackupAdapterClusterConfig`` アノテーション内 .. Hint:: 以下のコンテンツをコピーし、 `Cluster` で演算子またはアノテーションを構成するために使用する`ConfigMap` または`Secret` の中に貼り付けます。必ず、 `YAML reserves for literals `_ の`|` 文字と適切なインデントを使用します。コメントを使用して、ツールのオプションをカスタマイズします。 .. code:: yaml # An array of labels and/or annotations that will be placed # on the elected PVC group electedResourcesDecorators: - key: "backup.example.com/elected" metadataType: "label" value: "true" # An array of labels and/or annotations that will be placed # on every excluded pod and PVC excludedResourcesDecorators: - key: "backup.example.com/excluded" metadataType: "label" value: "true" - key: "backup.example.com/excluded-reason" metadataType: "annotation" value: "Not necessary for backup" # A LabelSelector containing the labels being used to filter Pods # and PVCs to decorate with excludedResourcesDecorators. # It accepts a label selector rule as value. # See https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors # When empty, all the Pods and every PVC that is not elected will be excluded. excludedResourcesSelector: app=xyz,env=prod # An array of labels and/or annotations that will be placed # on the instance pod thats been selected for the backup by # the operator and which contains the hooks. # At least one element is required backupInstanceDecorators: - key: "backup.example.com/hasHooks" metadataType: "label" value: "true" # The pre-backup hook configuration allows you to control the names # of the annotations in which the operator will place the container # name, the command to run before taking the backup, and the command # to run in case of error/abort on the third-party tool side. # Such metadata will be applied on the instance thats been selected # by the operator for the backup (see `backupInstanceDecorators`) preBackupHookConfiguration: # Where to place the information about the container that will run # the pre-backup command. The container name is a fixed value and # cannot be configured. Will be saved in the annotations. # To decorate the pod with the hooks refer to: instanceWithHookDecorators container: key: "app.example.com/pre-backup-container" # Where to place the information about the command that will be # executed before the backup is taken. The command is a fixed value # and cannot be configured. Will be saved in the annotations. # To decorate the pod with the hooks refer to: instanceWithHookDecorators command: key: "app.example.com/pre-backup-command" # Where to place the information about the command that will be # executed in case of an error on the third-party tool side. # The command is a fixed value and cannot be configured. # Will be saved in the annotations. # To decorate the pod with the hooks refer to: instanceWithHookDecorators onError: key: "app.example.com/pre-backup-on-error" # The post-backup hook configuration allows you to control the names # of the annotations in which the operator will place the container # name and the command to run after taking the backup. # Such metadata will be applied on the instance thats been selected by # the operator for the backup (see `backupInstanceDecorators`). postBackupHookConfiguration: # Where to place the information about the container that will run # the post-backup command. The container name is a fixed value and # cannot be configured. Will be saved in the annotations. # To decorate the pod with hooks refer to: instanceWithHookDecorators container: key: "app.example.com/post-backup-container" # Where to place the information about the command that will be # executed after the backup is taken. The command is a fixed value # and cannot be configured. Will be saved in the annotations. # To decorate the pod with hooks refer to: instanceWithHookDecorators command: key: "app.example.com/post-backup-command" カステン -------- Kastenは、Kubernetesの非常に人気のあるデータ保護ツールであり、Kubernetesアプリケーションのバックアップと復元、ディザスターリカバリー、およびアプリケーションモビリティを可能にします。詳細については、 `Kastenwebsite `_ および :ref:`Kasten by Veeam ImplementationGuide ` を参照してください。 つまり、KubernetesクラスターのEDB PostgresでKastenとの透過的な統合を有効にするには、\ ``Cluster`` 仕様の\ ``k8s.enterprisedb.io/addons`` アノテーションに\ ``kasten`` 値を追加するだけです。例 .. code:: yaml kind: Cluster metadata: name: one-instance annotations: k8s.enterprisedb.io/addons: ["kasten"] k8s.enterprisedb.io/snapshotAllowColdBackupOnPrimary: enabled spec: instances: 1 storage: size: 1Gi walStorage: size: 1Gi クラスターが作成され正常になると、オペレーターは指定されたバックアップとして最も遠いアヘッドレプリカインスタンスを選択し、アノテーションとラベルを介してKasten固有のバックアップフックをそのインスタンスに追加します。 .. Important:: クラスターに`k8s.enterprisedb.io/snapshotAllowColdBackupOnPrimary: enabled` のアノテーションが付けられていない限り、オペレーターはプライマリインスタンスをシャットダウンしてコールドバックアップを取ることを拒否します Kastenの構成と使用方法の詳細については、実装ガイドの :ref:`Instance pod configuration ` および :ref:`Iron Bankイメージを使用したPG4Kオペレーターのインストール ` セクションを参照してください。 .. _制限事項-1: 制限事項 ^^^^^^^^ バックアップ部分に関する限り、現在KastenとのKubernetes統合のEDB Postgresは **コールドバックアップ** のみをサポートしています。これらは **オフラインバックアップ** とも呼ばれます。これは、選択したレプリカが一時的にフェンスされ、外部バックアップアダプターがPVCグループ、つまり\ ``PGDATA`` ボリューム、および使用可能な場合はWALボリュームの物理的スナップショットを取得できることを意味します。 この短い時間フレームでは、スタンバイは読み取り専用の接続を受け入れることができません。使用可能なスタンバイがなく、通常は単一インスタンスのクラスターにいるため、アノテーション ``k8s.enterprisedb.io/snapshotAllowColdBackupOnPrimary`` がtrueに設定されている場合、Kastenはプライマリを一時的にフェンスし、読み取り/書き込み操作の点でダウンタイムが発生します。このユースケースは、通常、開発環境に任されます。 リカバリーの面では、Kastenとの統合はスナップショットリカバリーのみをサポートしています。現時点ではKastenアドオンでは利用可能なポイントインタイムリカバリーPITRはなく、RPOはKasten環境のスナップショットの頻度によって決まります。組織がKastenに依存している場合、これは通常許容されますが、PITRが必要な場合は、オブジェクトストアのネイティブ継続バックアップ方法を検討することをお勧めします。 ヴェレロ -------- Veleroは、Kubernetesクラスターリソースと永続ボリュームを安全にバックアップ、復元、ディザスターリカバリーを実行、および移行するためのオープンソースツールです。詳細については、 `Velero documentation `_ を参照してください。 KubernetesクラスターのEDB PostgresとVelero互換性を有効にするには、 ``velero`` 値をクラスター仕様の\ ``k8s.enterprisedb.io/addons`` アノテーションに追加します。例 .. code:: yaml kind: Cluster metadata: name: one-instance annotations: k8s.enterprisedb.io/addons: ["velero"] k8s.enterprisedb.io/snapshotAllowColdBackupOnPrimary: enabled spec: instances: 1 storage: size: 1Gi walStorage: size: 1Gi クラスターが作成され正常になると、オペレーターは指定されたバックアップとして最も遠いアヘッドレプリカインスタンスを選択し、Velero固有のバックアップフックをそのインスタンスにアノテーションとして追加します。 これらの `annotations `_ は、Veleroがコマンドを実行して、バックアップするPostgresインスタンスを準備するために使用されます。 .. Important:: クラスターに`k8s.enterprisedb.io/snapshotAllowColdBackupOnPrimary: enabled` のアノテーションが付けられていない限り、オペレーターはプライマリインスタンスをシャットダウンしてコールドバックアップを取得することを拒否します。 .. _制限事項-2: 制限事項 ^^^^^^^^ バックアップ部分に関する限り、現在VeleroとのKubernetes統合のEDB Postgresは **コールドバックアップ** のみをサポートしています。これらは **オフラインバックアップ** とも呼ばれます。これは、選択したレプリカが一時的にフェンスされ、外部バックアップアダプターがPVCグループ、つまり\ ``PGDATA`` ボリューム、および使用可能な場合はWALボリュームの物理的スナップショットを取得できることを意味します。 この短い時間フレームでは、スタンバイは読み取り専用の接続を受け入れることができません。使用可能なスタンバイがなく、通常は単一インスタンスのクラスターにいるため、アノテーション\ ``k8s.enterprisedb.io/snapshotAllowColdBackupOnPrimary`` がtrueに設定されている場合、Veleroはプライマリを一時的にフェンスし、読み取り/書き込み操作の点でダウンタイムが発生します。このユースケースは、通常、開発環境に任されます。 リカバリーの面では、Veleroとの統合は、現時点ではスナップショットリカバリーのみをサポートしています。現時点ではVeleroアドオンでは利用可能なポイントインタイムリカバリーPITRはなく、RPOはVelero環境のスナップショットの頻度によって決まります。組織がVeleroに依存している場合、これは通常許容されますが、PITRが必要な場合は、オブジェクトストアのネイティブの継続的バックアップ方法を検討することをお勧めします。 バックアップ ^^^^^^^^^^^^ デザイン、KubernetesのEDB Postgresは、可能な限り多くのバックアップ機能をVeleroにオフロードします。前述のバックアップフックを利用できるようにすることのみが必要です。 KubernetesのEDB Postgresは、必要な構成をすべて透過的に設定し、残りは標準のVeleroであるため、Veleroを使用してPostgresクラスターをバックアップすることは、他のオブジェクトの場合と同様に簡単です。例 .. code:: bash velero backup create mybackup \ --include-namespaces mynamespace \ -n velero-install-namespace このコマンドは、構成されたオブジェクトストレージと構成されたスナップショットAPIを使用して標準のVeleroバックアップを作成します。 .. Important:: デフォルトでは、Veleroアドオンはバックアップオペレーションからいくつかのリソース、つまり選択されていないインスタンスのポッドとPVCのみを除外します。ご存知のとおり、オペレーターは最初のレプリカのPVCをバックアップしようとします。ただし、 `velero backup` コマンドのオプションを使用して、バックアップの一部にするリソースを微調整できます。 リストア ^^^^^^^^ バックアップと同様に、リカバリプロセスは標準のVelero手順です。上記のパラメーターで作成されたバックアップから復元するコマンドは次のとおりです。 .. code:: bash velero create restore myrestore \ --from-backup mybackup \ -n velero-install-namespace