시스템 엔지니어에 가까운 인프라 인턴을 진행하면서 공부한 내용들을 인프라 파트에 정리할 생각이다.
1. 배포 방식의 변화
위 그림은 쿠버네티스 공식자료에 게시된 그림이다.
전통적인 방식의 배포방식부터 컨테이너 기반의 배포방식까지 시스템 구조를 나타낸 그림이다.
1-1. 전통적인 배포
기존 전통적인 방식으로 베어메탈 위에 OS를 올리고, 바로 App를 배포하는 방식은 단점이 있었다.
서로 다른 App들이 OS와 자원을 공유하면서 발생하는 단점들이다.
- OS를 공유하고 있어 패키지 버전 문제로 App 호환성 문제가 발생하기 쉽다.
- 자원을 공유하고 있어 App 사용하는 자원에 따라 다른 App 성능에 영향을 줄 수 있다.
1-2. 가상화 기반 배포
그렇게 나온 것이 가상화 기반 배포 방식이다.
<참고>
위에 그림에는 가상화 Type2로 베어메탈-OS-Hypervisor 순으로 올라가 있는데, 베어메탈 위에 Hypervisor를 직접 올리는 Type1도 있다.
이는 하나의 큰 서버를 작은 단위의 VM으로 나누어 사용하여 서버를 좀 더 효율적으로 사용할 수 있게 도와주고, VM에 떠 있는 App이 다른 VM 위에 떠 있는 App에 영향을 주지 않는다는 장점이 있다.
하지만 이것도 단점이 있다.
- VM마다 OS를 설치를 하기 때문에, 오버헤드가 발생한다.
- VM이 할당받은 자원을 모두 활용하는 것이 아니기 때문에, 의미 없이 남는 자원이 발생한다.
- 무겁다.
1-3. 컨테이너 기반 배포
그렇게 나온 것이 컨테이너 기반 배포방식이다.
VM은 OS부터 격리하였지만, 컨테이너는 OS를 공유한다. 다만, VM과 마찬가지로 컨테이너는 자체 파일 시스템, CPU 점유율, 메모리, 프로세스는 격리가 되어있어 클라우드나 OS 배포본에 모두 이식할 수 있다. 그리고 가볍다.
하지만, 단점은 다음과 같다.
- OS를 공유하고 있어 컨테이너 하나라고 보안에 취약점이 발생하면 전체가 위험해진다.
- 컨테이너는 프로세스이므로 데이터 영구 저장을 위해 별도의 스토리지 솔루션이 필요하다
- 컨테이너 간의 네트워크 설정이 복잡하다.
- 이식은 용이한데, 다른 OS와 호환성 문제가 발생할 수 있다.
배포할 서비스의 규모, 형태, 지불할 수 있는 비용과 같이 여러 조건을 따져보고 배포방식을 선정하면 된다.
그래도 최근 클라우드 환경이 떠오르면서 가장 마지막에 나온 컨테이너 기반 배포방식을 많이 활용하고 있다.
여기서 컨테이너가 많아지고, 여러 서버에 띄워진 컨테이너들이 서로 상호작용을 하며 하나의 서비스를 이룰 때, 이걸 어떻게 관리를 할까?
서버 하나하나 들어가서 컨테이너에 접근해 이슈를 파악하고, 컨테이너 간의 통신을 위한 네트워크 설정도 모두 일일이 다 하고 있으면 부서진 모니터와 키보드만 늘어날 것이다.
그래서 나온 것이 바로 Kubernetes (K8s) 이다.
2. Kubernetes
바로 쿠버네티스의 구성요소로 들어가기 전에 전체적인 그림을 보겠다.
위에 그림에서 컨테이너 배포환경을 가져와 쿠버네티스의 구조를 그린 것이다.
여러 대의 서버가 쿠버네티스를 통해 한 클러스터로 묶여 각각의 서버는 노드의 역할을 하고 있다.
가상화 기반의 배포환경보다 가볍고 효율적으로 보인다.
그런데 큰 서버에 쿠버네티스 환경을 구성할 때 전체적인 그림은 다음과 같다.
이러한 방식 때문에 쿠버네티스를 사용하는 이유를 납득하는 데 오래 걸렸다.
가볍고 효율적인 컨테이너 배포방식을 채택하고, 그 컨테이너를 잘 관리하려고 쿠버네티스를 사용하는 것이 아니였나?
하나의 베어메탈 위에 하이퍼바이저를 올리고, 여러대의 VM을 각각 노드로 취급해서 쿠버네티스로 묶으면 성능 저하가 있지 않나? ← 여기서 막혔다.
단점은 다음과 같다.
- 이중 오버헤드: VM 오버헤드, 컨테이너 런타임 오버 헤드
- 자원 낭비: VM이 자체 커널과 OS를 가져야되서 기본 메모리/디스크 소비가 증가
- 복잡성 증가: VM관리, Kubernetes 관리
성능 저하가 있음에도 VM 위에 쿠버네티스를 띄울 때, 장점은 다음과 같다.
- 보안: 하이퍼바이저를 통해 커널까지 분리되어 컨테이너 간 취약점 전파 위험이 어느정도 해소
- 클러스터 관리: 노드를 VM으로 쉽게 생성, 삭제, 스냅샷 복원을 할 수 있어 운영이 간편
- 노드 자원 관리: VM 자체에서 자원을 명확하게 제한 가능
보안, 클러스터 및 노드 관리에 이점이 있기 때문에 어느정도 성능 감소를 부담하고, VM 위에 쿠버네티스를 띄워 활용한다.
가상화 기반 배포환경의 단점이였던 낭비되는 자원의 문제는 클러스터 내의 노드의 자원 상황에 맞추어 Pod가 뜨기 때문에, 남는 자원 문제는 해결된다. (VM에 남는 자원이 영영 안쓰이는 것이 아니다)
오히려 큰 서버를 하나의 노드로 사용하는 것이 성능에서 이점이 있을 수 있지만, 운영상의 장점이 있어서 VM 위에 쿠버네티스를 띄워 활용한다.
그리고 서버를 여러대 사서 하나로 묶는 것보다 큰 서버 하나를 사서 나누어 구성하는 게 유지보수, 비용적 측면에서 유리하다.
３. Kubernetes 장단점
VM 위에 쿠버네티스 납득완료. 그러면 쿠버네티스를 왜 쓸까?
컨테이너 배포환경에서 여러 개의 컨테이너를 관리하려고 쓰는 것이다. 그에 따른 장단점은 다음과 같다.
장점
- 고가용성: Pod, 노드, 컨트롤 플레인 장애 시 자동 복구
- 자동화: 배포, 스케일링, 업데이트 등을 자동으로 관리
- 서비스 디스커버리 및 로드밸런싱: ClusterIP, Ingress 등으로 트래픽 자동 분산
- 자원 최적화: 노드에 적절히 Pod를 배치하고 자원 낭비 줄임
- 이식성/플랫폼 독립성: 어떤 클라우드/OS에서도 동일한 방식으로 실행
- 멀티테넌시 및 격리: 네임스페이스, RBAC 등으로 논리적 격리
단점
- 러닝커브: 러닝커브 각도가 가파르다 못해 수직이다. 어렵다.
- 운영 복잡성: 설치, 보안, 업데이트 등 손이 많이 감
- 자원 오버헤드: kubelet, kube-proxy, controller-manager 등 기본 데몬들이 자원 소모
- 어려운 디버깅: 컨테이너 하나가 죽었을 때, 원인 파악을 위해
kubectl logs,kubectl describe, events, metrics 등 여러 단계를 거쳐야 함
결국, 단점들은 고수가 등장하면 해결되는 일들이라 어느정도 규모가 있는 프로젝트라면 쿠버네티스를 활용하지 않을 이유가 없다.
쿠버네티스를 활용하는 이유는 이해가 되었었지만, VM위에 쿠버네티스를 세팅하는 이유가 이해가 안되서 초입에서 길을 잃었다.
다음은 쿠버네티스의 구성요소에 대해 다뤄보겠다.
