쿠버네티스 - 수평 확장 - 10

쿠버네티스의 장점 중 하나는 간단하게 확장할 수 있다는 점이다. 파드의 개수를 한번 늘려보자.

kubectl get rc

DESIRED 열은 RC가 유지해야 할 파드의 레플리카 수를 보여준다. CURRENT 열은 현재 실행 중인 파드의 실제 수를 나타낸다. 지금은 파드의 레플리카를 하나만 실행하도록 지정했기에 하나만 실행 중에 있다.

이제 한번 늘려보자.

kubectl scale rc suk9 --replicas=3
kubectl get rc
kubectl get pods

쿠버네티스에게 파드 인스턴스 세 개를 유지하도록 '알려줬다.' 이처럼 우리가 원하는 최종 결과만 선언하면 된다. 명령 결과 레플리카도와 파드가 3개로 증가한 것을 알 수 있다. 애플리케이션 스케일링이 끝났다.

 

이제 서비스와 파드의 관계를 알아보기 위해 로드밸런스 서비스로 요청을 날려보자.

curl http://127.0.0.1:58119
curl http://127.0.0.1:58119
curl http://127.0.0.1:58119

항상 응답이 같지 않다는 것에서, 요청이 무작위로 다른 파드에 전달되고 있음을 알 수 있다. 이처럼 서비스는 늘 같은 형태로 제공되지만 내부적으로 파드는 변할 수 있음을 알 수 있다. 물론 클라이언트는 이것을 신경 쓰거나 알 필요가 없다.

 

마찬가지의 맥락으로 파드가 어떤 워커 노드에 스케줄링 되었는지는 그다지 중요하지 않다. 각 파드는 요청된 만큼의 리소스를 제공받고 각 파드 끼리 같은 노드에 있든 떨어져 있든 상관없이 통신할 수 있다. kubectl get pods 명령어로는 파드가 실행 중인 노드의 정보를 알 수 없다. 그만큼 중요한 정보가 아니기 때문이다.

kubectl get pods -o wide

위의 명령어를 이용하면 현재 실행중인 파드가 어느 노드에서 스케줄링되었는지 알 수 있다.

물론 파드의 세부 정보를 확인할 때, 노드 정보를 함께 출력할 수 있다.

kubectl describe pod suk9-gnrzs

파드가 어떤 노드에서 실행되고 있는지 알 수 있다.

 

쿠버네티스 대시보드

이쯤 되면, 대시보드가 있다면 꽤 편리할 것 같다는 생각이 든다.

kubectl cluster-info | grep dashboard #GKE 환경의 경우
minikube dashboard #minikube 환경의 경우

대시보드에 접속해 현재 쿠버네티스의 상황을 한눈에 확인할 수 있다.

 

다음 시간에는 파드에 대해 조금 더 깊이 있게 다뤄보자.