쿠버네티스 소개

728x90

컨테이너

원래부터 리눅스는 프로세스별로 자원을 격리해서 사용하는 cgroup과 특정 디렉터리로 권한을 제한하는 chroot 등으로 격리 환경을 구축할 수 있다. 여기에 디스크의 파일 변경 사항을 레이어 형태로 저장하는 파일 시스템을 합해 컨테이너라는 개념이 탄생했다.

그리고 도커는 앞에서 언급한 기능들을 모아서 컨테이너를 손쉽게 사용할 수 있도록 한 것으로 주목받았다.

기존에는 가상화나 클라우드 컴퓨팅을 설명할 때는 가상 머신(VM)을 많이 언급했었지만 컨테이너가 널리 알려지면서 컨테이너에 많은 관심이 쏠리기 시작했다.

컨테이너에는 호스트 운영체제 위에 도커가 있고 바로 애플리케이션이 위치하는반면 가상 머신은 하이퍼바이저 위에 가상 머신마다 게스트 운영체제가 있고 그 위에 앱이 위치한다. 즉, 컨테이너가 구조상 레이어가 더 간단하므로 가상 머신보다 성능을 높이기 쉽다.

컨테이너가 등장하기 전에는 호스트에도 개발 환경에 필요한 설정을 똑같이 해야만했다. 이 과정에서 여러 가지 장애 요소가 많이 발생해서 어려움이 있기도 했다. 이런 불편한 점을 컨테이너와 오케스트레이션 시스템을 함께 사용하면 쉽게 해결할 수 있고 또 앱을 배포하고 관리하기가 더 편하고 강력해진다.

컨테이너 오케스트레이션 시스템

도커가 컨테이너를 사용하기 편하게 만들면서 애플리케이션 개발 과정 전체에 혁신을 가져왔다. 컨테이너를 이용하면 개발 환경과 운영 환경의 차이 때문에 일어나는 많은 장애를 막을 수 있다. 개발 환경에서 실행했던 컨테이너를 컨테이너 런타임(ex. 도커)만 있다면 실제 서버 어디에서든지 실행할 수 있기 때문이다. 하지만 컨테이너만으로는 실제 상용 서비스를 운영하기에는 부족하다. 이런 부족함을 컨테이너 오케스트레이션 시스템이 채워줄 수 있다.

일반적으로 실제 상용 서비스를 운영할 때는 서버를 여러대 띄어놓고 사용한다. 그 이유는 서버의 단일 장애점을 방지하여 서버 하나에 장애가 발생해도 그 장애 때문에 전체 서비스에 영향이 가지 않도록하기 위함이다. 이런 상용 서비스 구성에서 컨테이너만 단독으로 사용한다면 컨테이너 이미지를 만들고 여러 대 서버에 컨테이너를 배포하는 전체 과정을 수동으로 제어해야한다. 그리고 장애가 발생하면 해당 서버의 컨테이너를 다른 서버로 옮기는 등의 작업도 직접해야 한다.

하지만 컨테이너 오케스트레이션 시스템을 사용하면 수동으로 제어하는 부분 모두를 자동화하므로 시스템 운영이 훨씬 수월해진다.

컨테이너 오케스트레이션 시스템으로 상용 서비스에 사용할 서버들을 클러스터로 구성하면, 서버 1대든 100대든 컨테이너를 한 번의 명령으로 자동 배포할 수 있다. 그리고 사용 중인 클러스터 일부에 장애가 발생하면 오케스트레이션 시스템은 알아서 장애가 발생한 서버에 있는 컨테이너들을 정상 운영 중인 다른 서버로 옮겨서 실행시킵니다. 장애가 발생한 서버로 향하는 트래픽도 자동으로 중지시키고 새로 옮긴 컨테이너로 보낸다.

쿠버네티스

쿠버네티스(kubernetes)는 배의 조타수란 그리스 단어에서 유래했다.
또한 2014년 구글 내부에서 사용하던 컨테이너 오케스트레이션 시스템 보그(borg)를 오픈 소스 소프트웨어로 공개한 것이고 10년 이상 대규모 시스템을 운영해오면서 쌓은 노하우를 녹인 것이기도하다. 쿠버네시트는 k와 s사이의 글자 개수가 8개이므로 k8s라고도 표기한다.

