Kubernetes タグ: 10 のベスト プラクティスを紹介する専門家ガイド

Kubernetes ラベルを使用すると、DevOps チームは問題をより迅速に解決し、構成の変更を一元的に適用し、問題に迅速に対応できます。タグを使用するとコストに関する洞察も得られるため、監視、割り当て、管理の能力が向上します。タグを使用する際にベスト プラクティスに従うと、インフラストラクチャの可視性と効率的な運用から大きなメリットが得られます。

ここでは、Kubernetes ラベルについて知っておくべきことすべてを紹介します。ラベルとは何か、どのように機能するか、いつ使用するか、そして、強固なラベル付け戦略を構築するために従うべき 10 のベスト プラクティスについて説明します。

Kubernetes ラベルとは何ですか?

Kubernetes ラベルは、識別メタデータを Kubernetes オブジェクトにリンクするキーと値の文字列ペアです。 Kubernetes は、ラベルを使用して Kubernetes API からデータを取得およびフィルタリングし、選択したオブジェクトに対して一括操作を実行するための統合サポートをチームに提供します。

多くのチームは、Kubernetes ラベルを使用して、ノード、ポッド、またはその他の Kubernetes オブジェクトの所有権に関する情報を DevOps に提供し、追跡と運用上の意思決定を容易にしています。

新しいラベルを作成するときは、長さと許可される値に関する Kubernetes の制限に従う必要があります。タグの値は以下である必要があります:

• 63文字以下（タグ値は空でも可）
• 英数字で始まり、英数字で終わる（空でない限り）
• ダッシュ (-)、アンダースコア (_)、ピリオド (.)、および英数字のみを含めます。

kubectl を使用して、Kubernetes オブジェクトにどのようなラベルが付いているかを確認できます。たとえば、 pod1 という名前のポッドのすべてのラベルを取得するには、次のコマンドを実行します。

 > kubectl get pod1 -o json |​ jq 。メタデータ。ラベル

ラベルを作成するには、プロファイル仕様の metadata.labels オブジェクトでラベルを指定します。単一のポッドを記述する pod.yaml ファイルを考えてみましょう。

 apiVersion : v1kind : Podmetadata : name : nginxラベル:環境: dev
クリティカル: "true"仕様:コンテナ: -イメージ: nginx名前: nginxリソース:
リクエスト: CPU : 500 m

critical タグの値は true ではなく "true" であることに注意してください。これは、タグとその値が文字列である必要があるためです。

設定ファイルを適用してみましょう:

 > kubectl apply -f pod .yamlpod / nginxが作成されました

kubectl を使用して、既存の Kubernetes オブジェクトにラベルを直接適用または上書きできるようになりました。まず、ポッドにあるすべてのラベルを取得します。

 > kubectl get pod nginx -o json |​ jq 。メタデータ。ラベル{ "critical" : "true" ,
 "環境" : "dev" }

ここで、環境タグの値を変更し、新しいキーと値のタグのペア deprecated=true を追加するには、次のコマンドを実行します。

 > kubectlラベルポッドnginx環境= prod --overwritepod / nginx​
ラベル付き> kubectl label pod nginx deprecated = truepod / nginxラベル付き

--overwrite フラグを使用して明示的に上書きしない限り、タグの値を更新できないことに注意してください。生成されたタグは次のとおりです。

 > kubectl get pod nginx -o json |​ jq 。メタデータ。ラベル{ "非推奨" :
 "true" 、 ​​"critical" ： "true" 、 ​​"environment" ： "prod" }

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

Kubernetes は、オブジェクトにメタデータを添付するための 2 つの戦略、ラベルと注釈を提供します。

注釈は、オブジェクトに非識別メタデータを添付するキーと値のペアです。たとえば、注釈には、特定のリソースのログ記録や監視情報を含めることができます。

ラベルとアノテーションの主な違いは、アノテーションは Kubernetes リソースのフィルタリング、グループ化、または操作には使用されないことです。代わりに、それらを使用して、それに関する追加情報にアクセスできます。

