컨테이너와 오케스트레이션 시스템
리눅스는 원래 프로세스별로 자원을 격리해서 사용하는 cgroup과 특정 디렉터리로 권한을 제한하는 chroot 등으로 격리 환경을 구성할 수 있었다. 여기에 디스크의 파일 변경 사항을 레이어 형태로 저장하는 파일 시스템을 합해 컨테이너라는 개념이 탄생했다. 도커는 이러한 기능을 모아서 컨테이너를 손쉽게 이용할 수 있게 한 것으로 주목받았다.
왼쪽은 컨테이너의 구조, 오른쪽은 가상 머신의 구조이다. 컨테이너가 구조상 레이어가 더 간단하므로 가상 머신보다 성능을 높이기 쉽다.
도커를 이용하면 위의 사진처럼 간단한 명령으로 컨테이너 이미지를 만들고 저장소에 저장할 수 있다. 그리고 도커를 설치한 호스트에 해당 컨테이너 이미지를 다운로드해서 컨테이너를 실행할 수 있다. 이를 통해 앱을 배포하고 관리하기가 더 편하고 강력해졌다.
컨테이너를 이용하면 개발 환경에서 실행했던 컨테이너를 컨테이너 런타임(도커)만 있다면 실제 서버 어디에서든지 실행할 수 있다. 그러나 컨테이너 만으로 실제 상용 서비스를 운영하기에는 부족한 부분이 있다. 컨테이너 오케스트레이션 시스템은 컨테이너의 부족한 부분을 채워주는 역할이다.
실제 상용 서비스를 운영할 때는 서버 하나에 장애가 발생했을 때 그 장애 때문에 상용 서비스에 영향을 받지 않도록 여러 대 서버를 이용한다. 이러한 서비스 구성에서 컨테이너만 단독으로 사용한다면, 컨테이너 이미지를 만들고 여러 대 서버에 컨테이너를 배포하는 전체 과정을 수동으로 제어해야 한다. 그러나 컨테이너 오케스트레이션 시스템을 사용하면 수동 제어 부분 모두를 자동화하므로 시스템 운영이 훨씬 수월해진다.
컨테이너 오케스트레이션 시스템으로 상용 서비스에 사용할 서버들을 클러스터로 구성하면, 서버 1대든 100대든 컨테이너를 한 번의 명령으로 자동 배포할 수 있다. 그리고 사용중인 클러스터 일부에 장애가 발생하면 오케스트레이션 시스템은 알아서 장애가 발생한 서버에 있는 컨테이너들을 정상 운영 중인 다른 서버로 옮겨서 실행시킨다. 장애가 발생한 서버로 향하는 트래픽도 자동으로 중지시키고 새로 옮긴 컨테이너로 보낸다.
쿠버네티스의 특징
1.
선언적 API
쿠버네티스에서 가장 중요한 것은 desired state(원하는 상태) 라는 개념이다. 원하는 상태라 함은 사용자가 바라는 환경을 의미하고 좀 더 구체적으로는 얼마나 많은 웹서버가 떠 있으면 좋은지, 몇 번 포트로 서비스하기를 원하는지 등을 말한다.
컨테이너가 어떤 상태이길 원하는지만 쿠버네티스에 설정하면 지속해서 컨테이너의 상태를 확인한다. 그리고 설정한 상태가 아니면 그것에 맞게 맞춘다는 개념이다.
따라서 쿠버네티스를 사용하려면 어떤 상태가 있고 어떻게 상태를 선언하는지를 알아야 한다.
간단한 Pod Object 선언 예시
apiVersion: v1
kind: Pod
metadata:
name: example
spec:
containers:
- name: busybox
image: busybox:1.25
YAML
복사
쿠버네티스는 다양한 오브젝트의 명세 Spec을 YAML 파일로 정의하고 여기에 오브젝트의 종류와 원하는 상태를 입력하는 선언적 배포 방식으로 동작을 한다.
2.
워크로드 분리
분산 시스템을 개발할 때는 분산된 프로세스 각각이 잘 실행되는지, 이상이 생겼을 때는 어떻게 처리해야 하는지 등 시스템 안정성에 관한 고민을 많이 해야한다. 이때 쿠버네티스는 운영체제처럼 분산된 프로세스의 관리를 추상화하는 레이어가 되므로 시스템 운영에 관한 고민을 많이 덜어준다.
3.
어디서나 실행 가능
쿠버네티스의 현재 인기에 대한 주요 원인 중 하나는 어디에서나 실행할 수 있다는 점이다. 개인 컴퓨터, 여러 대의 서버, 퍼블릭 클라우드에서도 쿠버네티스를 사용할 수 있고, 단순한 테스트라면 웹에서도 사용할 수 있다.
4.
커뮤니티
많은 사람이 참여하는 활성화된 커뮤니티를 통해 언제든지 필요한 지원을 받을 수 있다.
