Kubernetes 持续交付：使用 ArgoCD 和 Flux 的 GitOps 管道

Kubernetes 上的持续交付已经远远超出了简单的 kubectl apply 命令。现代团队正在采用 GitOps，这是一种使用 Git 作为声明性基础设施和应用程序配置的单一事实来源的范例。通过将 GitOps 原则与 ArgoCD 和 Flux CD 等工具相结合，组织可以实现跨集群和环境扩展的可靠、可审核和自动化的部署管道。

本指南涵盖了使用 GitOps 方法在 Kubernetes 上构建生产级持续交付管道的架构、设置和最佳实践。

GitOps 原则

GitOps 基于四个核心原则，从根本上改变了团队管理部署的方式：

• 声明式配置 - 以声明方式描述系统的整个所需状态。对于 Kubernetes，这意味着存储在 Git 中的 YAML 清单、Helm 图表或 Kustomize 覆盖。
• 版本控制 - Git 是唯一的事实来源。每个更改都会通过拉取请求，提供完整的审计跟踪并通过恢复提交来实现轻松回滚。
• 自动对账 - 集群中运行的代理不断将 Git 中的所需状态与集群中的实际状态进行比较，并自动协调任何偏差。
• 持续观察 - 系统持续监控 Git 存储库和集群状态，对差异发出警报并确保集群始终与声明的配置匹配。

这些原则消除了手动部署步骤，减少了人为错误，并提供一致的工作流程，无论集群复杂程度如何。

ArgoCD 架构和设置

ArgoCD 是 Kubernetes 采用最广泛的 GitOps 工具。它提供了强大的 Web UI、CLI 和 API，用于管理跨集群的应用程序部署。

核心组件

ArgoCD 由几个协同工作的关键组件组成：

• API服务器 - 公开 gRPC/REST API 并提供 Web UI。处理身份验证、RBAC 和外部集成。
• 存储库服务器 - 克隆 Git 存储库并从 Helm 图表、Kustomize 或纯 YAML 生成 Kubernetes 清单。
• 应用控制器 - 持续监控正在运行的应用程序并将实时状态与 Git 中的所需状态进行比较。
• 雷迪斯 - 为存储库服务器和应用程序控制器提供缓存。

安装

使用官方清单或 Helm 图表将 ArgoCD 部署到您的集群：

# Create namespace and install ArgoCD
kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

# Or via Helm
helm repo add argo https://argoproj.github.io/argo-helm
helm install argocd argo/argo-cd \
  --namespace argocd \
  --create-namespace \
  --set server.service.type=LoadBalancer

定义应用程序

ArgoCD 使用 Application 自定义资源来定义要部署的内容和位置。这是一个典型的应用程序定义：

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-web-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/myorg/k8s-manifests.git
    targetRevision: main
    path: apps/my-web-app/overlays/production
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true
    retry:
      limit: 5
      backoff:
        duration: 5s
        factor: 2
        maxDuration: 3m

的 syncPolicy.automated 部分启用自动同步。的 prune 选项删除 Git 中不再定义的资源，而 selfHeal 恢复直接对集群进行的手动更改。

Flux CD：另一种方法

Flux CD 采用了与 GitOps 不同的架构方法。 Flux 不是具有 UI 的集中式服务器，而是作为一组 Kubernetes 控制器运行，每个控制器处理特定的问题。

助焊剂成分

• 源控制器 - 管理 Git 存储库、Helm 存储库和 OCI 工件源。
• 定制控制器 - 应用 Kustomize 覆盖和普通 YAML 清单。
• 舵控制器 - 通过以下方式管理 Helm 图表发布 HelmRelease 自定义资源。
• 通知控制器 - 处理入站和出站事件，与 Slack、Teams 和 Webhook 提供商集成。
• 图像自动化控制器 - 扫描容器注册表并在新映像可用时更新清单。

通量自举

# Bootstrap Flux on a cluster with a GitHub repository
flux bootstrap github \
  --owner=myorg \
  --repository=fleet-infra \
  --branch=main \
  --path=clusters/production \
  --personal

# Define a HelmRelease
apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
  name: nginx-ingress
  namespace: ingress-system
spec:
  interval: 5m
  chart:
    spec:
      chart: ingress-nginx
      version: "4.x"
      sourceRef:
        kind: HelmRepository
        name: ingress-nginx
        namespace: flux-system
  values:
    controller:
      replicaCount: 3
      metrics:
        enabled: true

ArgoCD 与 Flux：何时选择

当您需要丰富的 Web UI 来实现可见性、具有细粒度 RBAC 的多租户以及集中式管理平面时，ArgoCD 是理想的选择。 Flux 在喜欢轻量级、基于控制器的架构、需要图像自动化功能或希望与 Kubernetes API 生态系统进行更深入集成的环境中大放异彩。

GitOps 中的 Helm 图表管理

Helm 图表是 Kubernetes 应用程序事实上的打包格式。在 GitOps 工作流程中，跨环境管理 Helm 值需要仔细组织。

# Repository structure for multi-environment Helm management
k8s-manifests/
  base/
    my-app/
      Chart.yaml
      values.yaml          # Default values
      templates/
        deployment.yaml
        service.yaml
        ingress.yaml
  environments/
    dev/
      my-app/
        values.yaml        # Dev overrides
    staging/
      my-app/
        values.yaml        # Staging overrides
    production/
      my-app/
        values.yaml        # Production overrides

