안녕하세요. 번개장터 백엔드 엔지니어 박상조입니다. 먼저 간략하게 쿠버네티스에 대해 설명을 하겠습니다.
Kubernetes(이하 k8s)는 Google에서 개발한 Container Orchestration tool입니다. 그렇다면 Container Orchestration은 또 뭔가 하시는 분들이 계실 텐데요. 아마 Docker를 이용해 환경을 구성해 보신 분들이라면 불편한 점들이 많으셨을 겁니다. 예를 들면 장애 복구, 로드 밸런싱, 서비스 노출 등 여러 가지로 신경 쓸 점이 많으셨을 겁니다. 여기에 서버가 1대가 아니고 대형 환경을 구성 중이라면 상황은 더더욱 나빠질 겁니다.
이런 문제를 해결하기 위해 나온 도구가 Container Orchestration tool 입니다. 여러 서버를 묶어 클러스터로 관리 하고 컨테이너를 적절한 위치에 배포하고 자동으로 복구합니다. 그뿐만 아니라 업데이트, 롤백, 추가 등 수 많은 일을 합니다. 따라서 관리자가 어떤 서버에 어떻게 배포가 되는지 어떻게 서비스가 되는지 쉽게 결정하고 관리할 수 있습니다.
그럼 왜 k8s일까요? k8s 외에 Container Orchestration tool이 없는 것은 아닙니다. k8s의 장점에 대해 이것저것 비교한 글들은 많으니 넘어가고 단순히 점유율만 보더라도 현재는 거의 고민할 필요가 없을 정도로 압도적인 점유율을 보입니다. 또, AWS, Azure 등 큰 클라우드는 k8s에 기반을 둔 서비스를 제공하고 있습니다. 앞으로 당분간은 아마 k8s를 대체할 녀석이 나오지 않을 것 같습니다.
서론이 길었는데 그럼 우선 k8s의 구조에 대해서 간단하게 알아보겠습니다.
먼저 k8s는 클러스터가 크게 두 종류로 이루어집니다. 바로 Master와 Node인데 굉장히 간단한 구조입니다. 전체 클러스터를 관리하는 Master가 존재하고 실제 컨테이너가 배포되는 노드가 존재합니다. 그림으로 표현하면 아래와 같습니다.
여러 오브젝트가 있지만 여기선 앞으로 필요한 5가지 오브젝트만 설명해 드리겠습니다.
Pod은 k8s에서 컨테이너를 배포하기 위한 기본 단위입니다. 따라서 모든 컨테이너는 Pod을 통해 배포됩니다. 물론 컨테이너를 하나씩 배포할 수 있지만 k8s에서는 관련 컨테이너를 묶어 배포할 수 있습니다. 그림으로 표현하면 당연히 아래와 같은 모습입니다.
특이한 점은 이 Pod 내에서 컨테이너 간에는 localhost로 통신이 가능하고 디스크 볼륨을 공유할 수 있습니다.
보통 서비스 환경에서 이런 Pod들은 한 서비스에 한 Pod만 떠서 운영하지 않기 때문에 여러 Pod를 동시에 띄우고 업데이트하기는 불편합니다. 이런 일을 해주는 오브젝트가 바로 Deployment입니다. 이 Deployment를 통해 Pod의 개수와 이미지를 제어하고 관리할 수 있습니다. 이 Deployment의 이미지를 변경하면 Deployment 오브젝트가 알아서 롤링업데이트를 수행합니다.
컨테이너처럼 Pod도 저장공간이 영구적이지 않습니다. Pod이 내려가면 저장공간의 데이터도 같이 사라지게 됩니다. 이를 피하고자 Docker에서와같이 Volume을 Pod에 마운트 해서 사용 합니다. Volume에도 여러 종류가 있지만, 이 포스트에선 다루지 않겠습니다.
Namespace는 k8s의 논리적 구성단위입니다. 여러 오브젝트를 여러 Namespace로 나눠 관리할 수 있습니다. 접근 권한이나 리소스 할당도 가능합니다.
이렇게 구성한 환경을 노출하긴 위해서 필요한 오브젝트가 Service입니다. 보통 서비스를 할 때에 서비스 하나당 Pod 하나로 하는 경우는 굉장히 드물 것입니다. 그래서 k8s는 Pod에 label이라는 속성이 존재합니다. key, value 쌍으로 되어 있는 이 속성에 따라 Service가 실제로 서비스를 하는 구조입니다.
위의 오브젝트들이 실제 환경에서 서비스되는 모습을 그림으로 보면 다음과 같이 표현될 수 있습니다.
1과 2 두 가지를 서비스하고 있으며 1은 3개의 Pod로 2는 1개의 Pod로 서비스하고 있습니다. Deployment가 Pod의 수와 상태를 관리하고 있고 1번 서비스는 Namespace 1로 논리적으로 분리돼 있습니다. 위 그림에서는 Service가 모두 외부로 연결되지만 실제로는 그렇지 않은 Service도 존재하고 연결 방법도 달라질 수 있습니다. 이에 관해서는 포스팅이 너무 길어지는 관계로 생략하도록 하겠습니다. 중요한 개념이니 모르신다면 꼭 개인적으로 알아보시길 바랍니다.
이제 k8s를 사용하는 이유와 대략적인 구조를 알아봤습니다. 최종적으로 구성된 모습은 위와 조금 다르겠지만, 기본적인 원리와 모습은 위에서 설명한 것에서 벗어나지 않습니다. 제 포스팅을 이해해 나가는 데 꼭 필요한 정도만 아주 적게 설명한 내용이므로 실제 서비스를 구성하실 때에는 k8s에 대해 더 자세히 공부하시길 바랍니다.
읽어주셔서 감사합니다. 다음 포스팅으로 뵙겠습니다.
가입하기
