Kubernetes集群的治理模型，本质是在一个共享控制平面之上划清三件事：谁能做什么、能用多少资源、能与谁通信。多团队协作时，如果只靠口头约定或默认命名空间，很快就会遇到权限蔓延和资源争抢。一个稳定的治理模型通常从命名空间边界开始，配合RBAC、配额和网络策略逐层收紧，让每个团队的自主权与集群整体稳定性之间保持平衡。
需要注意的是，Kubernetes本身并不提供传统意义上的多租户硬隔离。它提供的是命名空间、RBAC、配额、网络策略等一系列可组合的控制手段。能否形成一个可落地的治理模型，取决于这些手段是否被规范使用，以及是否具备自动化校验能力。下面从团队边界、权限、配额、网络和策略引擎几个维度展开。
一、用命名空间建立团队边界
命名空间是Kubernetes划分逻辑边界的第一层。每个团队至少应当拥有独立的命名空间，避免不同团队创建同名Service或ConfigMap时产生冲突。命名空间还可以作为配额、RBAC绑定和网络策略的锚点，让后续治理规则能够按团队聚合。建议同时把环境维度拆开，例如team-a-dev、team-a-staging、team-a-prod，这样开发环境和生产环境在权限模型上可以天然区分。
命名空间本身不能阻止Pod之间的网络通信，也不能完全隔离API访问，所以它不是安全边界。但缺少命名空间规划，后续所有策略都会失去附着点。为了便于审计和成本分摊，可以给命名空间打上规范标签，例如owner、environment、cost-center。这些标签可以被ResourceQuota选择器、NetworkPolicy的namespaceSelector以及策略引擎复用。
创建团队命名空间时，建议同时声明资源配额和默认LimitRange，而不是只创建一个空命名空间就交给团队使用。下面是一个包含标签的基础命名空间示例：
apiVersion: v1
kind: Namespace
metadata:
name: team-a-prod
labels:
owner: team-a
environment: production
cost-center: cc-1001
命名空间一旦创建，团队内部可以自由创建Deployment、Service、ConfigMap等资源，但管理员仍然需要限制这些资源的数量和规格。下一节先讨论如何通过RBAC把操作权限限制在团队自己的命名空间内。
二、RBAC权限模型与授权粒度
RBAC是Kubernetes授权机制的核心，它通过Role、ClusterRole、RoleBinding和ClusterRoleBinding四类对象决定一个用户或服务账户能执行哪些操作。多团队场景下最重要的原则是默认拒绝、最小授权。不要为了省事把cluster-admin直接绑定给个人用户或团队组，否则任何一名成员都可以查看、修改或删除其他团队的资源。
通常建议为每个团队创建一个Role，只授予该团队命名空间内的常见操作权限，再通过RoleBinding把企业身份系统中的组映射到该角色。用户组信息来自OIDC或LDAP集成，管理员不需要为每个成员单独创建绑定。角色内部可以按资源类型拆分，例如允许管理Deployment、Service、ConfigMap，但不允许操作ResourceQuota或NetworkPolicy，这些应由平台团队保留。
下面示例演示如何给团队A授予其生产命名空间内的基本工作负载管理权限，并绑定到team-a-group这个用户组：
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: team-a-prod
name: team-a-developer
rules:
- apiGroups: ["apps"]
resources: ["deployments", "replicasets"]
verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
- apiGroups: [""]
resources: ["services", "configmaps", "secrets"]
verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
- apiGroups: [""]
resources: ["pods", "pods/log"]
verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
namespace: team-a-prod
name: team-a-developer-binding
subjects:
- kind: Group
name: team-a-group
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: team-a-developer
apiGroup: rbac.authorization.k8s.io
ClusterRole与Role的区别在于作用域：Role是命名空间级别，ClusterRole是集群级别。但ClusterRole也可以通过RoleBinding绑定到某个命名空间，此时权限只在该命名空间内生效。这种用法适合复用平台团队预先定义好的通用角色，但需要小心，因为ClusterRole中可能包含对集群级资源的访问权限，即使绑定到命名空间也无法覆盖集群级资源，但权限定义一旦过宽，会给审计带来负担。
在实际治理模型中，建议采用“团队自主命名空间”加“平台只读角色”的组合。普通成员只在自身命名空间内拥有写权限，平台管理员保留对集群级资源和配额对象的控制。这样既赋予团队日常开发效率，也避免误操作扩散到整个集群。
三、资源配额与限制策略
多个团队共享同一个集群时，资源争抢是最常见的冲突来源。一个团队如果提交大量Pod或申请过高的CPU、内存，可能挤压其他团队的可用资源。Kubernetes通过ResourceQuota对命名空间的总资源使用量设置上限，通过LimitRange对单个Pod或容器设置默认请求和限制，两者配合才能形成完整约束。
ResourceQuota可以限制CPU、内存的请求总量和限制总量，也可以限制存储卷数量、Service数量、ConfigMap数量等对象计数。配额对象会在创建资源时进行校验，如果超出配额，API Server会直接拒绝创建请求。需要注意的是，ResourceQuota本身不设置单个Pod的默认值，如果团队忘记写requests和limits，Pod可以被创建但可能无法调度或占用不合理资源。因此需要LimitRange补齐默认值。
下面是一个团队A生产命名空间的配额和LimitRange示例。该命名空间最多允许申请8核CPU和16Gi内存，单个容器默认请求0.1核CPU和128Mi内存，并强制要求设置limits：
apiVersion: v1
kind: ResourceQuota
metadata:
name: team-a-prod-quota
namespace: team-a-prod
spec:
hard:
requests.cpu: "8"
requests.memory: 16Gi
limits.cpu: "16"
limits.memory: 32Gi
persistentvolumeclaims: "10"
services: "20"
configmaps: "50"
---
apiVersion: v1
kind: LimitRange
metadata:
name: team-a-prod-limits
namespace: team-a-prod
spec:
limits:
- type: Container
default:
cpu: 500m
memory: 512Mi
defaultRequest:
cpu: 100m
memory: 128Mi
max:
cpu: "4"
memory: 8Gi
min:
cpu: 50m
memory: 64Mi
ResourceQuota可以按团队预算分档。例如核心业务团队可以获得更高的CPU配额，而临时实验环境使用较低配额。当团队需要在短时间内扩容时，可以通过变更配额申请流程向平台团队申请，而不是直接修改配额对象。这样让资源治理从被动救火变成主动规划。
还需要注意requests和limits的区别。requests用于调度决策，limits是容器运行时允许使用的上限。如果只设置limits而不设置requests，Kubernetes会将requests默认等于limits，可能导致节点资源被过度预留。反之，只设置requests而不设置limits，容器可以突破节点资源限制，影响其他Pod。多团队场景中建议通过LimitRange强制要求两者都设置，并通过策略引擎进行审计。
四、网络隔离与跨团队通信
默认情况下，Kubernetes集群中的Pod之间可以直接通信，只要目标Pod的IP可达。多团队共用集群时，如果不做网络策略隔离，团队A的Pod可能访问团队B的数据库或内部服务。NetworkPolicy允许管理员定义Pod间流量的进出规则，但前提是集群使用的CNI插件支持网络策略执行，例如Calico、Cilium或Weave Net。
NetworkPolicy的规则基于命名空间和Pod标签。可以先在命名空间中创建默认拒绝所有入站流量的策略，再按需放行来自特定命名空间或特定Pod标签的流量。跨团队通信不再依赖口头约定，而是由策略强制执行。例如只允许前端命名空间的Pod访问后端命名空间中带有app: api标签的Pod的8080端口。
下面示例先默认拒绝团队B数据库命名空间的所有入站流量，再放行来自团队A前端命名空间的指定端口访问：
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-ingress
namespace: team-b-data
spec:
podSelector: {}
policyTypes:
- Ingress
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-team-a-frontend-to-api
namespace: team-b-data
spec:
podSelector:
matchLabels:
app: api
policyTypes:
- Ingress
ingress:
- from:
- namespaceSelector:
matchLabels:
owner: team-a
podSelector:
matchLabels:
role: frontend
ports:
- protocol: TCP
port: 8080
NetworkPolicy是命名空间内资源，但它的namespaceSelector和podSelector可以跨越命名空间边界表达授权关系。共享服务可以放在公共命名空间中，通过精确的标签选择器开放给多个团队，而不需要把整个公共命名空间暴露给所有人。这种设计在服务网格之外提供了一层轻量的网络边界控制。
需要注意的是，NetworkPolicy主要面向IP和端口级别，无法处理七层HTTP路径或认证授权。如果业务需要更细粒度的跨团队API访问控制，可以使用服务网格或Ingress层策略补充。但就治理模型而言，网络策略已经是多租户网络边界的核心组件。
五、分层命名空间与策略引擎
当团队数量增加到几十个甚至更多，逐个命名空间手工创建配额、LimitRange和RBAC会变得非常繁琐，而且容易出现遗漏。分层命名空间控制器HNC允许建立树形命名空间结构，父命名空间可以自动将配额、LimitRange、RBAC角色等资源传播到子命名空间。例如创建一个prod父命名空间，下面挂多个团队的prod子命名空间，平台团队只需在父级维护一次策略。
HNC的好处是降低了策略漂移风险，但也引入了额外的控制器和运维复杂度。使用HNC之前需要评估团队命名空间的层级是否真的足够复杂，如果只有十几个团队，手工管理可能比引入HNC更简单。HNC还要求命名空间命名遵循一定规范，且子命名空间继承的资源类型是有限的，需要控制器版本支持。
与HNC相比，策略引擎如Kyverno和OPA Gatekeeper更侧重于自动化校验。它们通过准入控制拦截资源创建请求，可以强制所有Pod声明资源请求和限制、禁止使用latest镜像标签、限制镜像仓库来源、检查Pod是否有网络策略覆盖等。Kyverno的策略使用YAML表达，对平台团队更友好。下面示例强制要求所有容器设置requests和limits，否则拒绝创建：
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: require-resources-limits
spec:
validationFailureAction: enforce
rules:
- name: check-resources
match:
any:
- resources:
kinds:
- Pod
validate:
message: "每个容器都必须设置 CPU 和内存的 requests 与 limits"
pattern:
spec:
containers:
- resources:
requests:
cpu: "?*"
memory: "?*"
limits:
cpu: "?*"
memory: "?*"
策略引擎真正有价值的地方在于把治理规则从文档和人工审查转成自动拦截。没有策略引擎时，团队可能忘记设置资源限制，等到节点OOM才暴露问题。接入Kyverno或Gatekeeper后，不合规的资源直接无法提交，集群管理员可以更放心地把命名空间自助能力开放给团队。
综合来看，多层治理模型不是单一工具能解决的。命名空间提供边界，RBAC控制权限，ResourceQuota和LimitRange约束资源，NetworkPolicy隔离流量，HNC降低规模化管理成本，策略引擎保证规则持续执行。每一个层次都在解决不同维度的问题，组合起来才能形成面向多团队协作的可靠治理体系。
Kubernetes多租户RBAC资源配额修改时间：2026-09-24 23:34:04