title: K8s 系列 | 第 6 天：Namespace 与资源配额：多租户隔离基础
tags:
– Kubernetes
– K8s系列
– DevOps
– Namespace
– 资源配额
– 多租户

K8s 系列 | 第 6 天：Namespace 与资源配额：多租户隔离基础

第 6/30 天

一、引言

当一个 Kubernetes 集群被多个团队或多个应用共享时，如何防止”邻居吵闹”（noisy neighbor）问题？如何确保开发环境、测试环境和生产环境在同一个集群中和平共处？

答案是：Namespace（命名空间） 与 ResourceQuota（资源配额）。

Namespace 是 K8s 实现逻辑隔离的基石，它将集群资源划分为多个虚拟的”子集群”。而 ResourceQuota 则是保证这些子集群之间公平使用资源的护栏。今天我们就来深入解析这两个核心概念，并通过实战演示如何配置多租户隔离。

二、核心概念

2.1 什么是 Namespace？

Namespace 是 Kubernetes 中一种将集群资源进行逻辑分组的机制。它提供了一种在不同用户和团队之间划分集群资源的方式，通过资源名称的作用域来实现隔离。

关键特性：
– 同一个 Namespace 内，资源名称必须唯一；不同 Namespace 间，资源名称可以重复
– 大多数 K8s 资源（Pod、Service、Deployment 等）都属于某个 Namespace
– 集群级别的资源（Node、PV、Namespace 本身）不属于任何 Namespace

默认 Namespace：
– default：默认命名空间，未指定时资源创建于此
– kube-system：K8s 系统组件所在命名空间
– kube-public：所有用户（包括未认证用户）都可读取的公共命名空间
– kube-node-lease：节点心跳 Lease 对象所在命名空间

2.2 什么是 ResourceQuota？

ResourceQuota 是 Kubernetes 提供的资源配额控制机制，它可以限制一个 Namespace 内资源使用的总量上限。

可以限制的资源类型：
– 计算资源：CPU、内存的 requests 和 limits 总和上限
– 存储资源：PVC 存储总量上限、各类存储类的 PVC 数量上限
– 对象数量：Pod、Service、ConfigMap、PVC 等资源对象的最大数量

2.3 LimitRange：细粒度资源约束

LimitRange 在 ResourceQuota 的基础上进一步细化，为 Namespace 内单个 Pod 或 Container 设置默认的 requests/limits 和取值范围。

三、实战步骤

3.1 创建多个 Namespace

首先，为不同的团队创建独立的 Namespace：

# namespaces.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: team-alpha
  labels:
    team: alpha
    environment: production
---
apiVersion: v1
kind: Namespace
metadata:
  name: team-beta
  labels:
    team: beta
    environment: staging

kubectl apply -f namespaces.yaml
# 验证
kubectl get namespaces
kubectl describe namespace team-alpha

3.2 为 Namespace 配置 ResourceQuota

为 team-alpha 命名空间设置资源配额：

# quota-team-alpha.yaml
apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-quota
  namespace: team-alpha
spec:
  hard:
    requests.cpu: "4"
    requests.memory: "8Gi"
    limits.cpu: "8"
    limits.memory: "16Gi"
    persistentvolumeclaims: "5"
    pods: "20"
    services: "10"
    configmaps: "10"
    secrets: "10"

# 应用资源配额
kubectl apply -f quota-team-alpha.yaml

# 查看配额状态
kubectl get resourcequota compute-quota -n team-alpha -o yaml

# 查看配额使用情况
kubectl describe resourcequota compute-quota -n team-alpha

3.3 配置 LimitRange 设定默认资源限制

# limitrange-team-alpha.yaml
apiVersion: v1
kind: LimitRange
metadata:
  name: container-limits
  namespace: team-alpha
spec:
  limits:
  - max:
      cpu: "2"
      memory: "2Gi"
    min:
      cpu: "100m"
      memory: "128Mi"
    default:
      cpu: "500m"
      memory: "512Mi"
    defaultRequest:
      cpu: "200m"
      memory: "256Mi"
    type: Container

kubectl apply -f limitrange-team-alpha.yaml
kubectl describe limitrange container-limits -n team-alpha

3.4 测试资源配额约束效果

创建超出配额的 Pod 来验证 ResourceQuota 的工作机制：

