[Kubernetes] 1&2. Basic of Docker & K8S

서론

본 글은 마르코 룩샤의 Kubernetes in Action 책을 기반으로 쓰였으며,

챕터별 내용들을 정리하여 시리즈로 발행 중이다.

따라서 책 내용의 일부가 요약되어 있으며, 필자의 추가적인 해석이 포함되어 있다.

 

쿠버네티스 인 액션, 마르코 룩샤

다음 글

2021.03.24 - [Log.Develop/DevOps] - [Kubernetes] Chapter 3. Pod(파드)

[Kubernetes] Chapter 3. Pod(파드)

 

MSA와 K8S

참고로 k8s는 Kubernetes를 줄여서 부르는 말로, K와 S 사이에 8개의 문자가 있어서 k8s라고 쓰는 것이라고 한다.

쿠버네티스가 왜 필요한가?

• 모놀리스 애플리케이션은 모든 것이 서로 강하게 결합돼 있고, 전체가 하나의 운영체제 프로세스로 실행되기 때문에 하나의 개체로 개발, 배포 관리돼야 한다. 애플리케이션의 한 부분을 변경하더라도 전체 애플리케이션을 재배포해야 하며, 시간이 지남에 따라 구성 요소 간의 경계가 불분명해지고 상호의존성의 제약이 커지면서 전체 시스템의 복잡성이 증가하고 품질이 저하된다.
• 모놀리스는 scale up은 쉽지만 scale out은 보통 힘들다. scale up은 비교적 비용이 많이 든다.

그러나, 항상 어떠한 상황에서든 MSA로의 변경이 옳다고 할 수 없다.

아래의 내용에서 서비스는 K8S에서 의미를 가지고 있는 Service가 아니다.

읽어보면 좋을 링크 : https://medium.com/giljae/마이크로-서비스를-사용하지-않는-경우-cfaae59e4fcc

• 모놀리스 방식에서 큰 규모의 프로젝트더라도 Domain에 따라 멀티 모듈 형식으로 구분하여 개발하게 되면 충분히 개발 및 배포의 이점을 누릴 수 있으며, 사실상 이런 구조는 MSA에서 겪는 문제를 똑같이 겪게 된다.(Service 간의 의존성 문제가 모듈 간 의존성 문제로 변경된다거나..)
• MSA는 개발자에게 더 높은 수준의 복잡성을 다룰 것을 요구한다. 서비스 단계에서의 복잡성 뿐 아니라, 서비스 간 의존성, 서비스 간 네트워킹 문제, 이런 이슈들로 인한 성능 문제 등 기존 모놀리스 시스템에서는 더 작은 수준으로 일어나던 문제들이 시스템 전반의 핵심적인 문제들로 성장하게 된다.

배포가 너무 어렵다.

MSA 방식에서는 배포가 상당히 어렵다.

• 구성 요소가 많아지면 배포 조합의 수 뿐만 아니라 구성 요소간의 상호 종속성 수가 훨씬 더 많아지므로 배포 관련 결정이 점점 어려워진다.
• 마이크로서비스를 배포할 때 전체가 하나의 시스템처럼 동작할 수 있도록 누군가 또는 무언가가 제대로 구성해야 한다.
• 마이크로서비스 수가 증가함에 따라 서버 장애 상황에서 시스템 운영 팀이 해야할 일은 매우 복잡하고 다양하다.
• 다양한 서비스에 알맞은 다양한 환경이 필요한데, 이런 환경을 따로 구성해서 배포할꺼면 그냥 컨테이너 이미지 하나로 전체를 배포하게 된다. 이 과정에서 모듈 간 버전 문제, 의존성 문제가 생길 수 있다.

컨테이너

애플리케이션이 더 작은 수의 커다란 구성 요소로만 이뤄진 경우 각 구성 요소에 전용 가상머신(VM)을 제공하고 고유한 운영체제 인스턴스를 제공해 환경을 격리할 수 있다. 이 방법의 문제점은 다음과 같다.

• 구성 요소가 점점 작아지고 많아지면 하드웨어 리소스를 낭비하게 된다.
• 시스템 관리자의 작업량도 증가하기 때문에 인적 자원도 낭비된다.

이에 반해 리눅스 컨테이너 기술로 격리하면 유사하지만 오버헤드가 훨씬 적다.

(각 게스트 OS가 Hypervisor를 거치는 것이 아니라, 하나의 Host OS에서 실행되는 동일한 커널에서 시스템 콜을 수행한다.)

이러한 컨테이너 격리 메커니즘이 가능하게 하는 기술은 다음과 같다.

• 리눅스 네임스페이스 : 각 프로세스가 시스템에 대한 독립된 뷰만 볼 수 있도록 한다.
• 리눅스 컨트롤 그룹(cgroup) : 프로세스가 사용할 수 있는 리소스의 양(CPU, 메모리 등)을 제한한다.

Docker

도커의 세 가지 주요 개념은 다음과 같다.

• 이미지 : 애플리케이션과 해당 환경을 패키지화한 것.
• 레지스트리 : 도커 이미지를 저장하고 이미지를 공유할 수 있는 저장소다.
• 컨테이너 : 도커 기반 컨테이너 이미지에서 생성된 일반적인 리눅스 컨테이너이다.

K8S

컨테이너화된 애플리케이션을 쉽게 배포하고 관리할 수 있게 해주는 소프트웨어 시스템.

개발자가 애플리케이션 매니페스트를 마스터에 게시하면 쿠버네티스는 해당 애플리케이션을 워커 노드 클러스터에 배포한다.

참고 : Manifest는 (배, 비행기의) 화물 목록[승객 명단]을 뜻하는 영단어로, 집합의 일부 혹은 파일들의 그룹을 위한 메타데이터를 포함하는 파일을 뜻한다.

 

가끔 Docker vs Kubernetes 이런 질문을 찾아볼 수 있는데,

엄연히 쿠버네티스는 Docker와 같은 컨테이너 기술을 바탕으로 컨테이너 관리(컨테이너 오케스트레이션, Container Ochestration)을

편리하게 해주는 기술의 일종이다.

아래의 잘 설명된 IBM Cloud 영상을 보면 더더욱 이해가 잘 될 것이다!

www.youtube.com/watch?v=2vMEQ5zs1ko

 

쿠버네티스 사용의 장점

• 애플리케이션 배포의 단순화
• 하드웨어 활용도 높이기
• 상태 확인과 자가 치유
• 오토스케일링
• 애플리케이션 개발 단순화

k8s 구조

쿠버네티스에서 컨테이너 이미지 실행하기