GKE 多租户架构实战：基于命名空间的团队隔离、RBAC、资源配额与成本分摊指南-育师

GKE 多租户架构实战：基于命名空间的团队隔离、RBAC、资源配额与成本分摊指南

【免费下载链接】skillsAgent Skills for Google products and technologies项目地址: https://gitcode.com/GitHub_Trending/skills29/skills

本文以 Google Kubernetes Engine（GKE）多租户设计为核心，系统讲解在同一集群内基于命名空间实现软隔离的完整方案：从租户模型选型、命名空间创建、RBAC 权限规划、ResourceQuota 与 LimitRange 资源治理，到 NetworkPolicy 网络隔离，再到基于标签与 GKE Cost Allocation 的成本分摊。读完本文，你将掌握一套可直接落地、可审计、可扩展的企业级 GKE 多租户基线。

何时使用多租户方案

在 gke-multitenancy 技能的定义中，以下场景是启用多租户设计的主要动因：

多个团队共享同一个 GKE 集群（最典型的企业场景）；
在单个集群内按环境（dev/staging/prod）隔离工作负载；
落实最小权限（least-privilege）访问控制；
跨团队或跨项目进行成本归属与分摊。

同时需要明确边界：本方案不适用于单租户集群配置或通用部署指导（后者应使用 gke-basics 或 gke-app-onboarding）。多租户与平台级安全加固（RBAC 强化、Binary Authorization、Shielded Nodes、GKE Sandbox 等）存在交集但定位不同——平台安全属于集群控制面层面，见 gke-platform-security；而多租户聚焦"如何在一个集群里安全、公平、可计量地容纳多个租户"。

多租户模型：隔离强度、复杂度与成本的权衡

模型	隔离强度	复杂度	成本
Namespace-per-team（每团队一个命名空间）	软隔离（RBAC + NetworkPolicy）	低	最低（共享集群）
Namespace-per-environment（每环境一个命名空间）	软隔离	低	低
Node pool-per-team（每团队一个节点池）	中等（专用计算资源）	中	中
Cluster-per-team（每团队一个集群）	硬隔离（完全隔离）	高	最高

黄金路径建议：优先从"每团队一个命名空间"起步以获得最佳成本效率，只有在合规要求确实需要更强隔离时才向更高级别升级。这一推荐与 gke-basics 中"默认使用 Autopilot、按需选择 Standard"的取舍逻辑一致——共享集群 + 命名空间软隔离是绝大多数工作负载成本与安全的最优平衡点。

命名空间隔离搭建：五步基线

第一步：创建命名空间并打标签

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

为命名空间打上的team标签会同时服务于两层用途：一是作为后续 NetworkPolicy 选择器与成本分摊的元数据基础；二是让运维人员通过kubectl get ns -l team=a快速筛选资源。注意：GKE 采用 Autopilot 模式时，命名空间的创建与资源约束行为完全一致，无需区分集群模式。

第二步：RBAC 配置——最小权限、永不绑定 system:authenticated

核心原则：只在命名空间范围内授予团队所需的最小权限，绝不绑定到system:authenticated组。

# 团队命名空间作用域的 Role 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: "team-a@example.com" # Google Group apiGroup: rbac.authorization.k8s.io roleRef: kind: Role name: team-a-developer apiGroup: rbac.authorization.k8s.io

RBAC 最佳实践（与 gke-platform-security 的 RBAC 加固指引完全一致）：

用 Google Groups 作为 subject：绑定到team-a@example.com这类 Google Group，而非逐个用户，便于在 IAM 侧统一管理团队成员进退；
优先用命名空间级 Role 而非 ClusterRole：将权限爆炸半径限制在单个租户内；
禁用集群级不安全绑定：在集群层面通过rbacBindingConfig.enableInsecureBindingSystemAuthenticated: false和rbacBindingConfig.enableInsecureBindingSystemUnauthenticated: false阻断遗留的system:authenticated/system:unauthenticated绑定（Day-0 配置）；
事后审计权限：可用 MCP 工具k8s:check_k8s_auth或kubectl auth can-i --list --as=<user>验证某用户的实际权限；用k8s:get_k8s_resource(resourceType="clusterrolebinding")或kubectl get clusterrolebindings,rolebindings --all-namespaces盘点全集群绑定。

第三步：ResourceQuota——防止单一团队耗尽集群资源

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"

ResourceQuota是租户公平性的核心闸门：它同时约束请求量（requests，调度依据）与上限量（limits，运行时压制上限），并对 Pod、Service、PVC 等对象数量做硬限制。一旦团队 A 触达配额，其命名空间内的新资源创建会被准入控制器直接拒绝，从而保护团队 B 的可用容量。配额可按 CPU/memory 单位（"10"表示 10 核）、存储（Gi）与对象计数三种维度混合设置。

第四步：LimitRange——为每个容器设定默认与上限资源

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解决的是"团队内个体失控"问题：未显式声明资源请求/上限的 Pod 会继承default/defaultRequest，从而保证配额可被准确计量；max则防止单个容器申请过度资源，与ResourceQuota形成"团队-个体"双层治理。

[!IMPORTANT]强制默认值规则：当在LimitRange中定义min或max时，必须同时定义对应的default和defaultRequest。如果只设置min/max而没有默认值，任何未显式声明资源 requests/limits 的 Pod 都会被准入控制器拒绝，导致团队部署失败。这是 GKE 多租户实施中最常见的"踩坑点"之一。

第五步：网络隔离——默认拒绝 + 仅允许同命名空间流量

