labelとselector
※9/13追記：認識の間違いがあったため、再検証して、内容を更新しました。
Service(ClusterIPやLBなど)のselectorの指定とワークロード(deploymentやpodなど)のlabelのマッチ条件について、以下のようになる
- Serviceのselectorの内容とワークロードのlabelの内容と完全一致する場合、マッチする
+ selectorの内容がlabelを包含する場合(labelがselectorの子集)、マッチする - selectorのすべての内容がワークロードのlabelに含まれている(selectorがlabelの子集合*Subset)場合、マッチする
検証パターン：
ワークロードとServiceのlabel関係は以下パターンで検証しました。
"〇"の項目はServiceとワークロードが紐付け(マッチ)できたことを示します。
| selector(LB)→ label(deploy)↓ |
app1=a | app2=b | app3=c | app1=a app2=b |
app1=a app3=c |
app2=b app3=c |
app1=a app2=b app3=c |
|---|---|---|---|---|---|---|---|
| app1=a | 〇 | ✖ | ✖ | ✖ | ✖ | ✖ | ✖ |
| app2=b | ✖ | 〇 | ✖ | ✖ | ✖ | ✖ | ✖ |
| app3=c | ✖ | ✖ | 〇 | ✖ | ✖ | ✖ | ✖ |
| app1=a app2=b |
〇 | 〇 | ✖ | 〇 | ✖ | ✖ | ✖ |
| app1=a app3=c |
〇 | ✖ | 〇 | ✖ | 〇 | ✖ | ✖ |
| app2=b app3=c |
✖ | 〇 | 〇 | ✖ | ✖ | 〇 | ✖ |
| app1=a app2=b app3=c |
〇 | 〇 | 〇 | 〇 | 〇 | 〇 | 〇 |
Selectorの種類
SelectorはServiceだけでなく、ワークロードやNode Affinity(Podのスケジューリング)などでKubernetesの世界で広く使用されている。
KubernetesのSelectorは2種類あります：
- Equality-base(等価ベース)：上記のような、同じ情報を持っているかどうかを判断する(
=か!=での判断)Selector- Serviceのselectorなど
- Set-based(集合ベース)：In,NotIn,Existsのようなちょっと複雑な条件を書けるSelector
matchExpressions項目内に条件を記述する
matchExpressionsはNode Affinityで紹介したので、興味ある方は参考にしてください。
リソース種類のサポート状況
- ServiceやReplicationController
- Equality-baseのみ
- Job、Deployment、ReplicaSetやDaemonSet
- Set-based
- Equality-base
注意点
不可変フィールド(field)
Deploymentのselectorを修正しようとした時に、以下のエラーに出会いました。
{...
matchexpressions:[]v1.labelselectorrequirement(nil)}:field is immutableこれDeployment、ReplicaSet、DeamonSetのspec.Selectorが変更できないからです。
解決策：
リソースを一旦削除して、再作成することで、回避できます。
labelのkeyは重複不可
labelはkey-value形式(一般的にmap形式、pythonでは辞書形式という)のデータです。
このデータはkeyがindexみたいな役割がになっているため、keyの重複はできません。
重複したkeyを書いた場合、最後に書いたものが適用されます(前のものを上書きする)。
9/13追記：ワークロードのlabelもそうですが、Serviceのselectorの中のlabelも同じ動きとなります。
Pythonなどの開発経験がある方は、重複不可の理由はすぐお分かりかと思います。
最後に
今回はSelectorに関する知識を簡単にまとめました。
以前の内容とも関係あるので、ぜひそちらもチェックしてみてください。
ここまで読んでいただいて、お疲れ様でした。
コメント