必须通过kubernetes强制机制实现测试与生产环境完全隔离：为压测单独创建命名空间（如perf-test），禁止共享资源、跨命名空间网络访问及生产权限；rbac遵循最小必要原则，仅限自身命名空间内有限读写；配合resourcequota、limitrange和数据库账号权限控制，构建纵深防御体系。
测试用户组必须与生产环境完全隔离，不能靠“自觉”或“约定”，而要靠 Kubernetes 的强制机制切断误操作路径。
命名空间物理隔离生产与压测环境
绝不允许测试脚本运行在生产命名空间（如 prod）中。必须为压测单独创建命名空间，例如 perf-test 或 stress-prod-mirror，并确保该命名空间：
- 不与生产命名空间共享任何资源对象（Service、ConfigMap、Secret、PV/PVC）
- 禁止通过 NetworkPolicy 访问生产命名空间的 Service 或 Pod IP 段
- 使用独立的 ServiceAccount（如
perf-sa），且该账号未绑定任何生产相关 RoleBinding
RBAC 权限严格限定为只读+有限写入
测试用户组的权限应遵循“最小必要”原则，典型配置如下：
- 只授予
get、list、watch权限用于监控和验证 - 若需创建压测 Job/Deployment，仅开放
create、delete对jobs和deployments，且仅限自身命名空间 -
明确禁止对
secrets、configmaps、services、pods/exec的delete或patch操作 - 绝不可绑定 ClusterRole，所有 Role 必须定义在压测命名空间内
ResourceQuota + LimitRange 防止资源穿透
即使误写了指向生产库的连接字符串，也要让压测任务无法真正连通或耗尽资源：
- 在
perf-test命名空间中设置 ResourceQuota，限制最大 Pod 数（如count/pods: "20"）、CPU 请求总量（如requests.cpu: "4"） - 配置 LimitRange，为所有容器设默认内存上限（如
limits.memory: 1Gi），避免单个压测进程吃光节点内存 - 配合 Pod Security Admission（或旧版 PodSecurityPolicy），禁止容器以
privileged: true或挂载宿主机敏感路径运行
数据库访问层硬隔离
Kubernetes 层面的隔离只是第一道防线，数据库本身必须做纵深防御：
- 压测应用使用的数据库账号，只能连接专用压测库（如
app_perf），且该账号无DROP、TRUNCATE、ALTER权限 - 生产数据库禁止监听测试命名空间所在节点的网络接口；建议通过 Service Mesh（如 Istio）或网络策略，阻断
perf-test到生产 DB Service 的流量 - 敏感操作（如删除表、清空数据）必须走审批流程，由 DBA 手动执行，不暴露给自动化脚本
