쿠버네티스 1편: 입문자에게 쿠버네티스가 어려운 이유 (+ 쿠버네티스와 도커 차이)

저번주 수요일 글또 멤버 분들과 진행하는 도쿠(도커+쿠버네티스) 스터디에서 드디어 쿠버네티스 진도를 나가게 되었다.
이름은 많이 들어봤지만 항상 막연하기만 했던 쿠버네티스다.

 

이번 편은 단순 쿠버네티스 설명글과는 다르게, 이렇게 차별화를 해보려고 한다:

 

1. 입문자가 쿠버네티스를 어렵게 느낄 수밖에 없는 이유
2. 쿠버네티스의 어원과 등장 배경
3. 쿠버네티스에 대해 초보자가 갖기 쉬운 오해 + 헷갈릴 만한 질문 정리
4. AWS ECS(Elastic Container Service) 대신 굳이 쿠버네티스를 써야 하는 이유

 

 

---

 

입문자에게 쿠버네티스가 어려운 이유

처음 쿠버네티스를 공부하려고 구글에 검색했을 때 '도대체 이게 뭔 소린가?' 싶었다.
그래서 혹시 몰라서 '쿠버네티스가 어려운 이유'를 구글에 검색해봤는데, 별다른 블로그 검색 결과는 안 나오는 걸 보니 나만 그렇게 느낀 걸 수도 있겠다.

일단 위키피디아에 들어가서 쿠버네티스 개념을 설명하는 부분을 읽어보자.

 

 

쿠버네티스는 CPU, 메모리, 사용자 지정 메트릭스에 기반하여 애플리케이션을 디플로이하고 유지보수하고 스케일인/스케일아웃을 하는 총체적인 매커니즘을 제공하는, 프리미티브(primitive)로 불리는 빌딩 블록들의 집합을 정의한다.
쿠버네티스는 느슨하게 결합되어 있으며 각기 다른 부하를 충족하기 위해 확장이 가능하다. 이 확장성은 크게는 쿠버네티스 API에 의해 제공되며 내부 구성 요소뿐 아니라 쿠버네티스에서 실행되는 확장 기능과 컨테이너에서도 사용된다.
플랫폼은 오브젝트라는 이름의 리소스를 정의함으로써 연산 및 스토리지 자원을 통제하며 이후 이것들을 관리한다.

 

 

사용자 지정 메트릭스, primitive, scaling, object...

원래 위키피디아 설명이 그리 가독성이 좋지는 않은 걸로 알고 있지만 그래도 여전히 감을 잡기 어려웠다.
또 쿠버네티스에 대해 좀 더 깊게 공부하려고 해도 pod, node, control plane 등 생소한 용어 때문에 여러 번 포기하고 싶을 때도 있었다.

 

곰곰이 생각해보면 쿠버네티스가 학습 진입장벽이 높은 이유는 크게 세 가지로 정리할 수 있을 것 같다.

 

1. 쏟아지는 낯선 용어들
2. multi-container 배포 및 관리는 실무 말고는 직접 경험해볼 기회가 거의 없기 때문
3. 코드 설명이 없기 때문

 

예를 들어 난 대학생 때 웹 개발을 토이 프로젝트로나마 잠깐 건드려본 경험이 있기 때문에, 새로운 프론트엔드 라이브러리를 익힐 때 금방 이해할 수 있다.

 

하지만 다중 컨테이너로 앱을 관리하고 배포하는 건 나처럼 실무 경험이 없는 입문자들이 쉽게 접할 수 있는 환경이 아니라고 생각한다.

또 IT 분야의 어느 개념이든, 관련된 코드를 직접 확인해본다면 (조금 시간은 걸려도) 가장 확실하게 이해할 수 있다.

 

쿠버네티스를 설명하는 글에선 대부분 코드가 없기 때문에 막연하고 추상적으로 느껴지는 것 같다.

이번 1편에서는 쿠버네티스 실습을 들어가기 전, 글로만 대략적인 개념을 정리해보고자 한다. 그리고 쿠버네티스 실습 경험을 좀 더 쌓고서 내가 이해한 개념을 다시 점검해보자.

 

 

 

쿠버네티스의 어원

Kubernetes, 줄여서 k8s(u부터 e까지 8글자다)란 그리스어로 'helmsman'(키잡이, 조타수) 또는 'pilot'을 의미한다.

선원(컨테이너)을 진두지휘하는 조종사, 또는 조종실에 있는 수많은 패널과 스위치로 배의 조종・조향을 통제하는 역할에 비유한 게 아닐까?

 

 

출처: https://en.m.wikipedia.org/wiki/File:011212-N-1328C-502_At_the_Helm.jpg

 

 

쿠버네티스의 등장 배경

쿠버네티스는 2015년(2014년이라고 하는 데도 있다) 구글이 공개한 오픈소스 프로젝트에서 시작했다.

쿠버네티스의 핵심 역할은 '컨테이너 오케스트레이션(orchestration, 조율 및 관리)'이다.

그런데 사실 2013년 도커가 처음 등장하고 나서 2년 뒤에 발표한 것이니 '의외로 아주 최신 기술은 아니구나'라고 생각했다.

 

아무래도 강의에서는 도커를 모두 배운 후에 쿠버네티스를 배우기 시작하니 '쿠버네티스는 도커의 발전된 버전'이라고 오해하기 쉬운 것 같다.

