[Kubernetes] 쿠버네티스의 등장 배경

※ 본 포스팅은 Network > Cloud > Docker > Kubernetes 순으로 먼저 클라우드와 인프라에 관한 전반적인 지식이 수행된 다음 읽어볼 것을 추천합니다.

 

[Docker] Docker의 개요

이번 포스팅에선 쿠버네티스를 사용하게된 이유에 대해서 알아보고 전체적인 구조에 대해 간단하게 살펴볼 예정입니다.

자세한 내용은 이후의 포스팅에서 다루도록 하겠습니다.

 

---

쿠버네티스는 왜 등장했는가?

2013년 3월에 도커가 세상에 등장하면서 서버 관리 방식을 컨테이너 기반으로 완전히 바꾸어버렸습니다.

Build, Ship, and Run Any App, Anywhere. Build 이미지를 만들고, Ship 레지스트리에 저장하고, Run 도커를 실행하고. 도커의 슬로건과 같은 말입니다. 도커의 등장으로 프로세스를 격리하는 리눅스 컨테이너 기술이 보편화되면서 많은 서비스들이 도커라이징하게 됩니다.

 

하지만 도커 이미지가 점차 많아지고 이에 따라 관리해야할 컨테이너가 점차 늘어나기 시작합니다. 처음 한두개 쯤이야 수동으로 직접 명령어를 입력해가며 관리할 수 있었지만 10개... 100개 점차 컨테이너가 늘어나면서 이를 위한 업무가 따로 필요할 정도에 이르렀습니다.

 

각 서버 인스턴스의 상태를 체크하며 해당 컨테이너를 어디에 배포할지부터 시작해서 죽은 컨테이너를 다시 살리는 업무까지 도커가 너무 많아지다 보니 컨테이너들을 관리를 자동화할 툴이 필요하게 되었습니다.

 

그래서 등장한 것이 바로 쿠버네티스입니다. 쿠버네티스는 배의 조타수라는 그리스 단어에서 유래된 단어로써, 기존의 수동으로 제어하던 컨테이너의 배포 및 운영을 모두 자동화하는 오케스트레이션 시스템으로, 상용 서비스에 사용할 서버들을 클러스터(여러 대의 서버를 묶어 시스템 하나로 구성하는 방식)로 구성하면 서버가 몇 대이든 상관없이 한 번의 명령으로 모든 컨테이너를 자동 배포할 수 있습니다.

 

또한 사용 중인 클러스터 일부에 장애가 발생하면 오케스트레이션 시스템이 알아서 장애가 발생한 서버에 있는 컨테이너들을 정상 운영 중인 다른 서버로 옮겨서 실행시켜 줍니다.

 

이와 같이 오케스트레이션 시스템이 개발자의 부담을 상당 부분 덜어줌으로서 개발자는 안정성은 오케스트레이션 시스템에 맡겨두고 장애가 발생한 서버에 집중할 수 있습니다.

 

또 한가지 장점으로 쿠버네티스는 Google에서 개발했지만 현재는 Cloud native Computing Foundation(CNCF)재단에 기부해서 향후에 유료화 같은 문제에 관해서 걱정이 없습니다. 이러한 이유로 현재는 많은 오케스트레이션 기술 중에서도 사실상 표준으로 자리 잡았습니다.

 

# Kubernetes가 너무 길어서 k와s 사이에 글자가 8개 있다는 것을 본따서 K8S라고도 부릅니다.

 

 

쿠버네티스는 프로덕션 수준에서 기본 기능을 굉장히 충실히 제공해주는데, 이러한 기술에 특징은 아래와 같습니다.

• 상태관리 : 상태를 선언하고 선언한 상태를 계속해서 유지시켜준다. 예를들어 노드가 죽거나 컨테이너 응답이 없을 경우 자동으로 새로운 컨테이너를 띄우거나, 자동으로 죽여주는 등 선언한 처음 그대로의 상태를 계속해서 유지시켜줍니다.

• 스케줄링 : 어떤 서버에 컨테이너를 띄울까를 고민하지 않아도 쿠버네티스가 조건에 맞는 노드를 찾아서 컨테이너를 배치시켜줍니다.

• 클러스터 : 가상 네트워크를 통해 통신하기 때문에 하나의 서버에 있는 것처럼 관리할 수 있습니다.

• 서비스 디스커버리 : 서로 다른 서비스를 쉽게 찾고 통신할 수 있습니다.

 

쿠버네티스의 이해를 돕는 영상