현대 소프트웨어 개발의 패러다임은 거대한 단일 구조인 모놀리식(Monolithic)에서 작고 독립적인 단위인 마이크로서비스 아키텍처(MSA)로 급격히 이동했습니다. 이 변화의 중심에는 클라우드 네이티브(Cloud Native)라는 개념이 자리 잡고 있습니다. 단순히 클라우드 서버를 사용하는 것을 넘어, 애플리케이션을 탄력적이고 확장 가능한 형태로 구축하는 것이 핵심입니다. 그리고 이 거대한 생태계를 지탱하는 사실상의 표준(De facto Standard) 운영체제가 바로 쿠버네티스(Kubernetes)입니다.
많은 엔지니어들이 컨테이너 기술에 입문할 때 겪는 첫 번째 난관은 도구의 복잡성입니다. 하지만 쿠버네티스는 단순한 도구가 아니라, 수천 개의 컨테이너를 유기적으로 관리하는 '오케스트레이션' 플랫폼입니다. 본 글에서는 쿠버네티스의 핵심 원리부터 실무에서 반드시 알아야 할 주요 오브젝트, 그리고 클라우드 벤더별 서비스 차이점까지 심층적으로 분석합니다.
도커와 쿠버네티스: 경쟁이 아닌 상생
초심자가 가장 흔히 하는 오해 중 하나는 "도커(Docker)를 쓸까, 쿠버네티스를 쓸까?"라는 양자택일의 질문입니다. 이는 마치 "벽돌을 쓸까, 건축 도면을 쓸까?"라고 묻는 것과 같습니다.
- 도커(Docker): 애플리케이션을 패키징하고 실행하는 컨테이너 런타임 기술입니다. 한 번에 하나의 컨테이너를 다루는 데 최적화되어 있습니다.
- 쿠버네티스(Kubernetes): 다수의 도커 컨테이너를 조율하고 관리하는 오케스트레이션 시스템입니다. 배포, 스케일링, 장애 복구를 담당합니다.
실무 환경에서는 수십, 수백 개의 컨테이너가 동시에 동작합니다. 이때 특정 컨테이너가 다운되었을 때 자동으로 재시작하거나, 트래픽이 몰릴 때 컨테이너 개수를 늘리는 작업이 필요합니다. 도커만으로는 이를 수동으로 처리해야 하지만, 쿠버네티스는 이 모든 과정을 자동화합니다. 즉, 도커가 '선박에 실을 컨테이너 박스'라면, 쿠버네티스는 '항만의 크레인과 물류 시스템'입니다.
쿠버네티스 아키텍처: 두뇌와 팔다리
쿠버네티스 클러스터는 크게 컨트롤 플레인(Control Plane)과 워커 노드(Worker Node)로 나뉩니다. 이 구조를 이해하는 것이 트러블슈팅의 시작입니다.
1. 컨트롤 플레인 (Master Node)
클러스터의 '두뇌' 역할을 하며 다음과 같은 핵심 컴포넌트로 구성됩니다.
- API Server: 모든 요청의 관문입니다.
kubectl명령어는 오직 이 API 서버하고만 통신합니다. - etcd: 클러스터의 모든 상태 데이터가 저장되는 고가용성 키-값 저장소입니다. 유일하게 상태(State)를 저장하는 곳이므로 백업이 필수적입니다.
- Scheduler: 새로 생성된 파드(Pod)를 감지하고, 리소스 상황에 맞춰 적절한 노드에 배치합니다.
- Controller Manager: 노드 다운, 복제본 수 유지 등 클러스터의 상태를 끊임없이 확인하고 교정합니다.
2. 워커 노드 (Worker Node)
실제 애플리케이션이 구동되는 '작업 공간'입니다.
- Kubelet: 마스터의 API 서버와 통신하며 노드 내의 파드를 관리하는 에이전트입니다.
- Kube-proxy: 노드의 네트워크 규칙을 유지 관리하여 파드 간의 통신을 가능하게 합니다.
- Container Runtime: 실제 컨테이너를 실행하는 엔진(Docker, containerd 등)입니다.
핵심 오브젝트: Pod, Deployment, Service
쿠버네티스에 명령을 내릴 때는 YAML 형식의 명세서를 작성하여 API 서버에 제출합니다. 가장 빈번하게 사용되는 세 가지 오브젝트를 살펴보겠습니다.
파드 (Pod): 배포의 최소 단위
쿠버네티스는 컨테이너를 직접 조작하지 않고, 파드(Pod)라는 껍데기로 감싸서 관리합니다. 하나의 파드에는 하나 이상의 컨테이너가 포함될 수 있으며, 이들은 IP와 저장소(Volume)를 공유합니다.
디플로이먼트 (Deployment): 상태 관리자
파드는 일회성 성격이 강해 언제든 죽을 수 있습니다. 디플로이먼트(Deployment)는 "파드를 3개 유지해라"와 같은 선언적 상태를 정의합니다. 파드가 하나 죽으면 디플로이먼트(정확히는 ReplicaSet)가 이를 감지하고 즉시 새로운 파드를 생성합니다.
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-web-app
spec:
replicas: 3 # 파드를 3개로 유지
selector:
matchLabels:
app: web
template:
metadata:
labels:
app: web
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80서비스 (Service): 네트워크 노출
파드는 생성될 때마다 IP가 바뀝니다. 외부나 다른 내부 서비스가 파드에 안정적으로 접근하려면 고정된 진입점이 필요한데, 이것이 서비스(Service)입니다.
- ClusterIP: 클러스터 내부에서만 접근 가능한 기본 타입.
- NodePort: 모든 노드의 특정 포트를 개방하여 외부 접근 허용.
- LoadBalancer: 클라우드 공급자(AWS, GCP 등)의 로드 밸런서를 프로비저닝하여 외부 트래픽 연결.
매니지드 서비스 비교: AWS EKS vs Google GKE
쿠버네티스를 직접 설치(On-premise)하는 것은 유지보수 비용이 매우 높습니다. 따라서 대부분의 기업은 클라우드 벤더가 제공하는 매니지드 서비스를 사용합니다. 가장 대표적인 두 서비스를 비교해 보겠습니다.
| 구분 | AWS EKS (Elastic Kubernetes Service) | Google GKE (Google Kubernetes Engine) |
|---|---|---|
| 특징 | AWS 생태계와의 강력한 통합. 엔터프라이즈 점유율이 높음. | 쿠버네티스를 만든 구글의 본가 서비스. 최신 기능 지원이 가장 빠름. |
| 편의성 | 초기 설정이 다소 복잡하며, 추가적인 애드온 설치가 필요할 수 있음. | 자동화 수준이 매우 높음(Autopilot 모드). 콘솔 UI가 직관적임. |
| 추천 대상 | 이미 AWS 인프라를 깊게 사용 중인 조직. | 쿠버네티스 본연의 기능을 쉽고 빠르게 활용하고 싶은 조직. |
결론: 마이크로서비스를 향한 여정
쿠버네티스는 단순한 유행이 아니라, 모던 인프라스트럭처의 운영체제로 자리 잡았습니다. 처음에는 개념이 방대하고 학습 곡선(Learning Curve)이 가파르게 느껴질 수 있습니다. 하지만 파드, 디플로이먼트, 서비스라는 기본 오브젝트의 상호작용을 이해하고 나면, 어떤 규모의 트래픽도 감당할 수 있는 강력한 무기를 손에 넣게 됩니다.
성공적인 클라우드 네이티브 전환을 위해서는 단순히 도구를 도입하는 것을 넘어, 애플리케이션을 작게 나누고(MSA), 컨테이너화하며, 이를 자동화하여 배포하는 전체 파이프라인을 구축하는 시각이 필요합니다. 지금 바로 로컬 환경에서 minikube나 Docker Desktop을 통해 작은 파드 하나를 띄워보는 것부터 시작해 보십시오.
Post a Comment