2021.05.11

'단순한 개념 속 복잡한 내부' 쿠버네티스 작동 원리 이해하기

Matthew Tyson | InfoWorld
쿠버네티스(Kubernetes)는 오늘날 마이크로서비스에서 가장 핵심적인 기술이다. 컨테이너화된 애플리케이션의 마이크로서비스 클러스터를 더 간편하게, 자동화된 방식으로 관리할 수 있다. 개념은 이처럼 간단하지만 그 이면은 꽤 복잡하다. 쿠버네티스 기술이 어떻게 작동하는지 자세히 살펴보자.

쿠버네티스를 이해하는 손쉬운 방법의 하나는 컨테이너를 위한 분산 운영체제라고 생각하는 것이다. 쿠버네티스는 컨테이너(주로 도커(Docker) 컨테이너)와 컨테이너를 실행하는 인프라의 상호작용과 확장을 관장하는 데 필요한 툴과 명령을 제공한다. 쿠버네티스는 다양한 상황에서 사용할 수 있도록 개발된 범용 툴로, 매우 유연하고 동시에 매우 복잡하다.
 

쿠버네티스 작업자 노드와 제어부

쿠버네티스에는 두 가지 측면이 있다. 작업자 노드와 제어부다. 작업자 노드는 실제 컨테이너화된 애플리케이션과 이 애플리케이션이 필요로 하는 쿠버네티스 툴이 함께 존재하는 장소이고, 제어부는 이 클러스터를 관리하는 툴이 위치하는 장소다. <그림 1>은 이러한 아키텍처의 전체 모습을 표현한 것이다.
 
 <그림 1> 쿠버네티스 전체 아키텍처 © IDG

<그림 1>에서 볼 수 있듯 아키텍처는 작업자 노드와 헤드 노드로 분할되는데, 각각 워크로드 실행과 관리 툴 실행을 담당한다. 두 경우 모두 노드는 가상 또는 실제 머신이다.
 

쿠버네티스 노드와 워크로드 확장하기

중요한 점은 쿠버네티스는 작업자 노드 워크로드를 실행하는 데 사용할 수 있는 리소스(컴퓨팅, 메모리, 디스크, 네트워크)로 기반 인프라를 인식하지만, 이를 직접 제어하지는 않는다는 것이다. 즉, 워크로드 확장을 담당하지만 노드의 가용성 조정을 맡는 것은 더 고차원 메커니즘이다. 예를 들면 퍼블릭 클라우드 자동 확장이나 수동 개입 같은 것이다. 이 용도로는 컨트롤러를 사용해 외부 시스템과 상호작용할 수 있는데 이 방법은 아래에서 자세히 다룬다.
 

쿠버네티스 작업자 노드의 구성요소

<그림 2>는 쿠버네티스 작업자 노드의 필수 요소를 보여준다. 각 구성요소를 차례로 살펴보자.
 
<그림 2> 쿠버네티스 작업자 노드 필수 요소 © IDG

큐블렛(kubelet): 작업자 노드에서 실행되는 작은 프로그램으로 제어부와 노드 간의 협상을 담당한다. 핵심 용도는 헤드 노드 클러스터에서 포드(pod)로 가는 지시를 이행하고 작업자 로드의 현재 상태를 보고하는 것이다.

큐브 프록시(kube proxy): 노드에서 네트워크 규칙을 적용하고 노드를 오가는 트래픽을 허용하는 역할을 한다. 클러스터 수준에서 작동하면서 클러스터로 가는 네트워크 경로에 대한 규칙을 정의하는 인그레스(ingress)와는 다르다.

포드(pod): 노드의 개별적인 작업 단위로, 복제 수준에서 하나 또는 여러 개의 컨테이너화된 애플리케이션을 래핑하는 추상화다. 포드는 같은 머신에 있는 포드 간 통신을 허용하는 동시에 함께 실행되는 컨테이너를 논리적으로 그룹화하고 격리하는 수단을 제공한다. 컨테이너와 포드 간의 관계는 쿠버네티스 배포 설명자로 규정된다.

배포와 레플리카셋(ReplicaSet): 포드는 일반적으로 레플리카셋의 일부로 구성 및 배포된다. 레플리카셋은 포드의 원하는 런타임 특성을 정의하고 쿠버네티스가 그 상태를 유지하도록 한다. 레플리카셋은 일반적으로 배포에 의해 정의되는데, 배포는 레플리카셋 매개변수, 그리고 클러스터를 관리할 때 사용할 전략(즉, 포드를 업데이트할지 재생성할지)을 정의한다.

