[GCP]GKE 차근 차근 알아보기 2탄 — GKE 서비스 및 확장 해보기
안녕하세요 이정운 입니다.
지난번에 “GKE 차근 차근 알아보기 1탄 — GKE 개요” 를 통해서 간단하게 Google Kubernetes Engine(GKE) cluster 를 생성해보고 이를 통해서 GKE 개요에 대해서 살펴봤었는데 이번엔 조금 더 들어가서 지난번 이야기에서 생성한 GKE cluster 를 가지고 샘플 container 를 배포하고 간단하게 서비스가 동작하는 것을 살펴보도록 하겠습니다. 이를 통해서, GKE 안에서 어떻게 실제 Kubernetes 가 동작하는지를 보고/테스트 해보면서 이야기하는 시간을 가져 보도록 하겠습니다. 간단하고 작은 테스트이긴 하지만 이를 통해서 GKE 가 어떤 일을 할 수 있고 어떤 특성 및 장점을 가지고 있는지 파악이 가능하지 않을까 합니다.
기 언급 드렸지만 Kubernetes 에 대해서 일일이 설명하지는 않을 예정이며 GKE 입장으로 주로 이야기하도록 하겠습니다. 그러나 결국 GKE 의 동작을 설명 하다보면 아마도 그 얘기가 그 얘기가(?) 되지 않을까 합니다. ^^&
늘 강조하지만 본 이야기는 하단과 같은 좋은 링크를 참고해서 작성되었고 테스트 되었습니다.
Kubernetes engine Quickstart
https://cloud.google.com/kubernetes-engine/docs/quickstart
Kubernetes 101: Pods, Nodes, Containers, and Clusters
https://medium.com/google-cloud/kubernetes-101-pods-nodes-containers-and-clusters-c1509e409e16
Viewing Pods and Nodes
https://kubernetes.io/docs/tutorials/kubernetes-basics/explore/explore-intro/
#1) GKE 로 기본 서비스 해보기
역시나 이번에도 이런 저런 설명을 길게 하는 것보다 직접 한번 해보는 것이 더 나으실거라 GKE 로 기본 서비스를 배포해서 테스트하는 것을 먼저 진행해보도록 하겠습니다. 이를 위해서 GCP 환경이라면 Cloud Shell 로 접속한 후 하단의 kubectl 명령을 통해서 샘플 container 를 GKE cluster 에 배포 합니다.
kubectl run hello-server --image gcr.io/google-samples/hello-app:1.0 --port 8080여기서 기본 Kubernetes 를 해본 분들도 ‘gcr.io/google-samples/hello-app:1.0’ 라는 부분이 생소할텐데 이건 Google 의 비공개 container 저장소인 Google Container Registry(GCR) 의 주소 이며 더 정확히 들어가면 GCR 내의 hello-app 이라는 이미지의 주소입니다.
GCR 을 쉽게 말씀드리면 Docker 이미지를 관리하고, 취약성 분석을 수행할 수 있으며 세분화된 액세스 제어 기능으로 보다 높은 보안성을 제공할 수 있는 비공개 Docker 저장소 입니다. (말은 거창하지만 Google cloud 에서 쉽게 container 를 저장할 수 있는 비공개 저장소로 보시면 됩니다.)
https://cloud.google.com/container-registry/
결국 방금 실행한 명령은 GCP 에 있는 비공개 Docker 저장소인 GCR 의 hello-app 이라는 샘플 Docker 이미지를 가지고와서 GKE cluster 에 배포 및 실행하는 명령어로 보시면 됩니다.
지금 수행한 kubectl 명령은 단순하게 run 을 수행하지만 내부적으로는 Kubernetes 의 deployment 를 생성하게 됩니다. Kubernetes 의 CLI 도구인 kubectl 을 통해서 명령어로 deployment 상태를 확인할 수도 있으며 하단과 같이 관리콘솔의 Workload 메뉴에서도 지금 배포한 deployment 의 상태를 확인할 수 있습니다.
또한, GUI 형태가 아니라 개발자들에게 친숙한 yaml 형태로도 바로 메뉴에서 확인이 가능합니다. 저도 해보면서 느꼈는데 kubectl 로 간단하게 GKE cluster 에 배포해도 필요한 설정들이 자동으로 기본 적용되어 yaml 은 생각보다 내용이 많았으며, 이를 조금 더 찬찬히 공부하게 되면 Kubernetes 를 더 이해하는데 도움이 되지 않을까 합니다.
테스트로 hello-app 이라는 container 를 GKE cluster 환경에 배포했으니 이제 이를 실제적으로 외부에서 서비스하기 위해 노출해주는 작업을 수행하도록 하겠습니다. 이번에도 kubectl 을 이용해서 하단과 같이 수행합니다. (Kubernetes 를 테스트해보시면 아시겠지만 생각보다 많은 작업이 kubectl 이라는 CLI 도구를 통해서 이루어집니다. 해보시면 작업은 이게 제일 편하긴 합니다.) 그리고 나서 ‘kubectl get service’ 명령을 통해서 service 를 확인해보면 지정된 이름으로 service 가 생성되고 LoadBalancer 타입이기 때문에 external-ip 가 매핑된 것을 확인할 수 있습니다.
kubectl expose deployment hello-server --type LoadBalancer --port 80 --target-port 8080그러면 이제 실제 서비스를 확인해보기 위해서 브라우저에서 external-ip 로 호출하면 하단과 같이 샘플 서비스의 서비스 결과가 잘 나오는 것을 확인할 수 있습니다.
추신: Kubernetes 를 공부하다 보면 처음에 제일 헷갈리는 것이 service 타입으로 ClusterIP, NodePort, LoadBalancer, Ingress 등등 각 차이가 잘 이해가 안됩니다. 제가 봤을때 그 부분에 대해서 각각의 특징을 그림을 통해서 제일 잘 정리해둔 이야기가 하단의 글이지 않을까 하며 혹시 자세한 내용이 궁금하신 분들은 링크 참고하시기 바라겠습니다.
Kubernetes NodePort vs LoadBalancer vs Ingress? When should I use what?
https://medium.com/google-cloud/kubernetes-nodeport-vs-loadbalancer-vs-ingress-when-should-i-use-what-922f010849e0
브라우저를 이용해서 테스트 서비스가 잘 되는걸 확인했으면, 급 궁금해지는 부분은 “실제 LoadBalancer 역할은 누가 하고 있을까” 이지 않을까 합니다. 그래서 찾아보니 하단과 같이 GKE cluster 에서 LoadBalancer 객체를 만들때 자동으로 GCP 의 Internal Loadbalancer 를 생성해서 하단과 같이 IP 와 backend 설정까지 알아서 해주고 있더군요. (관리콘솔에서 GKE cluster > Services > Service 명 > Details 에 생성한 Load Balancer 이름을 확인 가능합니다.)
추가적으로 방금 생성한 service 도 관리콘솔의 Services 메뉴에서 상태를 확인할 수 있으며 yaml 파일로도 확인 가능합니다.
#2) GKE cluster 확장 하기
이전 파트에서 간단하게 샘플 container 를 이용해서 GKE cluster 로 서비스를 배포하고 브라우저를 이용해서 서비스 테스트를 해봤습니다. 이제는 다음 단계로 해당 서비스를 이리 저리 확장해 보면서 GKE cluster 가 어떻게 동작하는지 확인 해보도록 하겠습니다. (사실 결국은 Kubernetes 가 어떻게 동작하는지 확인이 될듯 합니다.)
GKE cluster 에서 서비스를 수행하는 pod 의 확장은 굉장히 쉬우며 하단과 같은 kubectl 명령으로 바로 pod 를 확장 할 수 있습니다. (참고로 pod 는 Kuberentes 서비스의 최소 단위이자 집합이며 하나 이상의 Container 로 이루어 집니다. 이 부분이 더 궁금하신 분은 해당 링크를 참고하세요 — https://kubernetes.io/docs/tutorials/kubernetes-basics/explore/explore-intro/ )
kubectl scale deployment hello-server --replicas=3당연히, kubectl scale 명령만이 아니라 refplica 가 3 으로 설정된 deployment yaml 자체를 새로 만들어서 적용하는 방식을 통해서도 pod 확장을 수행할 수 있습니다. 이렇게 replica 의 개수를 증가하면 Kubernetes 는 내부적으로 ReplicaSet 을 통해 실제 pod 의 개수도 3개로 맞추게 됩니다.(ReplicaSet 은 지정된 수의 pod 복제본이 수행되도록 하는 기능을 가지고 있으며 좀 더 자세한 사항이 궁금한 분들은 이 링크를 참고하세요 – https://kubernetes.io/docs/concepts/workloads/controllers/replicaset/)
그런데 이때, pod 를 확장하면 생각하는 가장 쉬운 오류중의 하나는 pod 를 3개로 확장했을 때, 당연히 node 가 3개이니 고르게 잘 node 당 pod 하나씩 올라가서 구동할 것이라는 착각 입니다. 확인해 보시면 아시겠지만 kubernetes 는 그렇게 쉽게(?) 예전 분산 환경처럼 구동되지 않으며 Stateless 상태인 pod 의 사상에 맞추어서 구동됩니다. Kubernetes 입장에서는 별도로 지정된 정책이 없다면 node 를 보고 자원적으로 가능하다면 pool 에서 꺼내서 그냥 pod 를 위치 시킵니다. Pod 를 3개로 늘려달라는 명령이므로 그저 큰 고민 없이 node pool 안에 pod 를 3개만 만드는 거죠. (사실 scheduler 가 고민을 많이 하긴 하는데 지금은 그런 조건에 닿지 않을 것이기 때문입니다. 이리 저리 숫자를 변경해서 테스트 해보시면 아시겠지만 들쭉 날쭉 합니다.)
kubectl get pod -o wide일반적인 분산 운영환경을 경험해보신 분들에게는 이해가 가지 않는 상황이겠지만 Kubernetes 입장에서 보면 현재로서는 문제도 없고 당연할 수도 있습니다. (기존 개념을 깨는게 이해가 더 편할수 있습니다 ^^&)
만약 좀 더 분산환경에 적합하고 안정적으로 3 개의 pod 가 이쁘게(?) 3개의 Node 로 각각 분산되기를 원한다면 kubernetes 의 다양한 정책을 통해서 그렇게 구성할 수도 있습니다. 이러한 작업을 위해서 Kubernetes 에서는 라벨을 보고 pod 를 지정된 node 로 배포할 수 있는 nodeSelector 를 제공하며, 이에 추가하여 조금 복잡하기는 하지만 사용자가 다양한 조건을 지정해서 조절할 수 있는 affinity 와 anti-affinity 를 node 단위와 pod 단위 정책으로 적용하여 사용할 수도 있습니다.
예를 들어 상단과 같이 podAntiAffinity 를 적절히 만들어서 기존 배포된 환경에 적용하게 되면 하단과 같이 3개의 pod 가 3개의 node 에 분산되어서 서비스 가능하게 만들 수 있습니다.
이러한 Advanced scheduling 에 대해서 조금 더 자세한 내용이 궁금하신 분들은 하단의 링크를 참고하시기 바라겠습니다.
Advanced Scheduling and Pod Affinity and Anti-affinity
https://docs.openshift.com/container-platform/3.6/admin_guide/scheduling/pod_affinity.html
마지막으로 pod 에 대한 확장을 넘어서 Node 에 대한 확장을 원하는 경우가 있을 수 있습니가. 이런 경우라면 GCP 의 관리콘솔에서 GKE cluster 를 선택하고 Edit 를 클릭한 후에, 하단에서 보는 것과 같이 Size 만 변경하시면 Node 에 대한 확장 및 축소를 아주 손쉽게 하실 수 있습니다. (각자 편한 방식을 사용하면 됩니다.)
여기까지 잘 따라오셨다면 “GKE 차근 차근 알아보기 2탄 — GKE 서비스 해보기” 를 무사히 테스트 해보신 것입니다. 이미 이야기를 보셔서 아시겠지만 크게 복잡한 내용을 다루기 보다는 간단한 샘플 container 를 실제적으로 만들어둔 GKE cluster 에 배포하고 서비스를 해보는 형태로 진행 하였습니다. 그리고 이에 덧붙여 Kubernetes 의 장점 중의 하나인 pod 나 node 를 확장하면서 기본적으로 GKE cluster 가 어떻게 동작하는지를 살펴봤습니다.
아주 쉽고 간단하게 테스트 해봤지만 GKE 를 사용하는 기본적인 방법으로 향후 실제로 GKE 를 사용해서 운영하실 때에도 많이 사용하지 않을까 합니다. 그럼 이번 이야기는 여기서 마무리 하고 다음에 다른 이야기로 다시 돌아오겠습니다. 그럼 이만 휘리릭~~~
* Disclaimer: 본 글의 작성자는 Google 직원이지만 Google cloud 를 공부하는 한 개인으로서 작성된 글입니다. 본 글의 내용, 입장은 Google 을 대변하지 않으며 Google 이 해당 콘텐츠를 보장하지 않습니다.