그보다는, 쿠버네티스가 컨테이너 기술과 같이 성장했고 컨테이너를 관리하는 데 빠질 수 없는 핵심 요소라고 이해하는 게 맞겠다.

 

 

 

AWS ECS vs. 쿠버네티스

내가 지금 듣고 있는 유데미 강의에선 쿠버네티스를 배우기 전에, 여러 컨테이너를 AWS ECS(Elastic Container Service)로 다루는 실습을 진행해보았다. AWS EC2(Elastic Cloud Service)는 알겠는데, ECS는 또 뭘까?

 

 

AWS ECS(Elastic Container Service)란 '컨테이너 애플리케이션을 쉽게 배포, 관리 및 확대할 수 있도록 도와주는 완전 관리형 컨테이너 오케스트레이션 서비스'입니다.
(출처: https://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/Welcome.html)

 

 

언뜻 보면 AWS ECS가 쿠버네티스의 역할이 겹치는 것 같다. 그러면 왜 대부분 사람들은 AWS ECS보다는 쿠버네티스를 쓰는 걸까?

 

 

AWS ECS 대신 쿠버네티스를 배워야 하는 이유

첫째, 바로 lock-in 효과 때문이다.

락인(lock-in)효과란 고객이 어떤 상품이나 서비스만 계속 사용하도록 묶어두는 효과를 말한다.

만약 컨테이너를 관리하는데 AWS ECS에서만 작업한다면, 컨테이너를 관리하는 규칙이 모두 AWS에만 특화되어 있기 때문에 다른 인프라나 클라우드 서비스로 앱을 옮기기가 쉽지 않다.

다시 말해서 컨테이너 배포의 모든 설정, 관리 규칙 등을 또다른 CSP(Cloud Service Provider)에 맞게 수정해야 한다는 뜻이다.

 

 

 

 

 

 

반면에 k8s는 configuration file이 존재하는데, (편의상 "kubeconfig"이라고 하자) 이 kubeconfig 파일을 어떠한 tool(?)에 전달하면 어느 종류의 CSP나 서버든 간에 이를 읽어들여 똑같이 적용할 수 있다.
그리고 configuration 파일을 작성하는 법은 한 가지로 통일되어 있다.

즉 쿠버네티스만 알면 서버나 클라우드 서비스에 상관없이 일관되게 대처할 수 있다는 뜻이다.

 

 

 

 

쿠버네티스에 대한 오해와 진실

쿠버네티스를 본격적으로 공부하기 전에 헷갈렸던 부분을 강의에서 잘 짚어주고 있다.

질문에 대한 답변에 내가 조사한 내용을 덧붙여서 정리해본다.

 

 

1. 쿠버네티스만 설치하면 도커는 이제 아예 사용 안해도 되나요?

아니다. 쿠버네티스는 도커를 대체할 수 없다.

쿠버네티스는 Docker로 만든 컨테이너를 관리하는 것이지, 쿠버네티스가 있다고 해서 도커를 사용 안하는 건 아니다.

한 가지 덧붙이자면, 쿠버네티스는 꼭 도커로 만든 컨테이너를 필요로 하지는 않는다.

꼭 도커가 아니더라도 container runtime interface를 지원하는 CRI-O 같은 컨테이너 런타임이 있다면 작동할 수 있다(이게 뭔 말인지 몰라도 괜찮다. 일단 패스!).

 

 

 

2. 쿠버네티스는 툴(tool)인가요?

애매한데, 아니라고 해야 할 것 같다('툴'에 대한 정의가 그렇게 엄밀하진 않기 때문).

쿠버네티스는 어떤 특정한 목적을 달성하기 위한 소프트웨어의 일부분인 툴(tool)보다는 더 큰 개념이기 때문이다.

컨테이너의 orchestration과 대규모 배포를 도와주는 프레임워크, 플랫폼이라고 보는 게 맞지 않을까?

 

 

3. 쿠버네티스는 AWS, Azure와 같은 클라우드 서비스인가요?

아니다. 쿠버네티스는 클라우드 서비스와 독립적으로 작동한다.

또 AWS, Azure는 이익을 달성하기 위한 클라우드 서비스인 반면 쿠버네티스는 태생이 오픈 소스 프로젝트다.

 

 

4. 쿠버네티스는 특정 클라우드 서비스하고만 호환되나요?

아니다. Kubernetes를 지원만 한다면, 어느 CSP에서든 쓸 수 있다.

 

 

 

 

쿠버네티스가 알아서 하는 것, 사람이 해야 하는 것

어느 식당에서 주방장이 요리를 한다고 생각해보자.
음식을 만들려면 당연히 식재료가 필요하다. 그리고 불을 올려야 하니 가스도 필요할 거고 각종 주방도구, 식기 등등도 있어야 한다.
우리는 쿠버네티스가 많은 걸 자동화해준다고 생각하지만, 사실 쿠버네티스는 이 자원(식재료, 물, 가스 등)을 알아서 잘 활용해서 여러 메뉴의 조리 과정을 관리할 뿐이다. 요리에 필요한 식재료는 사람이 직접 주방으로 날라야 하듯이, 개발자도 쿠버네티스를 활용하려면 먼저 클러스터와 노드를 생성하고 컴퓨팅 자원도 준비해놓아야 한다.