ArgoCD Sync 트러블슈팅 — 레포 오타부터 RDS 보안 그룹까지

도람·2026년 4월 30일

트러블슈팅

목록 보기
5/10

ArgoCD Sync 트러블슈팅 — 레포 경로 오류부터 RDS 보안 그룹까지

이번 포스팅은 ArgoCD Sync를 시도하다가 연속으로 두 가지 문제를 맞닥뜨린 트러블슈팅 기록이다.
결론부터 말하면 레포 이름 오타 → 폴더 경로 오류 → RDS 보안 그룹 차단 순서로 문제가 터졌고, 아직 완전히 해결 전 단계다.


사전 준비 — 엔드포인트 확인 및 리소스 생성

Sync 전에 RDS, ElastiCache 엔드포인트를 확인하고 쿠버네티스 리소스를 미리 만들어둔다.

# RDS, ElastiCache 엔드포인트 확인
terraform output rds_endpoint
terraform output elasticache_endpoint
# namespace, configmap 생성
kubectl apply -f kubernetes/base/namespace.yaml
kubectl apply -f kubernetes/base/configmap.yaml
# DB, Redis, JWT 정보를 Secret으로 등록
kubectl create secret generic app-secret \
  --namespace=production \
  --from-literal=DB_HOST=pposiraegi-db.c5wkmcaauwn2.ap-northeast-2.rds.amazonaws.com \
  --from-literal=DB_USERNAME=pposiraegi \
  --from-literal=DB_PASSWORD=DB비밀번호 \
  --from-literal=REDIS_HOST=pposiraegi-redis.qka9g8.0001.apn2.cache.amazonaws.com \
  --from-literal=JWT_SECRET=JWT시크릿

Secret이란?
비밀번호, API 키처럼 외부에 노출되면 안 되는 값을 쿠버네티스 안에서 안전하게 관리하는 리소스다.
--from-literal로 값을 직접 넣으면 자동으로 base64 인코딩되어 저장된다.


트러블슈팅 1 — ArgoCD Sync 실패 (레포/경로 문제)

Sync 시도

kubectl apply -f argocd-app.yaml

# UI에서 SYNC → SYNCHRONIZE 클릭 후 반응 없음
# 터미널로 직접 해결하기로 함

# ArgoCD 파드 확인
kubectl get pods -n argocd

# ArgoCD 서버에 직접 로그인
kubectl -n argocd exec -it argocd-server-7648988dc6-zq7hn -- \
  argocd login localhost:8080 --insecure --username admin --password NDiUuc1t8XJKmF2O

# 수동 Sync
kubectl -n argocd exec -it argocd-server-7648988dc6-zq7hn -- \
  argocd app sync pposiraegi --insecure

UI에서 Sync 버튼을 눌렀는데 아무 반응이 없어서, ArgoCD 서버 파드에 직접 exec로 들어가서 CLI로 진행했다.


문제 1 — feat/eks-migration 브랜치를 못 찾음

브랜치를 찾지 못한다는 에러가 발생했다. 하나씩 확인했다.

# 원격 브랜치 목록 확인
git branch -r

→ 브랜치는 실제로 존재함.

# 해당 브랜치에 커밋이 있는지 확인
git log --oneline origin/feat/eks-migration

→ 커밋도 있음.

# argocd-app.yaml 내용 확인
cat argocd-app.yaml

→ path 설정은 이상 없음.

# 실제 레포 이름 확인
git remote -v

원인 발견 — 레포 이름 오타

항목URL
argocd-app.yaml에 입력된 값https://github.com/Goorm4I/pposiraegi-ecommerce-msa
실제 레포 주소https://github.com/Goorm4I/pposiraegi-ecommerce

argocd-app.yamlrepoURL을 올바른 주소로 수정 후 재적용했다.

kubectl apply -f argocd-app.yaml
kubectl -n argocd exec -it argocd-server-7648988dc6-zq7hn -- \
  argocd app sync pposiraegi --insecure

문제 2 — app path does not exist

레포 이름은 고쳤는데 이번엔 경로 문제가 발생했다.

원인

ArgoCD는 레포 루트에서 kubernetes/ 폴더를 찾는데,
실제 폴더 구조는 infrastructure/kubernetes/ 였다.

pposiraegi-ecommerce/
└── infrastructure/
    └── kubernetes/   ← 실제 위치

argocd-app.yamlpathinfrastructure/kubernetes로 수정 후 재적용했다.

