Kubernetes集群合并优化：本科毕设研究需求与技术咨询

嘿，作为深耕K8s集群优化的开发者，我可以明确告诉你：把开发（dev）和测试（test）阶段部署在同一集群完全合理，这也是很多中小团队降本增效的常用方案，只要做好隔离和资源管控，完全能兼顾效率和稳定性。下面我分两部分给你拆解：

一、为什么合并Dev/Test集群是合理的？ #

• 资源利用率最大化：不用维护两套独立集群，节省服务器硬件成本和运维精力（比如不用重复配置监控、日志、Ingress等基础组件）。K8s的调度器还能动态分配资源——当dev环境负载低时，test可以复用闲置资源，反之亦然。
• 环境一致性提升：dev和test共享同一集群的基础服务（比如同版本的存储类、DNS、Ingress Controller），能大幅减少“dev环境正常，test环境报错”的环境差异问题，让测试结果更可信。
• 运维复杂度降低：只需要维护一套集群的升级、补丁、备份流程，不用在两个集群间重复操作，减少运维出错的概率。

当然，合并的前提是必须做好严格的隔离，否则test的高负载可能拖垮dev环境，或者dev的误操作会影响test的测试进度——这也是接下来要重点讲的整合方案核心。

二、如何开展Dev/Test集群整合？ #

1. 基础隔离：用Namespace划分环境 #

首先用Namespace把dev和test彻底分开，这是最基础的隔离手段：

# 创建dev和test命名空间
kubectl create namespace dev
kubectl create namespace test

2. 资源管控：用ResourceQuota和LimitRange防止资源抢占 #

给每个Namespace配置资源配额，避免某一环境占用过多资源影响另一环境：

• 给dev Namespace设置ResourceQuota（示例）：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: dev-quota
  namespace: dev
spec:
  hard:
    cpu: "4"          # 最多使用4核CPU
    memory: "8Gi"     # 最多使用8GB内存
    pods: "20"        # 最多运行20个Pod

• 配合LimitRange限制单个Pod的资源请求和上限，防止单个Pod耗尽Namespace资源：

apiVersion: v1
kind: LimitRange
metadata:
  name: dev-limit-range
  namespace: dev
spec:
  limits:
  - default:
      cpu: "500m"
      memory: "1Gi"
    defaultRequest:
      cpu: "200m"
      memory: "512Mi"
    type: Container

3. 权限隔离：用RBAC避免跨环境误操作 #

通过RBAC给dev团队和test团队分配仅能操作对应Namespace的权限：

• 给dev团队创建Role，仅允许操作dev Namespace内的Deployment、Pod等资源：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev
  name: dev-role
rules:
- apiGroups: ["apps", ""]
  resources: ["deployments", "pods", "services", "configmaps"]
  verbs: ["get", "list", "create", "update", "delete"]

• 将该Role绑定到dev团队的用户或ServiceAccount：

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: dev-role-binding
  namespace: dev
subjects:
- kind: User
  name: dev-user  # 替换为实际的dev团队用户名
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: dev-role
  apiGroup: rbac.authorization.k8s.io

4. 网络隔离：用NetworkPolicy阻断跨环境流量 #

如果需要更严格的隔离，配置NetworkPolicy禁止dev和test的Pod互相访问：

• 给dev Namespace配置NetworkPolicy，仅允许内部Pod通信：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: dev-isolation
  namespace: dev
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector: {}  # 仅允许dev Namespace内的Pod访问

5. 配置区分：用ConfigMap/Secret隔离环境配置 #

用ConfigMap存储dev和test的不同配置（比如数据库地址、API域名），用Secret存储敏感信息（比如密钥、密码）：

• dev环境的ConfigMap示例：

apiVersion: v1
kind: ConfigMap
metadata:
  name: dev-app-config
  namespace: dev
data:
  DB_HOST: "dev-db.example.com"
  API_URL: "https://dev-api.example.com"

• 部署应用时指定对应Namespace的配置资源即可。

6. 监控与日志：按Namespace拆分数据 #

配置监控（Prometheus+Grafana）和日志系统（ELK/Loki）时，按Namespace过滤数据：

• Prometheus通过namespace="dev"或namespace="test"标签过滤指标，分别创建dev和test的监控仪表盘；
• 日志系统给不同Namespace的日志打标签，排查问题时仅查询对应环境的日志。

7. CI/CD自动化：确保部署到正确环境 #

用CI/CD工具（GitLab CI、Jenkins等）自动化部署时，通过参数控制部署的Namespace：

• 示例GitLab CI脚本片段：

deploy-dev:
  stage: deploy
  script:
    - kubectl apply -f dev-deployment.yaml -n dev
  only:
    - dev

deploy-test:
  stage: deploy
  script:
    - kubectl apply -f test-deployment.yaml -n test
  only:
    - test

最后给你的实践建议 #

• 先迁移非核心的dev/test服务到合并集群，测试稳定性后再逐步迁移所有服务；
• 定期检查两个Namespace的资源使用情况，根据实际负载调整ResourceQuota；
• 做好集群备份（比如用Velero），避免集群故障同时影响两个环境。

内容的提问来源于stack exchange，提问作者user9323079