大家好！在使用Argo CD时，您是否曾困惑“为什么我的资源没有自动删除？”或者“有没有办法按照特定顺序部署？”所有这些问题的答案都可以在应用程序清单的spec.syncPolicy部分找到。
今天，我们将详细探讨各种同步选项和策略，它们将完善部署的精细度。🛠️
1. 🔍 spec.syncPolicy 核心属性总结
syncPolicy定义了Argo CD如何将Git中的“期望状态”与集群中的“当前状态”进行匹配的顶层策略。
① automated (自动同步)
检测Git中的变更，并自动将其反映到集群中。
- prune: 是否删除Git中已删除的资源（默认值：false）。🗑️
- selfHeal: 当集群资源被手动修改时，是否将其恢复到Git状态（默认值：false）。🏥
② retry (重试策略)
设置同步失败时的重试次数和间隔。
- limit: 最大重试次数。
- backoff: 重试间隔（支持指数退避）。🔁
2. ⚡ 核心 syncOptions 详细指南
syncOptions以列表形式提供了在同步过程中使用的具体技术选项。
✅ ApplyOutOfSyncOnly=true (性能优化)
默认情况下，Argo CD在同步时会重新apply应用程序的所有资源。但是，如果资源很多，这将是巨大的浪费。
- 作用: 仅选择状态为OutOfSync（未同步）的资源进行更新。
- 优点: 减少API服务器负载，显著提高同步速度。⚡
✅ Replace=true (强制更新策略)
Kubernetes的某些资源无法通过kubectl apply进行修改。（例如：Immutable字段的更改）
- 作用: 使用replace或delete后create的方式强制更新资源，而不是apply。
- 注意: 资源可能会暂时被删除，因此请注意服务中断。🛠️
✅ PrunePropagationPolicy=foreground (安全删除)
决定删除资源时如何处理子资源（如Pod）。
- Foreground: 在删除父资源（如Deployment）之前，先彻底清理子资源。这是最安全的方式。🛡️
- Background (默认): 先删除父资源，子资源稍后由垃圾回收器处理。
✅ CreateNamespace=true
如果集群中不存在目标命名空间，Argo CD会自动创建它。🏗️
3. 🌊 部署顺序的魔力: Sync Waves
在部署应用程序时，如果需要“DB先启动，然后WAS再启动”这样的顺序，可以使用Sync Waves。这并非通过syncOptions设置，而是通过单个资源的Annotation进行配置。
- 工作原理: 资源按照从低到高（例如：-5到10）的数字顺序进行部署。
- 优点: 在依赖关系复杂的微服务环境中，确保部署的稳定性。🌊
4. 💻 实战代码: 完整配置示例
这是结合了上述所有内容的Argo CD Application清单。请通过注释再次确认各项设置的含义。
YAML
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: master-ops-app
namespace: argocd
spec:
project: default
source:
repoURL: 'https://github.com/my-org/manifests.git'
targetRevision: main
path: apps/my-service
destination:
server: 'https://kubernetes.default.svc'
namespace: production
# 1. 同步策略设置 🔄
syncPolicy:
automated:
prune: true # 自动反映删除
selfHeal: true # 手动修改恢复
# 2. 详细同步选项列表 ⚙️
syncOptions:
- ApplyOutOfSyncOnly=true # 仅更新已更改的资源
- Replace=true # 重新创建不可修改的资源
- PrunePropagationPolicy=foreground # 从子资源开始按序删除
- CreateNamespace=true # 自动创建命名空间
- ServerSideApply=true # 优化大型清单处理
- FailOnSharedResource=true # 防止资源重复管理 🚫
# 3. 失败时重试策略 🔁
retry:
limit: 5
backoff:
duration: 5s
factor: 2
maxDuration: 3m
---
# 4. 在单个资源（例如：ConfigMap）中使用Sync Wave的示例
apiVersion: v1
kind: ConfigMap
metadata:
name: app-config
annotations:
# 设置为最先部署（数字越小越快）🌊
argocd.argoproj.io/sync-wave: "-10"
data:
config: "setting"5. 💡 额外有用的 syncOptions
- Validate=false: 与kubectl apply –validate=false相同，跳过资源模式验证。
- SkipDryRunOnMissingResource=true: 防止在CRD尚未安装的情况下部署自定义资源时发生的Dry-run错误。
- RespectIgnoreDifferences=true: 严格应用spec.ignoreDifferences设置作为同步判断标准。
📝 总结表格
| 属性 / 选项 | 主要作用 | 比喻 |
| — | — | — |
| prune | Git删除时集群同步删除 | 极简主义（整理不用的物品） |
| selfHeal | 手动修改自动恢复 | 维持稳态（恢复原状） |
| ApplyOutOfSyncOnly | 仅更新变更部分 | 只修理需要的部分 |
| Replace | 资源重新创建 | 如果无法修复就买新的 |
| Sync Waves | 控制资源部署顺序 | 像多米诺骨牌一样按顺序排列 |
—
💡 总结
Argo CD的syncPolicy不仅仅是“自动化”，它还提供了关于“如何更安全、更快速地部署”的答案。特别是在大规模环境中，ApplyOutOfSyncOnly和Sync Waves等选项并非可选项，而是必需品。🎯
希望今天的指南能对您的稳定基础设施运营提供巨大帮助！
发表回复