produced by stylez

Sign in Subscribe
Rancher

RancherのProjectとKubernetesのNamespaceは何が違う？

Rancherの画面には、ProjectとNamespaceが階層で表示されます。 どちらもアプリケーションや利用者を分けるために使われますが、同じものではありません。

RancherのProjectとKubernetesのNamespaceは何が違う？

Rancherの画面には、ProjectとNamespaceが階層で表示されます。

どちらもアプリケーションや利用者を分けるために使われますが、同じものではありません。

NamespaceはKubernetes標準の分離単位

Namespaceは、Kubernetesリソースを論理的に分けるための仕組みです。

kubectl get namespaces
kubectl get deployments -n development
kubectl get pods -n production

Deployment、Pod、Service、Secret、ConfigMapなど、多くのリソースはNamespaceに所属します。

例えば、developmentとproductionを分けると、同じ名前のDeploymentをそれぞれのNamespaceに作成できます。

Cluster
├── Namespace: development
│   └── Deployment: web
└── Namespace: production
    └── Deployment: web

NamespaceはRancherを利用しないKubernetesクラスタにも存在します。

ProjectはRancherが追加する管理単位

Projectは、複数のNamespaceをまとめて管理するためのRancher独自の概念です。

Cluster
├── Project: shopping-service
│   ├── Namespace: shopping-dev
│   ├── Namespace: shopping-staging
│   └── Namespace: shopping-prod
│
└── Project: platform
    ├── Namespace: monitoring
    └── Namespace: logging

Projectを利用すると、同じチームや用途に属するNamespaceをまとめ、その単位でメンバーや権限を整理できます。

最大の違いは「どこから見えるか」

項目 Namespace Project
提供元 Kubernetes Rancher
kubectl getで直接確認 できる 通常のKubernetesリソースとしては扱わない
主な用途 リソースの論理分離 複数Namespaceのグループ化
権限管理 RoleBindingなど Project Roleを配下へ適用
Rancherを外した後 そのまま残る Rancher側の管理概念としては利用しない

RancherのProjectを使っていても、実際のワークロードはNamespace内に作成されます。

Projectは何を基準に分けるべきか

Projectの分け方に一つの正解はありません。次の境界を基準にすると整理しやすくなります。

  • 管理するチームが異なる
  • 閲覧・変更を許可するユーザーが異なる
  • リソース割り当てや運用責任を分けたい
  • 同じアプリケーションの複数環境をまとめたい

例えば、同じ開発チームが開発・検証環境を管理する場合は、次の形が考えられます。

Project: application-team
├── Namespace: application-dev
└── Namespace: application-test

本番環境だけ運用担当者を分けるなら、Project自体を分ける方が権限を説明しやすくなります。

Project: application-nonprod
├── Namespace: application-dev
└── Namespace: application-test

Project: application-prod
└── Namespace: application-prod

「環境ごとにProjectを作る」が常に正しいわけではない

Projectを細かく分けすぎると、メンバー設定や運用ルールが増えます。逆に、一つのProjectへ多くのNamespaceを集めすぎると、権限の境界が曖昧になります。

先に次の2点を書き出してから設計すると、過度に複雑になりにくくなります。

  1. どのNamespaceが必要か
  2. 誰が各Namespaceを管理するか

同じ担当者と同じ運用ルールを適用するNamespaceを、Projectへまとめるのが基本です。

Namespaceを別Projectへ移すときの注意

Namespaceの所属Projectを変更すると、Rancherから適用されるProject単位の権限やリソース管理の前提が変わります。

本番環境では、移動前に少なくとも次を確認します。

  • 移動後に誰が参照・変更できるか
  • Project Roleに依存している利用者がいないか
  • Project単位のResource Quotaを利用していないか
  • 自動化や運用手順がProject名を前提にしていないか

まとめ

NamespaceはKubernetesが提供するリソースの分離単位です。Projectは、複数のNamespaceをチームや用途ごとにまとめるRancherの管理単位です。

迷ったときは、次の順番で考えます。

  1. アプリケーションや環境ごとにNamespaceを整理する
  2. そのNamespaceを管理するチームと権限を整理する
  3. 同じ運用境界にあるNamespaceをProjectへまとめる

Read next

Comments ()