[K8s in Action] 1. 쿠버네티스 소개

1. 쿠버네티스와 같은 시스템이 필요한 이유

1. 모놀리스 애플리케이션에서 마이크로서비스로의 전환
   • 모놀리스 애플리케이션은 수평적으로 확장하기 어려운 구조.
   • 독립적으로 배포할 수 있는 마이크로서비스로 분할해야 함.
   • 마이크로서비스는 일반적으로 RESTful API를 제공하는 HTPP와 같은 동기 프로토콜과 AMQP아 같은 비동기 프로토콜로 통신한다. (최근에는 gRPC나 RSocket도 사용.)
   • 이러한 프로토콜은 정적인 외부 API를 제공하는 독립형 프로세스이기 때문에 개별적으로 개발, 배포할 수 있음.
   • 마이크로서비스는 각 팀이 개별적으로 개발하기 때문에, 애플리케이션 구성 요소 간 종속성의 차이가 불가피해진다.
2. 애플리케이션에 일관된 환경 제공
   • 개발자와 운영 팀의 가장 큰 문제는 애플리케이션을 실행하는 환경이 다르다는 것이다. 이를 일관되게 관리하는 것이 중요하다.
3. 지속적인 배포로 전환: 데브옵스와 노옵스
   • 자주 릴리스를 하려면 개발자가 직접 배포하는 게 낫다. 하지만 개발자는 인프라와 데이터 센터의 하드웨어 구성에 대해 잘 모른다.
   • 하드웨어 인프라를 전혀 몰라도 운영 팀 없이 개발자가 앱을 직접 배포하는 것이 가장 이상적이다.
   • 쿠버네티스를 사용하면 하드웨어를 추상화할 수 있으며, 시스템 관리자는 실행되는 앱을 알 필요 없이 인프라를 운영할 수 있다.

2. 컨테이너의 이해

1. 컨테이너

   • 컨테이너는 가상머신과 다르게 호스트 운영체제 내에서 실행된다. 그러나 컨테이너의 프로세스는 다른 프로세스와 격리되어 있다.
   • VM 아래에는 Hypervisor와 호스트 OS가 있다. VM 내에서 앱이 게스트 OS 커널에 대한 시스템 콜을 수행하면, 커널은 Hypervisor 통해서 물리적 CPU에서 x86 명령을 수행한다.
   • 반면 컨테이너는 호스트 OS에서 실행되는 동일한 커널에서 시스템 콜을 수행한다.

2. 컨테이너 격리를 가능하게 하는 매커니즘
   1) namespace

   • 초기 구동 시 하나의 네임스페이스가 있다.
   • 추가 네임스페이스를 생성하고 리소스를 구성하면 프로세스는 동일한 네임스페이스 내의 리소스만 볼 수 있다.
   • 여러 종류의 네임스페이스가 있기 때문에 프로세스는 여러 네임스페이스에 속할 수 있다.

   2) cgroups

   • 각 컨테이너가 사용할 수 있는 시스템 리소스의 양을 제한할 수 있다.
   • 프로세스는 설정된 양 이상의 CPU, 메모리, 네트워크 대역폭 등을 사용할 수 없다.

3. 도커
   - 도커로 패키징된 앱을 실행하면 함께 제공된 파일시스템 내용을 정확히 볼 수 있다.

   • 이는 VM에 OS를 설치하고 그 안에 앱을 설치한 다음 VM 이미지를 생성하는 것과 유사하다.
   • 도커 기반 컨테이너 이미지와 VM 이미지의 가장 큰 차이점은, 컨테이너 이미지가 여러 이미지에서 공유되고 재사용될 수 있는 레이어로 구성되어 있다는 것이다. 즉, 동일한 레이어를 포함하는 다른 컨테이너 이미지를 실행할 때 다른 레이어가 이미 다운로드 된 경우 이미지의 특정 레이어만 다운로드하면 된다.
   • 도커의 세 가지 주요 개념은 이미지 / 레지스트리 / 컨테이너 이다.
     - 이미지: 앱과 환경을 패키지화한 것. 파일시스템과 메타데이터도 포함됨.
     - 레지스트리 : 도커 이미지를 저장하고 외부에 쉽게 공유할 수 있는 저장소. push/pull 기능 제공.
     - 컨테이너 : 도커 기반 컨테이너 이미지에서 생성된 리눅스 컨테이너.
     
   • 이미지 레이어의 이해
     - 컨테이너 이미지 레이어는 읽기 전용이다. 동일한 기본 레이어를 기반으로 한 두 개의 이미지에서 생성한 두 개의 컨테이너는 동일한 파일을 읽을 수 있지만, 그중 하나가 해당 파일을 덮어쓰면 다른 컨테이너는 해당 변경사항을 볼 수 없다. 컨테이너가 실행될 때 이미지 레이어 위에 새로운 쓰기 가능한 레이어가 만들어지기 때문이다.

3. 쿠버네티스 소개

1. 쿠버네티스 아키텍처

• 쿠버네티스는 컨테이너화된 앱을 쉽게 배포하고 관리할 수 있게 해주는 소프트웨어 시스템이다.
• 쿠버네티스 시스템은 master node와 worker node로 구성된다. 개발자가 App manifest를 master에 게시하면 쿠버네티스는 해당 app을 worker node cluster에 배포한다. 구성 요소가 어떤 노드에 배포되든지 개발자나 시스템 관리자에게 중요하지 않다.

2. 쿠버네티스 클러스터 아키텍처
   1) 마스터 노드와 워커 노드
   - 쿠버네티스 클러스터는 여러 노드로 구성되며, master node 혹은 worker node이다.
   - master node는 전체 쿠버네티스 시스템을 제어하고 관리하는 Kubernetes Control Plane을 실행한다.
   - worker node는 실제 배포되는 컨테이너 애플리케이션을 실행한다.
   2) Control Plane
   - API server / Scheduler / Controller Manager / Etcd로 구성된다.
   - API server : 사용자, 컨트롤 플레인 구성 요소와 통신한다.
   - Scheduler : 애플리케이션의 배포를 담당한다.(앱의 배포 가능한 각 구성 요소를 워크 노드에 할당한다.)
   - Controller Manager : 구성 요소 복제본, 워커 노드 추적, 노드 장애 처리와 같은 클러스터단의 기능을 수행한다.
   - etcd : 클러스터 구성을 지속적으로 저장하는 신뢰할 수 있는 분산 데이터 저장소다.
   3) Node
   - Container Runtime / Kubelet / kube-proxy로 구성된다.
   

Reference - Kubernetes in Action by Marco Luksa