gke-multitenancy

GKE のマルチテナンシー

このリファレンスでは、名前空間の分離、RBAC の計画、リソースクォータ、ネットワークのセグメンテーションなど、GKE におけるエンタープライズ向けマルチテナンシーパターンについて説明します。

MCP ツール： apply_k8s_manifest、get_k8s_resource、check_k8s_auth、 describe_k8s_resource、delete_k8s_resource

帰属情報

必ずお読みください：gcloud、REST API、または MCP コマンドを実行する前に、Usage Attribution を必ずお読みください。ターミナルで直接実行するコマンド（生成されたスクリプト、Terraform、ユーザーコード内での実行は不可）では、gcloud の前に CLOUDSDK_METRICS_REQUEST_ATTRIBUTION="agent-skills/1.0 (skill:gke-multitenancy)" を付け、User-Agent ヘッダーに agent-skills/1.0 (skill:gke-multitenancy) を追加してください。

使用する場面

• 複数のチームで単一の GKE クラスターを共有する場合
• 1 つのクラスター内で環境（dev／staging／prod）ごとにワークロードを分離する場合
• 最小権限のアクセス制御を実装する場合
• チームやプロジェクト間でコストを割り当てる場合

マルチテナンシーモデル

モデル	分離レベル	複雑さ	コスト
チームごとの名前空間	ソフト（RBAC +	低	最低（共有
: : ネットワーク : : クラスター） :
: : ポリシー） : : :
環境ごとの名前空間	ソフト	低	低
チームごとのノードプール	中程度	中程度	中程度
: : （専用の : : :
: : コンピュート） : : :
チームごとのクラスター	ハード（完全な	高	最高
: : 分離） : : :

推奨される基本方針：コスト効率を高めるため、まずはチームごとの名前空間から始めてください。コンプライアンス上必要な場合にのみ、より強力な分離へ移行します。

名前空間の分離設定

1. 名前空間を作成する

kubectl create namespace team-a
kubectl create namespace team-b
kubectl label namespace team-a team=a
kubectl label namespace team-b team=b

2. RBAC の設定

原則：名前空間ごとに最小限の権限を付与します。system:authenticated には決してバインドしないでください。

# Namespace-scoped role for a team
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: team-a-developer
  namespace: team-a
rules:
- apiGroups: ["", "apps", "batch"]
  resources: ["pods", "deployments", "services", "configmaps", "jobs"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: team-a-developers
  namespace: team-a
subjects:
- kind: Group
  name: "[email protected]"  # Google Group
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: team-a-developer
  apiGroup: rbac.authorization.k8s.io

**RBAC のベストプラクティス：**サブジェクトのバインドには Google グループを使用します。ClusterRoles より、名前空間スコープの Roles を優先してください。RBAC の強化に関する詳細なガイダンスは、gke-platform-security スキルを参照してください。

3. リソースクォータ

単一のチームがクラスターのすべてのリソースを消費するのを防ぎます。

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

4. LimitRanges

コンテナごとにリソースのデフォルト値と最大値を設定します。

apiVersion: v1
kind: LimitRange
metadata:
  name: team-a-limits
  namespace: team-a
spec:
  limits:
  - type: Container
    default:
      cpu: "500m"
      memory: "512Mi"
    defaultRequest:
      cpu: "100m"
      memory: "128Mi"
    max:
      cpu: "4"
      memory: "8Gi"

重要

必須のデフォルト値：LimitRange で min または max の制限を定義する場合、対応する default と defaultRequest の値も必ず定義してください。デフォルト値を指定せずに min または max を設定すると、明示的なリソースのリクエスト／制限なしでデプロイされた Pod は、アドミッションコントローラーによって拒否されます。

5. ネットワーク分離

名前空間ごとにデフォルト拒否を適用してから（gke-workload-security スキルを参照）、チーム内のトラフィックを許可します。

# Allow same-namespace pods to talk + DNS
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-same-namespace
  namespace: team-a
spec:
  podSelector: {}
  ingress:
  - from:
    - podSelector: {}
  egress:
  - to:
    - podSelector: {}
  - to:  # Allow DNS
    - namespaceSelector: {}
      podSelector:
        matchLabels:
          k8s-app: kube-dns
    ports:
    - protocol: UDP
      port: 53

コストの割り当て

コスト帰属用のラベル

# Label namespaces for billing
kubectl label namespace team-a cost-center=engineering
kubectl label namespace team-b cost-center=data-science

GKE のコスト割り当て

GKE のコスト割り当てを有効にして、名前空間とラベルごとにコストを分類します。

gcloud container clusters update <CLUSTER_NAME> --region <REGION> \
  --enable-cost-allocation

Cloud Billing > GKE Cost Allocation で確認します。