第5章：GitOps与自动化部署

什么是GitOps

核心理念

定义：

GitOps：将Git作为单一事实来源（Single Source of Truth），
通过Git管理基础设施和应用配置，实现声明式、自动化部署。

传统部署 vs GitOps

传统部署：

┌─────────────┐
│  开发完成    │
└─────────────┘
      ↓
┌─────────────┐
│  手动构建    │ kubectl apply -f deployment.yaml
└─────────────┘
      ↓
┌─────────────┐
│ Kubernetes  │
└─────────────┘

问题：
 人工操作易出错
 无法追溯变更历史
 配置漂移（Config Drift）
 难以回滚

GitOps流程：

┌─────────────┐
│ Git仓库      │ ← 单一事实来源
│ (YAML配置)  │
└─────────────┘
      ↓ Git push
┌─────────────┐
│ ArgoCD/Flux │ ← 自动监听Git变化
│ (自动同步)  │
└─────────────┘
      ↓ 自动部署
┌─────────────┐
│ Kubernetes  │
└─────────────┘

优势：
 声明式配置
 Git历史记录
 自动同步
 一键回滚

GitOps原则

1. 声明式（Declarative）：
   - 所有配置用声明式方式定义（YAML）
   - 描述期望状态，而非具体步骤

2. 版本控制（Versioned）：
   - 所有配置存储在Git中
   - 利用Git的版本管理能力

3. 自动拉取（Pull）：
   - GitOps Agent自动从Git拉取配置
   - 而非手动推送（Push）

4. 持续协调（Reconciliation）：
   - 持续监控实际状态和期望状态
   - 自动修正差异

ArgoCD实战

1. 安装ArgoCD

安装到Kubernetes：

# 1. 创建命名空间
kubectl create namespace argocd

# 2. 安装ArgoCD
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

# 3. 等待Pod就绪
kubectl wait --for=condition=available --timeout=600s deployment/argocd-server -n argocd

# 4. 获取初始密码
kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d

# 5. 端口转发访问UI
kubectl port-forward svc/argocd-server -n argocd 8080:443

# 访问：https://localhost:8080
# 用户名：admin
# 密码：（上面获取的密码）

安装ArgoCD CLI：

# Linux
curl -sSL -o /usr/local/bin/argocd https://github.com/argoproj/argo-cd/releases/latest/download/argocd-linux-amd64
chmod +x /usr/local/bin/argocd

# macOS
brew install argocd

# 登录
argocd login localhost:8080 --username admin --password <password>

2. 创建应用

准备Git仓库：

myapp-gitops/
├── base/
│   ├── deployment.yaml
│   ├── service.yaml
│   └── kustomization.yaml
└── overlays/
    ├── dev/
    │   ├── kustomization.yaml
    │   └── namespace.yaml
    ├── staging/
    │   └── kustomization.yaml
    └── production/
        └── kustomization.yaml

base/deployment.yaml：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: myapp:latest
        ports:
        - containerPort: 8080

base/kustomization.yaml：

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - deployment.yaml
  - service.yaml

overlays/production/kustomization.yaml：

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: production
bases:
  - ../../base
replicas:
  - name: myapp
    count: 5
images:
  - name: myapp
    newTag: v1.0.0

使用ArgoCD CLI创建应用：

argocd app create myapp \
  --repo https://github.com/example/myapp-gitops.git \
  --path overlays/production \
  --dest-server https://kubernetes.default.svc \
  --dest-namespace production \
  --sync-policy automated \
  --auto-prune \
  --self-heal

使用YAML创建应用：

# argocd-application.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: myapp
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/example/myapp-gitops.git
    targetRevision: main
    path: overlays/production
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true      # 自动删除不再需要的资源
      selfHeal: true   # 自动修复手动修改
      allowEmpty: false
    syncOptions:
      - CreateNamespace=true
    retry:
      limit: 5
      backoff:
        duration: 5s
        factor: 2
        maxDuration: 3m

kubectl apply -f argocd-application.yaml

3. ArgoCD核心功能

同步策略：

