2. 命名空间基础:Namespace概念、创建与管理Namespace、资源配额(ResourceQuota)、默认配额策略

2.1 命名空间(Namespace)概念与作用

在Kubernetes中,命名空间(Namespace)是用于实现虚拟集群的核心抽象。它允许你在同一个物理集群内创建多个相互隔离的虚拟环境,每个环境拥有独立的资源视图和访问控制边界。

特性 说明
资源隔离 Pod、Service、Deployment等资源在命名空间内唯一命名,跨命名空间不可见
权限边界 RBAC策略可精确绑定到命名空间级别,实现细粒度访问控制
配额管理 通过ResourceQuota限制命名空间内CPU、内存、存储等资源总量
网络策略 NetworkPolicy可控制命名空间内Pod之间的流量规则
多租户基础 每个租户对应一个或多个命名空间,实现逻辑上的多租户隔离
关键认知:命名空间不是物理隔离,而是逻辑隔离。同一集群内不同命名空间的Pod仍可通过ClusterIP或NodePort通信,除非显式配置NetworkPolicy进行限制。

2.2 命名空间生命周期管理

2.2.1 创建命名空间

Kubernetes支持两种创建方式:声明式(YAML)和命令式(kubectl)。

方式一:声明式YAML

apiVersion: v1
kind: Namespace
metadata:
  name: team-alpha
  labels:
    environment: production
    team: alpha
  annotations:
    description: "Alpha团队生产环境命名空间"
kubectl apply -f namespace-team-alpha.yaml

方式二:命令式创建

kubectl create namespace team-beta

2.2.2 查看与切换命名空间

# 列出所有命名空间
kubectl get namespaces

# 查看命名空间详细信息
kubectl describe namespace team-alpha

# 切换当前上下文默认命名空间
kubectl config set-context --current --namespace=team-alpha

# 在命令中临时指定命名空间
kubectl get pods -n team-alpha

2.2.3 删除命名空间

⚠️ 危险操作:删除命名空间会级联删除该空间下所有资源(Pod、Service、Deployment、ConfigMap、Secret等),且不可恢复。生产环境操作前务必确认。
kubectl delete namespace team-alpha

2.3 资源配额(ResourceQuota)

ResourceQuota是Kubernetes内置的资源管控机制,用于限制命名空间内资源的总消耗量,防止单个租户过度占用集群资源。

2.3.1 核心配额维度

资源类型 配额字段 说明
计算资源 requests.cpu / requests.memory 所有Pod的CPU/Memory请求总量上限
计算资源 limits.cpu / limits.memory 所有Pod的CPU/Memory限制总量上限
存储资源 requests.storage 所有PVC的存储请求总量上限
对象数量 count/pods / count/services 命名空间内Pod/Service等对象的最大数量
扩展资源 requests.nvidia.com/gpu GPU等特殊硬件资源配额

2.3.2 创建ResourceQuota

apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-quota
  namespace: team-alpha
spec:
  hard:
    requests.cpu: "4"
    requests.memory: "8Gi"
    limits.cpu: "8"
    limits.memory: "16Gi"
    requests.storage: "50Gi"
    count/pods: "20"
    count/services: "10"
    count/configmaps: "10"
kubectl apply -f resourcequota-team-alpha.yaml

2.3.3 查看配额状态

# 查看配额定义
kubectl get resourcequota -n team-alpha

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

输出示例:

Name:            team-quota
Namespace:       team-alpha
Resource         Used  Hard
--------         ----  ----
count/configmaps 2     10
count/pods       5     20
count/services   3     10
limits.cpu       3     8
limits.memory    6Gi   16Gi
requests.cpu     1.5   4
requests.memory  3Gi   8Gi
requests.storage 10Gi  50Gi
实践要点:当Pod创建请求超出配额时,API Server会返回403 Forbidden错误。建议在CI/CD流水线中提前检查配额余量,避免部署失败。

2.4 默认配额策略(LimitRange)

LimitRange用于在命名空间级别设置默认资源请求/限制和最小/最大约束。当Pod未显式设置资源规格时,LimitRange会自动注入默认值。

2.4.1 LimitRange核心能力

策略类型 字段 作用
默认值 default Pod未设置limits时自动注入
默认请求 defaultRequest Pod未设置requests时自动注入
最大值 max Pod的limits不能超过此值
最小值 min Pod的requests不能低于此值
比例约束 maxLimitRequestRatio limits/requests的最大比例

2.4.2 创建LimitRange

apiVersion: v1
kind: LimitRange
metadata:
  name: team-limits
  namespace: team-alpha
spec:
  limits:
  - max:
      cpu: "2"
      memory: "4Gi"
    min:
      cpu: "100m"
      memory: "128Mi"
    default:
      cpu: "500m"
      memory: "1Gi"
    defaultRequest:
      cpu: "200m"
      memory: "512Mi"
    maxLimitRequestRatio:
      cpu: "4"
    type: Container
kubectl apply -f limitrange-team-alpha.yaml

2.4.3 验证默认注入效果

# 创建一个未设置资源规格的Pod
kubectl run test-pod --image=nginx -n team-alpha

# 查看Pod实际资源规格
kubectl get pod test-pod -n team-alpha -o yaml | grep -A 5 resources

输出显示LimitRange自动注入了默认值:

resources:
  limits:
    cpu: 500m
    memory: 1Gi
  requests:
    cpu: 200m
    memory: 512Mi
⚠️ 冲突风险:如果Pod显式设置的资源值超出LimitRange的min/max范围,Pod创建将被拒绝。建议在团队规范中明确资源规格标准。

2.5 ResourceQuota与LimitRange协同工作流

下图展示了命名空间内资源管控的完整流程:

ResourceQuota 与 LimitRange 协同工作流 用户 / CI 提交 Pod LimitRange 校验 注入默认值 / 检查 min/max 范围 是否超出范围? ❌ 拒绝创建 ResourceQuota 校验 检查命名空间资源余量 配额是否充足? ❌ 拒绝创建 ✅ Pod 成功创建 说明:LimitRange 先做单 Pod 规格校验,ResourceQuota 再做命名空间总量校验,双重保障资源安全

2.6 多租户隔离最佳实践

  • 命名空间命名规范:采用 <团队名>-<环境> 格式,如 team-alpha-prod、team-beta-staging
  • 配额先行:创建命名空间后立即绑定ResourceQuota,防止资源滥用
  • 默认策略兜底:使用LimitRange确保所有Pod都有合理的资源规格,避免无限制Pod影响集群稳定性
  • 监控告警:对ResourceQuota使用率设置告警阈值(如80%、90%),提前扩容或清理
  • 审计日志:开启Kubernetes审计日志,记录命名空间内资源变更操作
沙盘实验建议:在测试集群中创建3个命名空间(dev/staging/prod),分别配置不同的ResourceQuota和LimitRange,验证Pod创建、配额超限、默认值注入等场景。使用kubectl describe quota观察配额使用变化。