ラベルとアノテーション#

Kubernetesのリソースはフラット構造で編成され、階層情報やそれらの間の関係はありません。ただし、このようなリソースとオブジェクトは、 ラベル および アノテーション を介してリンクし、関係にすることができます。

注釈

詳細については、 annotations および labels に関するKubernetesドキュメントを参照してください。

要するに

  • アノテーションは、外部ツールとの統合を促進することを目的に、追加の非識別情報をリソースに割り当てるために使用されます

  • ラベルはオブジェクトをグループ化し、Kubernetesのネイティブセレクター機能を介して照会するために使用されます

CloudNativePG展開で使用するラベルおよび/またはアノテーションを1つ以上選択できます。次に、クラスターのメタデータでこれらのラベルおよび/またはアノテーションを定義すると、それによって作成されたすべてのリソースポッドを含むに自動的に継承されるようにオペレーターを構成する必要があります。

注釈

ラベルとアノテーションの継承は、ポッドテンプレートなどの代替アプローチの代わりにCloudNativePGが採用した技術です。

事前定義されたラベル#

以下は、CloudNativePGによって管理される事前定義されたラベルのリストです。

cnpg.io/backupName バックアップ識別子、Backup およびVolumeSnapshot リソースでのみ使用できます

cnpg.io/cluster クラスターの名前

cnpg.io/immediateBackup バックアップがimmediate がtrue に設定されているScheduledBackup オブジェクトから作成された最初のバックアップである場合、 Backup リソースに適用されます。

cnpg.io/instanceName PostgreSQLインスタンスの名前 - このラベルは、古い非推奨のpostgresql ラベルを置き換えます。

cnpg.io/jobRole ジョブのロールつまり import 、initdb 、join , …

cnpg.io/podRole PostgreSQLを実行しているポッドを識別するために、現在instance に修正されています

cnpg.io/poolerName PgBouncerプーラーの名前

cnpg.io/pvcRole PG_DATA やPG_WAL などのPVCの目的

cnpg.io/reload ConfigMap およびSecret リソースで使用できます。 true に設定されている場合、リソースの変更はオペレーターによって自動的にリロードされます。

cnpg.io/scheduled-backup 使用可能な場合、特定のBackup オブジェクトを作成したScheduledBackup リソースの名前

role ポッドで実行されているインスタンスがprimary またはreplica かどうか

cnpg.io/backupTimeline バックアップが取られたインスタンスのタイムライン

cnpg.io/backupYear バックアップが取られた年

cnpg.io/backupMonth バックアップが取られた年/月

cnpg.io/backupDate バックアップのISO 8601形式YYYYMMDD の日付

cnpg.io/onlineBackup バックアップがオンラインホットかコールドPostgresがダウンしているときに取得されるか

事前定義されたアノテーション#

以下は、CloudNativePGによって管理される事前定義されたアノテーションのリストです。

container.apparmor.security.beta.kubernetes.io/* 名前付けたコンテナに適用するAppArmorプロファイルの名前。

詳細についてはドキュメント

cnpg.io/coredumpFilter Postgresプロセスのコアダンプを制御するフィルター、ビットマスクで表現されます。デフォルトでは、ダンプから共有メモリセグメントを除外するために0x31 に設定されます。 PostgreSQLコアダンプ を参照してください。

詳細については、

cnpg.io/clusterManifest このリソースPVCなどを所有するCluster のマニフェスト - このラベルは、古い非推奨のcnpg.io/hibernateClusterManifest ラベルを置き換えます。

cnpg.io/fencedInstances フェンスする必要があるインスタンスのリスト。JSON形式で表現されます。リストに* 要素が含まれる場合、クラスター全体がフェンスされます。

cnpg.io/forceLegacyBackup --name オプションが利用できなかったバージョン3.42023年1月より前のbarman-cloud-backup の動作をシミュレートするために、テスト目的のみでCluster リソースに適用されます。

cnpg.io/hash リソースのハッシュ値

cnpg.io/hibernation Cluster リソースに適用されて、

declarative hibernation feature を制御します。許可される値はon およびoff です。

cnpg.io/managedSecrets オペレーターによって管理され、各PostgresクラスターのServiceAccount リソースに自動的に設定されるシークレットをプルします

cnpg.io/nodeSerial ポッドリソースで、Postgresクラスター内のインスタンスのシリアル番号を識別します

cnpg.io/operatorVersion オペレーターのバージョン

cnpg.io/pgControldata pg_controldata コマンドの出力 - このアノテーションは、古い非推奨のcnpg.io/hibernatePgControlData アノテーションを置き換えます。

cnpg.io/podEnvHash cnpg.io/podSpec アノテーションとして 非推奨 になり、ポッド環境も含まれるようになりました

cnpg.io/podSpec オペレーターによって生成されたポッドのspec のスナップショット - このアノテーションは、古い非推奨のcnpg.io/podEnvHash アノテーションを置き換えます。

cnpg.io/poolerSpecHash プーラーリソースのハッシュ

cnpg.io/pvcStatus 塩ビの現在のステータス、 initializing 、 ready 、detached のいずれか

cnpg.io/reconciliationLoop Cluster でdisabled に設定されている場合、オペレーターは調整ループの実行を防止します

cnpg.io/reloadedAt 最新のクラスターreload 時間が含まれます。reload は、プラグインを介してユーザーによってトリガーされます

cnpg.io/skipEmptyWalArchiveCheck Cluster リソースでtrue に設定されている場合、オペレーターは、データを書き込む前にWALアーカイブが空であることを確認するチェックを無効にします。自分の責任で使用してください。

cnpg.io/backupStartWAL バックアップ開始時のWAL

cnpg.io/backupEndWAL バックアップ終了時のWAL

cnpg.io/backupStartTime バックアップが開始された時刻

cnpg.io/backupEndTime バックアップが終了した時刻

cnpg.io/snapshotStartTime スナップショットが開始された時刻

cnpg.io/snapshotEndTime スナップショットが使用する準備ができているとしてマークされた時間

kubectl.kubernetes.io/restartedAt 利用可能な場合、最後にPostgresクラスターの再起動が要求された時間

前提条件#

デフォルトでは、クラスターのメタデータで定義されたラベルまたはアノテーションは、関連付けられたリソースに継承されません。ラベル/アノテーションの継承を有効にするには、 オペレーター設定 セクションで提供されている指示に従う必要があります。

以下では、その例を続行し、次のことに制限します。

  • アノテーション categories

  • ラベル app 、environment 、およびworkload

注釈

注釈とラベルの両方に、コンテキストに最も適した名前を自由に選択してください。名前付けにワイルドカードを使用し、継承する`mycompany/` で始まるすべてのラベルまたはアノテーションに`mycompany/*` のような戦略を採用することもできることに注意してください。

クラスターのメタデータの定義#

リソースがデプロイされる 前 、クラスターを定義するときに、次のようにメタデータを適切に設定できます。

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: cluster-example
  annotations:
    categories: database
  labels:
    environment: production
    workload: database
    app: sso
spec:
     # ... <snip>

クラスターが展開されると、たとえば、次の方法でポッドにラベルが正しく設定されていることを確認できます。

kubectl get pods --show-labels

現在の制限#

現在、CloudNativePGは、ラベルまたはアノテーションの削除を自動的に伝播しません。したがって、基になるポッドに伝播されたアノテーションまたはラベルがクラスターから削除される場合、オペレーターは、関連するリソースでそれを自動的に削除しません。