Kubernetes GitOps 最佳实践：分支策略，环境隔离与审批流程

1. 前言：为什么需要GitOps

GitOps这个概念最早由Weaveworks提出，现在已经成为了云原生领域的热门实践。简单来说，GitOps就是把Git作为唯一的事实来源(Single Source of Truth)，通过声明式的方式管理基础设施和应用部署。

想象一下，你团队里有10个开发人员，每个人都在自己的电脑上修改Kubernetes配置，然后直接kubectl apply到集群。不出一个月，你的生产环境就会变成一团乱麻。而GitOps就像是一个严格的管家，要求所有变更都必须通过Git提交，经过审核后才能应用到集群。

2. 分支策略：GitOps的核心骨架

2.1 主流分支策略对比

在GitOps实践中，分支策略决定了代码如何流动。以下是三种常见模式：

2.1.1 单分支策略（Trunk-Based）

# 技术栈：ArgoCD + Kubernetes
# 仓库结构示例：
.
├── apps
│   ├── frontend
│   │   ├── base
│   │   └── overlays/production
│   └── backend
│       ├── base
│       └── overlays/staging
└── infrastructure
    ├── monitoring
    └── networking

# 注释：所有环境配置都在同一分支，通过目录结构区分环境
# 优点：简单直接，适合小型团队
# 缺点：缺乏环境隔离，容易误操作

2.1.2 环境分支策略

# 技术栈：FluxCD + Kubernetes
# 分支结构：
- main (基础配置)
- staging (继承main，添加staging特定配置)
- production (继承main，添加production特定配置)

# 注释：每个环境对应一个分支，通过分支保护规则控制权限
# 优点：环境隔离性好
# 缺点：合并冲突可能较多

2.1.3 发布分支策略

# 技术栈：ArgoCD + Helm + Kubernetes
# 分支结构：
- develop (持续集成)
- release-1.0 (准备发布的版本)
- hotfix-1.0.1 (紧急修复)
- main (当前生产版本)

# 注释：适合需要严格版本控制的场景
# 优点：版本控制清晰
# 缺点：流程复杂

2.2 我们的推荐策略：混合模式

经过多年实践，我们发现以下策略在大多数场景下效果最佳：

# 技术栈：ArgoCD + Kustomize + Kubernetes
# 仓库结构示例：
.
├── .argocd
│   └── app-projects.yaml  # ArgoCD项目配置
├── apps
│   ├── frontend
│   │   ├── base           # 通用配置
│   │   ├── staging        # 环境特定配置
│   │   └── production
│   └── backend
│       ├── base
│       ├── staging
│       └── production
└── clusters
    ├── cluster-a
    │   └── applications.yaml  # 集群应用清单
    └── cluster-b
        └── applications.yaml

# 注释：
# 1. 使用目录结构而非分支区分环境
# 2. 每个集群有独立的应用清单
# 3. 通过Kustomize实现配置继承和覆盖

3. 环境隔离：安全与效率的平衡术

3.1 物理隔离 vs 逻辑隔离

3.1.1 物理隔离（独立集群）

# 技术栈：Terraform + Kubernetes
# 生产环境集群定义示例 (terraform/main.tf)：
module "production_cluster" {
  source = "terraform-aws-modules/eks/aws"
  
  cluster_name = "prod-cluster"
  cluster_version = "1.27"
  vpc_id = module.vpc.vpc_id
  
  node_groups = {
    prod-ng = {
      desired_capacity = 5
      max_capacity     = 10
      min_capacity     = 3
      instance_types  = ["m5.2xlarge"]
    }
  }
}

# 注释：
# 1. 生产环境使用更强大的实例类型
# 2. 节点数量配置更保守以保证稳定性
# 3. 完全独立的VPC和网络配置

3.1.2 逻辑隔离（命名空间）

# 技术栈：Kubernetes RBAC + NetworkPolicies
# 生产环境命名空间配置示例 (k8s/production/namespace.yaml)：
apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    env: production
    istio-injection: enabled

---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-egress
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Egress

# 注释：
# 1. 为生产环境启用Istio sidecar注入
# 2. 默认拒绝所有出站流量
# 3. 通过标签明确标识环境

3.2 配置隔离的艺术

# 技术栈：Kustomize + Kubernetes
# 基础配置 (apps/backend/base/deployment.yaml)：
apiVersion: apps/v1
kind: Deployment
metadata:
  name: backend
spec:
  replicas: 2
  template:
    spec:
      containers:
      - name: backend
        image: my-registry/backend:latest
        resources:
          requests:
            cpu: "100m"
            memory: "128Mi"

