🔨[개발] Kubernetes를 써보자

지금 사내에서 개발중인 서비스는 다음과 같은 구조로 구성되어 있음:

1. 실제 사용자가 접속해서 Request를 날리는 App
2. Request를 처리하는 Backend (FastAPI) → Redis Queue 또는 DB에 삽입
3. Queue에 넣은 요청을 Dispatcher가 Celery Worker로 전달
4. Celery Worker가 Task를 하나씩 실행

즉, 각 프로그램을 단순 명령어로 실행하고 있음.
이 구조를 Kubernetes로 오케스트레이션하면 더 편하게, 안전하게 관리할 수 있을까?
장점과 적용 방법을 단계별로 정리해보자.

---

1. Kubernetes

1.1 Kubernetes란?

컨테이너화된 애플리케이션의 대규모 자동 배포,
스케일링 및 관리를 간편하게 만들어주는 오픈 소스 기반
컨테이너 오케스트레이션(Container Orchestration) 도구

쉽게 말하면,
“컨테이너를 군집으로 묶고, 관리하는 자동화 시스템”

K8s 이름 유래

• Kubernetes → 그리스어로 “조타수, 파일럿, 선장” 의미
• 개발자들이 짧게 줄여서 K8s로 사용
  • K + 8글자 생략 + s → “K”와 “s” 사이에 8글자 존재

---

1.2 컨테이너가 뭐지?

• 먼저, 컨테이너가 나오게 된 배경을 알아야 함
  

1. 전통적 배포 (Traditional Deployment)

• 한 대의 컴퓨터(서버)에 하나의 OS)를 설치하고 여러 프로그램 실행
• 예: PC에 Windows 설치 → 게임, 워드프로세서, 은행 보안 프로그램 설치
• 문제점:
  1. 보안 프로그램, 필수 프로그램 증가 → 리소스 사용량 증가, 속도 저하
  2. OS 단위로 격리되지 않아 프로그램 간 충돌 가능
  3. 확장/배포 유연성 부족

2. 가상화 배포 (Virtualized Deployment)

• 하나의 서버(OS) 위에 여러 가상 컴퓨터(VM)를 생성
• 하이퍼바이저(Hypervisor)가 OS와 VM 사이 중간 계층 역할
  • VM마다 OS 설치 가능 → 프로그램 독립 실행
• 장점:
  1. 프로그램 충돌 격리 가능
  2. 운영체제 단위로 환경 분리
• 단점:
  1. VM마다 OS 포함 → 리소스 사용량 많음
  2. VM 기동 시간 느림

3. 컨테이너 배포 (Container Deployment)

• 하이퍼바이저 → Container Runtime으로 대체
• VM → Container로 대체
• 컨테이너는 OS를 매번 설치할 필요 없이 커널을 공유하면서 프로그램 격리
• 장점:
  1. 가볍고 빠름 → OS 전체를 포함하지 않음
  2. 리소스 효율적 → 더 많은 애플리케이션 실행 가능
  3. 배포/확장 용이 → 이미지 기반, 빠른 시작
  4. 격리된 환경 제공 → 프로그램 간 충돌 최소화

Container Runtime: 컨테이너를 실제로 실행하고 관리하는 소프트웨어

배포 방식	OS 포함 여부	격리 수준	리소스 효율	기동 속도	특징
전통적 배포	OS 1개	낮음	낮음	빠름	모든 프로그램이 같은 OS에서 실행
가상화 배포 (VM)	VM마다 OS 포함	높음	낮음	느림	프로그램 간 충돌 방지, OS 단위 격리
컨테이너 배포	OS 공유, 커널만	높음	높음	매우 빠름	프로그램 단위 격리, 경량, 배포/확장 용이

즉, 컨테이너는 기존 전통적 배포와 가상화 배포의 한계를 극복하고,
프로그램 단위 격리와 가벼운 리소스 사용,
빠른 배포를 가능하게 해 현대 마이크로서비스 환경에 최적화된 배포 방식을 제공함

---

1.3 오케스트레이션(Orchestration)이란?

• 다수의 컨테이너를 배포, 확장, 모니터링, 장애 대응까지 자동화하는 기술

마치 컴퓨터 게임에서 여러 캐릭터를 동시에 관리하고,
그들이 잘 협력하며 미션을 수행할 수 있도록 지휘하는 것처럼,
컴퓨터 프로그램(애플리케이션)들을 효율적으로 관리해 주는 도구입니다.
특히 이 프로그램들은 '컨테이너'라고 불리는 특별한 상자 안에 담겨 있으며,
쿠버네티스는 이들 상자를 필요한 곳에 옮기고, 상자 안의 프로그램이 잘 돌아가도록 도움

아 ~ 점점 많아지는 컨테이너들을 통합적으로
문제없이 돌아갈 수 있도록 해주는
자동 컨테이너 관리 솔루션이구나!

