Labels and annotations¶
Kubernetesのリソースはフラットな構造で編成されており、階層情報やリソース間のリレーションはありません。ただし、このようなリソースとオブジェクトをリンクして、 ラベル および 注釈 を通じてリレーションを構築できます。
要するに:
注釈は、追加の非識別情報を割り当てるために使用されます 外部ツールとの統合を促進することを目的としたリソース
オブジェクトをグループ化し、Kubernetesのネイティブを介してクエリーするためにlabelが使用されます セレクター機能
CloudNativePGデプロイメントで使用する1つ以上のラベルや注釈を選択できます。次に、クラスターのメタデータでこれらのラベルや注釈を定義するときに、作成されたすべてのリソース(ポッドを含む)によって自動的に継承されるように、オペレーターを構成する必要があります。
注釈
ラベルと注釈の継承は、ポッドテンプレートなどの代替アプローチの代わりにCloudNativePGで採用されている手法です。
前提条件¶
デフォルトでは、クラスターのメタデータで定義されたlabelまたは注釈は、関連するリソースによって継承されません。label/注釈の継承を有効にオーダーには、 Operator configuration セクションで提供される指示に従う必要があります。
以下では、その例を続けて、以下に限定します。
注釈:
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はラベルまたは注釈の削除を自動的に伝播しません。したがって、アノテーションまたはlabelがクラスターから削除された場合、以前にポッドに伝達されていた場合、オペレーターは関連リソースからそれを自動的に削除しません。