[CKA] 애플리케이션 장애 대응

2계층 애플리케이션의 장애는 사용자 요청이 들어오는 프론트엔드에서 데이터베이스까지 경로를 따라가며 확인합니다. 한 번에 설정을 바꾸기보다 각 계층의 입력과 출력을 확인하면 원인을 빠르게 좁힐 수 있습니다.

외부 접근과 Service

curl <node-ip>:<node-port>
kubectl get svc <web-service> -n <namespace>
kubectl describe svc <web-service> -n <namespace>
kubectl get endpoints <web-service> -n <namespace>

Service에 endpoint가 없다면 selector와 Pod label을 비교합니다. endpoint가 있다면 port, targetPort, 컨테이너가 실제로 수신하는 포트를 확인합니다.

외부 요청 → NodePort → Service port → targetPort → Pod

Pod 상태와 로그

kubectl get pods -n <namespace>
kubectl describe pod <pod> -n <namespace>
kubectl logs <pod> -n <namespace>
kubectl logs <pod> -n <namespace> --previous
kubectl logs <pod> -n <namespace> -f

STATUS, RESTARTS, Events를 함께 봅니다. 재시작 전 실패 원인은 현재 컨테이너 로그가 아니라 --previous에서 확인해야 할 수 있습니다.

데이터베이스 연결

웹 Pod의 환경변수에 적힌 DB host가 실제 Service 이름과 같은지 확인합니다. mysql-service를 조회하지만 Service 이름이 mysql이라면 DNS 해석부터 실패합니다.

Deployment가 관리하는 Pod라면 Pod를 직접 수정하지 않고 Deployment의 Pod template을 고칩니다.

kubectl edit deployment <deployment> -n <namespace>
kubectl rollout status deployment/<deployment> -n <namespace>

데이터베이스 Service의 selector, endpoint, targetPort도 같은 방식으로 확인합니다. 연결 설정과 실제 리소스 이름을 비교하고, 그 리소스를 관리하는 상위 객체를 수정하는 것이 핵심입니다.