사이드카(sidecar): 포드 수준에서 부가적인 기능은 사이드카와 애드온을 통해 활성화된다. 사이드카는 포드 수준 로깅 및 상태 수집과 같은 작업을 처리한다. <그림 3>은 작업자 노드의 포드를 더 세부적으로 보여준다.
 
<그림 3> 작업자 노드의 포드 © IDG
 

쿠버네티스 제어부

지금까지 작업자 측을 중점적으로 알아봤다. 이제 컨트롤러로 초점을 바꿔서 쿠버네티스가 클러스터의 작동을 어떻게 제어하는지를 살펴보자. <그림 4>는 헤드 노드 구성요소를 세부적으로 보여준다.
 
<그림 4> 헤드 노드 구성요소 © IDG

Etcd: 가장 쉽게 이해할 수 있는 구성요소는 etcd('엣시디'라고 읽음)다. etcd는 전체 클러스터의 구성과 상태에 대한 레코드 데이터베이스 역할을 하는 분산 객체 저장소다.

API 서버: <그림 4>에서 명확히 볼 수 있듯이 API 서버는 클러스터의 중앙 통신 메커니즘이다. 제어부, 작업자 노드 및 관리자가 kubectl과 같은 쿠버네티스 명령줄 툴 또는 다른 UI를 통해 구성 변경을 적용할 때 이들 간의 상호작용을 중개한다.

스케줄러: 스케줄러는 포드가 실행될 노드를 파악하는 역할을 한다. 이것이 결정되는 세부적인 방법은 포드의 특성과 가용한 노드의 기존 상태에 따라 다르다. 스케줄러가 이 의사 결정에 접근하는 데 사용하는 전략을 수정할 수 있고 맞춤형 스케줄러를 작성하는 것도 가능하다. 스케줄러는 작업을 수행하면서 API 서버와 상호작용한다.

컨트롤러: 컨트롤러 구성요소는 클러스터를 구성된 원하는 상태로 유지하고 클러스터가 이 상태에서 벗어날 때 다시 이 상태를 지향하도록 하는 역할을 한다. 원하는 상태를 지정하고 그 상태를 유지하도록 작동한다는 면에서 온도 조절기와 비슷하다.

쿠버네티스 관점에서 설명해 보자. 사용자가 etcd 내에 로깅되는 영구 개체인 객체를 만든다. 객체는 이런저런 요소의 바람직한 상태에 관한 레코드다. 그러면 컨트롤러는 객체가 바람직한 사양 또는 속성을 갖게 하도록 움직인다.

예를 들어 앞서 설명한 레플리카셋은 사용량 기준에 따라 얼마나 많은 수의 포드가 실행 중이어야 하는지 정의한다. 여기서 레플리카셋은 객체, 지정된 포드 수는 사양이다. 이 레플리카셋과 관련한 클러스터의 실제 상태(status)가 있다. 컨트롤러는 이 상태에 관해 클러스터로부터 일관적인 보고서를 받고, 포드를 생성하거나 폐기함으로써 사양에 부합하는 상태를 만든다.
 

컨테이너 이미지 리포지토리

마지막으로 알아야 할 구성요소는 이미지 리포지토리(또는 이미지 레지스트리)다. 이 구성요소는 클러스터 외부에 위치하며, 필요한 컨테이너 정의를 다운로드하기 위해 관리자와 제어부가 사용한다. 레지스트리는 도커 허브(Docker Hub)를 포함한 다양한 조직에 의해 호스팅되며 퍼블릭 또는 프라이빗 형태가 있다. 주요 클라우드 제공업체는 모두 기업용 관리형 리포지토리를 제공한다.
 

컨테이너를 지배하는 쿠버네티스

이제 쿠버네티스의 아키텍처와 목표를 달성하기 위한 작동 방식을 이해했을 것이다. 쉽지 않게 느껴지겠지만, 애초에 컨테이너 기반 애플리케이션을 배포, 관리, 확장하는 것이 결코 간단한 일이 아니다. 쿠버네티스는 구성 범위가 넓고 유연해서 실무에서 마주치는 광범위한 컨테이너 기반 애플리케이션 상황에 대응할 수 있다.

쿠버네티스는 소프트웨어 아키텍처에 대한 현재의 접근 방법에서 주도적인 위치에 있는 기술이다. 따라서 데브옵스, 컨테이너, 클라우드 네이티브 애플리케이션, 마이크로서비스 아키텍처에 관심이 있는 누구나 쿠버네티스에 대한 지식을 반드시 갖추어야 한다. editor@itworld.co.kr



