ArgoCon Japan 2026 前瞻：从维护者交流到 Argo CD 3.5 升级准备

2026-07-20 27 预计阅读时间: 1 分钟
来源: cncf.io AI 摘要 Original link

Disclaimer: This article is an AI-assisted summary. Read it together with the original source when precision matters. The summary may omit context, version differences, or edge cases and is not official documentation.

预计阅读时间：7 分钟

2026 年 7 月 28 日，ArgoCon Japan 将在日本横滨举办一场特别的半日活动，时间为 13:30 至 18:30，并与 KubeCon + CloudNativeCon 同期举行。除了现场接触 Argo 项目维护者，来源标题还把企业实践和 Argo CD 3.5 的演进方向列为重点。对于已经在生产环境使用 GitOps 的团队，这类活动的价值不只是了解新功能，更在于校准升级计划、治理方式和故障边界。

半天活动最值得带去的三个问题

面对维护者时，泛泛地问“下一版有什么新功能”通常收获有限。更有效的做法，是把企业环境中的具体约束整理成可讨论的问题。

升级兼容性：团队当前运行哪个 Argo CD 版本？是否使用 ApplicationSet、自定义健康检查、资源钩子、Config Management Plugin 或多集群管理？这些扩展点往往决定升级风险。

规模与性能：需要明确 Application 数量、目标集群数量、单个应用的资源规模，以及 repo-server、application-controller 的 CPU 和内存压力。只有提供量化数据，维护者或其他企业用户才容易判断问题属于配置、容量还是产品边界。

权限与审计：企业采用本地账号、SSO 还是外部身份提供商？项目级 RBAC 是否足够？生产同步是否需要人工批准？这些问题通常比单纯讨论部署速度更接近 GitOps 落地的核心。

来源摘要没有列出 Argo CD 3.5 的具体功能，因此不应提前假设某项能力一定会进入该版本。现阶段更稳妥的动作，是建立现状清单，并在议程、发布说明或维护者分享出现后逐项核对。

先把当前 Argo CD 环境盘清楚

参加活动或评估升级前，可以这样实践：先导出版本、工作负载状态和受管应用清单。下面的命令假设 Argo CD 安装在 argocd 命名空间，并且本机已经配置好 kubectl；如果命名空间不同，请修改 NS。

#!/usr/bin/env bash
set -euo pipefail

NS="argocd"
OUT="argocd-audit-$(date +%Y%m%d-%H%M%S)"
mkdir -p "$OUT"

kubectl -n "$NS" get deploy,statefulset -o wide > "$OUT/workloads.txt"
kubectl -n "$NS" get pods -o wide > "$OUT/pods.txt"
kubectl -n "$NS" get configmap argocd-cm -o yaml > "$OUT/argocd-cm.yaml"
kubectl -n "$NS" get configmap argocd-rbac-cm -o yaml > "$OUT/argocd-rbac-cm.yaml"
kubectl get applications.argoproj.io -A -o yaml > "$OUT/applications.yaml"
kubectl get applicationsets.argoproj.io -A -o yaml > "$OUT/applicationsets.yaml" 2>/dev/null || true

kubectl -n "$NS" get pods \
  -l app.kubernetes.io/name=argocd-server \
  -o jsonpath='{range .items[*]}{.spec.containers[*].image}{"\n"}{end}' \
  | sort -u > "$OUT/images.txt"

printf 'Audit written to %s\n' "$OUT"

导出的文件可能包含仓库地址、身份提供商配置和其他内部信息。向外部人员分享之前，应删除凭据、Token、Secret 引用及敏感域名。这个脚本也不是完整备份方案，不能替代 etcd、Git 仓库和密钥系统的备份流程。

用一个最小应用验证升级路径

不要直接拿关键生产应用测试新版本。可以这样实践：准备一个结构简单、同步行为明确的验证应用。运行前必须把 repoURL 和 targetRevision 改成团队自己的测试仓库与分支，并确保仓库中的 manifests 目录包含合法的 Kubernetes YAML。

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: argocd-upgrade-smoke-test
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/your-org/gitops-smoke-test.git
    targetRevision: main
    path: manifests
  destination:
    server: https://kubernetes.default.svc
    namespace: argocd-smoke-test
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

应用清单可保存为 smoke-test.yaml，然后执行：

kubectl apply -f smoke-test.yaml
kubectl -n argocd get application argocd-upgrade-smoke-test -w

验证时不要只看 Synced。还应检查应用是否达到 Healthy、自动修复是否生效、删除资源能否被正确回收，以及控制器日志中是否出现弃用告警或权限错误。若生产环境使用 ApplicationSet、同步窗口或自定义插件，测试应用也应覆盖相同机制，否则冒烟测试代表性不足。

把会议内容转成可执行的升级决策

会后可以按四项内容整理结论：目标版本带来的实际收益、已确认的破坏性变更、扩展组件兼容性，以及可回滚路径。对于 Argo CD 3.5，所有判断都应以届时公布的官方发布说明、升级文档和维护者说明为准。

企业团队还需要保留一套升级基线：当前镜像版本、核心 ConfigMap、RBAC、Application 与 ApplicationSet 清单、关键指标以及典型同步耗时。先在隔离环境恢复这套基线，再执行版本升级和回归测试。只有健康检查、同步、回滚、SSO、RBAC、多集群连接和通知链路都通过验证，才适合扩大部署范围。

ArgoCon Japan 2026 提供了一个难得的窗口，可以把内部长期积累的问题直接带到维护者和其他使用者面前。最有价值的准备不是列一份功能愿望，而是带上版本数据、规模数据、失败样例和可复现步骤，让关于 Argo CD 3.5 的讨论最终落到清晰的工程决策上。

# AI # CNCF # Go # 云原生 # 后端

相关推荐