GitOps 实战：基于 Argo CD 的 Kubernetes 应用版本回滚

flytalei2026-10-22 9:51

文章目录

  • [GitOps 实战：基于 Argo CD 的 Kubernetes 应用版本回滚](#GitOps 实战：基于 Argo CD 的 Kubernetes 应用版本回滚)
    • 一、实验背景
      • [1.1 为什么要进行这次实践？](#1.1 为什么要进行这次实践？)
      • [1.2 本次实验要解决的问题](#1.2 本次实验要解决的问题)
    • 二、实验环境与架构
      • [2.1 实验环境](#2.1 实验环境)
      • [2.2 GitOps 工作流程](#2.2 GitOps 工作流程)
      • [2.3 关键概念](#2.3 关键概念)
    • [三、第一阶段：检查 Git 配置与历史版本](#三、第一阶段：检查 Git 配置与历史版本)
      • [3.1 克隆实验仓库](#3.1 克隆实验仓库)
      • [3.2 查看 Deployment 文件的提交历史](#3.2 查看 Deployment 文件的提交历史)
      • [3.3 查看当前 Deployment YAML](#3.3 查看当前 Deployment YAML)
      • [3.4 对比当前版本和之前版本](#3.4 对比当前版本和之前版本)
    • [四、第二阶段：检查 Kubernetes 当前状态](#四、第二阶段：检查 Kubernetes 当前状态)
      • [4.1 查看 Argo CD Application](#4.1 查看 Argo CD Application)
      • [4.2 查看 Deployment 当前镜像](#4.2 查看 Deployment 当前镜像)
      • [4.3 查看当前 Pod](#4.3 查看当前 Pod)
      • [4.4 检查目标镜像是否存在](#4.4 检查目标镜像是否存在)
      • [4.5 检查 Argo CD 的追踪配置](#4.5 检查 Argo CD 的追踪配置)
    • [五、第三阶段：修改 Git 中的期望状态](#五、第三阶段：修改 Git 中的期望状态)
      • [5.1 确认工作区干净](#5.1 确认工作区干净)
      • [5.2 修改 Deployment 镜像](#5.2 修改 Deployment 镜像)
      • [5.3 检查配置差异](#5.3 检查配置差异)
    • [六、第四阶段：创建 Git 回滚提交](#六、第四阶段：创建 Git 回滚提交)
      • [6.1 提交变更](#6.1 提交变更)
      • [6.2 为什么使用新的回滚提交？](#6.2 为什么使用新的回滚提交？)
      • [6.3 推送前检查远程分支](#6.3 推送前检查远程分支)
      • [6.4 推送回滚提交](#6.4 推送回滚提交)
    • [七、第五阶段：通过 Argo CD 同步回滚配置](#七、第五阶段：通过 Argo CD 同步回滚配置)
      • [7.1 为什么还需要手动同步？](#7.1 为什么还需要手动同步？)
      • [7.2 执行同步](#7.2 执行同步)
      • [7.3 观察 Kubernetes 滚动更新](#7.3 观察 Kubernetes 滚动更新)
    • 八、第六阶段：验证回滚结果
      • [8.1 验证 Deployment 镜像](#8.1 验证 Deployment 镜像)
      • [8.2 验证 Deployment 滚动更新](#8.2 验证 Deployment 滚动更新)
      • [8.3 验证 Pod 状态](#8.3 验证 Pod 状态)
      • [8.4 验证 Argo CD 同步与健康状态](#8.4 验证 Argo CD 同步与健康状态)
      • [8.5 验证结果汇总](#8.5 验证结果汇总)
    • 九、故障排查与风险控制
      • [9.1 如果 Argo CD 一直显示 OutOfSync](#9.1 如果 Argo CD 一直显示 OutOfSync)
      • [9.2 如果 Pod 出现 ImagePullBackOff](#9.2 如果 Pod 出现 ImagePullBackOff)
      • [9.3 为什么不直接使用 kubectl set image 回滚？](#9.3 为什么不直接使用 kubectl set image 回滚？)
    • [十、GitOps 回滚与 Kubernetes 原生回滚的区别](#十、GitOps 回滚与 Kubernetes 原生回滚的区别)
    • 十一、面试复盘
      • [11.1 面试官可能会问：你实际做过 GitOps 回滚吗？](#11.1 面试官可能会问：你实际做过 GitOps 回滚吗？)
      • [11.2 面试官可能会问：为什么不直接 kubectl set image？](#11.2 面试官可能会问：为什么不直接 kubectl set image？)
      • [11.3 面试官可能会问：如何确认回滚真正成功？](#11.3 面试官可能会问：如何确认回滚真正成功？)
    • 十二、下一阶段实验计划
      • [实验 A：错误镜像发布](#实验 A：错误镜像发布)
      • [实验 B：通过 GitOps 恢复](#实验 B：通过 GitOps 恢复)
      • [实验 C：形成可复用的故障处理案例](#实验 C：形成可复用的故障处理案例)
    • 十三、实验总结

GitOps 实战：基于 Argo CD 的 Kubernetes 应用版本回滚

项目：逐浪笔记（Spring Boot + Vue + DevOps）

实验主题：GitOps 发布管理与应用版本回滚

技术栈：Git、Gitee、Argo CD、Kubernetes、K3s、Docker Registry、Nginx

实验状态：成功完成 GitOps 配置回滚及 Kubernetes Deployment 滚动更新

回滚记录：ab8e7b0

实验日期：2026-10-21

一、实验背景

1.1 为什么要进行这次实践？

在 DevOps 持续交付链路中，应用部署并不意味着交付工作的结束。新版本发布后，仍然可能出现程序异常、镜像错误、配置不兼容或服务不可用等问题。

如果线上版本出现故障，运维人员需要快速定位当前运行版本，并将应用恢复到已知可用的版本。

在传统部署方式中，运维人员可能直接修改服务器上的配置，或者使用 Kubernetes 命令临时修改 Deployment。这些方式可以在特定情况下解决问题，但如果没有同步更新版本管理系统，就容易导致 Git 中的期望配置与集群实际配置不一致。

GitOps 的核心思路是将 Git 仓库作为应用期望状态的管理来源，由 Argo CD 持续比较 Git 中声明的资源与 Kubernetes 集群中的实际资源，并根据配置的同步策略完成部署。

因此，本次实践的目标不是简单地把 Nginx 镜像从一个标签切换到另一个标签，而是完整验证以下链路：

Git 版本定位 → 修改期望配置 → 创建回滚提交 → 推送 Gitee → Argo CD 同步 → Kubernetes 滚动更新 → 验证恢复结果。

1.2 本次实验要解决的问题

假设 Nginx Demo 当前运行的是 build-4，由于新版本可能存在问题，需要恢复到之前的 build-3。

本次实验通过 GitOps 方式完成回滚，并验证以下内容：

  1. 能否通过 Git 历史找到之前的配置版本。
  2. 能否确认回滚目标镜像仍然存在。
  3. 能否通过新的 Git 提交记录回滚操作。
  4. Argo CD 能否读取 Git 中的新配置并同步集群。
  5. Kubernetes 是否成功完成 Deployment 滚动更新。
  6. 最终镜像、Pod 状态和 Argo CD 状态是否符合预期。

注意：本次属于主动执行的版本恢复演练，并不是实际生产故障。后续将继续模拟错误镜像发布，练习故障发现与恢复。

二、实验环境与架构

2.1 实验环境

项目 实际配置
Git 仓库 https://gitee.com/flytalei/my-blog.git
Git 分支 master
Argo CD Application nginx-gitops-lab
Kubernetes 发行版 K3s
应用命名空间 argocd-lab
GitOps 配置目录 gitops/labs/nginx-demo
Deployment nginx-demo
容器镜像仓库 127.0.0.1:5000
回滚前镜像 nginx-gitops-lab:build-4
回滚目标镜像 nginx-gitops-lab:build-3

本次操作在独立的 argocd-lab 命名空间中进行，目标是 Nginx Demo，不直接修改逐浪笔记的 Spring Boot 后端、Vue 前端或 MySQL 资源。

2.2 GitOps 工作流程

text 复制代码 
                    Gitee
             my-blog / master
                       |
                       v
          gitops/labs/nginx-demo/
                deployment.yaml
                       |
                       v
                   Argo CD
              Application:
              nginx-gitops-lab
                       |
                       v
               Kubernetes / K3s
                 argocd-lab
                       |
                       v
                 Deployment
                  nginx-demo
                       |
                       v
                 ReplicaSet
                       |
                       v
                  Nginx Pod

本次实验中，Git 仓库负责保存 Deployment 的期望配置，Argo CD 负责将该配置同步到 Kubernetes，Kubernetes Deployment 控制器负责根据 Pod 模板的变化完成滚动更新。

2.3 关键概念

Git： 保存配置文件及每次变更的历史记录。

Gitee： 远程 Git 仓库，保存实验使用的共享版本。

Argo CD Application： 定义需要从哪个仓库、哪个分支和哪个目录读取配置，以及将资源部署到哪个集群和命名空间。

Deployment： 管理应用副本，并在 Pod 模板发生变化时执行滚动更新。

ReplicaSet： 由 Deployment 管理，负责维持指定数量的 Pod 副本。

Pod： 实际运行 Nginx 容器的 Kubernetes 工作负载实例。

三、第一阶段：检查 Git 配置与历史版本

3.1 克隆实验仓库

为了避免直接在原有工作目录中操作，本次在服务器的 /tmp 目录下单独克隆仓库。

执行命令：

bash 复制代码 
cd /tmp

git clone https://gitee.com/flytalei/my-blog.git \
  gitops-rollback-check

cd /tmp/gitops-rollback-check

说明：

  • /tmp/gitops-rollback-check 是本次实验的独立工作目录。
  • 克隆操作不会直接修改服务器上的 Kubernetes 资源。
  • 后续 Git 操作需要注意本地分支与远程分支的关系。

如果使用 HTTPS 访问 Gitee 时要求输入凭据，应使用账户允许的 Git 认证方式，不要将密码或私人访问令牌写进实验文档。

3.2 查看 Deployment 文件的提交历史

执行：

bash 复制代码 
git log -5 --oneline -- \
  gitops/labs/nginx-demo/deployment.yaml

本次实际检查到的历史记录：

text 复制代码 
48bed57 ci: update nginx image to build-4
bcb2733 feat: deploy custom nginx image through Argo CD
5516877 Revert "test: simulate nginx image pull failure"
fab16cc test: simulate nginx image pull failure
debd40f Revert "feat: scale nginx GitOps lab to two replicas"

从提交记录可以看出，仓库曾经包含镜像升级、镜像拉取失败模拟和副本数调整等变更。

其中，48bed57 是当前使用 build-4 的提交，bcb2733 中的 Deployment 配置则使用 build-3。

需要注意：提交信息可以帮助理解变更意图，但最终仍然应该通过实际配置文件确认回滚目标，不能只根据提交名称判断。

3.3 查看当前 Deployment YAML

执行：

bash 复制代码 
cat gitops/labs/nginx-demo/deployment.yaml

本次实际配置的核心内容：

yaml 复制代码 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-demo
  namespace: argocd-lab
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx-demo
  template:
    metadata:
      labels:
        app: nginx-demo
    spec:
      containers:
        - name: nginx
          image: 127.0.0.1:5000/nginx-gitops-lab:build-4
          ports:
            - containerPort: 80

重点检查：

  • Deployment 名称为 nginx-demo。
  • 命名空间为 argocd-lab。
  • 副本数为 1。
  • 当前镜像标签为 build-4。
  • 容器监听端口为 80。

3.4 对比当前版本和之前版本

执行：

bash 复制代码 
git show \
  48bed57:gitops/labs/nginx-demo/deployment.yaml

git show \
  bcb2733:gitops/labs/nginx-demo/deployment.yaml

对比结果：

配置项 当前版本 48bed57 之前版本 bcb2733
镜像标签 build-4 build-3
Deployment 名称 nginx-demo nginx-demo
副本数 1 1
命名空间 argocd-lab argocd-lab

结论：本次回滚只需要恢复镜像标签，不需要回退整个 Git 提交，也不需要重新创建 Kubernetes 资源。

截图 1：Git 历史与配置版本对比

建议截图内容：

  1. git log -5 --oneline 的输出。
  2. git show 48bed57:... 中的 build-4 配置。
  3. git show bcb2733:... 中的 build-3 配置。

截图说明：通过 Git 历史定位目标版本，并比较配置差异，明确回滚范围。

四、第二阶段：检查 Kubernetes 当前状态

4.1 查看 Argo CD Application

执行：

bash 复制代码 
sudo k3s kubectl get applications.argoproj.io -A

本次实际结果：

text 复制代码 
NAMESPACE   NAME               SYNC STATUS   HEALTH STATUS
argocd      nginx-gitops-lab   Synced        Healthy

说明：

  • Synced 表示 Argo CD 当前比较的期望配置与集群配置一致。
  • Healthy 表示 Argo CD 评估的应用资源处于健康状态。

这说明回滚前，Argo CD 管理的应用状态正常，当前不存在已检测到的配置漂移。

4.2 查看 Deployment 当前镜像

执行：

bash 复制代码 
sudo k3s kubectl -n argocd-lab \
  get deployment nginx-demo \
  -o jsonpath='{.spec.template.spec.containers[0].image}{"\n"}'

实际结果：

text 复制代码 
127.0.0.1:5000/nginx-gitops-lab:build-4

这一步用于确认 Kubernetes 中 Deployment 的 Pod 模板当前声明使用的镜像。

需要注意，该命令查询的是 Deployment 配置，并不单独证明容器已经成功启动。

4.3 查看当前 Pod

执行：

bash 复制代码 
sudo k3s kubectl -n argocd-lab get pods -o wide

本次回滚前的结果：

text 复制代码 
NAME                          READY   STATUS    RESTARTS
nginx-demo-59fdd99b9b-xqxtm   1/1     Running   0

说明回滚前的 Nginx Pod 正常运行，没有发生容器重启。

4.4 检查目标镜像是否存在

执行：

bash 复制代码 
curl -sS --max-time 5 \
  http://127.0.0.1:5000/v2/nginx-gitops-lab/tags/list

实际结果：

json 复制代码 
{
  "name": "nginx-gitops-lab",
  "tags": ["build-3", "build-4"]
}

这说明本次查询的镜像仓库中存在 build-3 和 build-4 两个标签。

镜像存在是回滚前的重要检查条件，可以减少因目标标签不存在导致镜像拉取失败的风险。

但仓库中存在标签，并不绝对保证 Kubernetes 节点一定能够成功拉取镜像；镜像仓库网络、节点访问方式和容器运行时配置仍可能影响实际部署。

4.5 检查 Argo CD 的追踪配置

执行：

bash 复制代码 
sudo k3s kubectl get applications.argoproj.io \
  -A -o yaml

本次 Application 的关键配置：

yaml 复制代码 
spec:
  destination:
    namespace: argocd-lab
    server: https://kubernetes.default.svc
  source:
    path: gitops/labs/nginx-demo
    repoURL: git@gitee.com:flytalei/my-blog.git
    targetRevision: master
  syncPolicy:
    syncOptions:
      - CreateNamespace=true

通过配置确认：

  • 仓库地址：git@gitee.com:flytalei/my-blog.git
  • 目标分支：master
  • 配置路径：gitops/labs/nginx-demo
  • 目标命名空间：argocd-lab
  • 未配置 syncPolicy.automated 自动同步策略。

因此，推送回滚提交之后，需要在 Argo CD 中刷新状态，并手动执行同步。

截图 2：回滚前的 Kubernetes 状态

建议截图内容：

  1. Application 的 Synced / Healthy 状态。
  2. Deployment 当前镜像为 build-4。
  3. Nginx Pod 的 Running 状态。
  4. 镜像仓库中存在 build-3 和 build-4 的结果。

截图说明：回滚前先确认应用状态、当前版本及回滚目标，避免在不了解现状的情况下直接操作。

截图 3：Argo CD Application 配置

建议截图内容：

  1. Argo CD UI 中的 nginx-gitops-lab 应用详情。
  2. Git 仓库、目标分支及配置路径。
  3. 应用同步策略和当前状态。

截图说明：明确 Argo CD 的配置来源和同步方式，确定后续变更将影响哪个应用。

五、第三阶段：修改 Git 中的期望状态

5.1 确认工作区干净

进入实验目录：

bash 复制代码 
cd /tmp/gitops-rollback-check

git status --short --branch

本次执行时的结果：

text 复制代码 
## master...origin/master

说明工作区原本干净，本地 master 与远程 origin/master 一致。

在修改前检查 Git 状态，可以避免把其他未提交的工作意外混入回滚提交。

5.2 修改 Deployment 镜像

执行：

bash 复制代码 
sed -i \
  's#nginx-gitops-lab:build-4#nginx-gitops-lab:build-3#' \
  gitops/labs/nginx-demo/deployment.yaml

这里使用 sed 替换镜像标签，只修改 Deployment 文件中的目标字符串。

随后检查文件：

bash 复制代码 
grep -n 'image:' \
  gitops/labs/nginx-demo/deployment.yaml

预期结果：

text 复制代码 
image: 127.0.0.1:5000/nginx-gitops-lab:build-3

5.3 检查配置差异

执行：

bash 复制代码 
git diff --check

git diff -- \
  gitops/labs/nginx-demo/deployment.yaml

本次实际差异：

diff 复制代码 
-          image: 127.0.0.1:5000/nginx-gitops-lab:build-4
+          image: 127.0.0.1:5000/nginx-gitops-lab:build-3

git diff --check 没有报告问题，说明没有检测到常见的空白字符错误。

更重要的是，差异只涉及镜像标签，没有修改副本数、Service、命名空间或其他配置。

这体现了生产运维中的一个重要原则：故障恢复时尽可能缩小变更范围，降低引入新问题的风险。

截图 4：修改前后的 YAML 差异

建议截图内容：

  1. git diff 的完整输出。
  2. build-4 到 build-3 的镜像标签变化。
  3. git diff --check 的检查结果。

截图说明：通过代码差异确认此次回滚只修改了目标镜像，确保变更可控。

六、第四阶段：创建 Git 回滚提交

6.1 提交变更

执行：

bash 复制代码 
git add gitops/labs/nginx-demo/deployment.yaml

git commit \
  -m "rollback: restore nginx demo image to build-3"

本次最终生成的提交为：

text 复制代码 
ab8e7b0 rollback: restore nginx demo image to build-3

提交信息使用英文，明确描述了回滚动作和目标镜像版本。

6.2 为什么使用新的回滚提交？

本次没有使用 git reset --hard 将分支强行退回历史提交，而是创建了一个新的提交。

原因如下：

  1. 保留原有提交历史。
  2. 明确记录回滚发生的时间和原因。
  3. 便于代码审查与后续审计。
  4. 方便追踪回滚前后版本。
  5. 不需要改写远程分支历史。

这里需要区分两种概念：

  • Git 中的回滚提交：通过新的配置变更恢复旧版本。
  • git revert 命令：根据指定提交生成反向变更。

本次使用的是直接恢复镜像配置并创建新的回滚提交，并没有执行 git revert 命令。

6.3 推送前检查远程分支

执行：

bash 复制代码 
git fetch origin

git log --oneline HEAD..origin/master

git status -sb

本次结果：

text 复制代码 
## master...origin/master [ahead 1]

同时，git log HEAD..origin/master 没有输出。

这说明本地分支领先远程一个提交，没有发现远程分支存在本地尚未包含的提交。

这一步可以降低推送时发生非快进冲突的风险，但如果多人同时操作，推送前仍然应检查最新远程状态。

6.4 推送回滚提交

执行：

bash 复制代码 
git push origin master

推送完成后执行：

bash 复制代码 
git fetch origin

git log -1 --oneline origin/master

本次确认结果：

text 复制代码 
ab8e7b0 (HEAD -> master, origin/master, origin/HEAD) rollback: restore nginx demo image to build-3

这表明本地 master 与远程 origin/master 均已指向回滚提交。

需要注意：此时只能确认 Git 变更已经推送成功，不能仅凭该结果断言 Kubernetes 已完成回滚。

另外，本次直接更新了远程 master。在多人协作或生产环境中，应遵循团队的分支保护、代码评审和发布审批流程，避免未经审核的变更影响其他 GitOps 应用。

截图 5：Git 回滚提交与远程推送

建议截图内容：

  1. git commit 的提交结果。
  2. git status -sb 显示领先远程一个提交。
  3. git push origin master 的成功输出。
  4. git log -1 --oneline origin/master 显示 ab8e7b0。

截图说明：证明回滚配置已形成独立 Git 提交，并已进入 Argo CD 追踪的远程分支。

七、第五阶段：通过 Argo CD 同步回滚配置

7.1 为什么还需要手动同步？

本次 Application 配置没有启用自动同步：

yaml 复制代码 
syncPolicy:
  syncOptions:
    - CreateNamespace=true

其中没有 automated 配置。

因此，推送 Git 提交后，需要让 Argo CD 刷新仓库状态，并在 UI 中手动执行 Sync。

Git 提交只是更新期望配置；Argo CD 同步才会将该配置应用到 Kubernetes。

7.2 执行同步

在 Argo CD UI 中：

  1. 打开 nginx-gitops-lab Application。
  2. 点击 Refresh，刷新仓库状态。
  3. 检查变更内容，确认镜像由 build-4 变为 build-3。
  4. 点击 Sync。
  5. 确认执行同步。
  6. 等待 Deployment 更新完成。

本次同步后，Argo CD 将新的 Deployment 配置应用到了 argocd-lab 命名空间。

7.3 观察 Kubernetes 滚动更新

Deployment 的 Pod 模板发生变化后，Kubernetes 会根据 Deployment 的更新策略创建新的 ReplicaSet，并逐步替换旧 Pod。

本次回滚前的 Pod：

text 复制代码 
nginx-demo-59fdd99b9b-xqxtm

回滚后的 Pod：

text 复制代码 
nginx-demo-5864cf89f-ppgbh

Pod 名称发生变化，符合 Deployment 因模板更新而创建新 Pod 的预期。

截图 6：Argo CD 同步前后的状态

建议截图内容：

  1. 刷新后显示的镜像差异。
  2. 点击 Sync 的操作界面。
  3. 同步完成后的资源树。
  4. Application 的 Synced 和 Healthy 状态。

截图说明：展示 Argo CD 从 Git 读取回滚配置，并将其应用到 Kubernetes 的过程。

八、第六阶段：验证回滚结果

回滚完成后，需要从多个层面进行验证，不能只依赖 Argo CD 页面上的绿色状态。

8.1 验证 Deployment 镜像

执行：

bash 复制代码 
sudo k3s kubectl -n argocd-lab \
  get deployment nginx-demo \
  -o jsonpath='{.spec.template.spec.containers[0].image}{"\n"}'

实际结果：

text 复制代码 
127.0.0.1:5000/nginx-gitops-lab:build-3

验证通过：Deployment 的 Pod 模板已声明使用 build-3。

8.2 验证 Deployment 滚动更新

执行：

bash 复制代码 
sudo k3s kubectl -n argocd-lab \
  rollout status deployment/nginx-demo \
  --timeout=120s

本次实际结果：

text 复制代码 
deployment "nginx-demo" successfully rolled out

验证通过：Deployment 已成功完成滚动更新。

8.3 验证 Pod 状态

执行：

bash 复制代码 
sudo k3s kubectl -n argocd-lab get pods -o wide

本次实际结果：

text 复制代码 
NAME                         READY   STATUS    RESTARTS
nginx-demo-5864cf89f-ppgbh   1/1     Running   0

验证通过：

  • Pod 已经启动。
  • Ready 状态为 1/1。
  • Pod 状态为 Running。
  • 容器重启次数为 0。

8.4 验证 Argo CD 同步与健康状态

执行：

bash 复制代码 
sudo k3s kubectl get application nginx-gitops-lab \
  -n argocd \
  -o jsonpath='{.status.sync.status}{" | "}{.status.health.status}{"\n"}'

本次实际结果：

text 复制代码 
Synced | Healthy

验证通过：Argo CD 显示 Git 与集群状态一致，应用资源健康。

8.5 验证结果汇总

验证项 实际结果 结论
Git 回滚提交 ab8e7b0 通过
远程分支 master 已包含回滚提交 通过
Deployment 镜像 build-3 通过
Deployment 滚动更新 successfully rolled out 通过
Pod 状态 1/1 Running 通过
容器重启次数 0 通过
Argo CD 同步状态 Synced 通过
Argo CD 健康状态 Healthy 通过
HTTP 业务访问 尚未单独验证 待验证

本次实验已经证明 Deployment 成功回滚、Pod 正常运行且 Argo CD 状态正常。若要进一步确认服务端到端可用，还需要通过 Service 或实际访问入口进行 HTTP 验证。

截图 7：最终回滚验证

建议截图内容：

  1. Deployment 当前镜像为 build-3。
  2. rollout status 成功输出。
  3. Pod 状态为 1/1 Running。
  4. Argo CD 状态为 Synced | Healthy。

截图说明：从 Kubernetes 和 Argo CD 两个层面确认回滚结果，形成完整的验证证据。

九、故障排查与风险控制

9.1 如果 Argo CD 一直显示 OutOfSync

排查顺序：

  1. 确认回滚提交已经推送到远程仓库。
  2. 确认 Application 追踪的分支为 master。
  3. 确认配置路径为 gitops/labs/nginx-demo。
  4. 点击 Refresh，刷新仓库状态。
  5. 检查 YAML 是否存在语法错误。
  6. 检查是否存在其他控制器或人工修改导致的配置差异。

不要在未确认原因前直接反复执行 Sync。

9.2 如果 Pod 出现 ImagePullBackOff

重点检查：

  1. 镜像标签是否存在。
  2. Kubernetes 节点是否能够访问镜像仓库。
  3. 容器运行时使用的镜像仓库地址是否正确。
  4. 是否需要配置镜像拉取凭据。
  5. Pod Events 中记录的实际错误原因。

特别注意：127.0.0.1 指的是访问该地址的当前网络命名空间自身。对于本地镜像仓库，必须确认 Kubernetes 节点上的容器运行时确实能够通过这个地址访问仓库。本次已经成功运行 build-3，证明本次实验环境下该镜像配置可以正常工作，但不代表这个地址适合所有 Kubernetes 集群。

9.3 为什么不直接使用 kubectl set image 回滚？

例如：

bash 复制代码 
kubectl set image deployment/nginx-demo \
  nginx=127.0.0.1:5000/nginx-gitops-lab:build-3 \
  -n argocd-lab

这条命令可以直接修改 Kubernetes Deployment，但在 GitOps 管理下，如果 Git 仍然声明 build-4，Argo CD 可能再次将集群恢复到 Git 中的配置。

因此，本次选择修改 Git 配置并通过 Argo CD 同步，避免 Git 与集群之间出现持续漂移。

十、GitOps 回滚与 Kubernetes 原生回滚的区别

对比项 GitOps 回滚 kubectl rollout undo
回滚依据 Git 中恢复后的期望配置 Deployment 历史修订版本
主要操作对象 Git 配置及其同步流程 Kubernetes Deployment
是否保留 Git 变更记录 是 不会自动生成 Git 提交
Git 与集群一致性 通过 Argo CD 同步恢复一致 可能与 Git 配置不一致
适用场景 GitOps 管理的应用发布与恢复 Kubernetes 原生 Deployment 回滚

需要注意：rollout undo 适用于 Deployment 等支持回滚历史的工作负载，但并不会自动回退所有外部依赖、数据库数据或 Git 中的配置。

在 GitOps 场景中，Git 变更记录与集群状态需要分别管理和验证。

十一、面试复盘

11.1 面试官可能会问：你实际做过 GitOps 回滚吗？

参考回答：

我在逐浪笔记项目的 K3s 实验环境中，通过 Gitee 和 Argo CD 实践了完整的 GitOps 回滚流程。

当时 Nginx Demo 使用 build-4，我先通过 Git 历史定位到使用 build-3 的旧配置，并确认目标镜像存在。随后只修改 Deployment 中的镜像标签，创建回滚提交 ab8e7b0 并推送到 Gitee。

由于 Argo CD 没有启用自动同步，我在页面手动执行 Sync。最后通过 Kubernetes 命令确认 Deployment 已恢复为 build-3、滚动更新成功、Pod 处于 Running 状态，同时 Argo CD 显示 Synced 和 Healthy。

这次实践让我理解了 Git 配置恢复、Argo CD 同步和 Kubernetes 滚动更新之间的职责边界。

11.2 面试官可能会问：为什么不直接 kubectl set image？

参考回答：

因为应用由 Argo CD 按 Git 中的期望状态管理。如果只在集群中修改镜像，而没有同步更新 Git，Git 与集群可能出现配置漂移，后续同步时还可能被恢复到旧配置。

因此，我优先通过 Git 提交记录回滚配置，再由 Argo CD 执行同步，这样既保留审计记录，也能保持期望状态与实际状态一致。

11.3 面试官可能会问：如何确认回滚真正成功？

参考回答：

我会分层验证。首先检查 Git 中的目标镜像和回滚提交，然后确认 Argo CD 已同步且资源健康，再检查 Kubernetes Deployment 的镜像、滚动更新状态和 Pod Ready 状态。最后通过 HTTP 请求验证服务是否真正可以访问。

仅仅看到 Git 推送成功或 Argo CD 显示 Synced，都不足以单独证明业务已经完全恢复。

十二、下一阶段实验计划

本次已完成正常路径的 GitOps 回滚。后续将继续开展故障注入与恢复演练。

实验 A：错误镜像发布

  • 使用隔离的实验分支或独立测试配置。
  • 发布一个故意不存在的镜像标签。
  • 观察 Deployment 更新过程及 Pod 异常状态。
  • 使用 kubectl describe pod、Events 和日志定位问题。
  • 记录故障表现及判断依据。

实验 B：通过 GitOps 恢复

  • 在 Git 中新增回滚提交。
  • 恢复到已知可用的镜像版本。
  • 通过 Argo CD 执行同步。
  • 验证 Deployment、Pod 和 Application 状态。
  • 补充 HTTP 访问验证。

实验 C：形成可复用的故障处理案例

  • 记录故障现象、原因、影响范围和处理步骤。
  • 对比 GitOps 回滚与 kubectl rollout undo。
  • 总结回滚前检查、回滚操作、恢复验证和防止复发的措施。

十三、实验总结

本次实践完成了从 Git 历史定位、目标镜像检查、Git 回滚提交、远程推送，到 Argo CD 手动同步及 Kubernetes 滚动更新的完整流程。

最终确认 Deployment 已恢复为 build-3，滚动更新成功，Pod 正常运行，Argo CD 显示 Synced 和 Healthy。

通过这次实验，逐浪笔记项目进一步补充了 GitOps 发布管理与版本恢复方面的实践经验。下一步将继续开展错误镜像发布与故障恢复演练，进一步提升故障诊断、变更控制和持续交付恢复能力。

相关推荐
Z21-X1 小时前
云原生运维学习笔记：从云计算概念到服务器硬件的入门之旅
运维·笔记·学习·云原生
墨神谕1 小时前
Docker 数据卷（Volume）详解：Dockerfile 声明、Docker Compose 挂载宿主机目录及持久化实战
运维·docker·容器
zh73142 小时前
Docker Desktop docker_data.vhdx 使用时间长了过大，解决办法
运维·docker·容器
墨神谕2 小时前
Docker Compose 从入门到实战：核心概念、YAML 配置详解、常用命令与多容器部署
运维·docker·容器
KIDULT°2 小时前
【K8s 实战】Volume 存储、PV/PVC、ConfigMap 与 Secret 完整实验
云原生·容器·kubernetes
逐流人2 小时前
ELK企业级日志分析系统：从零搭建集中化日志平台
运维·elk·云原生·云计算·日志分析
Z21-X2 小时前
云原生运维学习笔记：存储、网络与操作系统——云计算的底层基石
运维·笔记·学习·云原生
qianyuqiye13 小时前
K8s 命名空间与 Pod 入门：从概念到实战
java·docker·kubernetes
SelectDB16 小时前
开源替代怎么选：能力对照、三条部署路径与四类边界速查
数据库·云原生·开源
热门推荐
01如何新建文件夹？ 电脑新建文件夹的4种方法02国内可直接用、免费额度/永久免费的大模型API清单（含 SiliconFlow、火山、阿里、智谱、百度、Kimi、DeepSeek、DMXAPI 等）03历年考研数学一、数学二、数学三真题试卷及答案PDF04GitHub 镜像站点05几个好用的ip纯净度检测网站06乙二醇水溶液物性参数07「全语录+省流版」邵艾伦 × 孙宇晨：聊风口、聊个人IP、聊年轻人如何抓住 AI 时代的机会08昇腾910B系列芯片完全指南：四款型号对比、服务器选型与大模型部署实战09苹果iPA游戏软件资源下载网站10Windows 10/11 如何退出微软账户并改用本地账户登录（含找不到选项的解决方法）