syncPolicy:
  automated:
    prune: true        # 自动删除多余资源
    selfHeal: true     # 自动修复配置漂移
  syncOptions:
    - CreateNamespace=true
    - PruneLast=true   # 最后删除资源

健康检查：

ArgoCD自动检查资源健康状态：
- Deployment：Ready Replicas = Desired Replicas
- Service：Endpoints > 0
- Ingress：LoadBalancer IP分配成功

健康状态：
 Healthy：所有资源健康
⚠️ Progressing：部署中
 Degraded：部分资源不健康

差异对比：

# 查看Git配置和集群实际状态的差异
argocd app diff myapp

# 手动同步
argocd app sync myapp

# 查看历史
argocd app history myapp

# 回滚到指定版本
argocd app rollback myapp 3

4. 多环境管理

App of Apps模式：

# apps/applications.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: apps
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/example/gitops-apps.git
    targetRevision: main
    path: apps
  destination:
    server: https://kubernetes.default.svc
    namespace: argocd
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

apps目录结构：

apps/
├── dev-myapp.yaml
├── staging-myapp.yaml
├── production-myapp.yaml
├── dev-database.yaml
└── production-database.yaml

dev-myapp.yaml：

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: myapp-dev
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/example/myapp-gitops.git
    targetRevision: develop
    path: overlays/dev
  destination:
    server: https://kubernetes.default.svc
    namespace: dev
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Flux CD实战

1. 安装Flux CD

# 1. 安装Flux CLI
curl -s https://fluxcd.io/install.sh | sudo bash

# 2. 检查集群兼容性
flux check --pre

# 3. 引导安装（bootstrap）
export GITHUB_TOKEN=<your-token>

flux bootstrap github \
  --owner=<github-username> \
  --repository=fleet-infra \
  --branch=main \
  --path=clusters/production \
  --personal

# Flux会自动：
# - 在GitHub创建fleet-infra仓库
# - 安装Flux组件到Kubernetes
# - 配置自动同步

2. 创建GitRepository

# gitrepository.yaml
apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
  name: myapp
  namespace: flux-system
spec:
  interval: 1m
  url: https://github.com/example/myapp-gitops
  ref:
    branch: main

kubectl apply -f gitrepository.yaml

3. 创建Kustomization

# kustomization.yaml
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: myapp
  namespace: flux-system
spec:
  interval: 5m
  path: ./overlays/production
  prune: true
  sourceRef:
    kind: GitRepository
    name: myapp
  healthChecks:
    - apiVersion: apps/v1
      kind: Deployment
      name: myapp
      namespace: production

kubectl apply -f kustomization.yaml

4. 镜像自动更新

ImageRepository（监听镜像仓库）：

# imagerepository.yaml
apiVersion: image.toolkit.fluxcd.io/v1beta2
kind: ImageRepository
metadata:
  name: myapp
  namespace: flux-system
spec:
  image: harbor.example.com/myproject/myapp
  interval: 1m
  secretRef:
    name: harbor-credentials

ImagePolicy（镜像策略）：

# imagepolicy.yaml
apiVersion: image.toolkit.fluxcd.io/v1beta2
kind: ImagePolicy
metadata:
  name: myapp
  namespace: flux-system
spec:
  imageRepositoryRef:
    name: myapp
  policy:
    semver:
      range: 1.0.x  # 只更新1.0.x版本

ImageUpdateAutomation（自动更新）：

# imageupdateautomation.yaml
apiVersion: image.toolkit.fluxcd.io/v1beta1
kind: ImageUpdateAutomation
metadata:
  name: myapp
  namespace: flux-system
spec:
  interval: 1m
  sourceRef:
    kind: GitRepository
    name: myapp
  git:
    checkout:
      ref:
        branch: main
    commit:
      author:
        email: fluxcd@example.com
        name: Flux CD
      messageTemplate: |
        Update image to {{range .Updated.Images}}{{println .}}{{end}}
  update:
    path: ./overlays/production
    strategy: Setters

在Deployment中使用：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  template:
    spec:
      containers:
      - name: myapp
        image: harbor.example.com/myproject/myapp:v1.0.0 # {"$imagepolicy": "flux-system:myapp"}

工作流程：