2021.05.11

'단순한 개념 속 복잡한 내부' 쿠버네티스 작동 원리 이해하기

Matthew Tyson | InfoWorld
쿠버네티스(Kubernetes)는 오늘날 마이크로서비스에서 가장 핵심적인 기술이다. 컨테이너화된 애플리케이션의 마이크로서비스 클러스터를 더 간편하게, 자동화된 방식으로 관리할 수 있다. 개념은 이처럼 간단하지만 그 이면은 꽤 복잡하다. 쿠버네티스 기술이 어떻게 작동하는지 자세히 살펴보자.

쿠버네티스를 이해하는 손쉬운 방법의 하나는 컨테이너를 위한 분산 운영체제라고 생각하는 것이다. 쿠버네티스는 컨테이너(주로 도커(Docker) 컨테이너)와 컨테이너를 실행하는 인프라의 상호작용과 확장을 관장하는 데 필요한 툴과 명령을 제공한다. 쿠버네티스는 다양한 상황에서 사용할 수 있도록 개발된 범용 툴로, 매우 유연하고 동시에 매우 복잡하다.
 

쿠버네티스 작업자 노드와 제어부

쿠버네티스에는 두 가지 측면이 있다. 작업자 노드와 제어부다. 작업자 노드는 실제 컨테이너화된 애플리케이션과 이 애플리케이션이 필요로 하는 쿠버네티스 툴이 함께 존재하는 장소이고, 제어부는 이 클러스터를 관리하는 툴이 위치하는 장소다. <그림 1>은 이러한 아키텍처의 전체 모습을 표현한 것이다.
 
 <그림 1> 쿠버네티스 전체 아키텍처 © IDG

<그림 1>에서 볼 수 있듯 아키텍처는 작업자 노드와 헤드 노드로 분할되는데, 각각 워크로드 실행과 관리 툴 실행을 담당한다. 두 경우 모두 노드는 가상 또는 실제 머신이다.
 

쿠버네티스 노드와 워크로드 확장하기

중요한 점은 쿠버네티스는 작업자 노드 워크로드를 실행하는 데 사용할 수 있는 리소스(컴퓨팅, 메모리, 디스크, 네트워크)로 기반 인프라를 인식하지만, 이를 직접 제어하지는 않는다는 것이다. 즉, 워크로드 확장을 담당하지만 노드의 가용성 조정을 맡는 것은 더 고차원 메커니즘이다. 예를 들면 퍼블릭 클라우드 자동 확장이나 수동 개입 같은 것이다. 이 용도로는 컨트롤러를 사용해 외부 시스템과 상호작용할 수 있는데 이 방법은 아래에서 자세히 다룬다.
 

쿠버네티스 작업자 노드의 구성요소

<그림 2>는 쿠버네티스 작업자 노드의 필수 요소를 보여준다. 각 구성요소를 차례로 살펴보자.
 
<그림 2> 쿠버네티스 작업자 노드 필수 요소 © IDG

큐블렛(kubelet): 작업자 노드에서 실행되는 작은 프로그램으로 제어부와 노드 간의 협상을 담당한다. 핵심 용도는 헤드 노드 클러스터에서 포드(pod)로 가는 지시를 이행하고 작업자 로드의 현재 상태를 보고하는 것이다.

큐브 프록시(kube proxy): 노드에서 네트워크 규칙을 적용하고 노드를 오가는 트래픽을 허용하는 역할을 한다. 클러스터 수준에서 작동하면서 클러스터로 가는 네트워크 경로에 대한 규칙을 정의하는 인그레스(ingress)와는 다르다.

포드(pod): 노드의 개별적인 작업 단위로, 복제 수준에서 하나 또는 여러 개의 컨테이너화된 애플리케이션을 래핑하는 추상화다. 포드는 같은 머신에 있는 포드 간 통신을 허용하는 동시에 함께 실행되는 컨테이너를 논리적으로 그룹화하고 격리하는 수단을 제공한다. 컨테이너와 포드 간의 관계는 쿠버네티스 배포 설명자로 규정된다.

배포와 레플리카셋(ReplicaSet): 포드는 일반적으로 레플리카셋의 일부로 구성 및 배포된다. 레플리카셋은 포드의 원하는 런타임 특성을 정의하고 쿠버네티스가 그 상태를 유지하도록 한다. 레플리카셋은 일반적으로 배포에 의해 정의되는데, 배포는 레플리카셋 매개변수, 그리고 클러스터를 관리할 때 사용할 전략(즉, 포드를 업데이트할지 재생성할지)을 정의한다.