たとえば、以前にデプロイされたポッドがスケジュールされているノードには、次のように注釈が付けられます。

 > kubectl get nodeデモ- node - o json | jq 。メタデータ。注釈{
 "kubeadm.alpha.kubernetes.io/cri-socket" : "unix:///var/run/cri-dockerd.sock" ,
 "node.alpha.kubernetes.io/ttl" : "0" 、
 "volumes.kubernetes.io/controller-managed-attach-detach" : "true" }

これらの注釈は、ノードの特性に関する情報を提供しません。代わりに、ノードがどのように動作するかについてのデータを提供します。

Kubernetes ラベルはいつ使用すればよいですか?

オブジェクトクエリのグループリソース

同じタグのキーと値のペアを複数のリソースに追加すると、他のユーザーはすべてのリソースを簡単にクエリできます。たとえば、DevOps エンジニアは開発環境が利用できないことを発見します。この時点で、ラベル environment:dev を含むすべてのポッドのステータスをすぐに確認できます。

コマンドの例を次に示します。

 > kubectl get pods -l ' environment=dev' NAME READY STATUS RESTARTS AGEnginx
 0 / 1クラッシュループバックオフ1 5 m

これにより、チームは影響を受けるポッドをすぐに確認し、すべてのリソースを参照して開発環境内のリソースのみを選択するよりもはるかに速く問題を解決できます。

さまざまなデプロイメントが多数存在する複雑な状況では、エンジニアリング チームがリソースに environment:dev ラベルを追加しないと、DevOps エンジニアが適切なポッドを見つけるのに長い時間がかかります。 DevOps エンジニアは、汎用の kubectl get pods コマンドを使用してから grep を使用する必要があります。

一括操作の実行

Kubernetes ラベルのもう 1 つの使用例は、リソース ラベルに基づいて一括操作を実行することです。

クラウドのコストを削減するために、エンジニアが毎晩すべてのステージング環境を削除すると想定します。 Kubernetes ラベルを使用すると、このタスクを簡単に自動化できます。

たとえば、 environment:local 、 environment:dev 、または environment:staging のタグが付けられたすべてのオブジェクトを削除するコマンドは次のとおりです。

 > kubectl deleteデプロイメント、サービス、ステートフルセット-環境
(ローカル、開発、ステージング) '

ノードラベルに基づいてポッドをスケジュールする

Kubernetes ラベルの隠れた魅力は、Kubernetes 自体でポッドを適切なノードにスケジュールするために頻繁に使用されていることです。ラベルを使用すると、Kubernetes で特定のノードへの特定のデプロイメントをスケジュールすることで、作成するリソースをより適切に制御できます。

実際にどのように機能するか見てみましょう:

 > kubectl get nodesNAME STATUS ROLES AGE VERSIONgke - node - 1 fe68171準備完了
1d v1 .22 .12 - gke .2300 gke -ノード- 3 cdf3d2b 3d対応
v1 .22 .12 - gke .2300 gke -ノード- 5 f7b4cf1準備完了5 d v1 .22 .12 - gke .500 > kubectl
 get nodes -l ' critical = true'リソースが見つかりません

現在、ラベル critical:true を持つノードはありません。

ノード セレクターを使用して、ラベル critical:true を持つノードにスケジュールする必要があるポッドを作成してみます。以下は pod.yaml 構成ファイルです。

 apiVersion : v1kind : Podmetadata : name : nginxラベル:環境: prodspec :
 nodeSelector : critical : "true"コンテナ: -イメージ: nginx名前: nginxリソース:
リクエスト: CPU : 500 m

では、これを適用して何が起こるか確認してみましょう。

 > kubectl apply -f pod .yamlpod / nginxが作成されました> kubectl get pod nginxNAME
 READY STATUS再起動AGEnginx 0 / 1保留中0 1 m > kubectl get events
 --フィールドセレクターが関連するオブジェクト。 name = nginxLAST SEEN TYPE REASON OBJECT