1. CI构建新镜像：myapp:v1.0.1
   ↓
2. ImageRepository检测到新镜像
   ↓
3. ImagePolicy验证版本符合策略
   ↓
4. ImageUpdateAutomation更新Git中的YAML
   ↓
5. Flux检测到Git变化
   ↓
6. 自动部署到Kubernetes

多集群管理

1. ArgoCD多集群

添加集群：

# 列出当前上下文
kubectl config get-contexts

# 添加集群到ArgoCD
argocd cluster add <context-name>

# 查看已添加的集群
argocd cluster list

跨集群部署：

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: myapp-prod-us-east
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/example/myapp-gitops.git
    targetRevision: main
    path: overlays/production
  destination:
    server: https://prod-us-east-cluster.example.com  # 目标集群
    namespace: production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

2. ApplicationSet（多集群/多环境）

集群生成器：

# applicationset.yaml
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: myapp-multi-cluster
  namespace: argocd
spec:
  generators:
  - clusters:
      selector:
        matchLabels:
          environment: production
  template:
    metadata:
      name: 'myapp-{{name}}'
    spec:
      project: default
      source:
        repoURL: https://github.com/example/myapp-gitops.git
        targetRevision: main
        path: overlays/production
      destination:
        server: '{{server}}'
        namespace: production
      syncPolicy:
        automated:
          prune: true
          selfHeal: true

Git目录生成器：

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: myapp-environments
  namespace: argocd
