쿠버네티스 소개

쿠버네티스 입문을 요약한 내용입니다.

• 쿠버네티스는 컨테이너 오케스트레이션 시스템 세계의 사실상 표준이라고 볼수 있다.
• 컨테이너 오케스트레이션 시스템에는 도커 스웜, 코어OS 플리트, D2iQ의 DC/OS 등이 있었다.
• 도커가 스웜뿐만 아니라 쿠버네티스를 지원하기 시작하고 코어OS는 플리트 개발을 종료 했다.

1.1 컨테인너

• 리눅스는 원래 프로세스별로 자원을 격리해서 사용하는 cgroup과 특정 디렉터리로 권한을 제한하는 chroot 등으로 격리 환경을 구성할 수 있었다.
• 여기에 디스크의 파일 변경 사항을 레이어 형태로 저장하는 파이시스템을 합해 컨테이너라는 개념이 탄생
• 도커는 위에 기능을 모아서 컨테이너를 손쉽게 사용할 수 있도록 한 것으로 주목을 받았음
  • countainerd, runc, cri-o 같은 다양한 컨테이너 런타임들이 등장

가상화나 클라우드 컴퓨팅을 설명할 때는 가상 머신을 많이 언급 했지만 컨테이너와는 내부 구조 차이가 있다.

• 컨테이너는 호스트 운영체제 위에 도커가 있고 바로 앱이 위치함
• 가상 머신은 하이퍼바이저 위에 가상 머신 마다 게스트 운영체제가 있고 그 위에 앱이 위치함
• 컨테이너가 구조상 레이거가 더 간단하므로 가상 머신보다 성능을 높이기 쉽다.

• 도커를 이용하면 그림처럼 간단한 명령으로 컨테이너 이미지를 만들고 저장소에 저장할 수 있다.

• 컨테이너가 등장하기 전에는 호스트에도 개발환경을 똑같이 설정을 해야했다.
  • 똑같이 만드는 과정에 여러가지 장애 요소가 많아 어려움이 있었다.

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

• 컨테이너를 이용하면 개발 환경과 운영 환경의 차이 때문에 일어나는 많은 장애를 막을 수 있다.
• 개발 환경에서 실행했던 컨테이너를 컨테이너 런타임만 있다면 실제 서버 어디든지 실행 할 수 있다.
• 컨테이너만으로 실제 상용 서비스를 운영하기에는 부족한 부분이 있어 컨테이너 오케스트레이션 시스템을 사용한다.
• 실제 사용 서비스를 운영할 때는 보통 서버 하나만 운영하지 않는다.
• 서버 하나에 장애가 발생했을 때 그 장애 때문에 상용 서비스에 영향을 받지 않도록 여러 대 서버를 이용해서 서비스를 구성한다.
• 상용 서비스 구성에서 컨테이너만 단독으로 사용할 경우
  • 컨테이너 이미지를 만들고 어러 대 서버에 컨테이너를 배포하는 과정을 수동으로 제어해야 함
  • 서버에 장애가 발생했을 때 해당 서버의 컨테이너를 다른 서버로 옮기는 작업도 직정 해야함
• 컨테이너 오케스트레이션 시스템을 사용할 경우
  • 여러대의 서버에 컨테이너를 한번의 명령으로 자동 배포 가능
  • 클러스터 일부에 장애가 발생하면 오케스트레이션 시스템이 알아서 장애가 발생한 서버의 컨테이너를 다른 서버로 옮겨서 실행 시켜줌
• 개발자는 장애가 발생한 시스템만 신경 쓸수 있음

1.3 쿠버네티스

