GitHub Actions도 고치고, 부트스트랩도 정상 실행됐는데 이번엔 ArgoCD가 CD(배포) 과정에서 문제가 생겼다. ArgoCD는 Git 저장소를 바라보며 Kubernetes 클러스터에 자동으로 배포해주는 도구인데, 이 단계에서 또 막혔다.

위처럼 OutOfSync + Degraded 상태가 떠서 로그를 확인해보기로 했다.

• OutOfSync: Git에 있는 설정과 실제 클러스터 상태가 다르다는 뜻
• Degraded: 배포된 애플리케이션이 정상 동작하지 않는다는 뜻

로그 확인

kubectl describe application pposiraegi -n argocd

로그에서 눈에 띄는 내용은 다음과 같았다.

external-secrets.io/ClusterSecretStore CRD가 없음
external-secrets.io/ExternalSecret CRD가 없음

ClusterSecretStore와 ExternalSecret CRD가 없다는 에러였다.

CRD(Custom Resource Definition)란 Kubernetes에 기본으로 없는 리소스 타입을 사용자가 직접 정의해서 추가하는 것이다. ESO를 설치하면 이 CRD들이 함께 등록된다.

원인은 이전 bootstrap 스크립트 실행 중 Loki 설치 단계에서 Windows 환경 문제로 오류가 발생했고, 그 이후 단계인 ESO(External Secrets Operator) 설치까지 진행되지 못했기 때문이었다. ESO는 AWS Secrets Manager 같은 외부 시크릿 저장소의 값을 Kubernetes Secret으로 자동으로 동기화해주는 도구다.

따라서 ESO만 따로 설치해주기로 했다.

ESO 따로 설치

./scripts/bootstrap-platform.sh --from eso

ESO 설치는 완료됐는데 여전히 OutOfSync 상태였다. Pod 상태를 확인해봤다.

waypoint만 떠 있고 나머지 서비스들이 올라오지 않은 상태였다. ArgoCD가 자동으로 sync를 하지 못하고 있어서 강제로 sync를 실행해보기로 했다.

ArgoCD sync 강제 실행

kubectl -n argocd exec -it $(kubectl get pods -n argocd -l app.kubernetes.io/name=argocd-server -o jsonpath='{.items[0].metadata.name}') -- argocd app sync pposiraegi --insecure --server argocd-server:80

ArgoCD CLI를 사용하려면 먼저 로그인이 필요하다고 떴다. 초기 admin 비밀번호를 확인한 뒤, port-forward로 ArgoCD 서버에 접근해서 로그인했다.

# 초기 admin 비밀번호 확인
kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d

# port-forward 후 로그인
kubectl port-forward svc/argocd-server -n argocd 8080:80 &
sleep 3
kubectl -n argocd exec -it $(kubectl get pods -n argocd -l app.kubernetes.io/name=argocd-server -o jsonpath='{.items[0].metadata.name}') -- argocd login localhost:8080 --insecure --username admin --password [위에서 확인한 비밀번호]

로그인 성공. 이제 sync를 다시 실행했다.

kubectl -n argocd exec -it $(kubectl get pods -n argocd -l app.kubernetes.io/name=argocd-server -o jsonpath='{.items[0].metadata.name}') -- argocd app sync pposiraegi --insecure --server localhost:8080

sync가 정상적으로 진행되는 것을 확인했다. 이제 production 네임스페이스의 Pod 상태를 확인해봤다.

production Pod 확인

kubectl get pods -n production

모든 서비스의 Pod가 정상적으로 올라왔다. 이제 실제 서비스에 접속해봤다.

서비스 확인

pposiraegi.cloud에 정상적으로 접속되는 것을 확인했다. 길고 긴 삽질이 드디어 끝났다.

마무리 정리

팀원은 MacOS 환경이라 bootstrap 스크립트가 한 번에 실행됐지만, Windows 환경에서는 여러 문제가 연달아 발생했다.

• Git Bash에서 sudo 권한 없음 → helm 수동 설치
• helm 실행 경로 문제 → PATH 직접 설정
• Windows에 /proc 경로가 없음 → Loki 설치 실패
• kubectl이 aws CLI 경로를 인식하지 못함 → 심볼릭 링크 + kubeconfig 수동 수정
• ESO 미설치로 인한 CRD 누락 → ESO 단독 설치

같은 스크립트라도 OS 환경에 따라 전혀 다르게 동작할 수 있다는 걸 몸소 경험했다. 다음에 스크립트를 작성할 때는 OS 환경 분기 처리를 꼭 고려해야겠다고 느꼈다.