[쿠버네티스] Kubernetes 아키텍처 입문: 클러스터는 어떻게 구성될까?

쿠버네티스의 아키텍처 구성

 

 

위 명령어의 출력 결과를 보면 kube-system 네임스페이스에 여러 Pod가 실행 중인 것을 확인할 수 있습니다. 이러한 Pod들은 단순한 시스템 프로세스가 아니라, 쿠버네티스 클러스터 전체를 운영하고 관리하는 핵심 컴포넌트들입니다.

대표적으로 클러스터의 모든 요청을 처리하는 kube-apiserver, 클러스터의 상태 정보를 저장하는 etcd, 신규 Pod의 배치 위치를 결정하는 kube-scheduler, 그리고 클러스터가 원하는 상태를 유지하도록 지속적으로 제어하는 kube-controller-manager 등이 각각 Pod 형태로 실행되고 있습니다.

위에서 확인한 kube-apiserver, etcd, kube-scheduler 등의 핵심 Pod들은 클러스터 전체를 관리하는 역할을 하며, 이들이 모여 실행되는 곳을 컨트롤 플레인(마스터 노드)이라고 부릅니다.

 

쿠버네티스의 아키텍처는 크게 이처럼 클러스터를 관리하는 컨트롤 플레인과, 우리가 만든 실제 애플리케이션 Pod들이 띄워져 동작하는 워커 노드(Worker Node)로 나뉘게 됩니다.

 

현재 예시에서는 워커 노드가 2대로 구성되어 있지만, 실제 운영 환경에서는 수십 대에서 많게는 수백 대의 노드로 클러스터를 구성하는 경우가 일반적입니다.

또한 운영 환경에서는 클러스터의 핵심 제어 기능을 담당하는 컨트롤 플레인 노드에 사용자 애플리케이션 파드를 배포하지 않는 것이 표준적인 운영 방식입니다. 이는 클러스터 관리 기능의 안정성과 가용성을 보장하기 위한 기본 원칙으로, 컨트롤 플레인 리소스를 사용자 워크로드와 분리하여 운영하는 것이 권장됩니다.

 

여기서 주목해야 할 부분은 Pod 내부에서 실행되는 실제 애플리케이션 프로세스입니다.

그림에서는 이해를 돕기 위해 Tomcat 프로세스로 표현하였지만, 실제 운영 환경에서는 Spring Boot 기반의 애플리케이션을 비롯해 Node.js, Python, Go 등 다양한 언어와 프레임워크로 개발된 서비스가 컨테이너 형태로 배포됩니다.

결국 대부분의 Pod는 개발자가 작성한 애플리케이션 코드를 실행하기 위한 목적으로 생성됩니다. 쿠버네티스의 본질적인 역할 역시 이러한 애플리케이션이 안정적으로 실행되고, 필요에 따라 확장되며, 장애 발생 시 자동으로 복구될 수 있도록 지원하는 데 있습니다.

간혹 "데이터베이스도 쿠버네티스 위에서 운영할 수 있지 않을까?"라는 질문을 받곤 합니다. 결론부터 말하면 기술적으로는 충분히 가능합니다. 실제로 PostgreSQL, MySQL, Redis, MongoDB와 같은 다양한 데이터 플랫폼이 쿠버네티스 환경에서 운영되고 있으며, 최근에는 Operator를 활용한 자동화된 운영 방식도 널리 사용되고 있습니다.

다만 데이터베이스는 일반 애플리케이션과 달리 상태를 보존해야 하는 대표적인 워크로드입니다. 데이터 정합성, 백업 및 복구, 장애 조치, 스토리지 관리 등 고려해야 할 요소가 많아 전통적인 온프레미스 환경에서도 높은 수준의 운영 역량이 요구됩니다.

특히 데이터베이스 장애는 단순히 프로세스를 재기동하는 것으로 해결되지 않는 경우가 많습니다. 데이터 손상, 성능 저하, 클러스터 장애, 복제 지연과 같은 문제는 데이터베이스 아키텍처 자체에 대한 깊은 이해가 필요하며, 이는 애플리케이션 개발이나 쿠버네티스 운영과는 또 다른 전문 영역에 해당합니다.

 

반면 Redis, Kafka와 같은 미들웨어 플랫폼은 이미 쿠버네티스 환경에서 폭넓게 활용되고 있으며, 대규모 운영 사례 또한 충분히 검증되어 있습니다. 특히 마이크로서비스 아키텍처 환경에서는 이러한 플랫폼을 쿠버네티스 기반으로 운영하는 것이 일반적인 형태로 자리 잡고 있습니다.

 

이러한 이유로 많은 기업들은 쿠버네티스를 애플리케이션 계층과 미들웨어 플랫폼의 운영 환경으로 활용하고, 핵심 데이터베이스는 Oracle RAC, Exadata, 클라우드 관리형 데이터베이스 서비스와 같은 별도의 전문 플랫폼에서 운영하는 방식을 선택하고 있습니다.

 

물론 Oracle 데이터베이스 역시 쿠버네티스 환경에서 운영하는 것이 가능합니다. 그러나 이를 위해서는 Oracle 아키텍처에 대한 깊은 이해뿐만 아니라 쿠버네티스, 스토리지, 네트워크, 고가용성 구성에 대한 전문 지식이 함께 요구됩니다. 따라서 대부분의 기업에서는 검증된 데이터베이스 플랫폼을 별도로 운영하고, 쿠버네티스는 애플리케이션과 미들웨어 계층에 집중시키는 전략을 채택하고 있습니다.

 

즉, 현대적인 엔터프라이즈 아키텍처에서는 애플리케이션 계층은 쿠버네티스 기반의 마이크로서비스로 구성하고, 데이터 계층은 베어메탈 또는 물리 인프라 기반의 고가용성 데이터베이스 플랫폼으로 분리하여 운영하는 구조가 일반적으로 채택되고 있습니다.