GitOps 部署架构

Architecture

GitOps 部署架构图，展示开发者 Git 工作流、CI/CD 管道构建和推送容器镜像、ArgoCD 或 Flux 检测 Git 清单变更、漂移检测、自动集群同步和向 Kubernetes 的滚动更新部署。该模板模拟 GitOps 范式，Git 是应用代码和基础设施状态的唯一真实来源，实现声明式、可审计和可重现的部署。对于采用 GitOps 实践进行 Kubernetes 部署的团队至关重要。

下载 .fz 文件

完整 FlowZap 代码

Developer { # Developer
n1: circle label:"Code Change"
n2: rectangle label:"Git Push to Main"
n3: rectangle label:"Open Pull Request"
n4: rectangle label:"Merge After Review"
n1.handle(right) -> n2.handle(left)
n2.handle(right) -> n3.handle(left) [label="Feature Branch"]
n3.handle(right) -> n4.handle(left) [label="Approved"]
n4.handle(bottom) -> CICD.n5.handle(top) [label="Trigger"]
}
CICD { # CI/CD Pipeline
n5: rectangle label:"Run Tests and Lint"
n6: rectangle label:"Build Container Image"
n7: rectangle label:"Push to Registry"
n8: rectangle label:"Update Manifest in Git"
n5.handle(right) -> n6.handle(left) [label="Tests Pass"]
n6.handle(right) -> n7.handle(left) [label="Tag: sha-abc123"]
n7.handle(right) -> n8.handle(left) [label="Update Image Tag"]
n8.handle(bottom) -> GitOps.n9.handle(top) [label="Commit Manifest"]
}
GitOps { # GitOps Controller (ArgoCD/Flux)
n9: rectangle label:"Detect Git Diff"
n10: rectangle label:"Compare Desired vs Live"
n11: diamond label:"Drift Detected?"
n12: rectangle label:"Sync to Cluster"
n13: rectangle label:"State Already Synced"
n14: rectangle label:"Health Check"
n9.handle(right) -> n10.handle(left) [label="Poll/Webhook"]
n10.handle(right) -> n11.handle(left)
n11.handle(right) -> n12.handle(left) [label="Yes"]
n11.handle(bottom) -> n13.handle(top) [label="No"]
n12.handle(right) -> n14.handle(left) [label="Apply"]
n14.handle(bottom) -> Cluster.n15.handle(top) [label="Deploy"]
}
Cluster { # Kubernetes Cluster
n15: rectangle label:"Rolling Update Deployment"
n16: rectangle label:"New Pods Created"
n17: rectangle label:"Old Pods Terminated"
n18: rectangle label:"Service Routes Traffic"
n19: circle label:"Deployment Complete"
n15.handle(right) -> n16.handle(left) [label="Scale Up"]
n16.handle(right) -> n17.handle(left) [label="Healthy"]
n17.handle(right) -> n18.handle(left) [label="Cutover"]
n18.handle(right) -> n19.handle(left)
}

为什么需要这个工作流？

Manual deployments and imperative scripts are error-prone, hard to audit, and impossible to reproduce. GitOps makes Git the single source of truth for infrastructure state, enabling declarative deployments where every change is version-controlled, peer-reviewed, and automatically applied to the cluster.

工作原理

Step 1: A developer pushes code changes and opens a pull request.
Step 2: The CI/CD pipeline runs tests, builds a container image, and pushes it to the registry.
Step 3: The pipeline updates the Kubernetes manifest in Git with the new image tag.
Step 4: ArgoCD or Flux detects the Git change and compares desired state with live cluster state.
Step 5: If drift is detected, the controller automatically syncs the cluster to match Git.
Step 6: Rolling updates deploy new pods, health checks verify them, and old pods are terminated.

替代方案

Imperative CI/CD pipelines (Jenkins) push changes directly to clusters without drift detection. Helm charts provide templating but not continuous reconciliation. This template shows the full GitOps workflow with ArgoCD/Flux.

Key Facts

Template Name	GitOps 部署架构
Category	Architecture
Steps	6 workflow steps
Format	FlowZap Code (.fz file)