컨테이너로 어플리케이션 워크로드를 운영하는 것은 일반 가상 환경에서 서버를 운영하는 것과 다르다.

특히 실제 서비스 운영 단계에 봉착하면 컨테이너 자체의 관리 뿐 아니라 Docker 설정 환경 상 이슈, 컨테이너 들 간에 Dependency 관리 및 스케일링과 같은 다양한 문제를 만나게 되며, 이러한 문제를 마주치면 컨테이너가 무조건 좋은 기술만은 아니라는 생각이 들게 된다.

 

이 문제를 해결하기 위해 실제 프로덕션 환경에서는 Container 들 간에 논리적인 Orchestration 을 수행하게 된다. 이를 통해 컨테이너를 적절히 배치하고 스케줄링하며 죽은 컨테이너를 재구성해준다.

 

이를 통해 실제로 컨테이너 기반의 서비스를 한다는 것은 기존 전통적인 방식대로 몇개 컨테이너 위에서 서비스를 구동하고 직접 유지보수하는 것이 아니라 수많은 컨테이너를 띄워놓고 Container Orchestration Tool 을 통해 수많은 컨테이너의 관리 및 제어를 하는 것을 의미하게 된다.

이를 통해 각종 리소스의 관리, 컨테이너 라이프사이클 관리 및 서비스 관리 전반을 포괄하는 Container Orchestrator 에 대해서는 반드시 알아야하는 필수 지식이 되게 된다. 컨테이너 오케스트레이터는 YAML, JSON 과 같은 설정 파일을 기반으로 컨테이너 클러스터를 서술하며 이를 통해 어플리케이션 환경, 네트워크 구성 방법, 로그 저장 방식 등 어플리케이션 전체 환경을 포괄하는 코드 파이프라인을 구성한다.

 

가장 유명한 서비스는 역시 구글의 Kubernetes(k8s) 이다. 사실상 컨테이너 오케스트레이션 툴의 스탠다드가 되어가고 있으며, 이를 클라우드 위에서 활용한다면 아마존의 EKS(Elastic Kubernetes Service) 등 위에서 매니지드 인프라를 통해 제공받게 된다.

 

쿠버네티스는 구글에서 시작되어 CNCF 재단에서 기증받아 운영되는 오픈소스 프로젝트로, 운영 환경의 기본 사상 자체가 모든 클러스터 환경의 관리를 kubectl 과 같은 CLI 를 통해 YAML 파일 형태로 관리하는 것을 추구한다. (실제로 수많은 컨테이너를 중앙 관리하려면 코드 없이 관리가 사실 상 불가능하다..)

 

쿠버네티스에서 컨테이너들은 일종의 클러스터(Cluster)를 구성하며 이는 노드들의 집합으로 이해하면 된다.

쿠버네티스는 위와 같이 제어부(Control Plane)와 데이터부(Data Plane)을 갖고 있으며, Control Plane 에서는 Worker Node 들과 Cluster 내의 Pod 들을 관리하고 제어하는 역할을 수행하고, 사용자가 제어할 수 있는 인터페이스를 API 서버 형태로 제공한다.

Data Plane 은 워커 노드(Worker Node)들로 구성되어 있으며 컨테이너화된 어플리케이션의 구성 요소인 파드(Pod)를 호스팅하게 된다.

 

데이터 플레인에는 Kube-proxy 라는 일종의 프록시 서버가 존재하는데, Data Plane 내에서 네트워크의 조작을 담당하며, 특히 각 Pod 가 Failover 될 수 있기 때문에 해당 부분에 대한 제어 등 Access 를 위한 엔드포인트로써 사용되어진다.

Data Plane 의 kubelet 은 컨테이너 제어를 위한 런타임 인터페이스로 초창기에는 Docker 에 종속적인 내부 모듈이었지만, 이제는 표준화된 런타임인 Container Runtime Interface(CRI) 를 기반으로 구성되어 컨테이너 관리를 위한 추상화된 계층 형태를 제공한다.

 

개발자 및 관리자는 Kubectl 이라는 쿠버네티스 API 명령어를 인터페이스로 k8s 클러스터의 컨트롤 플레인과 통신하며, 내부를 CLI 로 제어한다. 

 

 

기초적인 개념에 대한 1차 정리는 여기까지 마치고, 내부 구성 요소들에 대한 개념은 다음 포스팅에 정리합니다. :) 

 

+ Recent posts