Add-ons#
KubernetesのEDB Postgresは、クラスターごとに有効にできるアドオンをサポートしています。これらのアドオンは次のとおりです。
注釈
OpenShiftでVeleroを使用する予定がある場合は、Openshiftドキュメントの OADP section を参照してください。
オペレーターはすべてのアドオンを自動的に利用できるようになり、使用するには、
k8s.enterprisedb.io/addons
アノテーションを介してクラスターレベルで有効にする必要があります。
外部バックアップアダプター#
外部バックアップアダプタアドオンは、ラベルおよび/または注釈を介して識別するカスタマイズ可能な方法を介して、バックアップ用のサードパーティツールにKubernetesのEDB Postgresを統合する汎用方法を提供します。
どのPVCグループをバックアップするか
クラスターに1つ以上のアクティブなレプリカがある場合、どのPVCを除外するか
バックアップのために選択されたPostgreSQLインスタンスを実行しているポッドスタンバイまたは使用できない場合はプライマリ
バックアップシステムのアダプターを構成できる方法のみが異なる2つのアドオンから選択できます。
external-backup-adapter構成マップまたはシークレットを介してオペレーターの構成レベルで動作をカスタマイズ、オペレーターの展開によって管理されるすべてのPostgresクラスターと共有する場合 the `external-backup-adapter section below <Backup>` を参照してください。external-backup-adapter-cluster特定のアノテーションを介してPostgresクラスターレベルでアダプターの動作をカスタマイズする場合 the `external-backup-adapter-cluster section below <Backup>` を参照してください
このようなアドオンを使用すると、オペレーターが選択したポッドでバックアップを取得する前または後に実行するコマンドを含むアノテーションの名前を定義できます。
その結果、Kubernetesのサードパーティバックアップツールは、上記に依存して、PostgreSQLクラスターまたはそのセットと自分自身を調整できます。
リカバリーは、オペレーターが既存のPVCグループからクラスターを調整することに依存するだけです。
重要
外部バックアップアダプターは、バックアップを実行するツールではありません。これは、Kubernetesスペースのサードパーティバックアップツールが使用できる汎用インターフェイスを提供するだけです。このようなツールは、PVCおよび/またはコンテンツを安全に保存し、復旧時にKubernetesクラスターに必要なすべてのリソース定義とともに利用できるようにします。
アダプターのカスタマイズ#
前述のように、アダプターは2つの方法で構成でき、これにより、 Cluster
リソースで使用する必要がある実際のadd-on が決まります。
オペレーターによって管理されるすべてのPostgres Cluster
リソースに同じ動作を定義する予定がある場合は、
external-backup-adapter
アドオンを使用し、オペレーターの構成でアノテーション/ラベルを構成することをお勧めします。
所有するPostgres Cluster
リソースのサブセットに異なる動作を予定している場合は、
external-backup-adapter-cluster
アドオンを使用することをお勧めします。
両方のアドオンは、カスタマイズという点で同じ機能を共有します。これは、次のキーを持つYAMLオブジェクトとして定義する必要があります。
electedResourcesDecoratorsexcludedResourcesDecoratorsexcludedResourcesSelectorbackupInstanceDecoratorspreBackupHookConfigurationpostBackupHookConfiguration
以下、各セクションについて説明します。さらに下には、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
フィールドを介して、オペレーターレベルで完全に設定できます。
詳細については、このセクションの最後に提供されているサンプルファイル、または以下の例を参照してください。
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
リソースに追加することによりアクティブにできます。
k8s.enterprisedb.io/addons: ["external-backup-adapter"]
external-backup-adapter-cluster アドオン#
external-backup-adapter-cluster アドオンは、次の例に示すように、
k8s.enterprisedb.io/externalBackupAdapterClusterConfig
アノテーション-コンテンツとしてYAMLオブジェクトを受け入れます-を介して使用する各Cluster
リソースで構成する必要があります。
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 プラグインを使用して行うことができます。
kubectl cnp fencing off <cluster-name>
または、 cnp
プラグインがない場合は、次のコマンドを使用してフェンシングアノテーションを手動で削除できます。
kubectl annotate cluster <cluster-name> k8s.enterprisedb.io/fencedInstances-
詳細については、 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アノテーション内
ヒント
以下のコンテンツをコピーし、 Cluster で演算子またはアノテーションを構成するために使用する`ConfigMap` または`Secret` の中に貼り付けます。必ず、 YAML reserves for literals の`|` 文字と適切なインデントを使用します。コメントを使用して、ツールのオプションをカスタマイズします。
# 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 および Kasten by Veeam ImplementationGuide を参照してください。
つまり、KubernetesクラスターのEDB
PostgresでKastenとの透過的な統合を有効にするには、Cluster
仕様のk8s.enterprisedb.io/addons アノテーションにkasten
値を追加するだけです。例
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固有のバックアップフックをそのインスタンスに追加します。
重要
クラスターに`k8s.enterprisedb.io/snapshotAllowColdBackupOnPrimary: enabled` のアノテーションが付けられていない限り、オペレーターはプライマリインスタンスをシャットダウンしてコールドバックアップを取ることを拒否します
Kastenの構成と使用方法の詳細については、実装ガイドの Instance pod configuration および Iron Bankイメージを使用したPG4Kオペレーターのインストール セクションを参照してください。
制限事項#
バックアップ部分に関する限り、現在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
アノテーションに追加します。例
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インスタンスを準備するために使用されます。
重要
クラスターに`k8s.enterprisedb.io/snapshotAllowColdBackupOnPrimary: enabled` のアノテーションが付けられていない限り、オペレーターはプライマリインスタンスをシャットダウンしてコールドバックアップを取得することを拒否します。
制限事項#
バックアップ部分に関する限り、現在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クラスターをバックアップすることは、他のオブジェクトの場合と同様に簡単です。例
velero backup create mybackup \
--include-namespaces mynamespace \
-n velero-install-namespace
このコマンドは、構成されたオブジェクトストレージと構成されたスナップショットAPIを使用して標準のVeleroバックアップを作成します。
重要
デフォルトでは、Veleroアドオンはバックアップオペレーションからいくつかのリソース、つまり選択されていないインスタンスのポッドとPVCのみを除外します。ご存知のとおり、オペレーターは最初のレプリカのPVCをバックアップしようとします。ただし、 velero backup コマンドのオプションを使用して、バックアップの一部にするリソースを微調整できます。
リストア#
バックアップと同様に、リカバリプロセスは標準のVelero手順です。上記のパラメーターで作成されたバックアップから復元するコマンドは次のとおりです。
velero create restore myrestore \
--from-backup mybackup \
-n velero-install-namespace