오늘은 금융권에서 다루는 파이프라인 기술을 찾던 중 나의 부족한 지식을 채워줄 글이 찾아 이를 리뷰해보려고 한다. 제목처럼 Why Kubernetes 에 대해 다루는 글이다. 요즘 많은 회사에서 쿠버네티스를 사용하는데 그 이유가 뭘까 정말 궁금했다. 나는 평소 습관 중에 하나가 왜? 라는 질문을 굉장히 많이 하는 것이여서 일 할 때도, 공부할 때도 왜 이 기술을 택했으며 왜 이렇게 접근해야 하는지를 제일 먼저 생각한다. 그런데 이런 나의 등을 시원하게 긁어주는 글을 발견하게 되었고 홀린 듯 술술 읽어보니 이해하기 쉽게 잘 쓴 거 같아 리뷰하기로 결정했다.
기술 블로그 출처
왜 Kubernetes 인가? How가 아닌 Why로 접근하는 Kubernetes 이야기
저는 네이버 파이낸셜 페이플랫폼에서 개발 업무를 담당하고 있는 김태우 입니다.
medium.com
Kubernetes 탄생 요약
* 필자의 주관적인 생각이다.
베어메탈 → VM → Docker → Kubernetes
1. 베어메탈
베어메탈(bare metal)이란, 하드웨어 상에 어떤 소프트웨어도 설치되어 있지 않은 상태를 말한다. 일반적으로는 이렇게 아무것도 없는 상태에 OS와 웹 서버 구축에 필요한 nginx나 mysql 같은 프로그램을 수동으로 설치해 서버를 사용하는 방식을 베어메탈 서버라고 한다.
근데 이러한 베어메탈 서버에서는 남의 소스코드를 내 컴퓨터에서 돌리는 게 쉽지 않았다. 서버마다 하드웨어가 다를 뿐 더러 하드웨어가 같다고 하더라도 조금씩 다른 리눅스 버전이 깔려있고 조금씩 다른 버전의 프로그램이 설치되어 있기 때문에 서로 충돌 없이 안정적으로 실행 되는 것이 굉장히 힘든 일이었다.
이를 해결하기 위한 해결책으로 나온 기술이 Virtual Machine, 즉 VM이다.
2. VM
VM이란, 물리적 컴퓨터와 동일한 기능을 제공하는 가상의 소프트웨어 컴퓨터이다. 호스트 하드웨어에서 실행하는 프로그램으로써, 호스트 OS 또는 호스트 시스템에서 실행하는 다른 VM과 분리하여 자체 게스트 OS 및 애플리케이션을 갖춘 격리된 환경을 제공한다.
VM은 위 그림과 같이 하이퍼바이저라는 플랫폼을 이용해 하나의 서버에 여러 개의 OS를 실행시킨다. 하이퍼바이저를 실행하는 기본 OS를 호스트 OS, 하이퍼바이저가 실행하는 분리된 OS를 게스트 OS라고 나눠서 지칭한다.
* 하이퍼바이저: 가상화 기술을 사용해 하나의 물리적인 서버에서 여러 개의 VM을 실행할 수 있도록 해주는 소프트웨어나 하드웨어
- 네이티브 하이퍼바이저: 물리적인 하드웨어 위에서 직접 실행되며 호스트 운영 체제와는 독립적으로 동작함. VM들을 직접 관리
- 주로 사용 환경: 데이터 센터, 엔터프라이즈 환경
- ex. VMware ESXi, Microsoft Hyper-V
- 호스트형 하이퍼바이저: 호스트 운영 체제 위에서 실행되며 물리적인 하드웨어와 하이퍼바이저 사이에서 인터페이스 역할을 함.
- 주로 사용 환경: 개인용 컴퓨터, 개발 환경
- ex. Oracle VirtualBox, VMware Workstation
Guest OS는 하이퍼바이저를 통해 구현된 가상의 OS이므로 OS의 모든 환경을 일정하게 관리 혹은 복제가 가능하다. 따라서 VM을 사용하면 버전 호환성에 대한 이슈 없이 동일하게 복제 할 수 있고, OS를 나눠서 사용할 수 있기 때문에 각 OS에 필요한 프로그램만 설치해 사용할 수 있다.
그러나 VM은 호스트 OS 위에 하이퍼바이저를 올리고 그 위에 게스트 OS를 띄우는 방식으로 작동하기 때문에 효율이 떨어지고 메모리 및 디스크 공간을 많이 사용했다.
이를 해결하기 위한 해결책으로 나온 기술이 Docker이다.
3. Docker
Docker란, 컨테이너 기반 가상화 플랫폼으로, 애플리케이션을 소프트웨어 컨테이너 안에 패키징하고 실행하는 기술을 제공하는 오픈소스 프로젝트이다. 이를 통해 개발자들은 소프트웨어를 더 빠르게 개발, 배포, 실행할 수 있다.
VM은 서로 독립된 게스트 OS를 사용하지만 Docker는 프로그램 실행에 필요한 binary파일과 library 파일들만 가지고 있다. Docker는 자체적인 OS를 사용하기 위한 방법으로 filesystem, library만을 포함하는 Linux Image를 사용하고, kernel은 호스트 OS의 커널을 공유한다. 이렇게 되면 자체 커널이 없기 때문에 매우 가볍다. 또한, 게스트 OS 위에서 구동 되지 않기 때문에 CPU와 Memory 자원이 완벽히 분리되지 않지만 Docker Engine이 개념적으로 분리해준다. 개념적으로 분리해주기 때문에 보안에 취약한 면이 있지만 VM에 비해 훨씬 빠르고 유연한 자원 분배가 가능해졌다.
* 전통적인 운영 체제(OS)는 커널을 기반으로 파일 시스템과 라이브러리를 포함하고 있다.
- 커널(kernel): 운영 체제의 핵심 부분으로, 하드웨어와 소프트웨어 간의 상호작용을 관리한다.
- 파일 시스템(file system): 물리적인 저장 장치에 파일을 구성하고 관리하는 방식, 컴퓨터 시스템에서 데이터를 구조화하고 저장하는 데 사용되며, 파일 및 디렉토리의 생성, 읽기, 쓰기, 삭제 등의 작업을 제공한다.
- 라이브러리(library): 재사용 가능한 코드와 함수의 집합으로, 프로그래머가 프로그램을 개발할 때 유용한 기능을 제공한다
즉, VM은 OS를 격리하고 Docker는 process를 격리한다. 또한, Docker는 linux container의 개념을 빌려왔기 때문에 각 격리된 프로세스들을 container라고 부른다. VM의 게스트 OS와 유사하게 Container도 복사가 가능한 파일이기 때문에 이 파일을 Container Image라고 부른다.
그러나 Docker에도 어려움이 있었다. Docker가 가볍고 빠르지만 Docker 서버를 관리해주는 개발자들은 걱정해야 할 포인트들이 많았다. 예를 들어, Docker 서버가 다운되면 해당 서버는 트래픽을 차단한 후, 수동으로 죽은 Docker 서버를 찾아내 새로 서버를 띄워야 했다. 그리고 매번 서버 업데이트를 진행할 때도 각각의 Docker 서버를 이미지만 바꿔 새로 올려야 했다. 만약 트래픽이 너무 많이 몰려 현재 서버로 처리가 힘들어지면, Docker 서버를 증설하고 트래픽이 줄면 Docker 서버를 다시 줄여야 했다.
이런 문제점들은 기존 서버에도 존재했기 때문에 기존 서버들도 여러가지 방법을 통해 이 문제들을 해결하기 위해 노력해왔고 Docker는 Kubernetes라는 솔루션을 통해 이 문제들을 해결했다.
4. Kubernetes
Kubernetes(쿠버네티스)란, container 관리 엔진으로, 모든 container 관리 작업을 자동화한 플랫폼이다. Docker 관리 엔진이라고 하지 않는 이유는 Kubernetes와 Docker가 가장 많이 사용되는 조합일 뿐 Linux container 개념을 구현한 많은 container 엔진이 Kubernetes와 호환이 가능하기 때문이다.
K8s를 사용하면 모든 container 관리 작업은 자동화 되기 때문에 유저는 K8s에서 어떠한 관리도 하지 않고 '선언'만 한다.
예를들어, 유저는 A 도커 서버를 5개 띄우겠다는 선언을 하면 k8s는 기존 환경에서 A 도커 서버 5개를 띄운다. 또한 k8s는 A 도커 서버들을 열심히 관찰하며, 하나의 서버가 다운되면 다시 A 도커 서버를 띄워 5개의 서버가 실행되는 상태를 유지하기 위해 노력한다.
즉, k8s는 '현재 상태'를 우리가 '선언한 상태'와 동일하게 만들도록 계속해서 노력하는 것이 핵심이다.
k8s에서 모든 개념은 object라는 단위로 구성되어 있고, 우리의 '선언' 역시 하나의 object이다. k8s가 관리하는 도커 서버도 Pod라는 object로 존재하고 도커 서버를 5개 유지하겠다는 선언은 ReplicaSet이라는 object로 존재한다. 다시 말해, ReplicaSet은 N개의 Pod를 k8s에 유지하기 위해 노력한다.
k8s는 매우 다양한 object를 제공한다. 심지어 우리가 직접 만든 Custom Object를 생성할 수도 있다. 이렇게 다양한 Object를 통해 우리는 우리가 원하는 상태를 자세하게 정의할 수 있고, K8s는 24시간 계속해서 우리가 원하는 상태를 유지하기 위해 노력한다.
다만, k8s는 엔진이 아닌 플랫폼이다. k8s는 자체 엔진을 제공하는 것이 아닌 k8s의 플랫폼을 구현한 Provider들을 통해 k8s를 제공한다. amazon Elastic Kubernetes Service(EKS), Google Kubernetes (GKE), Azure Kubernetes (AKS) 등이 이에 속한다.
Kubernetes 자체는 완전한 클라우드 인프라를 제공하지 않는다. k8s는 오픈 소스 프로젝트이며, 사용자가 직접 클러스터를 구축하고 관리해야 한다. 이것을 일반적으로 '바닐라 Kubernetes'라고 부른다.
많은 클라우드 제공업체들은 k8s의 배포와 관리를 간편하게 하기 위한 관리형 서비스를 제공한다. 이러한 서비스는 k8s를 기반으로 하여 특정 클라우드 제공업체의 환경에서 쉬벡 배포하고 관리할 수 있도록 도와준다.
이러한 관리형 k8s 서비스는 클라우드 제공업체의 인프라와 도구를 기반으로 k8s 클러스터를 프로비저닝하고 관리한다. 사용자는 클라우드 제공업체의 콘솔 또는 API를 통해 k8s 클러스터를 생성하고 관리할 수 있다. 일반적으로 클라우드 제공업체는 해당 서비스의 관리 및 운영에 대한 책임을 지며, 사용자는 애플리케이션의 개발과 배포에 집중할 수 있다.
후기
이러한 발전 과정을 살펴보니 컴퓨팅 환경이 점차 효율적으로 진화하고 있다고 느껴진다. 베어 메탈에서 가상화 기술인 VM이 탄생하고, 컨테이너화 기술인 Docker를 통해 더 가벼운 환경이 되었다. 현재는 kubernetes라는 컨테이너화된 애플리케이션들을 효율적으로 관리하고 배포할 수 있는 플랫폼이 생겨나 더 효율적인 환경에 있다. 점차적으로 시스템 관리와 개발 프로세스가 단순해지고 효율적으로 이루어지게 되면서 개발자들은 자동화된 도구를 이용해 더 효율적인 인프라를 관리할 수 있게 된 거 같다.
