IT 技書の森

Namespace 分離

Kubernetes の Namespace を使ってリソース、ネットワーク、権限を論理的に分離するマルチテナント戦略

Kubernetesアーキテクチャ

Namespace 分離とは

Namespace は Kubernetes クラスター内の論理的な分離単位である。チーム、環境 (dev/stg/prod)、アプリケーションごとに Namespace を分け、リソース、ネットワーク、権限を分離する。

1 つのクラスターを複数のチームで共有するマルチテナント環境では、Namespace 分離がコスト効率とセキュリティのバランスを取る基本戦略になる。

分離の 3 層

Namespace 分離は、以下の 3 層を組み合わせて初めて有効に機能する。1 層だけでは不十分だ。

1. リソース分離 (Resource Quota + LimitRange)

Namespace ごとに CPU、メモリ、Pod 数の上限を設定し、1 つのチームがクラスター全体のリソースを占有するのを防ぐ。

apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-a-quota
  namespace: team-a
spec:
  hard:
    requests.cpu: "10"
    requests.memory: 20Gi
    pods: "50"

2. ネットワーク分離 (Network Policy)

デフォルトでは、Kubernetes の全 Pod は Namespace を越えて自由に通信できる。Network Policy で Namespace 間の通信を制御する。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-ingress
  namespace: team-a
spec:
  podSelector: {}
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              name: team-a  # 同じ Namespace からのみ許可

3. 権限分離 (RBAC)

Role と RoleBinding で、各チームの操作権限を自分の Namespace に限定する。

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: team-a-developer
  namespace: team-a
rules:
  - apiGroups: ["", "apps"]
    resources: ["pods", "deployments", "services"]
    verbs: ["get", "list", "create", "update", "delete"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: team-a-developer-binding
  namespace: team-a
subjects:
  - kind: Group
    name: team-a-developers
roleRef:
  kind: Role
  name: team-a-developer
  apiGroup: rbac.authorization.k8s.io

Namespace 設計パターン

パターン 1: チーム別

cluster/
├── team-frontend/
├── team-backend/
├── team-data/
└── shared-infra/    (監視、ログ収集など共通基盤)

チームの自律性が高く、各チームが独立してデプロイできる。チーム間の依存が少ない組織に適する。

パターン 2: 環境別

cluster/
├── development/
├── staging/
└── production/

小規模チームで、環境ごとの分離が主目的の場合に適する。ただし、本番と開発が同じクラスターにあるリスクを許容する必要がある。

パターン 3: チーム × 環境

cluster/
├── team-a-dev/
├── team-a-prod/
├── team-b-dev/
└── team-b-prod/

最も細かい分離だが、Namespace 数が多くなり管理コストが増加する。

Namespace 分離の限界

Namespace は論理的な分離であり、物理的な分離ではない。以下の限界を理解しておく必要がある。

  • ノードリソースの共有: 同じノード上の Pod は CPU やメモリを物理的に共有する。Resource Quota は Namespace 全体の上限を制御するが、ノードレベルの noisy neighbor 問題は防げない
  • カーネルの共有: コンテナは Linux カーネルを共有する。カーネルの脆弱性を突かれると、Namespace の境界を越えてアクセスされる可能性がある
  • クラスタースコープのリソース: Node、PersistentVolume、ClusterRole などはクラスター全体で共有され、Namespace で分離できない

強い分離が必要な場合

分離レベル 手段 コスト セキュリティ
論理分離 Namespace + Network Policy 低 中
ノード分離 Node Affinity + Taints 中 高
クラスター分離 専用クラスター 高 最高

規制要件 (PCI DSS、HIPAA) がある場合や、信頼できないワークロードを実行する場合は、Namespace 分離だけでは不十分で、ノード分離やクラスター分離を検討する。

よくある落とし穴

  • Network Policy を設定し忘れる: Namespace を分けただけでは、ネットワークは分離されない。Network Policy を明示的に設定しないと、全 Pod が自由に通信できる状態のままだ
  • default Namespace の使用: default Namespace にワークロードを配置すると、分離の恩恵を受けられない。default は使わず、必ず専用の Namespace を作成する
  • RBAC の設定漏れ: Namespace を分けても、ClusterRole で全 Namespace への権限を付与していると意味がない。Role (Namespace スコープ) と ClusterRole (クラスタースコープ) の違いを理解する

Kubernetes 公式ドキュメントの「Namespaces」セクションが一次情報源であり、「Kubernetes Security and Observability」(Brendan Creane, Amit Gupta 著) でマルチテナントの分離戦略が詳しく解説されている。

理論と実装の両面から学ぶなら関連書籍が参考になる。

関連用語