Kubernetesの Namespace（名前空間） は、ひとことで言うと 「クラスタの中を論理的に区切る仕切り」 です。
同じクラスタ上で、開発/検証/本番や、チームごとのアプリを安全に共存させたいときに必須になります。
この記事では、Namespaceの役割と設計の考え方を押さえつつ、手を動かして以下をやります。
- Namespaceを作る・切り替える
- 同名リソースを別Namespaceに共存させる
kubectlの誤爆（本番にapplyしちゃった…）を防ぐ- ResourceQuota / LimitRange で「使いすぎ」を制限する
- （発展）NetworkPolicy / RBAC で「通信・権限」も分離する
Namespaceで何が嬉しい？
1) “同じ名前”のリソースを共存できる
例：app というServiceやDeploymentをdev と prod の両方に作れます（クラスタ全体での衝突を防げる）。
2) まとめて見れる・まとめて消せる
kubectl get all -n dev のように、環境単位で可視化できます。
不要になった環境を namespaceごと削除 も可能（※注意点あり）。
3) 権限・リソース上限・通信を“環境単位”で設定できる
- RBAC（誰が何をできるか）
- ResourceQuota / LimitRange（CPU/メモリの上限）
- NetworkPolicy（通信制御）
Namespaceの基本ルール（ここだけ押さえればOK）
- Namespaceは 多くのリソースのスコープ（Deployment/Service/ConfigMap/Secretなど）
- 一方で クラスタスコープ のリソースもある
例：Node / PersistentVolume / StorageClass / ClusterRole など kubectlは何も指定しないと “現在のnamespace（contextの設定）” に対して操作する
→ ここが一番事故りやすいポイントです
ハンズオン：Namespaceを作って分離を体感する
以降、ローカルクラスタ（kind/minikube/Docker Desktop Kubernetesなど）で動きます。
※ kubectl が使える前提で進めます。
1) Namespaceを作る
kubectl create namespace dev
kubectl create namespace prod
kubectl get namespaces
2) 同じアプリ名を dev と prod に作って共存させる
app.yaml を作成（シンプルなWeb）：
apiVersion: apps/v1
kind: Deployment
metadata:
name: app
spec:
replicas: 1
selector:
matchLabels:
app: app
template:
metadata:
labels:
app: app
spec:
containers:
- name: web
image: nginxdemos/hello:plain-text
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: app
spec:
selector:
app: app
ports:
- port: 80
targetPort: 80
devに適用：
kubectl apply -f app.yaml -n dev
kubectl get deploy,svc -n dev
prodにも同じものを適用：
kubectl apply -f app.yaml -n prod
kubectl get deploy,svc -n prod
確認（同じ名前 app が両方に存在する）：
kubectl get svc -n dev
kubectl get svc -n prod
3) 「namespace指定し忘れ」を防ぐ：current namespace を固定する
毎回 -n dev を付けるのは忘れがちです。
contextにnamespaceをセットすると、安全度が上がります。
現在のcontext名を確認：
kubectl config current-context
dev用にnamespaceをセット：
kubectl config set-context --current --namespace=dev
kubectl config view --minify | grep namespace
以後、-n dev なしで dev を操作できます：
kubectl get pods
prodに切り替えたいときは：
kubectl config set-context --current --namespace=prod
kubectl get pods
コツ：本番クラスタでは “prod専用context” を作り、普段は触らない
さらにkubectlのエイリアス/プロンプトに namespace を表示すると誤爆が激減します。
4) Namespaceごとに「使いすぎ」を止める：ResourceQuota
チームや環境が増えると、誰かがリソースを食い潰します。
ResourceQuotaで Namespace単位の上限 を設定できます。
quota.yaml（devに上限を付ける例）：
apiVersion: v1
kind: ResourceQuota
metadata:
name: dev-quota
spec:
hard:
requests.cpu: "500m"
requests.memory: "512Mi"
limits.cpu: "1"
limits.memory: "1Gi"
pods: "5"
適用：
kubectl apply -f quota.yaml -n dev
kubectl describe resourcequota dev-quota -n dev
5) PodにCPU/メモリが書かれてない問題を潰す：LimitRange
ResourceQuotaを入れても、Pod側が requests/limits を書いてないと運用が崩れます。
LimitRangeで デフォルト値 を入れられます。
limitrange.yaml：
apiVersion: v1
kind: LimitRange
metadata:
name: dev-limits
spec:
limits:
- type: Container
defaultRequest:
cpu: 100m
memory: 128Mi
default:
cpu: 200m
memory: 256Mi
適用：
kubectl apply -f limitrange.yaml -n dev
kubectl describe limitrange dev-limits -n dev
これで、requests/limits を書いてないコンテナにもデフォルトが入ります。
6) よくある運用パターン（設計の指針）
パターンA：環境ごとにNamespace（dev / stg / prod）
- 小〜中規模で分かりやすい
- “同じマニフェスト” を環境ごとに適用しやすい
パターンB：チームごとにNamespace（team-a / team-b）
- マイクロサービスが増えるとこちらが強い
- ResourceQuota/RBACをチーム単位で持てる
パターンC：環境×チーム（dev-team-a など）
- 最も安全だが運用が複雑になりやすい
- Helm/Kustomize等の仕組みとセット推奨
発展：Namespace分離を「本当に効かせる」2つの追加要素
1) RBAC（誰が何をできるか）
- devは全権、prodは閲覧のみ、などが可能
Role/RoleBinding（Namespaceスコープ）を基本にする
2) NetworkPolicy（どこに通信していいか）
- Namespaceを分けただけでは 通信は遮断されません（多くの環境で）
- NetworkPolicyで「devからprodへ直アクセス禁止」などを定義する
※NetworkPolicyはクラスタのCNI実装に依存するので、ローカル学習では動作条件を確認して使うのがおすすめです。
トラブルシュート（Namespace絡みあるある）
Q1. applyしたのにリソースが見えない
-n を付け忘れて違うNamespaceを見ていることが多いです。
kubectl get deploy --all-namespaces
Q2. いつも -n 付け忘れる
contextにnamespaceを固定：
kubectl config set-context --current --namespace=dev
Q3. Namespace削除したのに終わらない（Terminating）
Finalizerや残骸で詰まるケースがあります。
学習用途なら、まず kubectl get で残ってるリソースがないか確認が安全です。
片付け
kubectl delete namespace dev
kubectl delete namespace prod
コメントを残す