15 | 开发和测试争抢环境？是时候进行多环境建设了

# ArgoCD Application for Staging
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app-staging
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/org/my-app.git
    targetRevision: main          # 追踪main分支
    path: k8s/overlays/staging
  destination:
    server: https://kubernetes.default.svc
    namespace: staging
  syncPolicy:
    automated:
      prune: true                 # 自动清理多余资源
      selfHeal: true              # 自动修复漂移
    syncOptions:
    - CreateNamespace=true

# 每个开发者分配自己的命名空间
kubectl create namespace dev-alice
kubectl create namespace dev-bob
kubectl create namespace dev-charlie

# 通过RBAC限制每个开发者只能操作自己的namespace

# 当Jira Epic创建时，通过webhook触发环境创建
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: project-environments
spec:
  generators:
  - pullRequest:
      github:
        owner: org
        repo: my-app
        tokenRef:
          secretName: github-token
          key: token
      rebase: false
  template:
    metadata:
      name: 'project-pr-{{number}}'
    spec:
      source:
        repoURL: https://github.com/org/my-app.git
        targetRevision: '{{head_sha}}'
        path: k8s/overlays/project
      destination:
        server: https://kubernetes.default.svc
        namespace: 'project-{{number}}'
      syncPolicy:
        automated: {}           # PR关闭后自动清理

# 生产环境 - 默认拒绝所有入站，只允许特定来源
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: production-deny-all-ingress
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress: []  # 空数组 = deny all

---
# 允许ingress controller访问
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-ingress
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: my-app
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: ingress-nginx
    ports:
    - protocol: TCP
      port: 8080

# 为不同环境自动生成不同的访问地址
apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: my-app-route
  namespace: staging
spec:
  parentRefs:
  - name: internal-gateway
    namespace: network
  hostnames:
  - "myapp.staging.internal"
  rules:
  - backendRefs:
    - name: my-app-svc
      port: 8080

# ResourceQuota示例 - 限制dev namespace的总资源
apiVersion: v1
kind: ResourceQuota
metadata:
  name: dev-quota
  namespace: dev
spec:
  hard:
    requests.cpu: "10"
    requests.memory: 20Gi
    limits.cpu: "20"
    limits.memory: 40Gi
    persistentvolumeclaims: "5"
    pods: "50"

# CronHPA - 工作时间扩展，下班后收缩
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app-dev-hpa
  namespace: dev
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  minReplicas: 1
  maxReplicas: 3
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50
  behavior:
    scaleDown:
      policies:
      - type: Percent
        value: 100
        periodSeconds: 60
      stabilizationWindowSeconds: 300
    scaleUp:
      stabilizationWindowSeconds: 0

❌ 陷阱1："Namespace爆炸"
   症状：几百个namespace没人清理
   根因：只有创建没有销毁机制
   后果：etcd压力大，apiserver变慢，资源浪费
   解法：TTL Controller + 定期审计 + 自动清理策略

❌ 陷阱2："测试环境与生产环境差异过大"
   症状：测试通过了但上线就挂
   根因：test环境用了mock数据/简化配置
   后果：测试形同虚设
   解法：Staging环境尽量复用生产基础设施和数据结构

❌ 陷阱3："开发环境互相影响"
   症状：Alice的代码把Bob的环境搞崩了
   根因：共享开发环境没有做资源隔离
   后果：团队协作效率下降
   解法：每人独立namespace + ResourceQuota硬限制

❌ 陷阱4："环境状态不可重现"
   症状："我这边好的啊，你那边怎么不行"
   根因：环境配置靠人肉记忆，没有声明式管理
   后果：Debug时间大量浪费
   解法：GitOps + 一切皆代码 + 配置漂移检测

❌ 陷阱5："忽略预发环境的重要性"
   症状：直接从staging上production
   根因：觉得preprod多余浪费资源
   后果：生产数据相关问题无法提前发现
   解法：Preprod是线上发布的最后一道防线，必须有

❌ 陷阱6："环境越多越好"
   症状：为每种场景都建独立环境
   根因：缺乏ROI评估
   后果：维护成本指数增长
   解法：定期评估每个环境的使用率和价值，精简合并低价值环境