メッセージ46秒警告失敗スケジューリングpod / nginx 0 / 1ノードが使用可能です: 1ノード
Podのノードアフィニティ/セレクターと一致しませんでした。プリエンプション: 0 / 1ノードが使用可能:
 1プリエンプションはスケジューリングには役立ちません。

必要なラベルがどのノードにもないため、ポッドをどのノードでもスケジュールできないことに注意してください。ここで、ノードの 1 つに目的のラベルを付けてみましょう。

 > kubectlラベルノードgke - node - 5 f7b4cf1 critical = truenode / gke - node - 5 f7b4cf1
ラベル> kubectl get nodes - l 'critical=true'名前ステータスロール年齢
バージョンgke - node - 5 f7b4cf1準備完了5h v1 .22 .12 - gke .500

それでは、ポッドを確認しましょう。

 > kubectl get pod nginxNAME READY STATUS RESTARTS AGEnginx 1 / 1実行中0
 3分31秒

ポッドがノードに正常にスケジュールされました。

ノード セレクターで複数のラベルが指定されている場合、ポッドをノードにスケジュールするには、それらのラベルがすべてノードで満たされている必要があることに注意してください。

Kubernetes ラベルのベストプラクティス 10 選

1. Kubernetesが推奨するラベルを使用する

Kubernetes は、オブジェクトをグループ化するためのラベルの推奨リストを提供します。たとえばKubernetesではapp.kubernetes.io/nameの使用を推奨しており、

app.kubernetes.io/instance は、それぞれアプリケーション名とインスタンスを表します。ラベルをカスタマイズするには、プレフィックス「app.kubernetes.io」を削除し、会社のサブドメインを追加するだけです。

2. 正しい文法に注意する

Kubernetes ラベルのキーと値のペアを作成するには、次の構文を使用する必要があります: /.詳細を見てみましょう:

• <プレフィックス>

プレフィックスはオプションです。これを使用する場合は、有効な DNS サブドメイン (例: 「cast.ai」) であり、合計 253 文字以下である必要があります。プレフィックスは、ユーザー専用ではないツールやコマンドに便利です。また、競合する可能性のある複数のタグをチームが使用できるようになるため、便利です (サードパーティ パッケージのタグなど)。

プレフィックス kubernetes.io/ および k8s.io は Kubernetes コア コンポーネント用に予約されていることに注意してください。

• <名前>

この部分はタグの任意の属性名を参照します。明確にするために、チームは「環境」という名前と「本番」や「テスト」などのラベル値を使用できます。

名前はタグ値と同じ要件を満たす必要がありますが、空にすることはできません。したがって、名前は 63 文字以下で、先頭と末尾に英数字 ([a-z0-9A-Z]) を使用し、間にダッシュ (-)、アンダースコア (_)、ドット (.)、英数字を含める必要があります。

3. タグの命名規則を標準化する

Kubernetes を使用する複数のチームは、同じラベル付け規則に従う必要があります。そうしないと、ラベル付け作業は何の価値ももたらさないでしょう。

開発パイプラインでリソース構成ファイルに対して静的コード分析を実行し、必要なタグがすべて存在することを確認することをお勧めします。タグを正しく適用しないと、自動化されたプロセスが中断される可能性があり、使用する監視ソリューションから誤検知アラートが送信される可能性があります。

4. ラベルの不必要な変更を避ける

Kubernetes のラベルは、スケジュール、展開、管理の目的でリソースを識別および選択するために使用されます。したがって、リソース タグを変更すると、広範囲にわたる予期しない影響が生じる可能性があります。

たとえば、一連のポッドの「アプリ」ラベルを「フロントエンド」から「バックエンド」に切り替えると、Kubernetes はそれらのポッドを「バックエンド」アプリケーションを実行するように設定されていないノードに再スケジュールできます。ポッドがクラッシュする可能性があります。その結果、使用できなくなります。

このような問題を回避するには、絶対に必要な場合にのみラベルを変更し、変更を行う前に結果を慎重に評価することが重要です。

5. ラベルを使用してオプションを選択する

チームは、等価性とセットに基づいてタグ付けされたオブジェクトを選択できます。