# 尝试创建超出 CPU 请求限制的 Pod
kubectl -n team-alpha run test-pod --image=nginx --requests=cpu=8
# 预期输出：Error from server (Forbidden): ... exceeded quota: compute-quota, requested: requests.cpu=8, used: requests.cpu=0, limited: requests.cpu=4

# 创建符合配额要求的 Pod
kubectl -n team-alpha run nginx --image=nginx --requests=cpu=200m --limits=cpu=500m
kubectl get pods -n team-alpha

3.5 使用 kubens 快速切换 Namespace

# 安装 kubens（如果未安装）
git clone https://github.com/ahmetb/kubectx.git ~/.kubectx
sudo ln -s ~/.kubectx/kubens /usr/local/bin/kubens

# 快速切换 Namespace
kubens team-alpha
kubens team-beta
kubens default

# 查看当前 Namespace
kubens -c

四、常见问题

Q1：Namespace 删除后，里面的资源会怎样？

所有属于该 Namespace 的资源都会被级联删除（包括 Pod、Service、Deployment 等）。但集群级别的资源（Node、PV、StorageClass）不受影响。删除 Namespace 时要格外小心，建议先备份关键配置。

Q2：如何查看当前上下文所在的 Namespace？

kubectl config view --minify -o jsonpath='{..namespace}'
# 或者更直观的方式
kubectl config get-contexts

Q3：ResourceQuota 和 LimitRange 冲突时怎么办？

ResourceQuota 优先于 LimitRange。 如果同时配置了两者，K8s 会先检查 ResourceQuota（Namespace 级别的总量上限），再检查 LimitRange（Pod/Container 级别的范围）。建议两者配合使用：ResourceQuota 设总闸门，LimitRange 设单 Pod 的水龙头。

Q4：如何设定某个 Namespace 不执行 ResourceQuota？

ResourceQuota 是按 Namespace 绑定的，不绑定 ResourceQuota 的 Namespace 就不受配额限制。如果你想让管理员 Namespace 不受限制，就不在其上创建 ResourceQuota 对象即可。

Q5：Namespace 是真正的安全隔离吗？

不是。 Namespace 提供的是逻辑隔离，并非安全隔离。同一集群中的不同 Namespace 之间可以通过 NetworkPolicy 实现网络隔离，也可以通过 RBAC 实现权限隔离，但 Namespace 本身并不能阻止一个 Namespace 中的 Pod 访问另一个 Namespace 中的 Service（如 service.namespace.svc.cluster.local）。真正的安全隔离需要结合 NetworkPolicy + RBAC + Pod Security Admission 来实现。

五、总结

通过今天的实战，我们掌握了：

最佳实践建议：
1. 尽早规划 Namespace 结构：根据团队、环境、项目维度设计 Namespace 树
2. ResourceQuota + LimitRange 组合使用：两者互补，形成双层资源管控
3. 为所有 Namespace 设置配额：包括 default 命名空间，避免”逃逸”行为
4. 定期审查配额使用率：使用 kubectl describe resourcequota 监控水位
5. 结合 RBAC：限制普通用户只能操作特定 Namespace 内的资源

多租户隔离是 Kubernetes 生产化部署的第一步，Namespace 和 ResourceQuota 是最基础也最重要的管控手段。掌握了它们，你就能在同一个集群中安全、有序地运行多个团队的工作负载。

下期预告

第 7 天：ConfigMap 与 Secret：配置管理最佳实践

应用配置与敏感信息的分离管理是 12-Factor App 的核心原则之一。在 K8s 中，ConfigMap 和 Secret 是实现配置与代码分离的标准方式。下期我们将深入探讨如何创建、挂载和更新 ConfigMap 与 Secret，以及在生产环境中管理敏感信息的安全最佳实践。

📚 系列目录
– 第 1 天：Kubernetes 是什么？核心概念与架构全景解析
– 第 2 天：手把手搭建你的第一个 K8s 集群（kubeadm 实战）
– 第 3 天：Pod 详解：K8s 最小的调度单元与生命周期管理
– 第 4 天：Deployment 与 ReplicaSet：声明式应用管理
– 第 5 天：Service 与网络基础：ClusterIP、NodePort、LoadBalancer 详解
– 第 6 天：Namespace 与资源配额：多租户隔离基础 ← 今日
– 第 7 天：ConfigMap 与 Secret：配置管理最佳实践（下期预告）
– … 持续更新中，敬请关注！