• 쿠버네티스는 배의 조타수란 그리스 단어에서 유래
• 2014년 구글안에서 사용하던 컨테이너 오케스트레이션 시스템 보그를 오픈 소스로 공개
• 10년 이상 대규모 시스템을 운영해오면서 쌓은 노하우를 녹인것
• kubernetes의 k와 s사이에 글자 개수가 8개라 k8s라고 표기하기도 함
• 쿠버네티스 사용 사례
  • 2016년 게임 포켓몬고를 쿠버네티스에서 성공적으로 운영
  • 2017년 Github가 웹서비스와 API를 쿠버네티스로 옮김
  • 2019년 카카오톡, 다음, 멜론, 카카오택시 등의 서비스가 쿠버네티스를 이용
• AWS, GCP, AZURE 등에서 쿠버네티스를 지원

1.4 쿠버네티스의 특징

• 쿠버네티스가 많은 인기를 얻는 이유는 사용하기 간편한 선언적 API, 손쉬운 접근성, 활성화된 커뮤니티

1.4.1 선언적 API

• 쿠버네티스의 가장 큰 설계 원칙은 API가 선언적이라는 것
• 쿠버네티스는 설정된 상태를 유지하기 위해서 지속적으로 컨테이너 상태를 확인 하고 설정 상태가 아니면 그것에 맞춘다는 개념
• 예를 들어 컨테이너가 항상 10개 실행 되도로 설정을 했을 경우
  • 서버 장애 등으로 컨테이너를 실행할 자원이 부족해져서 8개만 실행 되고 있을 경우 사용자가 장애를 처리하면 2개의 컨테이너를 자동으로 실행 시켜 10개 실행이 유지될 수 있도록 함
• 선언적 특징이 없다면 사용자가 컨테이너 2개를 추가하는 명령을 직접 실행해야함
  • 실행 중인 컨테이너를 사용자가 지속적으로 확인 해야함
• 선언적 특징으로 인해 원하는 상태만 쿠버네티스에 설정하면 유지할 수 있으므로 관리 비용이 줄어 든다.
• 컴포넌트를 여러개 실행해둘수 있으므로 단일 장애점이 없음
• 기존에는 앱 재시작 기능이 없었지만 사용자 요청에 따라 kubectl 1.15 부터는 디플로이먼트, 스테이트풀세트, 데몬 세트에 재시작 기능이 추가 되었습니다.

1.4.2 워크로드 분리

• 쿠버네티스를 사용하면 분산 시스템을 개발하고 어떻게 실행할지에 관한 고민을 많이 덜어 줄수 있다.
• 시스템에 이상이 생겼을 경우에 따라 고려해야할 사항이 많아지지만 쿠버네티스를 사용하면 운영체제처럼 분산된 프로세스의 관리를 추강화하는 레이어가 되므로 시스템 운영이 간편해짐
• 이러한 이유로 쿠버네티스를 클라우드 리눅스라고 이야기하기도 함

1.4.3 어디서나 실행 가능

• 개인 컴퓨터나 퍼블릭 클라우드에서도 쿠버네티스를 실행 할 수 있음
• 단순한 테스트라면 쿠버네티스 설치 없이도 웹에서도 사용해 볼수 있음
• 쿠버네티스를 처음 접하는 사람이 접근하기 쉬워 많은 사용자가 모이는 원동력이 됨

1.4.4 커뮤니티

• 활성화된 커뮤니티도 쿠버네티스의 또 다른 장점
• 쿠버네티스 공식 Github의 Isuues가 있다.
• 쿠버네티스 공식 슬랙 채널 및 한국 사용자들이 모이는 kr-users 채널도 있음
• 페이스북 그룹(Kubernetes Korea Group)에서도 많은 도움을 받을 수 있다.
• 쿠버네티스는 컨테이너 오케스트레이션 시스템 세계의 사실상 표준이라고 볼수 있다.
• 컨테이너 오케스트레이션 시스템에는 도커 스웜, 코어OS 플리트, D2iQ의 DC/OS 등이 있었다.
• 도커가 스웜뿐만 아니라 쿠버네티스를 지원하기 시작하고 코어OS는 플리트 개발을 종료 했다.