AWS - 쿠버네티스 - 5탄 쿠버네티스 앱 조사하기 (Minikube와 Katacoda를 이용한 가상 실습)

https://kubernetes.io/ko/docs/home/ 참고

 

아래는 공식 홈페이지의 설명에서 발췌한 내용이며, 문장 하나하나가 중요한 것으로 보여 그대로 발췌했다.(https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/explore/explore-intro/ 에서 발췌)

 

지난 포스팅에서 파드를 배포를 생성했을 때, 쿠버네티스는 여러분의 애플리케이션 인스턴스에 파드를 생성했다. 파드는 하나 또는 그 이상의 애플리케이션 컨테이너 (도커와 같은)들의 그룹을 나타내는 쿠버네티스의 추상적 개념으로 일부는 컨테이너에 대한 자원을 공유한다. 그 자원은 다음을 포함한다:

• 볼륨과 같은, 공유 스토리지
• 클러스터 IP 주소와 같은, 네트워킹
• 컨테이너 이미지 버전 또는 사용할 특정 포트와 같이, 각 컨테이너가 동작하는 방식에 대한 정보

파드는 특유한 "로컬호스트" 애플리케이션 모형을 만들어. 상대적으로 밀접하게 결합되어진 상이한 애플리케이션 컨테이너들을 수용할 수 있다. 가령, 파드는 Node.js 앱과 더불어 Node.js 웹서버에 의해 발행되는 데이터를 공급하는 상이한 컨테이너를 함께 수용할 수 있다. 파드 내 컨테이너는 IP 주소, 그리고 포트 스페이스를 공유하고 항상 함께 위치하고 함께 스케쥴링 되고 동일 노드 상의 컨텍스트를 공유하면서 동작한다.

파드는 쿠버네티스 플랫폼 상에서 최소 단위가 된다. 우리가 쿠버네티스에서 배포를 생성할 때, 그 배포는 컨테이너 내부에서 컨테이너와 함께 파드를 생성한다. 각 파드는 스케쥴 되어진 노드에게 묶여지게 된다. 그리고 (재구동 정책에 따라) 소멸되거나 삭제되기 전까지 그 노드에 유지된다. 노드에 실패가 발생할 경우, 클러스터 내에 가용한 다른 노드들을 대상으로 스케쥴되어진다.

 

파드는 언제나 노드 상에서 동작한다. 노드는 쿠버네티스에서 워커 머신을 말하며 클러스터에 따라 가상 또는 물리 머신일 수 있다. 각 노드는 마스터에 의해 관리된다. 하나의 노드는 여러 개의 파드를 가질 수 있고, 쿠버네티스 마스터는 클러스터 내 노드를 통해서 파드에 대한 스케쥴링을 자동으로 처리한다.

모든 쿠버네티스 노드는 최소한 다음과 같이 동작한다.

• Kubelet은, 쿠버네티스 마스터와 노드 간 통신을 책임지는 프로세스이며, 하나의 머신 상에서 동작하는 파드와 컨테이너를 관리한다.
• 컨테이너 런타임(도커와 같은)은 레지스트리에서 컨테이너 이미지를 가져와 묶여 있는 것을 풀고 애플리케이션을 동작시키는 책임을 맡는다.

 

그럼 이제 kubctl 커맨드를 이용하여 배포된 Application과 그 환경에 대한 정보를 얻어오는 실습을 진행해보자.

 

1. 앱 분석하기

그림1. 쿠버네티스 Application 분석(트러블슈팅)

그럼 실습에 앞서 지난 포스팅에서 확인했던 것처럼 어떤 파드들이 있는지 아래 명령어로 확인해보자.

kubctl get pods

그림2. 존재하는 파드 확인

1개의 파드가 존재한다. 그럼 해당 파드 내에 어떤 이미지가 존재하고 어떤 정보를 가지고 있는지 좀 더 상세한 파드의 정보를 아래 명령어로 확인해보자.

kubctl describe pods

그림3. 파드 상세 정보

여기서 파드, 컨테이너에 대한 세부 정보 (IP 주소, 사용 된 포트, 파드 수명주기와 관련된 이벤트 목록)를 볼 수 있다. 각각의 항목은 지금 당장 다 이해하기는 어렵더라고 눈으로 쓱 한번 봐두는 것이 좋겠다.

 

지난 포스팅 때 확인한 것처럼 파드는 격리 된 사설 네트워크에서 실행되고 있으므로 디버그하고 상호 작용할 수 있도록 프록시 서버를 열어야 한다.이를 위해 kubectl 프록시 명령을 사용하여 두 번째 터미널 창에서 프록시를 실행하자. 

echo -e "\n\n\n\e[92mStarting Proxy. After starting it will not output a response. Please click the first Terminal Tab\n"; kubectl proxy

그림4. 파드 프록시 실행

그리고 지난번에 했던 것처럼 파드 프록시를 통해 파드의 이름을 가져오고 이를 변수에 저장해보자.

export POD_NAME=$(kubectl get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}')
echo Name of the Pod: $POD_NAME

그림5. 파드 이름 불러오기

그리고 Application의 출력을 보기 위해 아래 curl 요청을 실행하자. 그러면 URL이 출력되는데 이는 파드의 API에 대한 경로이다.

curl http://localhost:8001/api/v1/namespaces/default/pods/$POD_NAME/proxy/

그림6. 파드 프록시를 통한 파드 호출

그럼 이제 로그를 확인해보자. Application이 일반적으로 STDOUT으로 보내는 모든 것은 파드 내 컨테이너에 대한 로그가 되며, 아래 명령어를 사용해 이러한 로그를 확인할 수 있다.

kubectl logs $POD_NAME

그림7. 컨테이너 로그 출력

컨테이너가 시작된 시간과 요청횟수 등이 기록된 로그를 확인할 수 있다. 참고로 원래 파드 내 특정 컨테이너를 명시해줘야 해당 컨테이너의 로그가 출력되지만 현재 우리는 파드 내 1개의 컨테이너만 가지고 있는 환경이기 때문에 별도로 컨테이너를 명시해주지 않았다.

 

파드가 한번 가동되고 실행되면 컨테이너에서 직접 명령을 실행할 수 있으며, 이를 위해 exec 명령을 사용하고 파드의 이름을 매개 변수로 사용한다. 이를 이용해 컨테이너의 매개변수를 출력해보자.

kubectl exec $POD_NAME -- env

그림8. 컨테이너의 환경 변수 출력

저장된 환경 변수가 출력되는 것을 볼 수 있다. 다시 한번 언급하지만, 현재 파드 내 컨테이너가 1개이기 때문에 별도로 컨테이너의 이름을 명령어에 넣어주지는 않았다.

 

다음으로 Pod의 컨테이너에서 bash 세션을 시작해보자.

kubectl exec -ti $POD_NAME -- bash

그림9. 컨테이너 bash 세션

NodeJS 애플리케이션을 실행하는 컨테이너에 열린 콘솔이 실행된 것을 볼 수 있다. 애플리케이션의 소스 코드는 server.js 파일에 있으니, cat 명령어로 확인해보자.

cat server.js

그림10. 컨테이너 내에 있는 server.js 확인

 

그럼 curl 명령어를 이용해서 해당 애플리케이션이 잘 동작하는지 확인해보자. 아래 명령어에서 localhost로 명시한 것은 현재 컨테이너 내에서 명령을 실행중이기 때문이다.

curl localhost:8080

그림11. 컨테이너 내에서 애플리케이션 호출

컨테이너 bash에서 나가기 위해서는 exit를 입력하면 된다.

exit

그림12. 컨테이너 bash 탈출