이 문서는 do4i 서비스가 배포 후 정상 수렴하지 않거나, 대표 기능이 비정상일 때 따르는 상세 대응 절차를 정리한다.
공통 판단은 서비스 배포 이상 1차 대응 절차를 먼저 따르고, 이 문서에서는 do4i에 특화된 리소스와 검증 지점을 본다.
do4i namespace 확인 권한ArgoCD 와 kubectl 확인 권한agents.do4i.com/api 또는 admin.do4ai.com/api 기준 URLdo4iapi Deployment, mysql StatefulSetapi-ingressagents.do4i.com/api, admin.do4ai.com/api아래를 먼저 끝낸다.
Application 상태 확인그 다음부터 do4i 특화 확인으로 내려간다.
api 와 mysql 관계를 먼저 본다sudo kubectl get deploy,sts,pods,svc,ing -n do4i
아래를 우선 확인한다.
api Deployment 가 replica 부족 상태인가mysql StatefulSet 이 정상 기동 중인가api 는 떴지만 DB 연결 때문에 readiness가 깨진 것은 아닌가do4i는 앱과 DB가 같이 흔들릴 수 있으므로 api만 보고 끝내면 안 된다.
api 로그에서 시작 실패 원인을 본다sudo kubectl logs deploy/api -n do4i --tail=100
먼저 보는 키워드는 아래다.
sudo kubectl describe ingress -n do4i api-ingress
sudo kubectl get svc -n do4i
아래를 확인한다.
agents.do4i.com 또는 admin.do4ai.com 기준과 맞는가/api 로 연결되는가api 가 뜨지 않거나 readiness가 회복되지 않으면 mysql 쪽 상태를 함께 본다.
sudo kubectl get pods -n do4i
sudo kubectl logs statefulset/mysql -n do4i --tail=100
아래 중 무엇인지 분리한다.
api pod 가 재시작 루프 없이 수렴하는가mysql 이 정상 상태를 유지하는가/api 진입점이 응답하는가아래 중 하나면 즉시 공유 또는 롤백을 검토한다.
api 와 mysql 이 동시에 비정상api 가 계속 재시작Application 상태api 와 mysql 상태