Kubernetes
쿠버네티스는 컨테이너화된 어플리케이션의 배포, 확장 및 관리를 자동화하는 오픈 소스 시스템입니다.
그러나 이러한 설명만으로 쿠버네티스를 정확하게 이해하기 어렵죠. 쿠버네티스를 이해하기 위해 쿠버네티스가 어떤 문제를 해결하는지 살펴봅시다.
컨테이너 배포의 문제
서버를 수동으로 관리하며 컨테이너를 수동으로 배포하는 경우를 생각해봅시다. 예를들어 AWS를 이용해 EC2를 인스턴스를 만들고, Docker를 설치해 컨테이너를 실행하는 것이죠. 이렇게 수동으로 배포하게되면 다양한 문제 상황에 직면하게 됩니다.
- 인스턴스의 자체적인 관리 및 구성
- 소프트웨어와 운영체제 버전 관리
- 컨테이너가 다운되는 경우에 대한 대비 (교체 필요)
- 모니터링 시스템 필요, 수동 교체도 필요
- 트래픽 급증시 더 많은 컨테이너 추가 필요 (트래픽에 따른 컨테이너 조절 필요)
- 인스턴스별 트래픽 분산 필요
물론 AWS는 컨테이너 재실행, 오토 스케일링, 로드 밸런싱 등의 기능을 제공하긴 합니다. 즉, 이미 위에 있는 문제들은 AWS/EC2 같은 서비스를 이용하면 쉽게 해결이 가능합니다.
수동으로 배포하지 않고 배포 서비스를 사용해야 하는 이유가 생긴 것이죠. 하지만 이런 서비스는 한 가지 단점을 갖고 있습니다. 바로 서비스 자체에 베포 프로세스가 묶인다는 것이죠.
클라우드 제공자의 클라우드 서비스를 이용한다면 우리는 그 서비스에서 정의한대로 모든 것을 구성해야 합니다. 그리고 그 구성은 마찬가지로 서비스에서 제공하는 기능을 이용해야 하는 것이죠.
문제는 이러한 설정은 하나의 클라우드 제공자에서만 동작하고, 다른 클라우드 제공자에선 작동하지 않을겁니다.
만약 AWS에서 Microsoft Azure로 전환하려면 제공하는 세부 사항, 서비스, 우리가 사용한 구성을 다른 서비스로 수동 변환 하는 등의 노력이 필요합니다. 제공하는 기능의 차이점등도 생각해야겠죠.
쿠버네티스는 바로 이런 부분을 도와주는 시스템입니다.
쿠버네티스
쿠버네티스는 클라우드 제공자와 상관없이 독립적으로 배포, 컨테이너 확장, 컨테이너 모니터링 및 실패시 교체 방법을 정의할 수 있도록 도와줍니다.
쿠버네티스는 오픈 소스 시스템이며 동시에 컨테이너 배포와 컨테이너 관리의 실질적 표준이기 때문입니다. 즉, 다음과 같은 기능의 정의가 가능해지는 것이죠.
- 자동 배포
- 확장 및 로드밸런싱
- 컨테이너 관리
쿠버네티스는 Configuration file을 작성하여 이러한 방식을 정의할 수 있도록 도와줍니다. 그리고 이러한 설정 파일은 다른 클라우드 제공자나 머신에 전달 되어도 동일하게 동작하게 되는 것이죠.
따라서 우리는 Configuration file을 작성하는 방법을 익혀야 합니다. 만약 설정 파일이 동작하지 않는 머신이 있다면 쿠버네티스 소프트웨어를 설치하여 파일을 해석할 수 있습니다.
Standardized way of describing the to-be-created and to-be-managed resources of the Kubernetes Cluster게다가 특정 클라우드 제공자가 추가 구성을 요구하는 경우, 해당 구성을 추가하는 것도 가능합니다.
한마디로 쿠버네티스는 모든 클라우드 공급자와 함께 사용할 수 있는 개념/소프트웨어 모음이라고 할 수 있습니다. 그리고 그 목표는 컨테이너 어플리케이션의 배포 및 관리에 대한 표준 정의 방식 제공입니다.
더 쉽게 Docker-Compose for multiple machine으로 해석도 가능합니다.
Core Concepts & Architecture
- Pod - 쿠버네티스의 가장 작은 단위로 Containers 및 리소스를 보유
- Proxy - Woker Node상의 네트워크 트래픽을 제어
- Worker Node - Pods를 포함하며 실행하는 주체, 즉 컨테이너를 실행시키는 주체 (AWS의 EC2 인스턴스와 대응되는 개념, 가상 컴퓨터)
- Master Node - Worker Node, Pod, Proxy를 제어하는 주체 실질적인 관리 (The Control Plane - 다양한 도구의 모음)
- Cluster - Master, Worker 노드로 구성된 네트워크
Master Node는 Cloud Provider API를 이용해 위 엔드 상태를 복제하라고 요청합니다.
Worker Nodes
Woker Node는 머신입니다. EC2에 대응되는 개념이죠. Master Node에 의해 관리되며 내부에 Pod가 있습니다.
Pod는 단순히 하나 이상의 어플리케이션 컨테이너와 컨테이너에 속하는 리소스(Volume, Ip, run config...)를 호스팅합니다. Pod 자체는 마스터노드에 의해 관리됩니다.
Worker Node는 특정 양의 CPU와 메모리를 가진 가상의 컴퓨터라고 이해할 수 있습니다. Docker 같은 소프트웨어도 설치되어 있을 수 있죠.
kubelet이라 불리는 마스터노트-워커노드 간의 통신 장치도 설치되어 있습니다. Node, Pod network communication을 관리하는 kube-proxy도 있습니다.
다행히 우리는 쿠버네티스를 통해 최종 상태만 정의하면 되고, 클라우드 제공자가 이런 최종 상태를 실제로 생성합니다.
Master Node
마스터노드 내부에서 가장 중요한 서비스는 API Server입니다. Worker Node의 kublet이 통신하는 대상이죠.
Pod를 감시하고, Pod 생성시 담당하는 Worker Node를 선택하는 역할을 하는 Scheduler입니다. Pod의 추가, 삭제 등의 작업을 진행하죠. API Server를 통해 Worker Node와 통신합니다.
Kube-Controller-Manager는 전반적으로 Woker Node를 관리하며 정확한 수의 Pod를 운영하도록 합니다. 당연히 Scheduler, API Server와 긴밀하게 작동합니다.
Cloud-Controller-Manager는 클라우드 제공자에게 무엇을 할지 알려주는 역할을 합니다.
정리
- Cluster - A set of Node machines which are running the Containerized Application (Worker Nodes) or control Other Nodes (Master Node)
- Nodes - Physical or virtual machine with a certain hardware capacity which hosts one or multiple Pods and communicates with the Cluster
- Master Node - Cluster Control Plane, managing the Pods across Worker Nodes
- Worker Node - Hosts Pods, running App Containers (+ resources)
- Pods - Pods hold the actual running App Containers + their required resources (e.g. volumes)
- Containers - Normal (Docker) Containers
- Services - A logical set (group) of Pods with a unique, Pod- and Container-independent IP address (아직 안배움)
참조
