Kubernetes 如何通过 Namespace 隔离不同环境资源

通过Namespace实现环境隔离，即为dev、test、prod等环境创建独立命名空间并显式指定资源归属，辅以RBAC、ResourceQuota、NetworkPolicy强化管控，避开系统级Namespace。

通过 Namespace 隔离不同环境资源，本质是利用 Kubernetes 的逻辑分区能力，把 dev、test、prod 等环境部署在彼此独立的虚拟空间里，同名资源互不干扰，权限和资源消耗也能分别管控。

按环境创建独立 Namespace

每个环境对应一个明确命名的 Namespace，比如 dev、test、prod。推荐用 YAML 文件定义，便于版本管理和复用：

1. 用 kubectl apply -f prod-ns.yaml 创建生产环境命名空间
2. YAML 中可加 label（如 env: prod），方便后续筛选或策略绑定
3. 避免直接用 kubectl create ns，不利于审计和 CI/CD 流程集成

资源部署时显式指定 Namespace

所有工作负载（Deployment、Service、ConfigMap 等）必须明确归属某个环境 Namespace，否则会落到 default 下，失去隔离意义：

1. 部署命令加 -n prod 参数，例如：kubectl apply -f app.yaml -n prod
2. YAML 文件中写死 metadata.namespace: prod，比命令行更可靠
3. 跨 Namespace 访问服务需用全限定域名，如 nginx-service.test.svc.cluster.local

配套机制强化隔离效果

仅靠 Namespace 不足以实现完整隔离，需结合其他机制协同生效：

1. RBAC 权限限制：为开发人员绑定 dev 的只读/编辑角色，禁止访问 prod
2. ResourceQuota：在 test 中限制最多 10 个 Pod、2Gi 内存，防测试误跑压垮集群
3. NetworkPolicy：默认拒绝跨 Namespace 流量，只允许 prod 访问数据库服务

系统级 Namespace 要避开

像 kube-system、kube-public 这些是 Kubernetes 自己用的，用户不应往里部署业务资源：

1. default 是默认兜底空间，新资源不指定 namespace 就进这里，建议禁用或仅作临时调试用
2. 可通过 kubectl get ns 定期检查是否有业务资源意外落入系统命名空间
3. 集群管理员可设置 admission webhook 拦截未声明 namespace 的 YAML 提交