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协同工作流
下图展示了命名空间内资源管控的完整流程:
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观察配额使用变化。