[k8s] 1. 쿠버네티스 시작하기 - 왜 쓸까?

1. 쿠버네티스 시작하기 - 왜 쓸까?

들어가기 전에

 서버 스터디를 시작하며 NHN TOAST 클라우드 플랫폼을 통해 도커를 접해보았다. 컨테이너를 쓰는 이유가 점점 납득이 갈 때쯤 '쿠버네티스가 그렇게 핫하다'는 말을 듣고 구글링해보다가 도커와 같이 공부하면 좋겠다는 생각에 무턱대고 도서관에 가서 책을 빌리고 공부를 시작했다. 매력적인 서비스임은 분명하다. 왜 매력적인 서비스인지 알아보려 한다.

컨테이너가 멋진 이유

컨테이너, 레이어의 개념에 관한 설명은 도커 관련 포스트에서 다뤘다.

http://zinirun.blogspot.com/2020/01/docker-1.html을 참조하기 바란다.

 컨테이너의 인기는 몇년 전부터 불같다. 도커, 컨테이너 관련 내용이 없는 IT 컨퍼런스는 찾기 힘들어지고 있다. 컨테이너 그 자체는 기술이 아니며, 수년 전부터 사용되고 있었다. 도커가 인기있는 이유는 유저에게 제공되는 도구와 사용의 편리함에 있다.

 현대의 개발 관행은 지속적 통합, 지속적 배포에 있다. 소프트웨어의 품질을 극대화하기 위함이다. 조직은 코드를 작성, 배포하는 지속적인 과정을 통해 품질 관리, 테스트를 도입해 수행한다. 그 결과 더욱 빨리 업데이트되고 버그가 수정되어 전체적인 품질이 향상되는 것이다. 그러나 테스트와 배포가 일치하는 개발 환경을 만드는 건 어렵다.

 도커를 사용하면 이 과정이 너무 편리해진다. 개발자의 PC에서 배포된 컨테이너는 사내 staging 서버에 쉽게 배포할 수 있다. 그 다음 클라우드에서 실행중인 배포 서버로 쉽게 전송할 수 있다. 이는 도커가 부모 레이어가 명시된 빌드 파일을 사용해서 컨테이너를 생성하기 때문이다. 이 방식은 OS, 패키지, 어플리케이션 버전의 일치를 보장하는 장점이 있다.

오케스트레이션

 쿠버네티스는 다른 컨테이너 오케스트레이션 도구보다 늦게 등장했다. 컨테이너 오케스트레이션이란 여러 개의 서버에 컨테이너를 배포, 운영하면서 서비스 간 연결을 쉽게 해주는 것이다. 서버마다 각각 이름을 부여해서 한개씩 접속하여 관리하는 것이 아닌, 서버 몇개를 하나로 묶어 적당한 서버를 자동으로 선택해 애플리케이션을 배포하고, 부하가 생기면 컨테이너를 늘리는 등의 기능을 제공한다. 오케스트레이션 툴들은 많았지만, 구글의 노하우와 강력한 확장성이 보장된 쿠버네티스의 등장으로 사실상 de facto가 되었다.

마스터-노드 구조

쿠버네티스는 전체 클러스터를 관리하는 마스터와 컨테이너가 배포되는 노드로 구성되어 있다. 모든 명령은 마스터의 API 서버를 호출하고, 노드는 마스터와 통신하면서 필요한 작업을 수행한다. 특정 노드에 명령을 내려도 노드에 직접 명령이 전해지는게 아니라 마스터에 명령을 내리고 마스터가 노드에 접속하여 대신 결과를 응답한다.

쿠버네티스의 현재

쿠버네티스 생태계는 현재도 빠르게 변하고 발전하고 있다. 사용법이 바뀌고 계속해서 새로운 기능들이 추가되고 있지만 기본적인 구성과 아키텍쳐는 거의 동일하다. 기본적인 동작 원리를 이해한다면 새로운 버전이 나와도 쉽게 이해하고 확장하여 사용할 수 있다.

-

쿠버네티스에 대한 상세한 개념이 궁금하다면 쿠버네티스 공식 홈페이지 (https://kubernetes.io/ko/docs/concepts/overview/what-is-kubernetes/)를 참고하자. 다음 글에서는 클러스터 설치 및 세팅에 관한 내용을 다루도록 하겠다.