kubectl apply -f argocd-app.yaml
kubectl -n argocd exec -it argocd-server-7648988dc6-zq7hn -- \
  argocd app sync pposiraegi --insecure

→ 연결 성공 🎉


트러블슈팅 2 — Pod CrashLoopBackOff (RDS 보안 그룹 차단)

다시 Sync 후 Pod 상태 확인

kubectl -n argocd exec -it argocd-server-7648988dc6-zq7hn -- \
  argocd app sync pposiraegi --insecure

successfully synced

그런데 Pod 상태를 확인하니 문제가 있었다.

kubectl get pods -n production

처음엔 Running처럼 보였는데...

CrashLoopBackOff 발생

CrashLoopBackOff란?
컨테이너가 시작됐다가 바로 죽는 걸 반복하는 상태다.
보통 앱 내부 에러, 설정 오류, 외부 서비스 연결 실패 등이 원인이다.


no more tasks 문제

Sync 중 no more tasks 에러도 함께 발생했다.

ArgoCD가 infrastructure/kubernetes/ 하위 폴더를 재귀적으로 탐색하지 못해서 production Pod를 찾지 못하는 문제였다.

해결 — directory.recurse: true 추가

argocd-app.yaml에 재귀 탐색 옵션을 추가했다.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: pposiraegi
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/Goorm4I/pposiraegi-ecommerce
    targetRevision: feat/eks-migration
    path: infrastructure/kubernetes
    directory:
      recurse: true   # 하위 폴더까지 재귀적으로 탐색
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
    - CreateNamespace=true
kubectl apply -f argocd-app.yaml
kubectl -n argocd exec -it argocd-server-7648988dc6-zq7hn -- \
  argocd app sync pposiraegi --insecure

Pod는 뜨기 시작했지만... CrashLoopBackOff는 계속됐다.


로그로 원인 파악

kubectl logs -n production order-service-88547fbf4-vcl4k

Connect timed out

원인 — EKS 노드 → RDS 보안 그룹이 막혀있음

기존 RDS 보안 그룹 인바운드 규칙이 api_gateway_sg, internal_msa_sg만 허용하고 있었는데, EKS 노드는 다른 보안 그룹을 사용하고 있어서 접근이 차단된 상태였다.


해결 — EKS 노드 보안 그룹 ID 확인 후 RDS/Redis 보안 그룹에 추가

# EKS 클러스터 보안 그룹 ID 확인
aws eks describe-cluster \
  --name pposiraegi-cluster \
  --query "cluster.resourcesVpcConfig.clusterSecurityGroupId" \
  --output text \
  --profile goorm

sg-0aa36452edaf69dd9 확인

modules/security/main.tf에서 rds_sgredis_sg에 EKS 노드 보안 그룹을 추가했다.

rds_sg — PostgreSQL 5432 포트 허용 추가

resource "aws_security_group" "rds_sg" {
  vpc_id      = var.vpc_id
  name        = "${var.project_name}-rds-sg"
  description = "RDS PostgreSQL security group"

  ingress {
    from_port       = 5432
    to_port         = 5432
    protocol        = "tcp"
    security_groups = [aws_security_group.api_gateway_sg.id, aws_security_group.internal_msa_sg.id]
  }

  # EKS 노드 접근 허용 추가
  ingress {
    from_port       = 5432
    to_port         = 5432
    protocol        = "tcp"
    security_groups = ["sg-0aa36452edaf69dd9"]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = { Name = "${var.project_name}-rds-sg" }
}

redis_sg — Redis 6379 포트 허용 추가

# EKS 노드 접근 허용 추가
ingress {
  from_port       = 6379
  to_port         = 6379
  protocol        = "tcp"
  security_groups = ["sg-0aa36452edaf69dd9"]
}
# Terraform으로 보안 그룹 변경 적용
terraform apply -var-file="terraform.tfvars"

정리

순서문제원인해결
1브랜치 못 찾음repoURL 레포 이름 오타yaml 수정 후 재적용
2app path does not existpath가 실제 폴더 위치와 다름infrastructure/kubernetes로 수정
3no more tasks하위 폴더 탐색 안 됨directory.recurse: true 추가
4CrashLoopBackOffEKS → RDS 보안 그룹 차단Terraform으로 인바운드 규칙 추가

Terraform 적용 후 Pod가 정상적으로 뜨는지는 다음 포스팅에서 이어서 정리할 예정이다.

profile
정도를 걷는 엔지니어

0개의 댓글