구글은 리눅스 재단과 협업해서 클라우드 네이티브 컴퓨팅 재단(Cloud Native Computing Foundation)을 만들고 쿠버네티스를 기부했다. 그 이후로 쿠버네티스는 커뮤니티의 힘으로 더 많은 성장을 이뤘다.

AWS에서도 쿠버네티스 관리형 서비스인 EKS(Amazon Elastic Kubernetes Service)를 출시했다.

쿠버네티스의 특징

쿠버네티스가 많은 인기를 얻은 이유는 사용하기 간편한 선언적 API, 처음 쿠버네티스를 사용할 때의 손쉬운 접근성, 강력한 커뮤니티 등이 있다.

선언적 API

쿠버네티스의 가장 큰 설계 원칙은 API가 '선언적'(declarative)이라는 것이다. 컨테이너가 어떤 상태이길 원하는지만 쿠버네티스에 설정하면 지속해서 컨테이너 상태를 확인한다. 그리고 설정한 상태가 아니라면 그것에 맞게 맞춘다는 개념이다.

쿠버네티스의 이런 '선언적' 특징을 이용하면 원하는 상태만 쿠버네티스에 정의해 유지할 수 있으므로 관리 비용이 많이 준다.

사용자가 설정한 명령이 없어지는 것 등을 염려하지 않아도 된다. 쿠버네티스를 사용하면 이런 문제를 걱정하지 않아도 된다. 클러스터가 동작 중이라면 항상 원하는 상태로 자동 복구를 하기 때문이다.

이 때문에 쿠버네티스에서 사용하는 컴포넌트들의 구현 또한 단순하다. 또한 컴포넌트를 여러 개 실행해둘 수 있으므로 단일 장애점(Single Point Of Failure, SPOF)이 없다.

하지만 '선언적' 특징 때문에 때로 불편한 점도 생긴다. 컨테이너가 몇 개 실행되어야 한다거나 앱이 없어야 할 때는 설정하기 쉽지만, 앱 재시작 같은 단순한 작업은 쿠버네티스에서 할 수 없다. 앱 재시작은 쿠버네티스 시스템 내부 동작으로 사용자가 제어할 수 없기 때문이다.

쿠버네티스 입장에서는 같은 설정, 즉 기존 설정과 비교했을 때 변경 사항이 없는 앱은 재시작하지 않아도 된다고 생각한다. 하지만 앱 재시작 기능을 넣어달라는 사용자 요청이 많아지면서 쿠버네티스 CLI인 kubectl 1.15부터는 디플로이먼트, 스테이트풀세트, 데몬세트에 재시작 기능이 추가됐다. 쿠버네티스 컴포넌트들의 선언적 특징을 그대로지만, kubectl이 직접 애너테이션을 변경하면서 재시작 동작을 제어하는 방식으로 바뀌었다.

워크로드 분리

쿠버네티스를 사용하면 분산 시스템을 개발하고 어떻게 실행할지에 관한 고민을 많이 덜어준다. 분산 시스템을 개발할 때는 분산된 프로세스 각각이 잘 실행되는지, 이상이 생겼을 때는 어떻게 처리해야 하는지 등 시스템 안전성에 관한 고민을 많이 해야한다. 이때 쿠버네티스는 운영체제처럼 분산된 프로세스의 관리를 추상화하는 레이어가 되므로 시스템 운영에 관한 고민을 많이 덜어 준다. 이 때문에 최근에 쿠버네티스를 클라우드의 리눅스라고 말하는 상황도 생기고 있다.

어디서나 실행 가능

쿠버네티스가 지금처럼 인기를 얻게 된 주요 원인 중 하나는 어디서나 실행할 수 있다는 점이다. 개인 컴퓨터에 쿠버네티스를 설치해서 사용해 볼 수 있고, 여러 대 서버에 설치해서 사용할 수 있다. 퍼블릭 클라우드에서도 쿠버네티스를 실행할 수 있고, 단순한 테스트라면 쿠버네티스 설치 없이도 웹에서도 사용해볼 수 있다. 즉, 처음 쿠버네티스를 접하려는 사람이 접근하기 쉬워 많은 사용자가 모이는 원동력이 되었다.

커뮤니티

활성화된 커뮤니티 또한 쿠버네티스의 큰 장점이다.