Argo CD APP + Nginx "Hello World" ¶
1. Directory APP ¶
这是 Kubernetes 原生的应用编排方式，通过声明式定义包含不同种类 API 资源对象的 YAML 编排文件来管理应用，Argo CD 会将这些分散的资源收敛在一起进行管理。
1. gitea 仓库配置 ¶
Git 仓库中创建以下包含 ConfigMap、Deployment 和 Service 配置的文件结构，适配你的 Argo CD 应用定义。
gitea-argocd-nginx/
└── manifests/
├── configmap.yaml # Nginx 配置
├── deployment.yaml # Nginx Deployment
└── service.yaml # Nginx Service
 |
|---|
1. ConfigMap 配置 ¶
(configmap.yaml)
apiVersion: v1
kind: ConfigMap
metadata:
name: nginx-config
labels:
app: nginx
data:
nginx.conf: |
events {
worker_connections 1024;
}
http {
server {
listen 80;
server_name localhost;
location / {
return 200 'Hello from Argo CD and Nginx!\n';
default_type text/plain;
}
}
}
2. Deployment 配置 ¶
(deployment.yaml)
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 2
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
annotations:
# configmap 配置热加载有两种场景：
# 1. 每次调用都去访问配置文件、可以使用热加载，挂载某个目录进去
# 2. 特殊场景、将配置信息按照 env 挂载成环境变量，pod 启动时直接加载进内存、需要开发检测配置信息是否变化、重新加载配置文件进内存。配置信息一般不会变、感觉没必要开发。
# a. 可以手动维护一个配置版本号 config-revision ，ConfigMap 改了就加 1。重启 pod 即可。
# b. 可以使用 Kustomize
config-revision: "3" # 当 nginx.conf 从 v1 改成 v2 时，这里改成 "2"
spec:
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80
volumeMounts:
- name: config-volume
mountPath: /etc/nginx
readOnly: true
volumes:
- name: config-volume
configMap:
name: nginx-config
items:
- key: nginx.conf
path: nginx.conf
3. Service 配置 ¶
(service.yaml)
apiVersion: v1
kind: Service
metadata:
name: nginx-service
labels:
app: nginx
spec:
type: ClusterIP
ports:
- port: 80
targetPort: 80
selector:
app: nginx
4. 推送到 Git 仓库 ¶
cd gitea-argocd-nginx
mkdir -p manifests
# 创建并编辑上述三个文件
git add manifests/
git commit -m "Add nginx hello world example"
git push origin main
2. argocd APP 创建 ¶
1. Application 资源 yaml 创建 ¶
cat directory-app.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: directory-app # 应用在 Argo CD 中的名称
namespace: argocd # Argo CD 自身的命名空间（固定）
labels:
env: dev
spec:
project: default # 所属的 Argo CD Project（权限隔离单元）
source:
path: manifests # Git 仓库中存放 K8s 配置文件的目录
repoURL: 'https://gitea.gitops.linuxcdn.com:60000/argocd-test/gitea-argocd-nginx.git' # Git 仓库地址
targetRevision: 'main' # 使用的分支（主分支）
destination:
namespace: default # 应用将部署到的目标命名空间
server: 'https://kubernetes.default.svc' # 目标集群 API 服务器地址（当前集群）
syncPolicy: # 同步策略
automated:
prune: false # 关闭自动删除（Git 中删除资源时，不自动清理集群）
selfHeal: false # 关闭自动修复（允许手动修改集群配置，不强制与 Git 同步）
syncOptions:
- CreateNamespace=true
kubectl apply -f directory-app.yaml
3. argocd 效果查看 ¶
1. ui 查看资源 ¶
| 查看 |
|---|
 |
2. 访问 svc ¶
[root@k8s-m1 test]# curl 10.233.44.114
Hello from Argo CD and Nginx!
4. 应用同步配置 ¶
同步策略配置 ¶
1. 同步模式（Sync Mode） ¶
- 手动同步（Manual）
默认模式。Argo CD 仅检测 Git 与集群的差异并提示，但不会自动执行同步，需要用户在 UI 点击 “Sync” 按钮或通过 CLI 触发（
argocd app sync <app-name>）。 适用场景：开发 / 测试环境中需要人工确认后再部署，或敏感操作（如生产环境的重大更新）。 - 自动同步（Automated）
开启后，Argo CD 会自动检测差异并同步（默认每 3 分钟检测一次，可通过
syncWindow调整频率）。 适用场景：需要完全自动化部署的场景（如 DevOps 流水线集成），或对部署时效性要求高的环境。
2. PRUNE RESOURCES（自动删除资源） ¶
- 作用：当你在 Git 仓库中删除某个资源定义（比如删掉一个
Service的 YAML 文件），Argo CD 会自动在集群中删除对应的资源，确保集群中不存在 “Git 中已移除” 的冗余资源。 - 反面场景：如果不开启，Git 中删除的资源会在集群中残留，久而久之导致 “集群状态” 与 “Git 定义” 脱节（比如旧的
Ingress或ConfigMap未清理，可能引发冲突）。 - 适用场景：需要严格保持集群与 Git 一致的环境（如生产环境），避免冗余资源占用空间或引发意外。
3. SELF HEAL（自动痊愈） ¶
- 作用：防止 “绕过 Git 直接修改集群” 的行为。如果有人手动在集群中修改资源（比如通过
kubectl edit临时调整Deployment的副本数），Argo CD 会检测到差异，并自动将其改回 Git 中定义的值。 - 反面场景：如果不开启，手动修改会长期生效，导致 “Git 定义” 与 “实际运行状态” 不一致，后续通过 Git 更新时可能出现预期外的冲突（比如 Git 中副本数是 3，手动改成 5 后，Git 再更新其他配置时，副本数会保持 5 而非 Git 定义的 3）。
- 适用场景：对合规性要求高的环境（如生产环境），防止未经审批的临时修改导致状态失控，确保所有变更必须通过 Git 提交（可审计、可回溯）。
4. 同步窗口（Sync Windows） ¶
限制同步操作的时间窗口（如仅允许工作日 9:00-18:00 同步），防止在非业务时间（如凌晨）执行部署导致故障难以处理。
- 示例：生产环境配置为 “仅周一至周五 10:00-16:00 允许自动同步”。
5. 保留资源（Retain Resources） ¶
特殊场景下，某些资源（如 PersistentVolumeClaim 存储数据）即使 Git 中删除，也不希望被清理（避免数据丢失），可通过标签 argocd.argoproj.io/retain: "true" 标记，Argo CD 会忽略对其的删除操作。