首先在命名空间上应用默认拒绝策略（完整默认拒绝策略清单见 gke-workload-security 配套资源 default-deny-netpol.yaml），然后放开团队内部流量：

# 允许同命名空间 Pod 之间通信 + 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: # 允许 DNS - namespaceSelector: {} podSelector: matchLabels: k8s-app: kube-dns ports: - protocol: UDP port: 53

这份策略的语义非常明确：

Ingress：只接受来自同一命名空间内 Pod 的入站流量；
Egress：出站只允许到达同命名空间 Pod，外加 kube-dns（UDP/53），保证集群内 DNS 解析可用；
其他命名空间（包括 team-b）的 Pod 一律无法访问 team-a，实现了租户间的网络级软隔离。

从仓库实现看，gke-workload-security 提供的default-deny-netpol.yaml使用podSelector: {}并同时声明policyTypes: [Ingress, Egress]，即对命名空间内全部 Pod双向默认拒绝，是上述精细化白名单策略的"前置条件"；其脚本 audit_cluster.sh 中也会检查networkPolicy.enabled或 Dataplane V2 的ADVANCED_DATAPATH是否开启——因为 NetworkPolicy 只有在集群启用了网络策略执行能力时才会真正生效。

启用网络策略执行（Dataplane V2 集群自带，无需此步）：

gcloud container clusters update <cluster-name> \ --update-addons=NetworkPolicy=ENABLED \ --region <region>

[!NOTE] 若集群使用了 Dataplane V2（--enable-dataplane-v2），网络策略执行能力内置，此步骤不需要执行（执行反而可能报错）。

跨租户安全联动：平台层的必要前置

命名空间级隔离要真正发挥作用，离不开集群平台层的安全基线。在 gke-platform-security 的"黄金路径安全默认值"中，以下设置是多租户场景的强相关前置：

workloadIdentityConfig.workloadPool：启用 Workload Identity Federation，避免租户内 Pod 使用节点默认服务账号访问云 API；
rbacBindingConfig.enableInsecureBindingSystemAuthenticated/unauthenticated = false：从根上阻断面向全部认证/未认证用户的危险绑定；
nodeConfig.workloadMetadataConfig.mode = GKE_METADATA：屏蔽遗留 metadata API，强制走 Workload Identity；
私有集群 + Dataplane V2：参见 gke-networking。

换言之，租户间的权限隔离（RBAC）与网络隔离（NetworkPolicy）只有在平台层禁用了"全局放行"的默认机制后才有意义。

成本分摊：标签驱动 + GKE Cost Allocation

为成本归属打标签

# 为计费打上命名空间标签 kubectl label namespace team-a cost-center=engineering kubectl label namespace team-b cost-center=data-science

cost-center标签将命名空间映射到业务成本中心，这是后续成本报表聚合的维度基础。

启用 GKE Cost Allocation

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

启用后，可在Cloud Billing > GKE Cost Allocation中按命名空间、标签、工作负载维度查看成本分解。

值得说明的是，这一步在 gke-cost-analysis 中被标记为集群变更（mutation）而非只读操作，必须先获得用户明确确认再执行；且命名空间/工作负载标签只会从启用时刻起进入计费导出（gcp_billing_export_resource_v1_*），不回溯历史数据。启用后 BigQuery 计费导出中会填充以下关键标签：

goog-k8s-cluster-name：集群名；
k8s-namespace：命名空间（即租户维度）；
k8s-workload-name/k8s-workload-type：工作负载名与类型。

配合该技能提供的bq query模板，即可回答"哪个租户最贵""各团队成本占比"等问题。成本分析时还需注意定价模型差异（同样适用于多租户成本评估）：Autopilot 按 Pod 资源请求计费（过度请求即使未使用也会产生费用），Standard 按节点池 VM 计费（空闲节点和多个低利用率开发集群会造成浪费），两种模式都有约 $0.10/小时的集群管理费（每个结算账号有一个集群的免费额度）。

通过 MCP 工具落地与验证

本仓库的 gke-basics 及 mcp-usage.md 提供了完整的 MCP 工具偏好层级：MCP 工具 > gcloud CLI > kubectl。多租户实施过程中可直接使用的 MCP 工具包括：

apply_k8s_manifest：应用上述 Role/RoleBinding/ResourceQuota/LimitRange/NetworkPolicy 等 YAML 清单（支持dryRun预演）；
get_k8s_resource：按命名空间、标签/字段选择器查询任意 K8s 资源（如核查各租户配额使用量）；
check_k8s_auth：校验某用户/服务账号在目标命名空间的 RBAC 权限（最小权限落实审计）；
describe_k8s_resource：查看资源详情与事件（如被配额拒绝的调度事件）；
delete_k8s_resource：清理租户资源（支持cascade与dryRun）。

所有工具均使用层级资源路径：projects/{PROJECT}/locations/{REGION}/clusters/{CLUSTER}/...，可用locations/-匹配所有区域。

常见陷阱与最佳实践小结

LimitRange 的 min/max 必须配 default/defaultRequest，否则未声明资源限制的 Pod 会被准入控制器拒绝；
RBAC 永远绑定 Google Group / ServiceAccount，不绑定system:authenticated，并配合集群级rbacBindingConfig禁用不安全绑定；
NetworkPolicy 生效依赖集群能力：Dataplane V2 内置执行，传统集群需先启用 NetworkPolicy 插件，且默认拒绝策略要先行；
成本分摊不可回溯：--enable-cost-allocation是集群变更操作，需用户确认后执行，且只在启用后开始产出细粒度标签；
隔离强度按需升级：黄金路径从 namespace-per-team 起步，仅在合规强制时升级到节点池甚至集群级隔离。