spec:
  generators:
  - git:
      repoURL: https://github.com/example/myapp-gitops.git
      revision: main
      directories:
      - path: overlays/*
  template:
    metadata:
      name: 'myapp-{{path.basename}}'
    spec:
      project: default
      source:
        repoURL: https://github.com/example/myapp-gitops.git
        targetRevision: main
        path: '{{path}}'
      destination:
        server: https://kubernetes.default.svc
        namespace: '{{path.basename}}'
      syncPolicy:
        automated:
          prune: true
          selfHeal: true

# 自动为overlays/dev、overlays/staging、overlays/production创建Application

灰度发布

1. Flagger + Istio

安装Flagger：

# 安装Flagger
kubectl apply -k github.com/fluxcd/flagger//kustomize/istio

# 安装Prometheus（用于指标）
kubectl apply -k github.com/fluxcd/flagger//kustomize/prometheus

Canary资源：

# canary.yaml
apiVersion: flagger.app/v1beta1
kind: Canary
metadata:
  name: myapp
  namespace: production
spec:
  # 目标Deployment
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: myapp

  # 服务配置
  service:
    port: 80
    targetPort: 8080
    gateways:
    - myapp-gateway
    hosts:
    - myapp.example.com

  # 分析配置
  analysis:
    interval: 1m          # 每1分钟分析一次
    threshold: 5          # 连续5次成功才继续
    maxWeight: 50         # 最大金丝雀流量50%
    stepWeight: 10        # 每次增加10%流量

    # 指标
    metrics:
    - name: request-success-rate
      thresholdRange:
        min: 99           # 成功率至少99%
      interval: 1m

    - name: request-duration
      thresholdRange:
        max: 500          # P99延迟不超过500ms
      interval: 1m

    # Webhook（可选，用于手动确认）
    webhooks:
    - name: acceptance-test
      type: pre-rollout
      url: http://flagger-loadtester.test/
      timeout: 30s
      metadata:
        type: bash
        cmd: "curl -sd 'test' http://myapp-canary:80/token | grep token"

    - name: load-test
      url: http://flagger-loadtester.test/
      timeout: 5s
      metadata:
        cmd: "hey -z 1m -q 10 -c 2 http://myapp-canary.production:80/"

金丝雀发布流程：

初始状态：
Primary (v1): 100%流量

第1分钟：
Primary (v1): 90%
Canary (v2):  10%
分析指标 →  成功

第2分钟：
Primary (v1): 80%
Canary (v2):  20%
分析指标 →  成功

...

第5分钟：
Primary (v1): 50%
Canary (v2):  50%
分析指标 →  成功

第6分钟：
Canary (v2): 100%
Primary (v1): 删除
发布完成

监控金丝雀发布：

# 查看Canary状态
kubectl get canary -n production

# 查看事件
kubectl describe canary myapp -n production

# 查看Flagger日志
kubectl logs -n istio-system deployment/flagger -f

2. 蓝绿部署

蓝绿部署配置：

apiVersion: flagger.app/v1beta1
kind: Canary
metadata:
  name: myapp
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: myapp
  service:
    port: 80
  analysis:
    interval: 1m
    threshold: 3
    iterations: 10
    match:
      - headers:
          x-canary:
            exact: "insider"  # 只有带特定header的流量才路由到金丝雀

  # 蓝绿部署（镜像流量）
  canaryAnalysis:
    # 先镜像流量到金丝雀（不影响用户）
    mirror: true
    # 分析成功后切换
    iterations: 10

完整DevOps工具链

1. 端到端流水线

┌─────────────────────────────────────────────────────┐
│                    开发阶段                          │
└─────────────────────────────────────────────────────┘
                    ↓ git push
┌─────────────────────────────────────────────────────┐
│              CI阶段（GitLab CI/Jenkins）             │
│  ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐     │
│  │ 编译   │→│ 测试   │→│ 构建   │→│ 推送   │     │
│  │ Build  │ │ Test   │ │ Docker │ │ Harbor │     │
│  └────────┘ └────────┘ └────────┘ └────────┘     │
└─────────────────────────────────────────────────────┘
                    ↓ 更新Git配置
┌─────────────────────────────────────────────────────┐
│              CD阶段（ArgoCD/Flux）                   │
│  ┌────────┐ ┌────────┐ ┌────────┐                │
│  │ 监听   │→│ 同步   │→│ 部署   │                │
│  │ Git    │ │ Config │ │ K8s    │                │
│  └────────┘ └────────┘ └────────┘                │
└─────────────────────────────────────────────────────┘
                    ↓
┌─────────────────────────────────────────────────────┐
│          运维阶段（Prometheus/Grafana）              │
│  ┌────────┐ ┌────────┐ ┌────────┐                │
│  │ 监控   │ │ 告警   │ │ 日志   │                │
│  └────────┘ └────────┘ └────────┘                │
└─────────────────────────────────────────────────────┘

2. 完整示例

项目结构：

myapp/
├── .gitlab-ci.yml           # CI配置
├── Dockerfile               # Docker构建
├── k8s/
│   ├── base/
│   │   ├── deployment.yaml
│   │   ├── service.yaml
│   │   └── kustomization.yaml
│   └── overlays/
│       ├── dev/
│       ├── staging/
│       └── production/
└── argocd/
    ├── application.yaml     # ArgoCD应用
    └── canary.yaml          # Flagger金丝雀

.gitlab-ci.yml：

stages:
  - build
  - test
  - package
  - deploy

variables:
  DOCKER_IMAGE: harbor.example.com/myproject/myapp

build:
  stage: build
  image: golang:1.21
  script:
    - go build -o bin/myapp

test:
  stage: test
  image: golang:1.21
  script:
    - go test -v ./...

docker-build:
  stage: package
  image: docker:latest
  services:
    - docker:dind
  script:
    - docker login $DOCKER_REGISTRY -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD
    - docker build -t ${DOCKER_IMAGE}:${CI_COMMIT_SHORT_SHA} .
    - docker push ${DOCKER_IMAGE}:${CI_COMMIT_SHORT_SHA}
  only:
    - main

update-gitops:
  stage: deploy
  image: alpine/git
  script:
    - git clone https://oauth2:${GITLAB_TOKEN}@gitlab.com/example/myapp-gitops.git
    - cd myapp-gitops
    - sed -i "s|image: .*|image: ${DOCKER_IMAGE}:${CI_COMMIT_SHORT_SHA}|" k8s/overlays/production/deployment.yaml
    - git add .
    - git commit -m "Update image to ${CI_COMMIT_SHORT_SHA}"
    - git push origin main
  only:
    - main

ArgoCD自动同步：

# argocd/application.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: myapp-production
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://gitlab.com/example/myapp-gitops.git
    targetRevision: main
    path: k8s/overlays/production
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

工作流程：

1. 开发提交代码 → GitLab
2. GitLab CI自动触发：
   - 编译、测试
   - 构建Docker镜像
   - 推送到Harbor
   - 更新GitOps仓库的镜像标签
3. ArgoCD检测到GitOps仓库变化
4. ArgoCD自动同步到Kubernetes
5. Flagger金丝雀发布：
   - 10% → 20% → ... → 100%
   - 自动监控指标
   - 失败自动回滚
6. Prometheus + Grafana监控
7. 告警（Slack/Email）

面试问答

什么是GitOps？有什么优势？

答案：

定义：

GitOps：将Git作为单一事实来源，
通过Git管理所有基础设施和应用配置，
实现声明式、自动化部署。

核心原则：

1. 声明式：YAML定义期望状态
2. 版本控制：所有配置存储在Git
3. 自动拉取：GitOps Agent自动同步
4. 持续协调：自动修正配置漂移

优势：

1. 版本管理：
   - 所有变更有Git记录
   - 可追溯、可审计
   - 一键回滚

2. 自动化：
   - Git push即部署
   - 无需kubectl命令
   - 减少人为错误

3. 安全性：
   - 不需要直接访问集群
   - 所有变更通过PR审批
   - 代码审查

4. 灾难恢复：
   - Git是备份
   - 快速重建集群
   - 一致的环境

5. 多环境管理：
   - dev/staging/production
   - 配置一致性
   - 环境差异可见

传统方式 vs GitOps：

维度	传统方式	GitOps
部署方式	kubectl apply	Git push
配置管理	手动/脚本	Git仓库
审计	日志	Git历史
回滚	手动	Git revert
配置漂移	难以检测	自动修复

ArgoCD和Flux CD有什么区别？

答案：

维度	ArgoCD	Flux CD
UI	功能强大	无（第三方）
架构	集中式	分布式（Toolkit）
学习曲线	平缓	陡峭
镜像自动更新	需要插件	内置
多集群	优秀	支持
RBAC	内置	基于K8s RBAC
适用场景	企业级	云原生

详细对比：

ArgoCD：

优势：
 Web UI（可视化管理）
 易于上手
 多集群管理强大
 ApplicationSet（多环境）

劣势：
 镜像自动更新需要插件
 较重（资源占用高）

Flux CD：

优势：
 轻量级（Toolkit架构）
 镜像自动更新（内置）
 GitOps原生（CNCF项目）

劣势：
 无官方UI
 学习曲线陡峭
 配置复杂

选择建议：

选择ArgoCD：
 需要Web UI
 团队初次接触GitOps
 多集群管理
 企业级需求

选择Flux CD：
 云原生团队
 需要镜像自动更新
 资源受限（边缘计算）
 GitOps纯粹主义者

如何实现GitOps的灰度发布？

答案：

方案1：Flagger + Istio：

apiVersion: flagger.app/v1beta1
kind: Canary
metadata:
  name: myapp
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: myapp
  analysis:
    interval: 1m
    threshold: 5
    maxWeight: 50
    stepWeight: 10
    metrics:
    - name: request-success-rate
      thresholdRange:
        min: 99

流程：
1. 部署新版本（金丝雀）
2. 10%流量 → 分析指标 → 成功
3. 20%流量 → 分析指标 → 成功
4. ...
5. 100%流量 → 完成

方案2：ArgoCD Rollouts：

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: myapp
spec:
  replicas: 5
  strategy:
    canary:
      steps:
      - setWeight: 20
      - pause: {duration: 5m}
      - setWeight: 40
      - pause: {duration: 5m}
      - setWeight: 60
      - pause: {duration: 5m}
      - setWeight: 80
      - pause: {duration: 5m}
  template:
    spec:
      containers:
      - name: myapp
        image: myapp:v2.0.0

方案3：GitOps + Feature Flag：

// 使用Feature Flag控制新功能
if featureFlag.IsEnabled("new_payment") {
    // 新版本代码
} else {
    // 旧版本代码
}

// 通过Git更新Feature Flag
// ConfigMap:
// new_payment: "10%"  → 10%用户使用新功能

监控和回滚：

监控指标：
- 成功率 > 99%
- P99延迟 < 500ms
- 错误率 < 1%

自动回滚条件：
- 成功率 < 99%
- 错误率 > 5%
- P99延迟 > 1s

手动回滚：
git revert <commit>
git push

ArgoCD自动同步旧版本

如何处理GitOps的密钥管理？

答案：

方案1：Sealed Secrets：

# 1. 安装Sealed Secrets Controller
kubectl apply -f https://github.com/bitnami-labs/sealed-secrets/releases/download/v0.24.0/controller.yaml

# 2. 安装kubeseal CLI
brew install kubeseal

# 3. 加密Secret
kubectl create secret generic myapp-secret \
  --from-literal=password=supersecret \
  --dry-run=client -o yaml | \
  kubeseal -o yaml > sealed-secret.yaml

# 4. 提交到Git
git add sealed-secret.yaml
git commit -m "Add sealed secret"
git push

# 5. Sealed Secret Controller自动解密
# sealed-secret.yaml → Secret

sealed-secret.yaml：

apiVersion: bitnami.com/v1alpha1
kind: SealedSecret
metadata:
  name: myapp-secret
spec:
  encryptedData:
    password: AgBvXq8z...  # 加密后的数据，可安全存储在Git

方案2：External Secrets Operator：

# externalsecret.yaml
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: myapp-secret
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: vault-backend
    kind: SecretStore
  target:
    name: myapp-secret
  data:
  - secretKey: password
    remoteRef:
      key: secret/data/myapp
      property: password

# 从Vault/AWS Secrets Manager等拉取密钥

方案3：SOPS（Mozilla）：

# 1. 安装SOPS
brew install sops

# 2. 配置加密密钥（使用age或GPG）
age-keygen -o key.txt

# 3. 加密Secret
sops --encrypt --age <public-key> secret.yaml > secret.enc.yaml

# 4. 提交到Git
git add secret.enc.yaml

# 5. ArgoCD自动解密（配置SOPS插件）

选择建议：

Sealed Secrets：
 简单易用
 Kubernetes原生
 无外部依赖

External Secrets：
 企业级密钥管理
 集成Vault/AWS/GCP
 密钥轮换

SOPS：
 灵活（支持多种加密）
 Git friendly
 适合小团队

GitOps如何保证配置一致性？

答案：

配置漂移检测：

1. ArgoCD/Flux持续监控：
   - Git配置（期望状态）
   - Kubernetes实际状态

2. 发现差异时：
   - OutOfSync状态
   - 发送告警

3. 自动修复（Self-Heal）：
   - 自动同步Git配置
   - 恢复期望状态

示例：

场景：手动修改Deployment副本数

kubectl scale deployment myapp --replicas=10

ArgoCD检测到差异：
Git: replicas=3
K8s: replicas=10

自动修复（如果启用selfHeal）：
kubectl scale deployment myapp --replicas=3

结果：恢复到Git配置

防止配置漂移的措施：

1. 启用Self-Heal：

syncPolicy:
  automated:
    selfHeal: true  # 自动修复

2. RBAC限制：

# 限制直接kubectl访问
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: developer
rules:
- apiGroups: [""]
  resources: ["pods", "services"]
  verbs: ["get", "list", "watch"]  # 只读权限

3. Admission Webhook：

# 拒绝未通过GitOps的变更
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: gitops-validator
webhooks:
- name: validate.gitops
  rules:
  - operations: ["CREATE", "UPDATE"]
    apiGroups: ["apps"]
    apiVersions: ["v1"]
    resources: ["deployments"]
  clientConfig:
    service:
      name: gitops-validator
      namespace: argocd

4. 监控告警：

Prometheus告警规则：
- 配置漂移 > 5分钟 → 告警
- Self-Heal失败 → 紧急告警

参考资料

恭喜你完成了《DevOps & CI/CD实践手册》的学习！

现在你已经掌握：

CI/CD流程设计
Jenkins和GitLab CI
Docker容器化
Kubernetes编排
GitOps自动化部署

下一步：

在实际项目中实践GitOps
搭建完整的DevOps工具链
持续优化和改进流程