사이드카(sidecar): 포드 수준에서 부가적인 기능은 사이드카와 애드온을 통해 활성화된다. 사이드카는 포드 수준 로깅 및 상태 수집과 같은 작업을 처리한다. <그림 3>은 작업자 노드의 포드를 더 세부적으로 보여준다.
 
<그림 3> 작업자 노드의 포드 © IDG
 

쿠버네티스 제어부

지금까지 작업자 측을 중점적으로 알아봤다. 이제 컨트롤러로 초점을 바꿔서 쿠버네티스가 클러스터의 작동을 어떻게 제어하는지를 살펴보자. <그림 4>는 헤드 노드 구성요소를 세부적으로 보여준다.
 
<그림 4> 헤드 노드 구성요소 © IDG

Etcd: 가장 쉽게 이해할 수 있는 구성요소는 etcd('엣시디'라고 읽음)다. etcd는 전체 클러스터의 구성과 상태에 대한 레코드 데이터베이스 역할을 하는 분산 객체 저장소다.

API 서버: <그림 4>에서 명확히 볼 수 있듯이 API 서버는 클러스터의 중앙 통신 메커니즘이다. 제어부, 작업자 노드 및 관리자가 kubectl과 같은 쿠버네티스 명령줄 툴 또는 다른 UI를 통해 구성 변경을 적용할 때 이들 간의 상호작용을 중개한다.

스케줄러: 스케줄러는 포드가 실행될 노드를 파악하는 역할을 한다. 이것이 결정되는 세부적인 방법은 포드의 특성과 가용한 노드의 기존 상태에 따라 다르다. 스케줄러가 이 의사 결정에 접근하는 데 사용하는 전략을 수정할 수 있고 맞춤형 스케줄러를 작성하는 것도 가능하다. 스케줄러는 작업을 수행하면서 API 서버와 상호작용한다.

컨트롤러: 컨트롤러 구성요소는 클러스터를 구성된 원하는 상태로 유지하고 클러스터가 이 상태에서 벗어날 때 다시 이 상태를 지향하도록 하는 역할을 한다. 원하는 상태를 지정하고 그 상태를 유지하도록 작동한다는 면에서 온도 조절기와 비슷하다.

쿠버네티스 관점에서 설명해 보자. 사용자가 etcd 내에 로깅되는 영구 개체인 객체를 만든다. 객체는 이런저런 요소의 바람직한 상태에 관한 레코드다. 그러면 컨트롤러는 객체가 바람직한 사양 또는 속성을 갖게 하도록 움직인다.

예를 들어 앞서 설명한 레플리카셋은 사용량 기준에 따라 얼마나 많은 수의 포드가 실행 중이어야 하는지 정의한다. 여기서 레플리카셋은 객체, 지정된 포드 수는 사양이다. 이 레플리카셋과 관련한 클러스터의 실제 상태(status)가 있다. 컨트롤러는 이 상태에 관해 클러스터로부터 일관적인 보고서를 받고, 포드를 생성하거나 폐기함으로써 사양에 부합하는 상태를 만든다.
 

컨테이너 이미지 리포지토리

마지막으로 알아야 할 구성요소는 이미지 리포지토리(또는 이미지 레지스트리)다. 이 구성요소는 클러스터 외부에 위치하며, 필요한 컨테이너 정의를 다운로드하기 위해 관리자와 제어부가 사용한다. 레지스트리는 도커 허브(Docker Hub)를 포함한 다양한 조직에 의해 호스팅되며 퍼블릭 또는 프라이빗 형태가 있다. 주요 클라우드 제공업체는 모두 기업용 관리형 리포지토리를 제공한다.
 

컨테이너를 지배하는 쿠버네티스

이제 쿠버네티스의 아키텍처와 목표를 달성하기 위한 작동 방식을 이해했을 것이다. 쉽지 않게 느껴지겠지만, 애초에 컨테이너 기반 애플리케이션을 배포, 관리, 확장하는 것이 결코 간단한 일이 아니다. 쿠버네티스는 구성 범위가 넓고 유연해서 실무에서 마주치는 광범위한 컨테이너 기반 애플리케이션 상황에 대응할 수 있다.

쿠버네티스는 소프트웨어 아키텍처에 대한 현재의 접근 방법에서 주도적인 위치에 있는 기술이다. 따라서 데브옵스, 컨테이너, 클라우드 네이티브 애플리케이션, 마이크로서비스 아키텍처에 관심이 있는 누구나 쿠버네티스에 대한 지식을 반드시 갖추어야 한다. editor@itworld.co.kr

X