DevOps Study 2주차 - Githubissues

initmumu commented 1 year ago

3장 쿠버네티스로 컨테이너 실행하기

kbpark9898 commented 1 year ago

kubectl [command] [TYPE] [NAME] [flags]

위 링크를 통해 minikube로 직접 클러스터를 로컬에 생성하고 서비스를 띄워볼 수 있다. (gcp 무료계정을 모두 사용한 사람은 minikube를 이용해 직접 실습을 진행할 수 있다.)

책에서는 kubectl get pods 명령어를 통해 pod의 정보를 확인한다. 이 때, describe 명령어를 사용하면 자원의 더 자세한 정보를 확인할 수 있다.

kubectl을 이용해 pod의 status 정보를 요청하면, 이 정보는 명확하게 Status 라는 field에 담겨서 나온다. 그런데 사실 k8s api에서 제공하는 pod 자원에 대한 정보는 훨씬 다양하다.

위 공식 문서에서 status 부분, 즉 PodStatus api의 응답 field를 살펴보면 kubectl로 요청한것처럼 단순하게 Status라는 field하나로 데이터가 내려오는것이 아님을 알 수 있다.

그렇다면 실제 서비스에서 k8s core api를 이용해 외부에서 자원을 요청하는 경우, 어떤 방법을 이용해 pod의 status를 결정할 수 있을까?

위의 사진은 k8s core api를 이용해 자세한 pod의 status 정보를 받아온 결과이다.

우선 status로 표기되는 running data를 phase field에서 찾아볼 수 있다.

그렇다면 이 데이터를 사용하면 될까??

잘못된 이미지로 deployment를 생성하고 CrashLoopbackOff status에 빠진 pod에 PodStatus core api를 실행해본 결과이다. 분명 kubectl로 얻어온 Status와 phase 값이 다른것을 알 수 있다.

그렇다고 conditions field를 이용하기엔 어떤 기준으로 특정 상태를 판별해야하는지 알 수 없다.

과연 어떻게 해야할까?

정답은 kubernetes dashboard의 공식 코드에 있다.

kubernetes dashboard의 공식 코드를 살펴보면 pod이 포함한 모든 container들을 순회하고, 이 container들의 상태를 종합적으로 판단하여 status를 결정한다는 사실을 알 수 있다.

역시 뭐든 공식문서가 최고다.

실제로 특정 컨테이너의 waiting status에 대한 reason이 CrashLoopBackOff 인것을 살펴볼 수 있었다.

안타깝게도 책의 예제는 제대로 동작하지 않는데, 그 이유는 책의 예제에서 사용하는 yaml 파일과 nginx 컨테이너의 기본설정간의 간극에 있다.

책의 예제에서 사용하는 yaml 파일은 nginx container의 리스닝 포트를 8080으로 설정한다.

하지만 container에 직접 접속해보면 nginx의 기본 리스닝 포트는 80으로 설정되어있는 것을 알 수 있다.

따라서 암만 서비스를 이용하여 컨테이너 8080 포트를 터널링 해줘봤자, nginx는 8080 포트를 보고있지 않으므로 다음과 같은 화면을 볼 수 있다..

따라서 해결방법은 두가지가 존재한다.

예제 yaml 파일의 컨테이너 리스닝 포트를 80으로 변경 후 다시 deployment를 만들고 service로 터널링하기
예제 yaml 파일로 deployment를 실행하고, 직접 nginx container에 접속하여 nginx의 default service port를 8080으로 변경한 뒤 exec 명령어를 통해 nginx 재실행