ラベルとアノテーション ====================== Kubernetesのリソースはフラット構造で編成され、階層情報やそれらの間の関係はありません。ただし、このようなリソースとオブジェクトは、 **ラベル** および **アノテーション** を介してリンクし、関係にすることができます。 .. Note:: 詳細については、 `annotations `_ および `labels `_ に関するKubernetesドキュメントを参照してください。 要するに - アノテーションは、外部ツールとの統合を促進することを目的に、追加の非識別情報をリソースに割り当てるために使用されます - ラベルはオブジェクトをグループ化し、Kubernetesのネイティブセレクター機能を介して照会するために使用されます CloudNativePG展開で使用するラベルおよび/またはアノテーションを1つ以上選択できます。次に、クラスターのメタデータでこれらのラベルおよび/またはアノテーションを定義すると、それによって作成されたすべてのリソースポッドを含むに自動的に継承されるようにオペレーターを構成する必要があります。 .. Note:: ラベルとアノテーションの継承は、ポッドテンプレートなどの代替アプローチの代わりに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プロファイルの名前。 :ref:`AppArmorを使用してポッドアクセスを制限する ` を参照 詳細についてはドキュメント ``cnpg.io/coredumpFilter`` Postgresプロセスのコアダンプを制御するフィルター、ビットマスクで表現されます。デフォルトでは、ダンプから共有メモリセグメントを除外するために\ ``0x31`` に設定されます。 :ref:`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`` リソースに適用されて、 :ref:`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クラスターの再起動が要求された時間 前提条件 -------- デフォルトでは、クラスターのメタデータで定義されたラベルまたはアノテーションは、関連付けられたリソースに継承されません。ラベル/アノテーションの継承を有効にするには、 :ref:`オペレーター設定 <オペレーター設定>` セクションで提供されている指示に従う必要があります。 以下では、その例を続行し、次のことに制限します。 - アノテーション ``categories`` - ラベル ``app`` 、\ ``environment`` 、および\ ``workload`` .. Note:: 注釈とラベルの両方に、コンテキストに最も適した名前を自由に選択してください。名前付けにワイルドカードを使用し、継承する`mycompany/` で始まるすべてのラベルまたはアノテーションに`mycompany/*` のような戦略を採用することもできることに注意してください。 クラスターのメタデータの定義 ---------------------------- リソースがデプロイされる **前** 、クラスターを定義するときに、次のようにメタデータを適切に設定できます。 .. code:: yaml apiVersion: postgresql.cnpg.io/v1 kind: Cluster metadata: name: cluster-example annotations: categories: database labels: environment: production workload: database app: sso spec: # ... クラスターが展開されると、たとえば、次の方法でポッドにラベルが正しく設定されていることを確認できます。 .. code:: shell kubectl get pods --show-labels 現在の制限 ---------- 現在、CloudNativePGは、ラベルまたはアノテーションの削除を自動的に伝播しません。したがって、基になるポッドに伝播されたアノテーションまたはラベルがクラスターから削除される場合、オペレーターは、関連するリソースでそれを自動的に削除しません。