01
どのラベルを読むか選ぶ
リソースモードは単体オブジェクト、配列、items配列を持つListまたは末尾がListの型に対応します。読むのはmetadata.labelsだけです。DeploymentのPodテンプレートを自動的にたどることはありません。
Kubernetes
Kubernetesラベルセレクター条件ごとの理由を確認
ラベルの構文を検証し、入力した各リソースが条件を満たすか確認します。
Kubernetesラベルセレクター
一致結果
入力はブラウザー内で処理します。クラスターへの接続、アップロード、ネットワーク照会は行いません。
入力設定と対応構文
= · == · != · in · notin · key · !key。カンマはAND条件です。空のセレクターは全入力に一致します。
上限：JSONは500,000文字、式は8,192文字、500リソース、64条件、各リソース256ラベル。
意味論：Kubernetes 1.35 / apimachinery v0.35.0の等価・集合・存在条件に対応。
入力が変わりました。出力する前に再テストしてください。
Podが選ばれないときは、Kubernetesラベルセレクターで実際のラベルと条件を照合してみてください。env!=prodは別の環境だけでなく、envキーがないオブジェクトにも一致します。最終件数だけでは、この違いは見えません。
ラベルマップとリソースはモードを選んで区別します。前者ではオブジェクト全体、後者ではmetadata.labelsを読みます。両方の入力は別々に保持されるので、metadataという名前のラベルを誤って外側の構造として扱いません。
Kubernetesラベルセレクターで判断を確かめる
一致しなかった条件を特定する
Kubernetesラベルセレクターは最初の不一致で説明を止めず、すべての条件を評価します。開発環境のPodがapp=webと!pausedを満たしていても、環境の集合には含まれない場合があります。どの条件を見直すべきか、リソースごとに確認できます。
空の値とキーの欠落を区別する
値が空文字列でもラベルのキーは存在します。キー自体がない場合とは異なるので、結果には実際の文字列またはキーなしと表示します。否定条件が成功した理由を、存在確認の成功と取り違えずに読めます。
意図しない選択を防ぐ三つの確認
02
値を変え、キーも削除して試す
productionをdevelopmentに変更した後、environmentキーを削除してinとnotinを比べます。自動テストは入力停止から350ミリ秒後です。オフにするとボタンまたはCtrl/Cmd + Enterで実行できます。
03
全条件と保存範囲を見る
各リソースを展開すると、ラベルと条件の結果を読めます。表示は50件ずつですが、コピーとダウンロードは全件です。入力を変更すると古い結果の保存は無効になり、再テストが必要です。
構文と選択結果を同じ画面で確認
キーと値を別々に検証
任意のDNS接頭辞は小文字で253文字以内、名前部分は1～63文字です。名前には大文字や途中のハイフン、下線、ピリオドも使えます。値は63文字までで空文字列も有効です。予約済み接頭辞は構文上の理由だけでは拒否しません。
等価ベースと集合ベースを組み合わせる
等価ベースの=、==、!=に加え、集合ベースのinとnotinに対応します。条件間のカンマはANDです。同じキーの候補を複数指定するなら一つのinの括弧内に並べます。等価条件を増やすと対象は広がらず、絞られます。
複数のリソースを区別したまま評価
入力順の番号とJSONパスを保持し、提供された種類、名前空間、名前を添えます。metadataまたはlabelsの省略・nullは空マップとして評価します。名前が重複していても別の入力として残り、勝手に統合されません。
文字列の値を勝手に直さない
kubectlで使うラベル値を確認するとき、"01"と"1"は同じになりません。数字、真偽値、nullを文字列に変換せずエラーにします。重複したJSONキーも拒否するため、後の値で前の値が消えることはありません。
入力範囲とAPIごとの違い
- 対象は文字列セレクターの一部
- Kubernetes 1.35 / apimachinery v0.35.0の等価・集合・存在条件を基準にしています。数値の<や>、キーをまたぐOR、ワイルドカード、正規表現、フィールドセレクター、ノードアフィニティは対象外です。
- 厳密なJSONをモード指定で読む
- コメントや末尾カンマは使えません。YAML、ファイル、URL取得、構造化されたmatchLabelsやmatchExpressionsは受け付けません。List型にはitems配列が必要です。通常のリソースのitemsフィールドを自動で一覧に読み替えることもありません。
- 上限超過や無効なラベルは全体を停止
- JSONは500,000文字、セレクターは8,192文字、500リソース、64条件、各リソース256ラベルまでです。文字数はUTF-16コード単位で数えます。深さ100、ノード50,000、数値1,000文字の解析上限もあり、無効な入力を飛ばして一部だけ出力することはありません。
- 空文字列の意味を他のAPIへ転用しない
- ここで空のセレクターは、空マップも含むすべての有効な入力に一致します。空のJSON欄は入力待ちなので、空マップは{}と記述します。Serviceの空selectorや構造化されたnullセレクターが同じ意味になるとは限りません。
- 出力はマニフェストではなく検査記録
- レポートには識別用のフィールド、ラベル、条件の結果だけを含み、他のリソースフィールドは含めません。ラベル修正やPodテンプレートの取得は行いません。一致しても、就緒状態、Serviceのエンドポイント、通信経路、コントローラーの所有関係までは確認できません。
Kubernetesラベルセレクターのよくある疑問
複数のラベルでPodを絞り込むには？
app=web,environment=productionのようにカンマでつなぎます。両方を満たす必要があります。app.kubernetes.io/nameのような接頭辞付きキーは省略せずに入力してください。単なるnameとは別のキーです。
ラベル条件でORは使えますか？
異なるキーをORで結ぶ構文には対応していません。同じキーの候補ならenvironment in (production,staging)を使えます。二つの等価条件をカンマで並べてもORにはならず、同時に満たす必要があります。
値のないラベルは有効ですか？
JSONでは{"maintenance":""}と表します。maintenanceはキーの存在、maintenance=は存在する空文字列、!maintenanceはキーの欠落を確認します。文字列構文のmaintenance in ()も空文字列を一つ含む集合なので、存在する空値に一致します。
特定のラベルがないリソースを数えるには？
!keyを指定し、一致件数を確認します。対象キーがないことを調べるだけで、すべてのラベルがないことを調べる条件ではありません。また、この件数は貼り付けた入力分だけなので、クラスター全体の件数とは限りません。
envがないのにenv!=prodが一致するのはなぜですか？
!=とnotinはキーがない場合も一致します。存在する値の中からprod以外を選びたいならenv,env!=prodと書きます。条件別の説明で、キーが欠けている場合と別の値がある場合を見分けられます。
まだ解決していない疑問がありますか？