모놀리틱 아키텍쳐에서 마이크로서비스 아키텍쳐의 전환은 하나의 서비스를 여러 컴포넌트로 나눈 뒤, 필요한 컴포넌트만 배포 및 운영할 수 있다는 장점을 가지게 하였다. 그러나, 이런 컴포넌트들의 수가 많아지면 컴포넌트들 간의 종속성이 높아진다. 이 때, 어떤 컴포넌트는 옛날 버전의 라이브러리를 필요로 하는 반면, 어떤 컴포넌트는 최신 버전의 라이브러리를 필요로 하게 되는 경우가 생길 수 있다. 이 상황에서, 그 라이브러리가 환경별로 특수한 요구 사항이 있다면 (ex. GLIB 등등) 배포가 매우 골치 아파진다.
Kubernetes를 사용하면 하드웨어를 추상화(요구 사항에 맞는 운영체제 인스턴스 제공) 하여 개발자가 위와 같은 상황을 위해, 환경설정을 하거나 하드웨어 인프라를 건드려야 하는 상황을 해결할 수 있다. 따라서 개발자는 하드웨어 인프라를 전혀 알지 못하더라도 운영팀을 거치지 않고(필요한 리소스 제공 논의, 운영체제 환경에 대한 논의 후 운영팀에게 서버를 받는 행위 등) 어플리케이션을 직접 배포할 수 있다.
Kubernetes와 친해지기 위해서 가장 먼저 컨테이너에 대한 이해가 선행되어야 한다. 컨테이너는 경량화된 Virtual Machine을 만든다고 보면 된다. 리눅스 호스트 머신이 있을 때, 각자 다른 리눅스 환경 기반의 가상 격리 환경을 제공 해준다고 생각하면 된다. 이렇게 되면 뭐가 좋냐? 마이크로서비스 아키텍쳐로 전환된 서비스의 각각의 컴포넌트가 다른 컨테이너에서 실행된다고 가정해보자. 말 그대로 '격리' 되어 있는 환경을 만들 수 있기 때문에, 하나의 컴포넌트가 뻗어서 crash 나도, 다른 컴포넌트 서비스의 영향을 주지 않는다. 격리의 예를 억지로 들자면... (ex. 나와 어떤 여자가 카카오톡 PC 버전으로 각자의 컴퓨터로 대화한다고 가정했을 떄, 내 카톡이 프로그램이 멈춘다고 그 여자의 카톡 프로그램은 멈추지 않는다...)
VM과의 차이점이 보이는가? 컨테이너가 혁신인 이유는 '경량화'된 '가상'의 '격리' 환경을 제공한다는 것이다. 물론 커널을 공유하니까, 동일 커널 기반으로 만든 OS만 가상화 환경으로 컨테이너를 만들 수 있다. 반면에 VM은 OS 커널 자체를 새로 다 설치하고(그래서 무겁다), Hypervisor가 이 가상 OS의 커널 실행을 Host OS의 커널 실행으로 해석해준다.
작성 중..