通过namespace实现环境隔离，即为dev、test、prod等环境创建独立命名空间并显式指定资源归属，辅以rbac、resourcequota、networkpolicy强化管控，避开系统级namespace。
通过 Namespace 隔离不同环境资源，本质是利用 Kubernetes 的逻辑分区能力，把 dev、test、prod 等环境部署在彼此独立的虚拟空间里，同名资源互不干扰，权限和资源消耗也能分别管控。
按环境创建独立 Namespace
每个环境对应一个明确命名的 Namespace，比如 dev、test、prod。推荐用 YAML 文件定义，便于版本管理和复用：
- 用
kubectl apply -f prod-ns.yaml创建生产环境命名空间 - YAML 中可加 label（如
env: prod），方便后续筛选或策略绑定 - 避免直接用
kubectl create ns，不利于审计和 CI/CD 流程集成
资源部署时显式指定 Namespace
所有工作负载（Deployment、Service、ConfigMap 等）必须明确归属某个环境 Namespace，否则会落到 default 下，失去隔离意义：
Kubernetes Security Posture Scorecard
下载
评估 Kubernetes 集群安全态势，覆盖 RBAC、工作负载安全、网络策略、基础设施即代码（IaC）、运行时监控和密钥管理等 30 项控制项……
- 部署命令加
-n prod参数，例如：kubectl apply -f app.yaml -n prod - YAML 文件中写死
metadata.namespace: prod，比命令行更可靠 - 跨 Namespace 访问服务需用全限定域名，如
nginx-service.test.svc.cluster.local
配套机制强化隔离效果
仅靠 Namespace 不足以实现完整隔离，需结合其他机制协同生效：
-
RBAC 权限限制：为开发人员绑定
dev的只读/编辑角色，禁止访问prod -
ResourceQuota：在
test中限制最多 10 个 Pod、2Gi 内存，防测试误跑压垮集群 -
NetworkPolicy：默认拒绝跨 Namespace 流量，只允许
prod访问数据库服务
系统级 Namespace 要避开
像 kube-system、kube-public 这些是 Kubernetes 自己用的，用户不应往里部署业务资源：
-
default是默认兜底空间，新资源不指定 namespace 就进这里，建议禁用或仅作临时调试用 - 可通过
kubectl get ns定期检查是否有业务资源意外落入系统命名空间 - 集群管理员可设置 admission webhook 拦截未声明 namespace 的 YAML 提交
