Kubernetes命名空间：资源隔离与多租户实践指南

1. 为什么需要命名空间？

在Kubernetes集群中，命名空间（Namespace）是最基础也是最重要的资源隔离机制。想象一下，如果没有命名空间，所有资源都混在同一个空间里会怎样？开发、测试、生产环境的Pod互相干扰，不同团队的服务可能因为命名冲突而无法部署，资源配额也无法按团队划分...这简直就是运维的噩梦。

我经历过一个典型的案例：某电商平台最初没有使用命名空间，结果开发团队误删了生产环境的ConfigMap，导致线上支付服务中断2小时。后来引入命名空间隔离后，这类事故再没发生过。

2. 命名空间的核心特性

2.1 资源隔离的三种维度

命名空间提供了三个层次的隔离：

1. 名称隔离：不同命名空间可以有同名资源
2. 权限隔离：RBAC可以基于命名空间授权
3. 资源配额：可以为每个命名空间设置独立的CPU/内存配额

yaml复制# 示例：为dev命名空间设置资源配额
apiVersion: v1
kind: ResourceQuota
metadata:
  name: dev-quota
  namespace: dev
spec:
  hard:
    requests.cpu: "10"
    requests.memory: 20Gi
    limits.cpu: "20"
    limits.memory: 40Gi

2.2 默认命名空间的玄机

Kubernetes安装后会创建4个默认命名空间：

• default：未指定命名空间时的默认位置
• kube-system：系统组件专用（千万别动！）
• kube-public：集群公共资源
• kube-node-lease：节点心跳检测

重要提示：生产环境中永远不要在default命名空间部署业务应用！这是我用惨痛教训换来的经验。

3. 多租户实践方案

3.1 基于命名空间的租户划分

在SaaS场景下，我们通常这样设计：

code复制cluster
├── namespace-tenant1
│   ├── deployment-app1
│   └── service-app1
├── namespace-tenant2
│   ├── deployment-app1
│   └── service-app1
└── namespace-shared
    ├── redis
    └── mysql

3.2 跨命名空间通信方案

当服务需要跨命名空间访问时，可以使用完整的DNS名称：

code复制<service-name>.<namespace-name>.svc.cluster.local

例如在tenant1命名空间访问tenant2的MySQL：

yaml复制apiVersion: v1
kind: Service
metadata:
  name: mysql
  namespace: tenant2
spec:
  ports:
  - port: 3306
  selector:
    app: mysql

然后在tenant1的Pod中就可以通过mysql.tenant2.svc.cluster.local:3306访问。

4. 环境隔离最佳实践

4.1 经典三环境模型

bash复制# 创建环境命名空间
kubectl create ns dev
kubectl create ns staging
kubectl create ns production

# 设置差异化资源配额
kubectl apply -f quota-dev.yaml -n dev
kubectl apply -f quota-prod.yaml -n production

4.2 命名规范建议

我推荐采用这种命名约定：

code复制<团队代号>-<环境>-<业务域>
示例：
marketing-dev-campaign
finance-prod-payment

5. 常见问题排查指南

5.1 资源无法删除问题

当命名空间卡在Terminating状态时，可以这样处理：

bash复制# 1. 导出命名空间定义
kubectl get ns <problem-namespace> -o json > temp.json

# 2. 移除finalizers字段
vi temp.json
# 删除"spec":{"finalizers":[...]}部分

# 3. 通过代理API直接操作
kubectl proxy &
curl -k -H "Content-Type: application/json" -X PUT \
  --data-binary @temp.json \
  http://127.0.0.1:8001/api/v1/namespaces/<problem-namespace>/finalize

5.2 跨命名空间服务发现失败

检查要点：

1. 确认CoreDNS正常运行
2. 检查网络策略是否允许跨命名空间通信
3. 验证服务端口是否暴露正确

bash复制# 诊断命令示例
kubectl run dns-test --image=busybox:1.28 -n dev --rm -it --restart=Never -- \
  nslookup mysql.tenant2.svc.cluster.local

6. 进阶使用技巧

6.1 命名空间资源监控

使用kube-state-metrics配合Prometheus监控各命名空间资源：

bash复制# 部署kube-state-metrics（Kubernetes 1.28+）
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm install ksm prometheus-community/kube-state-metrics -n monitoring

然后可以配置如下告警规则：

yaml复制- alert: NamespaceCPUOvercommit
  expr: sum(kube_pod_container_resource_limits{resource="cpu"}) by (namespace) / sum(kube_node_status_allocatable{resource="cpu"}) > 0.9
  for: 30m
  labels:
    severity: warning
  annotations:
    summary: "Namespace {{ $labels.namespace }} CPU overcommitment"

6.2 命名空间自动化管理

通过准入控制器实现自动化：

1. 使用NamespaceAutoProvision自动创建团队命名空间
2. 通过PodNodeSelector强制每个命名空间使用特定节点池
3. 用LimitRanger设置默认资源限制

go复制// 示例准入控制器代码片段
if ns.Labels["team"] != "" {
    if _, err := createRBAC(ns.Name, ns.Labels["team"]); err != nil {
        return deny(fmt.Sprintf("failed to create RBAC: %v", err))
    }
}

在实际项目中，我们通过这套机制将命名空间创建到审批时间从原来的2天缩短到10分钟，同时减少了90%的配置错误。