等価ベースの選択を使用すると、タグが指定された値 (または値群) と等しい、または等しくないオブジェクトを取得できます。構文を詳しく調べてみると、= と == はどちらも等価性を意味し、!= は不等価性を意味します。カンマで区切られた複数のタグを追加できます (ここではすべての条件が一致している必要があります)。たとえば、次のコマンドを実行するとします。

 > kubectl get pods -l '環境= dev 、リリース= daily'

ラベル environment:dev および release:daily を持つすべてのポッドが返されます。

一方、セットベースの選択では、複数の値を持つリソースを一度に検索できます。コレクションは、INSQL のキーワードに似ています。たとえば、次のコマンド:

 > kubectl get pods -l ' environment in ( prod , dev ) '

ラベル environment=prod または environment=dev を持つすべてのポッドが見つかります。

6. アプリケーションレベルのセマンティクスをタグに保存しない

Kubernetes ラベルはオブジェクトのメタデータとともに表示される場合がありますが、アプリケーションのデータ ストレージとして使用しないでください。 Kubernetes リソースは通常、短命で、アプリケーションに密接に結び付けられていないため、ラベルはすぐに同期されなくなり、役に立たなくなる可能性があります。

7. タグに機密情報を保存しない

パスワードや API 認証情報、その他の機密データをラベルに保存すると、誰かが Kubernetes クラスターにアクセスした場合、そのデータをプレーンテキストで表示できるようになります。これは重大なセキュリティ リスクであり、個人情報の盗難やデータ漏洩などの悪影響が生じる可能性があります。

機密情報はタグではなくシークレットの形式で保存することをお勧めします。シークレットは暗号化されており、それを必要とするポッドのみが復号化できます。こうすることで、たとえ誰かが Kubernetes クラスターにアクセスできたとしても、機密性の高いプライベートなデータを閲覧できなくなります。

8.ポッドテンプレートにラベルを追加する

ワークロードのリソースの一部であるポッド テンプレートにベース ラベルを追加します。これにより、Kubernetes コントローラーは指定した状態のポッドを一貫して作成できるようになります。

目標は、できるだけ多くのタグを作成することではなく、チームに価値をもたらすタグを作成することです。最初は小さく始めて、テンプレートの一部としてタグのリストを作成します。たとえば、リソースの所有者、リソースが実行される環境、バージョンを特定することから始めることができます。

9. ラベル付け作業を自動化する

自動化により膨大な時間を節約できますが、ラベル付けも例外ではありません。継続的インテグレーション/継続的デリバリー (CI/CD) パイプラインが設定されている場合は、横断的な懸念事項ラベルの一部を簡単に自動化できます。

CD ツールを使用してタグを自動的に添付することは、一貫性を確保し、エンジニアの生産性を向上させるため賢明です。また、タグが欠落している場合はビルドを失敗させ、担当チームに通知を送信することで、CI ジョブで正しいタグを強制することも良い方法です。

10. コスト監視にタグを使用する

タグは、Kubernetes クラウドのコストをよりよく理解するのに非常に役立ちます。コストの監視、割り当て、管理はすべて適切なタグ付け戦略に依存します。

複数のテナントが単一のクラスター内のリソースを共有する場合は、関連するタグを使用してコスト配分レポートを作成する必要があります。これにより、特定のコストが発生したチーム、サービス、またはアプリケーションを特定できるため、予期しないコストの急増を調査するときに非常に役立ちます。

この無料の監視ツールでタグ別にコストを追跡しましょう

CAST AI は、あらゆるワークロードのコストに関する情報を常に把握できるコスト監視ツールを提供します。コストは、任意のワークロードに存在する任意のタグでフィルタリングできるため、チーム、サービス、または使用するその他のタグごとにクラウド コストを簡単に追跡できます。ワークロードをタグ別にグループ化するオプションは近日中に提供されます。

クラスターを CAST AI の無料コスト監視ソリューションに接続することで、適切なラベル付けとコスト監視がもたらす違いを確認してください。