NKS로 쿠버네티스 이해하기 - 1

쿠버네티스란 무엇일까? 많이 들어봤지만, 단순히 "컨테이너를 관리하는 플랫폼" 정도로만 알고 있었다. 그러다 무료로 NKS(Naver Kubernetes Service)를 사용할 기회가 생겨, 클라우드 플랫폼에서 쿠버네티스를 직접 다뤄보면서 구조와 개념을 더 깊이 이해할 수 있었다.

 

기존에 서버를 배포할 때는 EC2 같은 인스턴스를 띄우고, 그 안에서 코드를 GitHub에서 가져오거나 Docker 이미지를 통해 배포하는 방식을 사용했었다. 즉, 하나의 서버 안에서 이미지를 여러 개 띄우거나, 코드를 빌드한 뒤 백그라운드에서 서버를 실행시키는 방식이었다. 그래서 처음엔 쿠버네티스도 이런 ‘서버 안에서 동작하는 기술’이라고 생각했고, 그 개념을 이해하는 데 시간이 좀 걸렸다.

 

물론, 서버 안에서 이미지를 띄우는 부분은 쿠버네티스도 유사하다. 하지만 결정적인 차이는 쿠버네티스는 그 '서버' 자체도 관리 대상이라는 점이다. 쿠버네티스에서 전체 환경을 클러스터(cluster)라고 부르며, 이 클러스터 안에는 노드(node)라는 단위가 존재한다. 이 노드 하나하나가 우리가 기존에 사용하던 서버나 가상머신(VM)과 같은 역할을 한다.

 

즉, Docker Compose가 컨테이너를 관리하는 도구라면, 쿠버네티스는 컨테이너뿐 아니라 서버(노드)까지 통합적으로 관리하는 플랫폼인 것이다. 이 차이를 이해하고 나니, 쿠버네티스가 왜 대규모 시스템 운영에 적합한지 조금은 감이 잡혔다.

 

쿠버네티스에서 구성 요소.. Pod?

쿠버네티스 클러스터 안에는 Pod라는 개념dd이 존재한다. Pod는 쉽게 말해 컨테이너를 감싸는 단위이며, 하나 이상의 컨테이너가 들어갈 수 있기 때문에 컨테이너들의 집합이라고 표현하는 게 더 적절하다.

기존에는 컨테이너를 EC2 같은 VM 안에서 여러 개 띄워서 사용했기 때문에, 쿠버네티스에서도 노드(=VM) 안에 여러 개의 Pod를 만드는 구조라고 생각했다. 실제로 노드 안에서 Pod가 동작하는 건 맞지만, 처음엔 개념적으로 조금 혼란스러웠다.

왜냐하면, 쿠버네티스에서는 클러스터라는 전체 환경 안에 노드와 Pod가 모두 존재한다. 즉, Pod가 노드 안에 올라가긴 하지만, 처음부터 특정 노드에 소속되어 만들어지는 것이 아니라, 클러스터라는 추상적인 공간 안에서 먼저 생성된다. 그리고 나서 쿠버네티스가 적절한 노드를 선택해 해당 Pod를 올려주는 방식이다.

결과적으로 Pod는 노드 위에 배치되지만, 사용자는 이를 직접 신경 쓰지 않아도 된다. 쿠버네티스가 자동으로 스케줄링하고 배치해주기 때문이다. 겉보기에는 노드 안에서 Pod가 동작하는 것처럼 보이지만, 실질적으로는 Pod와 노드는 쿠버네티스가 추상화한 구조 안에서 서로 연결되어 작동하는 개념이라고 이해하는 것이 맞다.

 

서버를 늘릴 때는 어떻게 하지..?

EC2에서 트래픽이 많아지거나 서버를 확장해야 할 일이 생기면, 동일한 이미지를 기반으로 컨테이너를 여러 개 띄우는 방식으로 대응하곤 했다. 그런데 쿠버네티스를 사용하게 되면서, 이런 상황에서 어떻게 확장할 수 있을지에 대해 조금 더 고민해보게 되었다.

쿠버네티스도 기본적으로는 비슷하다. 트래픽이 많아지면 먼저 Pod의 수를 늘리는 방식으로 확장한다. 이 점은 기존과 동일하다. 하지만 쿠버네티스에서는 노드(VM)도 여러 개 운영할 수 있기 때문에, 단순히 컨테이너 수만 늘리는 것이 아니라, 필요하다면 노드 자체도 늘릴 수 있는 구조라는 점에서 확장 방식에 차이가 있다.

즉, Pod를 늘리면 쿠버네티스는 이를 적절한 노드에 분산시킨다. 그런데 만약 기존 노드들이 포화 상태라 더 이상 Pod를 수용할 수 없다면, 새로운 노드를 추가하여 Pod를 배치하는 구조로 확장할 수 있다.

 

기존 방식은 컨테이너 단위의 수평 확장만 가능했다면, 쿠버네티스는 컨테이너(Pod)의 수평 확장뿐만 아니라, 노드(VM) 단위의 수직 확장까지 가능하기 때문에 훨씬 더 유연하고 대규모 시스템에도 적합하다는 생각이 들었다.

이런 구조를 직접 경험해보면서, 왜 쿠버네티스가 대규모 서비스에 적합하고 널리 사용되는지, 또 왜 소규모 서비스에는 오히려 과한 선택일 수 있는지를 깨닫게 되었다. 쿠버네티스는 관리 범위와 복잡도가 크기 때문에, 작은 서비스에서는 굳이 신경 쓰지 않아도 될 부분들까지 관리해야 하게 되고, 그게 오히려 비효율로 작용할 수 있다는 점이 단점으로 느껴졌다.

 

쿠버네티스는 Pod를 노드 안에 배치만 하는거라면서..?

처음에는 Pod가 노드 안에서 생성되는 줄 알았지만, 실제로는 클러스터라는 쿠버네티스 환경에서 생성되고, 이후에 적절한 노드로 배치된다는 것을 알게 되었다. 이 과정을 이해하다 보니 "그렇다면 노드는 단순히 자원을 제공하는 존재인가?"라는 의문이 들었고, 실제로도 그런 역할에 가깝다는 생각이 들었다.

기존의 EC2 기반 방식에서는 하나의 서버(인스턴스)가 자원 제공도 하고, 컨테이너 관리까지 직접 수행했다. 반면에 쿠버네티스에서는 이 역할이 명확하게 분리되어 있다.

클러스터는 전체를 통제하고 관리하는 중앙 제어 역할, 노드는 필요한 CPU, 메모리 같은 리소스를 제공하는 역할, 그리고 Pod는 실제 실행 단위(컨테이너 집합)로 동작하는 구조다.

흔히 쿠버네티스를 "오케스트레이션 도구"라고 부르는데, 이 비유가 정말 잘 들어맞는다고 느꼈다.

클러스터는 지휘자, Pod는 악보, 노드는 악기 또는 연주자라고 할 수 있다.

지휘자인 클러스터가 전체를 설계하고, 어떤 악보(Pod)를 어떤 연주자(노드)에게 맡길지 결정한다. 노드는 자신이 맡은 악보대로 충실히 연주(실행)만 하면 된다. 이처럼 관리와 실행이 철저히 분리된 구조가 쿠버네티스의 큰 장점이자, 복잡하지만 유연한 시스템을 가능하게 해주는 핵심인 것 같다.