namespace隔离是测试环境部署的第一道防线，需用语义化命名、显式绑定、配合networkpolicy/resourcequota，并确保configmap/secret同生命周期。
namespace 隔离是测试环境部署的第一道防线
Kubernetes 测试环境不是“跑起来就行”，而是要避免和开发、预发甚至其他测试分支互相污染。最直接有效的方式就是用 namespace 切分逻辑边界。
- 不要用默认的
default命名空间部署任何测试服务，哪怕只是临时验证 - 每套环境建议用语义化命名，比如
test-v2.3.1、uat-feature-x，避免用test1、test2这类无上下文名称 -
namespace本身不提供网络或资源硬隔离，需配合NetworkPolicy和ResourceQuota使用，否则 Pod 仍可能跨 namespace 访问 Service（尤其在 ClusterIP 场景下） - 创建后立即检查：
kubectl get ns test-v2.3.1 -o wide
确认STATUS是Active，且没有残留的 Finalizer（如卡在Terminating状态，说明有资源未清理干净）
Deployment + Service 组合必须显式绑定 namespace
很多测试失败源于命令行漏写 --namespace 或 YAML 中没指定 metadata.namespace，结果资源被创建到错误位置。
- 所有
kubectl命令操作测试资源时，优先加-n test-v2.3.1，不要依赖kubectl config set-context的当前上下文——它容易被其他终端或脚本覆盖 - YAML 文件里必须写全：
apiVersion: apps/v1 kind: Deployment metadata: name: api-server namespace: test-v2.3.1 # ← 这一行不能省 spec: # ...
- NodePort 类型的
Service要特别注意端口冲突：Kubernetes 只允许每个节点上一个 Service 占用特定 NodePort（30000–32767），多套测试环境共用集群时，必须手动分配不重叠的端口，比如test-v2.3.1用30080，uat-feature-x就得换30081，不能都写nodePort: 30080
Ingress 路由规则容易忽略 host 匹配优先级
用 Ingress 对接测试环境时，常见现象是：访问 test-v231.example.com 却跳转到了 default-backend 或其他环境页面。
- 核心原因是多个 Ingress 资源定义了相同
host，而 Kubernetes 按照字典序或创建时间决定优先级，不可控 - 正确做法：每个测试环境独占一个子域名，且 Ingress YAML 中
host字段必须精确匹配（不带通配符），例如：rules: - host: test-v231.example.com http: paths: - path: / pathType: Prefix backend: service: name: api-server port: number: 80 - 如果用的是 Nginx Ingress Controller，还需确认其 ConfigMap 是否启用了
use-forwarded-headers: "true"，否则在反向代理链路中，Host头可能被覆盖
ConfigMap 和 Secret 必须与 namespace 同生命周期
测试环境常需要动态切换数据库地址、密钥、开关配置，但很多人把 ConfigMap 放在 default 下，然后在测试 Deployment 中通过 envFrom 引用——这会导致删除 namespace 时 ConfigMap 还在，下次重建同名环境会复用旧配置。
- 所有支撑测试环境的
ConfigMap和Secret必须和应用一起创建在目标namespace内 - 修改配置后，Deployment 不会自动滚动更新，必须触发重启：
kubectl rollout restart deployment api-server -n test-v2.3.1
-
Secret的 base64 编码内容不能含换行符，否则挂载失败且 Pod 会卡在ContainerCreating，可用echo -n "value" | base64验证编码是否正确
真正麻烦的从来不是“怎么部署”，而是“怎么确保每次部署都是干净、可重现、可销毁的”。命名空间没清干净、NodePort 冲突、Ingress host 错位、ConfigMap 残留——这些问题在单次部署时不易察觉，但一旦进入多环境并行阶段，就会变成排查黑洞。
