[K8S] 왜 실무에서는 쿠버네티스를 많이 쓸까?

프로젝트 진행시 겪을 수 있는 구조적 문제는 다음과 같이 있습니다.

1. 개발 환경과 모니터링 시스템이 일치할 수 없는 구조적 한계

2. 개발 중에는 사용해보지 못한 모니터링 시스템을 구축해야 하는 상황

3. 오픈시 개발 프로젝트와 서로 다른 범위의 APP들을 모니터링하게 되는 구조

 

위의 문제들은 쿠버네티스 환경에서 사용하는 모니터링과 로깅 툴을 쓰면 해결할 수 있습니다.

 

즉, Prometheus, Grafana, Loki와 같은 툴을 활용하면, 개발과 운영 환경 간의 모니터링 일관성을 확보하고, 사전에 테스트한 시스템을 실서비스에 적용하며, 다양한 범위의 애플리케이션을 통합적으로 모니터링할 수 있게 됩니다.

 

 

예를 들어, Prometheus로 CPU 사용률, 메모리 사용량 등의 메트릭 데이터를 수집하고, 이를 Grafana를 통해 시각화하면 시스템 상태를 한눈에 파악하고 손쉽게 모니터링할 수 있습니다. 

 

 

또, Loki를 통해 Spring Boot 애플리케이션의 로그를 수집하고, 이를 Grafana에서 시각화하여 실시간으로 모니터링할 수 있습니다.

이처럼 Prometheus, Grafana, Loki 기반의 모니터링은 쿠버네티스에서 가장 널리 사용되는 사실상의 표준입니다.

 

쿠버네티스의 대표 기능

이제부터는 쿠버네티스가 자동으로 처리해주는 주요 기능들을 살펴보겠습니다.

테스트를 위해 위처럼 SpringBoot서버가 2개의 파드로 이중화되어 실행되는 환경을 구축하였습니다.

1. Traffic Routing

Service, Ingress, LoadBalancer 등을 통해 트래픽을 적절한 파드로 자동 분산해주는 기능입니다.

 

예를 들어, 아래 명령어를 마스터 노드에서 실행하면, 쿠버네티스 Service가 2개의 파드 중 하나로 트래픽을 라운드로빈 방식으로 분배해주는 것을 확인할 수 있습니다:

while true; do curl http://192.168.56.30:31221/hostname; sleep 2; echo ''; done;

app-1-2-2-1-78cbbff668-nzscr
app-1-2-2-1-78cbbff668-nzscr
app-1-2-2-1-78cbbff668-5lcgl
app-1-2-2-1-78cbbff668-5lcgl
app-1-2-2-1-78cbbff668-nzscr
app-1-2-2-1-78cbbff668-5lcgl

 

위 명령어는 /hostname 요청을 반복해서 보내고, 그 결과로 각 파드의 hostname이 번갈아 출력되며 트래픽이 분산되는 것을 확인할 수 있습니다.

2. Self-Healing

파드가 죽거나 비정상 상태일 때 자동으로 재시작하거나 교체해줍니다.

 

이번에는 아래 명령어를 통해 의도적으로 메모리 초과(Memory Leak)를 유발해, 파드 중 하나를 비정상 상태로 만들어보겠습니다.

curl 192.168.56.30:31221/memory-leak

 

 

위와 같이 /memory-leak 요청으로 의도적으로 파드 하나를 비정상 종료시키면,쿠버네티스는 즉시 해당 파드를 감지하고 새로운 파드를 자동으로 생성합니다. 이때, 파드 이름이 달라지고 재시작 횟수(Restart)가 증가한 것을 통해 자가 복구(Self-Healing) 기능이 정상적으로 작동했음을 확인할 수 있습니다.

3. AutoScaling

CPU 사용률이나 사용자 정의 지표에 따라 파드를 자동으로 늘리거나 줄여줍니다.

 

이번에는 다음 명령어를 통해 의도적으로 CPU 부하를 발생시켜보겠습니다.

curl http://192.168.56.30:31221/cpu-load

위 요청을 보내면 /cpu-load 엔드포인트에서 무한 루프나 CPU 연산을 반복 수행하여, 파드의 CPU 사용량이 급격히 증가하게 됩니다.

 

 

위와 같이 /cpu-load 요청으로 CPU 부하가 일정 수준을 초과하면, 쿠버네티스의 AutoScaling 기능이 작동하여 기존 2개에서 자동으로 4개의 파드로 확장(스케일 아웃)된 것을 확인할 수 있습니다. 이처럼 쿠버네티스는 사용자 개입 없이도 리소스 사용량에 따라 파드 수를 동적으로 조절하여 트래픽 급증에도 유연하게 대응할 수 있도록 도와줍니다.

4. Rolling Update

기존 서비스를 중단하지 않고, 점진적으로 새 버전으로 업데이트할 수 있도록 도와줍니다.

 

kubectl set image 명령어를 사용하면, 현재 배포 중인 애플리케이션의 이미지를 새 버전으로 교체하며 Rolling Update를 수행할 수 있습니다.

kubectl set image -n default deployment/app-1-2-2-1 app-1-2-2-1=1pro/app-update

 

app-1-2-2-1이라는 Deployment의 컨테이너 이미지를 1pro/app-update로 변경하면 아래와 같이 새로운 파드가 순차적으로 생성되며, 기존 파드가 점진적으로 교체됩니다. 또 서비스도 중단되지 않습니다.

 

또한 이번에는 1pro/app-error라는 문제가 있는 이미지를 배포하여 에러가 나면 안정된 상태로 복구할 수 있습니다.

# 오류 이미지 배포
kubectl set image -n default deployment/app-1-2-2-1 app-1-2-2-1=1pro/app-error
# 복구
kubectl rollout undo -n default deployment/app-1-2-2-1

 

지금까지 살펴본 기능들 외에도, 쿠버네티스는 인프라 환경 관리 측면에서도 큰 장점을 제공합니다.모든 인프라 구성을 YAML 파일로 선언적으로 관리하기 때문에, 변경 이력 관리가 쉬워지고 작업 추적이 가능하며 개발, 테스트, 운영 등 환경별 설정 파일을 분리해 관리하기도 편리합니다. 즉, 반복적인 수작업 없이도 안정적이고 일관된 인프라 운영이 가능해지는 것입니다.