Namespace 分離

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"

Quota を置くと副作用が付いてくる。cpu / memory の Quota がある Namespace では、新しく作る Pod は該当リソースの requests か limits を必ず指定しなければならず、指定の無い Pod は admission で拒否され得る。「昨日まで通っていたマニフェストが急に弾かれる」という混乱はここから起きる。だから Quota は LimitRange と対で入れる。LimitRange が既定の requests / limits を自動で埋めるので、各チームが毎回書き忘れる前提で運用できる。なお上の例は requests.* しか縛っていないため、上限側も抑えたいなら limits.cpu / limits.memory を別に指定する。

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

デフォルトでは、Kubernetes の全 Pod は Namespace を越えて自由に通信できる。Pod は自分を選ぶ Network Policy が 1 つ現れた時点で初めて隔離側に回り、それまでは受信も送信も素通しだ。

ここで前提を 1 つ押さえておく。Network Policy を実際に施行するのはネットワークプラグインであり、対応していないプラグインのクラスターではマニフェストを投入しても何も起きない。オブジェクトは正常に作成され、エラーも出ないまま無防備が続くので、最初に 1 度は遮断が効くことを通信して確かめる。

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

namespaceSelector で Namespace を名前で指すときは、コントロールプレーンが全 Namespace へ自動で付ける不変ラベル kubernetes.io/metadata.name を使う (Kubernetes 1.22 で stable)。name: team-a のような独自ラベルを書いた例が広く流布しているが、このラベルは自動では付かない。Namespace 側に手で付けていなければ from 条件が何にも一致せず、同一 Namespace からの通信まで落ちて全遮断になる。同じ Namespace 内だけを許す意図なら - podSelector: {} と書く方が取り違えが起きにくい。

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 数が多くなり管理コストが増加する。