쿠버네티스 트러블 슈팅에 대해 배울 예정이다.
웹과 데이터베이스 서버가 있는 2-Tier Application을 살펴보자.
데이터베이스 파드는 데이터베이스 응용 프로그램을 호스팅하고, 데이터베이스 서비스를 통해 웹 서버에 데이터를 제공한다.
웹 서버는 웹 파드에 호스팅 되고, 웹 서비스로 사용자에게 제공된다.
애플리케이션이 어떻게 구성되어 있는지 미리 구성도를 그려놓는 것을 권장한다.
Failure에 대해 얼마나 아느냐에 따라 구성도의 양 끝에서 문제를 해결해나갈 수 있다.
예를 들어, 사용자들이 애플리케이션 접근에 문제가 있다고 건의한다고 가정해보자.
먼저 애플리케이션 프론트엔드부터 시작할 것이다.
애플리케이션에 접근할 수 있다면 표준 테스트 방법을 사용한다.
웹 애플리케이션이라면 서버 IP와 NodePort에 curl을 통해 접근 가능한지 확인한다.
웹 파드의 서비스 주소를 확인한다.
구성 파일의 label과 selector의 key-value가 일치하는지 비교하여 확인한다.
파드가 잘 작동하는지 확인한다.
파드의 상태와 재시작 횟수를 확인하면 파드의 애플리케이션이 작동하고 있는지 계속해서 재생성되고 있는지 알 수 있다.
또한 kubectl logs
명령을 통해 애플리케이션 로그를 확인한다.
DB 파드 자체를 확인한다.
DB 파드 로그를 확인하여 DB에 문제가 있는지 확인한다.
이번에는 컨트롤 플레인 Failure을 해결하는 방법에 대해 알아볼 것이다.
먼저 클러스터에 있는 노드들의 상태를 확인한다.
노드들의 상태가 모두 정상인지 확인하고, 클러스터에서 작동 중인 파드의 상태를 확인한다.
kubeadm
을 이용해 배포된 클러스터에 컨트롤 플레인 구성 요소가 있다면 kube-system
네임스페이스 내의 파드가 실행중인지 확인할 수 있다.
또는 컨트롤 플레인의 구성 요소가 서비스로 배포되었는지 확인할 수도 있다.
마스터 노드에는 kube-apiserver, kube-controller-manager, kube-scheduler 등, 워커 노드에는 kubelet, kube-proxy 등의 서비스가 존재하므로 서비스 상태를 확인한다.
kubeadm의 경우, kubectl logs
명령으로 컨트롤 플레인의 구성요소 로그를 가진 파드 로그를 확인할 수 있다.
마스터 노드에서 기본으로 설정된 서비스의 경우, 호스트 로깅 솔루션을 이용한 서비스 로그를 확인할 수 있다.
이 경우에는 journalct -u
유틸리티를 이용히 kube-apiserver의 로그를 확인할 수 있다.