ArgoCD 面试题
35 道题- 分类
- DevOps
- 题目数
- 35 道
1 GitOps 核心原则与 ArgoCD 架构
答案:
GitOps 以 Git 仓库作为声明式基础设施和应用程序的唯一事实来源。ArgoCD 遵循 GitOps 四原则:声明式描述、版本控制和不可变存储、自动拉取期望状态、持续反馈差异。
ArgoCD 核心组件
| 组件 | 职责 |
|---|---|
| API Server | 接受 API/gRPC/CLI 请求,处理 Application CRD 状态 |
| Repository Server | 缓存并处理 Git 仓库元数据,生成 Manifests(Kustomize/Helm/Jsonnet) |
| Application Controller | 监控 Application 对象,对比 Live State 与 Desired State,执行 Sync |
| Redis | 缓存 Git 数据和 Application 信息,支持高可用 |
| Dex/SSO | 提供 OIDC/LDAP/SAML 身份认证代理 |
| Notification Controller | 处理订阅规则,发送 Webhook/Slack/Email 通知 |
| ApplicationSet Controller | 基于 Generators 自动生成 Application 对象 |
架构工作流
Git Push -> Repository Server 拉取并渲染 Manifests -> Application Controller 对比 Live State -> 发现差异 -> 执行 Sync 策略 -> 更新集群资源 -> Health Check 确认状态
2 Application CRD 定义结构
答案:
Application CRD 是 ArgoCD 的核心资源对象,定义目标应用与集群之间的映射关系。
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: guestbook
namespace: argocd
spec:
project: default
source:
repoURL: https://github.com/argoproj/argocd-example-apps.git
targetRevision: HEAD
path: guestbook
destination:
server: https://kubernetes.default.svc
namespace: guestbook
syncPolicy:
automated:
prune: true
selfHeal: true
allowEmpty: false
syncOptions:
- CreateNamespace=true
- PruneLast=true
retry:
limit: 5
backoff:
duration: 5s
factor: 2
maxDuration: 3m
关键字段说明
| 字段 | 作用 |
|---|---|
| spec.source | 定义 Git/Helm 仓库来源和路径 |
| spec.destination | 定义目标集群和命名空间 |
| spec.syncPolicy | 定义同步策略,包含自动同步、重试、资源配置 |
| spec.ignoreDifferences | 忽略特定字段的差异检查 |
3 Project CRD 与多租户隔离
答案:
AppProject 提供逻辑分组和访问控制边界,限制 Application 可操作的源仓库、目标集群和资源范围。
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
name: production
namespace: argocd
spec:
description: Production Project
sourceRepos:
- https://github.com/team-a/*
destinations:
- namespace: prod-*
server: https://kubernetes.default.svc
clusterResourceWhitelist:
- group: "*"
kind: Namespace
roles:
- name: admin
policies:
- p, proj:production:admin, applications, *, production/*, allow
隔离机制
源仓库限制确保 Application 只能引用被授权的 Git 仓库。目标集群限制确保应用只能部署到指定的集群或命名空间。资源白名单/黑名单控制 CRD 级别的操作权限。
4 Sync 策略:Manual 与 Automated
答案:
| 模式 | 触发方式 | 适用场景 |
|---|---|---|
| Manual Sync | 手动调用 API/CLI/UI | 生产环境严格变更管控 |
| Automated Sync | Git Push 自动触发 | Dev/Staging 持续部署 |
Auto Sync 配置项
- prune:删除集群中不在 Git 仓库定义的资源
- selfHeal:检测集群手工修改后自动恢复为 Git 状态
- allowEmpty:允许空目录同步,会删除命名空间下的所有资源
- syncOptions: Validate=false / CreateNamespace=true / PruneLast=true
Sync Retry 策略
retry:
limit: 5
backoff:
duration: 5s
factor: 2
maxDuration: 3m
5 Sync Wave 与 Sync Phase
答案:
Sync Phase 定义同步的三大阶段:PreSync -> Sync -> PostSync。Sync Wave 在同一阶段内定义资源应用的先后顺序,负值 Wave 先执行。
metadata:
annotations:
argocd.argoproj.io/sync-wave: "-5"
Wave 执行规则
- Wave 值越小优先级越高
- 同一 Wave 的资源并行应用
- 前一个 Wave 的所有资源 Health 为 Healthy 后进入下一 Wave
- Phase 为 PreSync -> Sync -> PostSync,每个 Phase 内部按 Wave 排序
典型用途
| Wave | 资源类型 |
|---|---|
| -5 | 数据库 Migration Job |
| -3 | ConfigMap / Secret |
| 0 | 核心 Deployment |
| 3 | Service / Ingress |
| 5 | Smoke Test Job |
6 Resource Hook 机制
答案:
Resource Hook 在 Sync 生命周期的特定时刻执行 Job,用于数据库迁移、数据初始化、验证测试等一次性任务。
Hook 类型
| Hook 类型 | 执行时机 | 超时默认 |
|---|---|---|
| PreSync | Sync 开始之前 | 60s |
| Sync | Sync 操作中 | 60s |
| PostSync | Sync 成功后 | 60s |
| SyncFail | Sync 失败后 | 60s |
| Skip | 跳过 Hook 执行 | N/A |
Hook 定义示例
apiVersion: batch/v1
kind: Job
metadata:
generateName: db-migrate-
annotations:
argocd.argoproj.io/hook: PreSync
argocd.argoproj.io/hook-delete-policy: HookSucceeded
spec:
template:
spec:
containers:
- name: migration
image: migrate-tool:latest
command: ["./migrate"]
restartPolicy: Never
7 多集群管理:Cluster Registration
答案:
ArgoCD 通过 Cluster Secret 管理多个目标集群,一个控制平面可管理数百个远程集群。
注册方式
argocd cluster add production-context --name prod-cluster --kubeconfig /path/to/kubeconfig
argocd cluster add staging-context --name staging-cluster
Cluster Secret 结构
apiVersion: v1
kind: Secret
metadata:
name: prod-cluster
namespace: argocd
labels:
argocd.argoproj.io/secret-type: cluster
type: Opaque
stringData:
name: prod-cluster
server: https://api.prod.example.com:6443
config: |
{
"bearerToken": "<token>",
"tlsClientConfig": {
"insecure": false,
"caData": "<base64-ca>"
}
}
集群标签与选择器
通过 Secret labels 实现集群分组,Application 或 ApplicationSet 按标签选择目标集群。
argocd.argoproj.io/secret-type: cluster
environment: production
region: us-east-1
8 RBAC 权限模型
答案:
ArgoCD RBAC 基于 Casbin 策略模型,控制用户对 Application、Project 和集群的操作权限。
策略定义位置
ConfigMap argocd-rbac-cm 中的 policy.csv 字段。
策略语法
p, <role/user>, <resource>, <action>, <object>, <effect>
内置角色
| 角色 | 权限范围 |
|---|---|
| role:admin | 全部管理权限 |
| role:readonly | 只读查看所有资源 |
| role:ci | 仅 Sync 操作权限 |
自定义角色示例
p, role:dev-team, applications, sync, dev-project/*, allow
p, role:dev-team, applications, get, dev-project/*, allow
p, role:dev-team, applications, delete, dev-project/*, deny
g, user-alice, role:dev-team
g, user-bob, role:admin
资源操作列表
| 资源 | 操作 |
|---|---|
| applications | get / create / update / delete / sync / override / action |
| clusters | get / create / update / delete |
| projects | get / create / update / delete |
| repositories | get / create / update / delete |
| logs | get |
9 SSO 集成:OIDC 与 Dex
答案:
ArgoCD 通过 Dex 作为身份代理实现 OIDC/LDAP/SAML 集成,也可直接对接 OIDC 提供商。
Dex 组件架构
User -> ArgoCD API Server -> Dex -> OIDC Provider(Google/GitHub/GitLab/Azure AD/LDAP)
argocd-cm 配置
data:
url: https://argocd.example.com
dex.config: |
connectors:
- type: gitlab
id: gitlab
name: GitLab
config:
clientID: $dex.gitlab.clientID
clientSecret: $dex.gitlab.clientSecret
baseURL: https://gitlab.example.com
- type: ldap
id: ldap
name: LDAP
config:
host: ldap.example.com:389
bindDN: cn=admin,dc=example,dc=com
bindPW: $dex.ldap.bindPW
usernamePrompt: Email
userSearch:
baseDN: ou=people,dc=example,dc=com
filter: "(mail=%s)"
直接 OIDC 配置
data:
url: https://argocd.example.com
oidc.config: |
name: Azure AD
issuer: https://login.microsoftonline.com/<tenant-id>/v2.0
clientID: $oidc.clientID
clientSecret: $oidc.clientSecret
requestedScopes: ["openid", "profile", "email", "groups"]
Claim 到 RBAC 映射
argocd-rbac-cm 支持通过 policy.default 和 scopes 字段将 OIDC Claims 映射为角色。
10 回滚与 Sync History
答案:
ArgoCD 保留每次 Sync 操作的完整历史记录,最多保留 10 条。回滚本质是重新同步到历史版本的 Desired State。
操作方式
argocd app rollback guestbook --id 15
History 记录内容
| 字段 | 说明 |
|---|---|
| id | Sync 操作唯一标识 |
| revision | Git 提交 SHA |
| deployedAt | 部署时间戳 |
| deployedBy | 执行用户 |
| source | 源仓库配置快照 |
| syncResult | 同步结果和资源变更清单 |
回滚限制
回滚仅恢复 Application 源配置,不保留基础设施状态。当目标 Git 分支被 force push 重写后,History 记录的 revision 可能失效。跨 Project 回滚不被支持。
11 Sync 状态机与 Health Check
答案:
Sync Status 描述 Application 当前状态与目标状态的一致性,Health Status 描述资源运行健康状况。
Sync Status
| 状态 | 含义 |
|---|---|
| Synced | Live State 与 Desired State 一致 |
| OutOfSync | Live State 与 Desired State 存在差异 |
| Syncing | Sync 操作执行中 |
| Failed | Sync 操作执行失败 |
| Unknown | 无法确定状态 |
Health Status
| 状态 | 含义 |
|---|---|
| Healthy | 资源正常运行 |
| Progressing | 资源部署中或更新中 |
| Degraded | 资源运行异常或处于错误状态 |
| Suspended | 资源被暂停(如 HPA scale to 0) |
| Missing | 期望的资源在集群中不存在 |
| Unknown | 无法评估健康状态 |
自定义 Health Check
Lua 脚本扩展资源健康评估逻辑,写入 argocd-cm 的 resource.customizations 字段。
return {
health = {
name = "MyCustomResource"
-- Lua 函数返回 health status
}
}
12 ApplicationSet Controller 架构
答案:
ApplicationSet Controller 基于生成器模板自动创建和管理多个 Application 对象,解决多集群、多环境、多租户场景下的重复配置问题。
工作流程
Generator 输入参数 -> Template 填充 Application Spec -> 生成 N 个 Application -> Controller 维护其生命周期
模板结构
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
name: guestbook
spec:
generators:
- list:
elements:
- cluster: prod
url: https://prod.example.com
- cluster: staging
url: https://staging.example.com
template:
metadata:
name: "XQOPENclusterXQCLOSE-guestbook"
spec:
project: default
source:
repoURL: https://github.com/argocd/guestbook.git
targetRevision: HEAD
path: "overlays/XQOPENclusterXQCLOSE"
destination:
server: "XQOPENurlXQCLOSE"
namespace: guestbook
13 ApplicationSet Generator 类型
答案:
ApplicationSet 提供多种 Generator 适配不同场景。
| Generator | 输入源 | 适用场景 |
|---|---|---|
| List | 静态元素列表 | 少量固定集群/环境 |
| Cluster | ArgoCD 已注册集群(含标签过滤) | 动态集群发现 |
| Git | Git 仓库目录/文件结构 | 分支策略、目录映射 |
| SCM Provider | GitHub/GitLab/Bitbucket 组织仓库 | 按仓库自动创建 |
| Pull Request | PR/MR 事件 | Review App 按需部署 |
| Matrix | 两个 Generator 组合 | 多维度笛卡尔积 |
| Merge | 多个 Generator 合并参数 | 共享基础参数 |
| ConfigMap | ConfigMap 内容 | 配置驱动生成 |
Git Generator 示例
generators:
- git:
repoURL: https://github.com/argocd/apps.git
revision: HEAD
directories:
- path: "apps/*"
14 Pull 模式 vs Push 模式
答案:
| 特性 | Pull 模式(ArgoCD 默认) | Push 模式 |
|---|---|---|
| 部署方向 | ArgoCD 主动拉取目标集群状态 | CI 工具主动推送部署 |
| 网络要求 | ArgoCD 可访问目标集群 API | CI 工具可访问目标集群 API |
| 安全边界 | 目标集群无需暴露 API Server | 需要集群凭证暴露给 CI |
| 漂移检测 | 内置轮询检测 | 需外部工具实现 |
| 适用场景 | 生产环境严格管控 | 与现有 CI 集成度高 |
Pull 模式优势
Git 仓库作为唯一入口,集群凭证不暴露给外部系统。ArgoCD Agent 安装在每个目标集群内部,控制平面仅发起出站连接,无需入站网络规则。漂移检测通过 Polling 或 Webhook 自动执行。
15 私有仓库配置
答案:
通过 Repository Secret 配置 Git 仓库认证凭证和 SSH 密钥。
HTTPS 认证
apiVersion: v1
kind: Secret
metadata:
name: private-repo
namespace: argocd
labels:
argocd.argoproj.io/secret-type: repository
stringData:
type: git
url: https://github.com/org/private-repo.git
username: git-token
password: <personal-access-token>
SSH 认证
stringData:
type: git
url: git@github.com:org/private-repo.git
sshPrivateKey: |
-----BEGIN OPENSSH PRIVATE KEY-----
...
-----END OPENSSH PRIVATE KEY-----
Helm OCI 仓库
stringData:
type: helm
url: oci://ghcr.io/org/charts
enableOCI: true
username: <user>
password: <token>
16 Webhook 触发配置
答案:
ArgoCD 支持通过 Webhook 接收 Git 平台事件通知,替代默认的 3 分钟轮询间隔实现秒级同步触发。
GitHub/GitLab/Bitbucket 配置
| 平台 | Webhook URL | 事件类型 |
|---|---|---|
| GitHub | https://argocd.example.com/api/webhook | push / pull_request |
| GitLab | https://argocd.example.com/api/webhook | Push Hook / Merge Request Hook |
| Bitbucket | https://argocd.example.com/api/webhook | repo:push / pullrequest:updated |
argocd-secret Webhook Secret 配置
stringData:
webhook.github.secret: <github-webhook-token>
webhook.gitlab.secret: <gitlab-webhook-token>
webhook.bitbucket.secret: <bitbucket-uuid>
webhook.bitbucketcloud.secret: <cloud-secret>
消息过滤与签名验证
ArgoCD 根据请求 Header 的 X-Hub-Signature 验证事件源,按仓库 URL 匹配 Application 触发同步。可配置在 Nginx/Istio 层限制 Webhook Endpoint 访问 IP 白名单。
17 Config Management Plugin:Kustomize 与 Helm
答案:
ArgoCD 原生支持 Kustomize、Helm、Jsonnet 和 YAML 直接渲染,通过 Config Management Plugin CMP 支持自定义渲染器。
Kustomize 配置
spec:
source:
repoURL: https://github.com/example/app.git
path: overlays/production
targetRevision: HEAD
kustomize:
namePrefix: prod-
commonLabels:
env: production
images:
- nginx:1.25.0
Helm Chart 配置
spec:
source:
repoURL: https://charts.example.com
chart: nginx-ingress
targetRevision: 4.0.0
helm:
releaseName: ingress-prod
values: |
controller:
replicaCount: 3
valueFiles:
- values-prod.yaml
parameters:
- name: controller.metrics.enabled
value: "true"
CMP 自定义插件
通过 sidecar 容器扩展,Container Network Interface 文件放置在 /custom-tools 目录。CMP 支持任意脚本或二进制工具渲染 Manifests。
18 大集群性能优化策略
答案:
| 优化方向 | 具体措施 |
|---|---|
| Controller 并发 | –controller-operation-processors=50 |
| Status 刷新 | –status-processors=20 |
| Redis 集群 | 使用 Redis Sentinel 或 Redis Cluster 替代单实例 |
| Repository Server 缓存 | 启用 Manifest Caching,设置 argocd-repo-server parallelism |
| Polling 间隔 | 延长默认 3 分钟间隔,依赖 Webhook 替代 Polling |
| Application 分片 | 按 Project/Cluster 划分多个 ArgoCD 实例 |
| 资源排除 | spec.ignoreDifferences 跳过无意义字段的对比 |
分片部署架构
argocd-application-controller:
sharding:
enabled: true
numberOfShards: 4
Scale 参考
| Application 数量 | 集群数量 | 建议配置 |
|---|---|---|
| < 500 | < 10 | 标准部署,无需优化 |
| 500 - 2000 | 10 - 50 | 增加 Controller 并发,启用 Redis HA |
| > 2000 | > 50 | 多实例分片,Cluster API 汇聚层 |
19 灾难恢复与备份
答案:
ArgoCD 的 Source of Truth 为 Git 仓库,灾难恢复的核心策略是重建 ArgoCD 实例后重新同步。
备份策略
| 数据来源 | 备份方法 | 恢复方法 |
|---|---|---|
| Application CRDs | kubectl get applications -n argocd -o yaml | kubectl apply |
| Project CRDs | kubectl get appprojects -n argocd -o yaml | kubectl apply |
| Cluster Secrets | kubectl get secrets -n argocd -l argocd.argoproj.io/secret-type=cluster | kubectl apply |
| Repo Secrets | kubectl get secrets -n argocd -l argocd.argoproj.io/secret-type=repository | kubectl apply |
| ConfigMap: argocd-cm | kubectl get cm argocd-cm -n argocd -o yaml | kubectl apply |
| ConfigMap: argocd-rbac-cm | kubectl get cm argocd-rbac-cm -n argocd -o yaml | kubectl apply |
| Secret: argocd-secret | kubectl get secret argocd-secret -n argocd -o yaml | kubectl apply |
恢复流程
- 部署 ArgoCD Operator 或 Helm Chart
- 还原 argocd-cm / argocd-rbac-cm / argocd-secret
- 注册集群凭据 Cluster Secrets
- 注册 Git 仓库凭据 Repository Secrets
- 还原 Project CRDs 和 Application CRDs
- 等待 Sync 完成
自动备份工具
ArgoCD Backup Tool 或 Velero 定时备份 argocd 命名空间资源。Backup CRD 定义备份范围和调度策略。
20 多环境管理策略
答案:
基于 Git 分支结构和 Repository Directory 映射实现多环境隔离。
分支模式
graph TD
A[main - 生产环境]
B[release/ - 预发布环境]
C[staging/ - 测试环境]
D[develop/ - 开发环境]
目录模式
graph TD
A[overlays/]
B[base/]
A1[production/]
A2[staging/]
A3[development/]
A --> A1
A --> A2
A --> A3
ApplicationSet 多环境实现
generators:
- list:
elements:
- env: dev
namespace: app-dev
cluster: https://dev.example.com
- env: staging
namespace: app-staging
cluster: https://staging.example.com
- env: prod
namespace: app-prod
cluster: https://prod.example.com
template:
spec:
source:
path: "overlays/XQOPENenvXQCLOSE"
destination:
namespace: "XQOPENnamespaceXQCLOSE"
server: "XQOPENclusterXQCLOSE"
环境间差异管理
公共配置置于 base 目录,环境特定配置置于 overlays 目录。Helm values 按环境独立文件管理。Secrets 通过 External Secrets Operator 或 Sealed Secrets 管理。
21 通知与告警集成
答案:
ArgoCD Notifications 基于订阅模型和模板系统,支持多通道告警推送。
架构组件
argocd-notifications-controller 读取订阅规则,匹配 Application 事件后渲染模板,分发至 Webhook/Slack/Email/Telegram/PagerDuty。
订阅配置 ConfigMap argocd-notifications-cm
data:
template.app-sync-succeeded: |
message: Application XQOPEN.app.metadata.nameXQCLOSE 同步成功
slacks:
attachments: |
[{"title": "部署完成", "text": "XQOPEN.app.metadata.nameXQCLOSE", "color": "good"}]
trigger.on-sync-succeeded: |
- description: Sync 成功
send:
- app-sync-succeeded
when: app.status.sync.status == 'Synced'
service.slack.prod-alerts: |
token: $slack-token
channels: #prod-deployments
subscriptions: |
- recipients:
- slack:prod-alerts
triggers:
- on-sync-succeeded
- on-sync-failed
applications:
- name: production-*
通知级别
| 触发事件 | 通知类型 |
|---|---|
| Sync 成功 | 成功通知 |
| Sync 失败 | 告警通知 |
| Sync 运行中 | 进度通知 |
| Health 降级 | 告警通知 |
| Health 恢复 | 恢复通知 |
22 Secret 管理方案
答案:
ArgoCD 不直接管理 Secret 明文,与外部 Secret 管理工具集成实现 Git 仓库安全存储。
集成方案对比
| 方案 | 加密位置 | 解密时机 | 适用场景 |
|---|---|---|---|
| Sealed Secrets | Git 仓库 | Controller 解密 | 小型团队 |
| External Secrets Operator | 外部 Provider | Controller 拉取 | 多云统一 Secret |
| Vault Agent Sidecar | HashiCorp Vault | Pod 启动注入 | 高安全要求 |
| SOPS + AGE/PGP | Git 仓库 | ArgoCD CMP 解密 | 轻量级方案 |
| AWS Secrets Manager / GCP Secret Manager | 云平台 | CSI Driver 挂载 | 云原生部署 |
Sealed Secrets 工作流
kubeseal 将 Secret 加密为 SealedSecret CRD -> 提交 Git 仓库 -> ArgoCD Sync 部署 -> Sealed Secrets Controller 解密为 Secret
External Secrets Operator 工作流
ExternalSecret CRD 引用 Vault/AWS/GCP Secret -> ArgoCD Sync 部署 -> ESO 拉取真实 Secret 并写入目标命名空间
23 渐进式部署:Blue-Green 与 Canary
答案:
ArgoCD 通过集成 Argo Rollouts 实现 Blue-Green 和 Canary 部署策略,扩展原生 Deployment 的更新能力。
Argo Rollouts CRD
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
name: app-rollout
spec:
replicas: 10
strategy:
canary:
steps:
- setWeight: 20
- pause: {duration: 60}
- setWeight: 50
- pause: {duration: 60}
- setWeight: 80
- pause: {duration: 30}
template:
metadata:
labels:
app: myapp
spec:
containers:
- name: app
image: myapp:v2
Blue-Green 策略
strategy:
blueGreen:
activeService: app-active
previewService: app-preview
autoPromotionEnabled: true
scaleDownDelaySeconds: 300
ArgoCD Integration
ArgoCD 将 Rollout CRD 视为标准 Kubernetes 资源进行 Sync 和 Health Check。Argo Rollouts Controller 管理 Rollout 的渐进式更新逻辑。ArgoCD 监控 Rollout 状态,在 Rollout 完成前标识为 Progressing。
24 与 Argo Workflows 和 Argo Events 配合
答案:
ArgoCD 作为 GitOps 引擎,与 Argo Workflows 和 Argo Events 组成完整 Argo Ecosystem。
| 组件 | 职责 | 集成方式 |
|---|---|---|
| ArgoCD | GitOps 持续部署 | Application + Sync |
| Argo Workflows | CI 工作流编排 | Sync 前执行 PreSync Hook |
| Argo Events | 事件驱动触发器 | Event Source 触发 Workflows |
| Argo Rollouts | 渐进式部署 | Rollout CRD 替代 Deployment |
集成场景
Git Push -> Argo Events Webhook 事件 -> 触发 Argo Workflows 构建镜像 -> 镜像构建完成更新 Git Manifest -> ArgoCD 检测变更并执行 Sync -> Rollout 渐进式更新
25 自定义资源健康检查
答案:
ArgoCD 内置常见 Kubernetes 资源的 Health Check 逻辑,通过 Lua 脚本扩展自定义 CRD 的健康评估。
Lua 自定义检查配置
argocd-cm ConfigMap 的 resource.customizations 字段。
data:
resource.customizations: |
argoproj.io/Rollout:
health.lua: |
hs = {}
hs.status = "Progressing"
hs.message = ""
if obj.status ~= nil then
if obj.status.currentStepIndex == obj.status.stepCount - 1 and obj.status.phase == "Healthy" then
hs.status = "Healthy"
return hs
end
if obj.status.phase == "Degraded" then
hs.status = "Degraded"
return hs
end
end
return hs
内置检查资源
Deployment、StatefulSet、DaemonSet、Job、Service、Ingress、PersistentVolumeClaim、PodDisruptionBudget、HorizontalPodAutoscaler、NetworkPolicy。
26 Resource Exclusion 与 Inline Manifest
答案:
Resource Exclusion 定义 ArgoCD 忽略的集群资源类型,Inline Manifest 允许直接在 Application 定义中嵌入 YAML。
Resource Exclusion 配置
argocd-cm ConfigMap 的 resource.exclusions 字段。
data:
resource.exclusions: |
- apiGroups:
- velero.io
kinds:
- Backup
- Restore
- apiGroups:
- ""
kinds:
- "*"
clusters:
- https://api.prod.example.com:6443
Inline Manifest 示例
spec:
source:
repoURL: https://github.com/example/manifests.git
targetRevision: HEAD
path: base
sources:
- repoURL: https://github.com/example/manifests.git
targetRevision: HEAD
path: overlays/prod
ref: prod
- repoURL: https://github.com/example/extra-config.git
targetRevision: HEAD
path: infra
Multi-source 聚合
ArgoCD 2.6+ 支持多源 Application,多个 Source 的 Manifests 合并后部署到同一目标。
27 命名空间管理与自动创建
答案:
通过 SyncOptions 控制目标命名空间的自动创建和资源清理。
CreateNamespace
spec:
syncPolicy:
syncOptions:
- CreateNamespace=true
ArgoCD 在 Sync 前检查目标命名空间是否存在,如果不存在则自动创建。命名空间不随 Application 删除而删除,防止级联删除影响其他资源。
PruneLast
syncOptions:
- PruneLast=true
Prune 操作在 Sync 完成后执行,确保新资源就绪后再删除旧版本资源,减少部署窗口期的服务中断。
Replace 模式
syncOptions:
- Replace=true
ArgoCD 在执行 Update 前先 Delete 再 Create 资源,适用于不支持 Patch 的 CRD。
28 审计日志与操作追溯
答案:
ArgoCD 审计日志记录所有操作事件,包括 Sync、Create、Update、Delete 和用户登录。
审计日志来源
| 数据源 | 记录内容 | 保留策略 |
|---|---|---|
| argocd-server 日志 | API 请求、操作事件 | 日志轮转配置 |
| Kubernetes Events | Sync 操作、状态变更 | 集群配置 |
| Application Status History | Sync 记录、Health 变更 | 最近 10 条 |
| Audit Log 配置 | 用户操作、认证事件 | 可配置持久化 |
审计日志配置
在 argocd-cm 中启用审计日志。
data:
audit.enabled: "true"
audit.log.format: json
audit.log.path: /var/log/argocd/audit.log
audit.log.maxsize: 100
audit.log.maxbackup: 5
操作追溯路径
用户 -> API Server -> Audit Logger -> Application Controller -> Kubernetes API -> 目标集群 Events
29 Image Updater 自动镜像更新
答案:
ArgoCD Image Updater 自动检测容器镜像仓库的新版本,更新 Application 的 Source 配置并触发 Sync。
更新策略
| 策略 | 行为 | 适用场景 |
|---|---|---|
| semver | 按语义版本号更新 | 稳定版本发布 |
| latest | 使用 latest 标签 | 开发环境 |
| name | 按镜像名称和标签格式匹配 | 自定义标签方案 |
| digest | 按镜像 Digest 更新 | 安全性优先 |
| digest pin | 固定 Digest 精准版本 | 生产环境 |
配置示例
Application annotations 启用 Image Updater。
metadata:
annotations:
argocd-image-updater.argoproj.io/image-list: myapp=gcr.io/project/app
argocd-image-updater.argoproj.io/myapp.update-strategy: semver
argocd-image-updater.argoproj.io/myapp.helm.image-name: image.repository
argocd-image-updater.argoproj.io/myapp.helm.image-tag: image.tag
工作流
Image Registry 有新 Tag -> Image Updater 检测更新 -> 更新 Git Manifest 文件 -> Git Commit & Push -> ArgoCD 检测仓库变化 -> 执行 Sync
30 ArgoCD CLI 常用操作
答案:
| 命令 | 功能 | 参数示例 |
|---|---|---|
| argocd app list | 列出所有 Application | –project production |
| argocd app get | 查看 Application 详情 | my-app -o yaml |
| argocd app sync | 手动同步 Application | –prune –dry-run |
| argocd app diff | 对比差异 | –local /tmp/manifests |
| argocd app rollback | 回滚到指定版本 | –id 15 |
| argocd app logs | 查看 Sync 日志 | –tail 100 |
| argocd app create | 创建 Application | -f app.yaml |
| argocd app delete | 删除 Application | –cascade |
| argocd app wait | 等待 Sync/Health 完成 | –health |
| argocd cluster list | 注册的集群列表 | |
| argocd cluster add | 注册新集群 | –name prod |
| argocd proj list | Project 列表 | |
| argocd proj create | 创建 Project | -f project.yaml |
| argocd repo list | 仓库列表 | |
| argocd account update-password | 更新 admin 密码 | |
| argocd admin export | 导出全部配置 | -o yaml |
| argocd admin import | 导入全部配置 | -f export.yaml |
常用参数
| 参数 | 说明 |
|---|---|
| –prune | 删除不在 Git 中的资源 |
| –dry-run | 预演模式,不实际执行 |
| –self-heal | 启用自愈 |
| –timeout | 操作超时时间 |
| –revision | 指定 Git 提交版本 |
31 多集群 ApplicationSet 实践
答案:
基于 Cluster Generator 实现跨集群 Application 自动发现和部署。
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
name: multi-cluster-app
spec:
generators:
- clusters:
selector:
matchLabels:
environment: production
template:
metadata:
name: "XQOPENnameXQCLOSE-guestbook"
spec:
project: production
source:
repoURL: https://github.com/example/guestbook.git
targetRevision: HEAD
path: "overlays/XQOPENnameXQCLOSE"
destination:
server: "XQOPENserverXQCLOSE"
namespace: guestbook
syncPolicy:
automated:
prune: true
selfHeal: true
集群标签管理
kubectl label secret prod-cluster -n argocd environment=production region=us-east-1
参数覆盖
ApplicationSet template 中的参数可通过 spec.generators[].clusters.values 字段覆盖默认值。
32 ArgoCD 安装与升级
答案:
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 \
--set configs.params.server.insecure=true
Operator 安装
kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
升级步骤
- Helm repo update / Operator 版本更新
- 执行 helm upgrade 或替换 Operator manifest
- 确认 argocd-server、argocd-repo-server、argocd-application-controller Pod 启动正常
- 验证 API 可用性和 Application Sync 状态
版本兼容性
ArgoCD 版本与 Kubernetes 版本存在兼容性矩阵,升级前确认目标集群 K8s 版本在支持范围内。Major 版本升级需要按以下顺序执行:argocd-cm ConfigMap 字段确认、RBAC 策略迁移、API 版本兼容性测试。
33 安全加固清单
答案:
| 安全维度 | 加固措施 |
|---|---|
| 网络访问 | argocd-server 仅暴露必要端口,TLS 终止配置,Admin Namespace 隔离 |
| 认证鉴权 | 禁用 admin 本地用户,强制 SSO 登录,最小权限 RBAC 策略 |
| Secret 管理 | 使用 External Secrets/Vault 替代 Git 存储 Secret,限制 argocd-secret 访问 |
| 仓库安全 | HTTPS 仓库使用 Token 认证,SSH 仓库限制 Key 权限,禁止 HTTP |
| 审计追踪 | 启用审计日志,对接 SIEM 系统,保留操作记录 |
| 集群隔离 | 生产集群与测试集群使用不同 ArgoCD 实例,Project 隔离 |
| 资源限制 | 设置 Container Resource Limits,防止 Controller OOM |
| 网络策略 | 限定 argocd-server 和 argocd-repo-server 的出站目标 |
argocd-cm 安全配置
data:
admin.enabled: "false"
server.insecure: "false"
users.anonymous.enabled: "false"
34 ArgoCD 与 CI 管道集成
答案:
CI 管道构建镜像后更新 Git Manifest,ArgoCD 检测变更后自动部署。
推荐集成模式
CI GitOps Workflow -> ArgoCD Pull Sync
Jenkins 集成
- CI Job 构建新镜像
- CI Job 推送镜像至 Registry
- CI Job 使用 kustomize edit set image 更新 overlay 文件
- CI Job git commit + git push Manifest 仓库
- ArgoCD Webhook 接收 push 事件
- ArgoCD 执行 Sync
GitLab CI 示例
update-manifest:
stage: deploy
image: alpine/git
script:
- git clone https://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.com/org/manifests.git
- cd manifests
- sed -i "s|image: myapp:.*|image: myapp:${CI_COMMIT_SHORT_SHA}|" overlays/prod/deployment.yaml
- git config user.email "ci@example.com"
- git config user.name "CI Pipeline"
- git add .
- git commit -m "Update image to ${CI_COMMIT_SHORT_SHA}"
- git push https://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.com/org/manifests.git
GitHub Actions 集成
- CI Pipeline 构建并推送镜像
- Action 使用 ArgoCD CLI 或 GitHub API 直接触发 Sync
- 或采用 GitOps 模式:Action 提交 Manifest 更新后等待 ArgoCD Webhook 触发
35 故障排查常见问题
答案:
| 问题现象 | 排查路径 | 常见根因 |
|---|---|---|
| Application 状态 OutOfSync | argocd app diff 查看具体差异 | 手动修改集群资源 / Git 回退 |
| Sync 失败 | argocd app logs 查看 Sync 日志 | Manifest 语法错误 / 资源冲突 |
| Health 卡在 Progressing | kubectl describe 查看资源状态 | Readiness Probe 失败 / PDB 阻塞 |
| Repository 连接失败 | argocd repo list 测试仓库连通性 | Token 过期 / SSH Key 无效 / 网络不通 |
| Cluster 连接失败 | argocd cluster list 检查集群状态 | Kubeconfig 过期 / API Server 不可达 |
| Webhook 未触发 | curl Webhook URL 手动测试 | Secret 不匹配 / 网络 ACL 限制 |
| 权限不足 | argocd account get-user-info 检查角色 | RBAC 策略缺失 / SSO Claim 映射错误 |
| ApplicationSet 未生成 | argocd appset list 查看控制器日志 | Generator 语法错误 / 标签选择器不匹配 |
常用诊断命令
argocd app get my-app -o yaml # Application 完整状态
argocd app diff my-app --hard-refresh # 强制刷新缓存后比对差异
argocd app sync my-app --dry-run --prune # 预演 Sync 操作
kubectl logs -n argocd deploy/argocd-application-controller # Controller 日志
kubectl logs -n argocd deploy/argocd-repo-server # Repository Server 日志
kubectl logs -n argocd deploy/argocd-server # API Server 日志