• 기존 단순 실행 스크립트와 차이:

  단순 실행	오케스트레이션(Kubernetes)
  수동 실행	자동 배포/확장
  장애 시 직접 재시작	장애 자동 복구
  로그, 상태 모니터링 수동	통합 모니터링 가능
  확장 시 서버 직접 관리	Horizontal Pod Autoscaling으로 자동 확장

---

1.4 Kubernetes의 핵심 기능

1. 자동 복구(Self-healing)

   • 실패한 컨테이너 자동 재시작
   • 정의된 상태와 다르면 자동 교체

2. 로드 밸런싱(Load Balancing)

   • 애플리케이션 트래픽 자동 분산
   • 외부 트래픽 처리용 고유 IP 제공

3. 서비스 발견(Service Discovery)

   • 컨테이너 간 통신 자동 설정

4. 확장성(Scaling)

   • 명령어 하나로 컨테이너 수 쉽게 늘리거나 줄이기 가능

---

1.5 Kubernetes의 핵심 구성 요소

• 파드(Pod)

  • 가장 작은 배포 단위, 하나 이상의 컨테이너 포함

• 서비스(Service)

  • 파드 집합에 대한 지속적인 접근 방법 제공

• 볼륨(Volume)

  • 데이터를 저장하고 파드 간 공유 가능

• 네임스페이스(Namespace)

  • 클러스터 리소스를 분할하여 격리 사용 가능

---

1.6 Kubernetes를 적용했을 때의 장점

1. 확장성(Scalability)

   • 요청 폭주 시 Pod 수를 자동으로 늘리고, 트래픽 감소 시 줄임
   • 예: FastAPI Backend 2 → 10 Pod 자동 확장

2. 자기 치유(Self-Healing)

   • Pod Crash 시 자동 재시작
   • 노드 장애 시 다른 노드로 재배치

3. 배포 용이성(Deployment)

   • Rolling Update, Rollback 지원
   • 다운타임 최소화

4. 환경 관리(Config)

   • ConfigMap/Secret으로 환경 변수와 인증 정보 관리
   • 이미지 버전 변경만으로 전체 서비스 업데이트 가능

5. 서비스 추상화

   • Pod IP 직접 관리 필요 없음 → Service가 내부 통신 담당
   • LoadBalancer/Ingress로 외부 접근 제어

6. 모니터링과 로깅

   • 통합 로그/모니터링 시스템과 쉽게 연동 가능
   • Prometheus, Grafana, ELK 스택 등

7. DevOps 친화

   • CI/CD 파이프라인과 연계 용이
   • IaC(Infrastructure as Code) 가능

---

2. 기존 환경에 Kubernetes를 적용해보자

2.1 App

• 적용 방식: Deployment + Service(LB), Auto-scaling 가능
• 기존 환경: 명령어로 수동 실행
• Kubernetes 적용 후: Deployment로 자동 배포, 롤링 업데이트 가능 → 관리 편리, 다운타임 최소화

---

2.2 Backend (FastAPI)

• 적용 방식: Deployment, Pod 수 조절, LoadBalancer Service로 요청 분산
• 기존 환경: 단일 인스턴스
• Kubernetes 적용 후: Pod 복제 가능, 요청 분산 → 트래픽 증가 시 자동 확장, 안정성 향상

---

2.3 Redis Queue

• 적용 방식: StatefulSet 또는 Deployment, Persist Volume 사용
• 기존 환경: 수동 관리
• Kubernetes 적용 후: Pod 재시작 시 데이터 유지 가능, 안정적 운영 가능

---

2.4 Dispatcher + Celery Worker

• 적용 방식: Dispatcher는 Deployment, Celery Worker는 Job/Deployment, 필요 시 Worker 수 조절
• 기존 환경: 수동 실행, 요청 처리 병렬화 어려움
• Kubernetes 적용 후: 자동 스케일링 가능, 요청 처리 병렬화 용이, 장애 대응 자동화

---

2.5 Config 관리

• 적용 방식: ConfigMap / Secret으로 환경 변수, DB URL, Redis URL 관리
• 기존 환경: .env 파일 수동 관리
• Kubernetes 적용 후: 안전하게 중앙 관리, 환경 분리 용이, CI/CD 연계 가능

---

2.6 전반적 변화 요약

프로그램	기존 환경	Kubernetes 적용 후
App	수동 실행	Deployment + LB, Auto-scaling
Backend	단일 인스턴스	Pod 복제, LoadBalancer 요청 분산
Redis Queue	수동 관리	StatefulSet/Deployment, Persist Volume
Dispatcher + Celery	수동 실행	Deployment + Job/Worker, 자동 스케일링
장애 대응	수동 재시작	Pod Crash 시 자동 재시작(Self-healing)
확장	수동 조정	Horizontal Pod Autoscaler(HPA)
환경 변수	.env 파일	ConfigMap/Secret으로 안전 관리
서비스 Discovery	직접 IP/Port 관리	Kubernetes Service + 내부 DNS 제공