# 生产环境覆盖 (apps/backend/production/kustomization.yaml)：
resources:
- ../../base
patches:
- target:
    kind: Deployment
    name: backend
  patch: |-
    - op: replace
      path: /spec/replicas
      value: 5
    - op: add
      path: /spec/template/spec/containers/0/resources/limits
      value:
        cpu: "1"
        memory: "1Gi"

# 注释：
# 1. 基础配置定义通用模板
# 2. 生产环境增加副本数和资源限制
# 3. 使用JSON Patch语法精确修改配置

4. 审批流程：安全最后一道防线

4.1 GitHub Pull Request流程示例

# 技术栈：GitHub Actions + ArgoCD
# GitHub工作流文件 (.github/workflows/deploy-prod.yaml)：
name: Deploy to Production

on:
  pull_request:
    branches: [main]
    paths:
      - 'apps/backend/production/**'

jobs:
  verify:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Validate Kustomize
        run: kustomize build apps/backend/production
        
  require-approval:
    needs: verify
    runs-on: ubuntu-latest
    steps:
      - name: Check approvals
        run: |
          if [ "${{ github.event.pull_request.review_comments }}" -lt 2 ]; then
            echo "至少需要2个批准才能合并"
            exit 1
          fi

# 注释：
# 1. 只有修改生产环境配置才会触发此工作流
# 2. 首先验证Kustomize配置是否有效
# 3. 要求至少2个批准才能合并

4.2 ArgoCD Sync Waves与手动批准

# 技术栈：ArgoCD ApplicationSet
# 应用集定义 (clusters/production/applications.yaml)：
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: backend-production
spec:
  project: production
  source:
    repoURL: git@github.com:myorg/gitops-repo.git
    targetRevision: HEAD
    path: apps/backend/production
  syncPolicy:
    automated:
      selfHeal: true
      prune: true
    syncOptions:
    - Validate=true
    - CreateNamespace=true
    - ApplyOutOfSyncOnly=true
    syncWave: 2
    managedNamespaceMetadata:
      labels:
        env: production

# 注释：
# 1. 设置syncWave为2，确保先部署依赖组件
# 2. 启用自动修复和清理
# 3. 为命名空间自动添加标签

5. 实战案例：电商平台GitOps实践

5.1 场景描述

假设我们有一个电商平台，包含以下组件：

前端Web应用
后端API服务
支付服务
Redis缓存
PostgreSQL数据库

5.2 完整配置示例

# 技术栈：ArgoCD + Kustomize + Helm + Kubernetes
# 仓库结构：
.
├── apps
│   ├── frontend
│   │   ├── base
│   │   │   ├── kustomization.yaml
│   │   │   ├── deployment.yaml
│   │   │   └── service.yaml
│   │   ├── staging
│   │   │   └── kustomization.yaml
│   │   └── production
│   │       └── kustomization.yaml
│   ├── backend
│   │   └── ... # 类似结构
│   └── redis
│       └── base
│           └── redis-values.yaml  # Helm values文件
├── infrastructure
│   ├── monitoring
│   │   └── prometheus-operator
│   └── networking
│       └── istio
└── clusters
    ├── staging
    │   └── applications.yaml
    └── production
        └── applications.yaml

# 生产环境Redis配置示例 (apps/redis/base/redis-values.yaml)：
global:
  redis:
    password: "secret"
architecture: replication
replica:
  replicaCount: 3
  persistence:
    enabled: true
    size: 100Gi
resources:
  requests:
    cpu: 2
    memory: 8Gi
  limits:
    cpu: 4
    memory: 16Gi

# 注释：
# 1. 使用Helm管理复杂应用如Redis
# 2. 生产环境配置持久化和资源限制
# 3. 密码通过Secret管理（实际文件中应引用Secret）

6. 常见陷阱与解决方案

6.1 配置漂移问题

问题描述：有人直接通过kubectl修改了生产环境，导致Git仓库与实际状态不一致。

解决方案：

# 技术栈：ArgoCD
# ArgoCD项目配置 (.argocd/app-projects.yaml)：
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: production
spec:
  destinations:
  - namespace: production
    server: https://kubernetes.default.svc
  clusterResourceWhitelist:
  - group: '*'
    kind: '*'
  syncWindows:
  - kind: deny
    schedule: '* * * * *'
    duration: 24h
    manualSync: true
  roles:
  - name: admin
    policies:
    - p, proj:production:admin, applications, *, production/*, allow
    - p, proj:production:admin, exec, *, production/*, allow

# 注释：
# 1. 设置同步窗口，默认阻止自动同步
# 2. 要求手动同步生产环境
# 3. 细粒度的RBAC控制

6.2 密钥管理问题

问题描述：如何安全地管理数据库密码等敏感信息？