Kubernetes

Namespace（名前空間）なまえくうかん

Kubernetesリソース分離マルチテナントRBACクラスター管理スコープ

Namespaceについて教えて

簡単に言うとこんな感じ！

Kubernetesの中に作れる「仕切り」みたいなものだよ！同じクラスターを開発チームと本番チームで共有するとき、それぞれ別の部屋に分けておくことで、お互いの設定やアプリが混ざらないようにできるんだ。同じ名前のアプリでもNamespaceが違えば別物として扱われるってこと！

Namespaceとは

Kubernetes（コンテナ管理基盤）では、複数のチームやプロジェクトが1つのクラスター（サーバー群）を共有することがよくあります。そのとき、アプリやサービスの設定が混ざってしまうと大変です。Namespace（名前空間）は、クラスターを論理的に区切る仕組みで、「開発用」「テスト用」「本番用」のように分割して管理できます。

Namespaceを使うと、同じ名前のリソース（Podやサービスなど）でもNamespaceが違えば別物として扱われます。たとえば development Namespaceの web-app と production Namespaceの web-app は完全に別のアプリとして独立します。また、アクセス権（RBAC）やリソース使用量の上限（ResourceQuota）もNamespace単位で設定できるので、チームをまたいだ管理がしやすくなります。

ただし、Namespaceはあくまで「論理的な仕切り」です。ノード（物理的なサーバー）やストレージボリュームなど、クラスター全体で共有するリソースはNamespaceの外に存在します。大規模なプロジェクトや複数チームで1つのKubernetesクラスターを使い回すマルチテナント構成において、Namespaceは欠かせない概念です。

Namespaceの構造と特徴

Namespaceが分けるもの・分けないもの

対象	Namespaceで分離できる？	補足
Pod（コンテナ）	✅ できる	別Namespace同士は独立
Service（通信口）	✅ できる	名前が重複してもOK
ConfigMap / Secret	✅ できる	設定・機密情報を分離
RBAC（アクセス権）	✅ できる	Namespace単位で権限設定
ResourceQuota（上限）	✅ できる	CPU・メモリの割り当て制限
Node（サーバー本体）	❌ できない	クラスター全体で共有
PersistentVolume（永続ストレージ）	❌ できない	クラスタースコープのリソース
ClusterRole（クラスター権限）	❌ できない	Namespace外のリソース

デフォルトで用意されているNamespace

Kubernetesをセットアップすると、最初から以下の4つのNamespaceが自動的に作られます。

Namespace名	用途
`default`	何も指定しないとここに作られる。初学者が最初に触れる場所
`kube-system`	KubernetesのシステムコンポーネントがいるNamespace。触らないのが基本
`kube-public`	全ユーザーが読み取り可能な公開情報用。ほとんど使われない
`kube-node-lease`	ノードの死活監視（ハートビート）用。自動管理される

覚え方・イメージ

「Namespaceはオフィスの部屋割り」

1フロア（クラスター）を複数の部屋（Namespace）に仕切るイメージ。部屋ごとに鍵（RBAC）や備品の上限（ResourceQuota）を決められる。廊下（Node）や電気・水道（ネットワーク基盤）はフロア全体で共有。

歴史と背景

2014年 — Kubernetesがオープンソースとして公開。当初からNamespaceの概念が設計に組み込まれていた
2016年頃 — 企業が本番環境でKubernetesを使い始め、複数チームが同一クラスターを共有する「マルチテナント」ニーズが急増
2018年 — CNCF（クラウドネイティブ技術の標準化団体）がKubernetesをGraduateプロジェクトに認定。Namespaceを使ったRBAC（役割ベースのアクセス制御）が標準的な設計パターンとして普及
現在 — 大企業では「チームごとにNamespaceを1つ」「環境（dev/stg/prod）ごとにNamespaceを分ける」などの運用パターンが定着。HierarchicalなNamespace管理を実現するOSSツール（HNC）も登場している

Namespaceの使い分けパターンと関連機能

実際の現場ではどのようにNamespaceを切るか、パターンがあります。

代表的な設計パターン

パターン	Namespace例	向いているケース
環境別	`development` / `staging` / `production`	1チームで複数環境を同一クラスターで管理
チーム別	`team-frontend` / `team-backend` / `team-data`	複数チームが独立して開発・運用
アプリ別	`app-shop` / `app-blog` / `app-admin`	マイクロサービスを明確に分離したいとき
組み合わせ	`team-a-prod` / `team-a-dev`	大規模でチームも環境も多い場合

Namespaceと連携する主要機能

Namespaceをまたいだ通信

Namespace間でも、サービス名にNamespaceを付けた形式で通信できます。

# 同じNamespace内の場合
http://web-service

# 別のNamespace（prod）へアクセスする場合
http://web-service.prod.svc.cluster.local

規格・仕様	内容
Kubernetes API v1	Namespaceはコアリソース（`v1` グループ）として定義
CNCF Kubernetes仕様	マルチテナント設計ガイドラインにNamespaceの使い方が含まれる
HNC（Hierarchical Namespace Controller）	Namespaceの親子関係を実現するKubernetesアドオン（CNCF管理）