ArgoCD 和 Flux 都原生支持 Helm。 ArgoCD 通过其存储库服务器在服务器端渲染图表，而 Flux 直接在其 Helm 控制器中使用 Helm SDK。

部署策略

选择正确的部署策略可以最大限度地降低风险并确保零停机发布。

滚动更新

默认的 Kubernetes 策略。 Pod 逐渐被新版本替换。配置 maxSurge 和 maxUnavailable 来控制推出速度。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 5
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  template:
    spec:
      containers:
        - name: app
          image: myapp:v2.1.0
          readinessProbe:
            httpGet:
              path: /health
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 10

蓝绿部署

运行两个相同的环境（蓝色和绿色）。将新版本部署到非活动环境，验证它，然后切换流量。这通过切换回以前的环境来提供即时回滚。使用服务标签选择器或 Istio 流量管理来实施。

金丝雀部署

逐渐将一小部分流量路由到新版本，随着信心的增长而增加百分比。 Flagger 和 Argo Rollouts 等工具通过基于指标的促销自动化金丝雀分析。

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: my-app
spec:
  replicas: 5
  strategy:
    canary:
      steps:
        - setWeight: 10
        - pause: { duration: 5m }
        - setWeight: 30
        - pause: { duration: 5m }
        - setWeight: 60
        - pause: { duration: 5m }
      canaryService: my-app-canary
      stableService: my-app-stable
      trafficRouting:
        istio:
          virtualService:
            name: my-app-vsvc
            routes:
              - primary

自动回滚

GitOps 使回滚变得简单：只需恢复 Git 提交即可。然而，基于健康检查的自动回滚提供了额外的安全网。

ArgoCD 通过其同步和健康评估系统支持自动回滚。如果应用程序在同步后进入降级状态，ArgoCD 可以自动回滚到最后一个已知的良好状态。

对于更复杂的回滚场景，Argo Rollouts 和 Flagger 可以分析 Prometheus 指标、运行自动化测试并中止显示性能下降的回滚。

秘密管理与密封秘密

在 Git 中存储机密对于 GitOps 来说是一个严峻的挑战。 Sealed Secrets 通过加密只能由目标集群中运行的控制器解密的机密来解决此问题。

# Install Sealed Secrets controller
helm repo add sealed-secrets https://bitnami-labs.github.io/sealed-secrets
helm install sealed-secrets sealed-secrets/sealed-secrets \
  --namespace kube-system

# Encrypt a secret
kubectl create secret generic db-credentials \
  --from-literal=username=admin \
  --from-literal=password=s3cure-p@ss \
  --dry-run=client -o yaml | \
  kubeseal --format yaml > db-credentials-sealed.yaml

由此产生的 SealedSecret 资源可以安全地提交给 Git。只有目标集群中的 Sealed Secrets 控制器持有解密所需的私钥。替代方法包括外部 Secrets Operator（用于从 AWS Secrets Manager、HashiCorp Vault 等提取）和用于文件级加密的 SOPS。

监控部署

部署状态的可见性对于生产 GitOps 管道至关重要。实施多层次监控：

• ArgoCD指标 - ArgoCD 公开 Prometheus 同步状态、运行状况和操作持续时间的指标。创建 Grafana 仪表板来跟踪部署频率和故障率。
• Kubernetes 活动 - 监控 Pod 调度、镜像拉取和就绪探测事件以及早发现问题。
• 应用程序健康检查 - 使用 Lua 脚本在 ArgoCD 中配置自定义运行状况检查，以定义“健康”对您的特定资源意味着什么。
• 警报 - 将 ArgoCD 通知与 Slack、PagerDuty 或电子邮件集成，以针对同步失败、运行状况恶化或漂移检测发出警报。

# ArgoCD Notification ConfigMap
apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-notifications-cm
  namespace: argocd
data:
  trigger.on-sync-failed: |
    - when: app.status.operationState.phase in ['Error', 'Failed']
      send: [slack-notification]
  template.slack-notification: |
    message: |
      Application {{.app.metadata.name}} sync {{.app.status.operationState.phase}}.
      Revision: {{.app.status.sync.revision}}
  service.slack: |
    token: $slack-token
    channel: deployments

多集群交付

随着组织规模的扩大，跨多个集群部署变得必要。 ArgoCD 通过注册外部集群来原生支持多集群管理。 Flux 通过引导工作负载集群的管理集群来实现这一点。

ArgoCD 中的 ApplicationSet 控制器对于多集群场景特别强大。它可以根据集群列表、Git 目录或拉取请求事件动态生成应用程序资源。

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: my-app-set
  namespace: argocd
spec:
  generators:
    - clusters:
        selector:
          matchLabels:
            env: production
  template:
    metadata:
      name: 'my-app-{{name}}'
    spec:
      project: default
      source:
        repoURL: https://github.com/myorg/k8s-manifests.git
        targetRevision: main
        path: 'apps/my-app/overlays/{{metadata.labels.region}}'
      destination:
        server: '{{server}}'
        namespace: my-app

结论

带有 ArgoCD 或 Flux CD 的 GitOps 为 Kubernetes 持续交付提供了坚实的基础。通过将 Git 视为事实来源、自动协调并利用渐进式交付策略，团队可以充满信心地进行部署并快速从故障中恢复。从简单的单集群设置开始，建立 Git 存储库结构，并随着平台的成熟逐步采用金丝雀部署、多集群管理和自动回滚策略等高级模式。

对 GitOps 基础设施的投资通过提高可靠性、更快的事件响应、完整的审计跟踪以及使部署像合并拉取请求一样简单的开发人员体验而获得回报。