mhKubernetesクラスタ内には、PodやService、Deploymentなど多くのリソースが存在します。
これらをただ作り続けると、誰が何を作ったのか、何のためなのか分かりにくくなります。
そこで登場するのが：
- Namespace（空間で分ける）
- Label（タグで分類する）
- Annotation（補足情報をつける）
です。順番に見ていきましょう。
🔹 Namespace：論理的な「グループ分け」
Namespaceは、Kubernetesリソースを論理的に分離する仕組みです。
どんなときに使う？
- チームごとに環境を分けたいとき（開発/本番など）
- リソース使用量を制限したいとき（CPU/メモリ）
- 名前の衝突を防ぎたいとき
例：
kubectl create namespace dev
kubectl get pods --namespace=devまたは省略形：
kubectl get pods -n devたとえば同じ名前のServiceが dev と prod に共存できます。
デフォルトで存在するNamespace
| 名前 | 説明 |
|---|---|
| default | 特に指定がないときのNamespace |
| kube-system | Kubernetes本体のコンポーネント用 |
| kube-public | 全ユーザーが閲覧可能な公開情報 |
| kube-node-lease | ノードのハートビート管理に使用される内部用途 |
🔸 Label：検索や分類のための「タグ付け」
Labelは、リソースに自由なキーバリュー形式のタグを付ける機能です。
これは、PodやServiceを分類したり、セレクタで選ぶときに使います。
例：
metadata:
labels:
app: myapp
tier: frontendServiceやDeploymentでは selector を使って、特定のラベルを持つPodだけに通信したり、管理対象にできます：
selector:
matchLabels:
app: myappkubectlで検索にも使える：
kubectl get pods -l app=myapp📝 Annotation：マシンではなく「人やツール向けの補足情報」
AnnotationもLabelと同じくキーバリューの形式ですが、検索には使いません。
用途は「詳細な情報のメモ・付加情報の格納」で、以下のようなケースで使います：
- 誰がデプロイしたか、デプロイツールのバージョン
- 外部監視ツールやCIツールへのヒント
- ドキュメントURLやチケット番号
例：
metadata:
annotations:
deployed-by: alice
commit-sha: "abc123"
documentation-url: "https://docs.example.com/myapp"🔍 kubectl describe を使うと、Annotationは表示されますが、kubectl get には表示されません。
✅ まとめ：役割の違い
| 機能 | 主な用途 | 例 |
|---|---|---|
| Namespace | リソースの論理分離（環境・チームなど） | dev / prod / staging |
| Label | リソースの分類・選択（検索・セレクタ） | app=myapp, tier=frontend |
| Annotation | 補足情報の付与（監視、デプロイ履歴など） | deployed-by=alice |
💡 実践のヒント
- NamespaceごとにRBACを設定すると、チーム単位のアクセス制御がしやすくなります
- Labelをしっかり設計しておくと、監視やトラブルシューティングが非常に楽になります
- Annotationには、CI/CDパイプラインが自動的に情報を書き込むケースも多いです
Namespace＋Labelを使って「チームごとの環境分離構成」を図解
補足説明：
Namespace: devとNamespace: prodに分かれ、それぞれに Pod や Service が存在しています。- 各Podには
Label: app=frontendやapp=backendが設定されており、Serviceはこれらのラベルで対象を選んでいます。 - チーム（開発/本番）で Namespace を使って分離し、Label によってさらに役割ごとの分類・選択ができる構成です。
