파드(Pod)를 직접 만들면 장애가 나도 쿠버네티스가 알아서 살려준다고 생각하는 분들이 많습니다. 실제로 처음 공부할 때 저도 그렇게 알고 있었는데, 직접 실습해 보니 파드를 단독으로 띄우면 노드가 죽었을 때 그냥 그대로 사라집니다. 이걸 보고서야 컨트롤러(Controller)가 왜 존재하는지 체감이 됐습니다. 컨트롤러를 통해 파드를 관리해야 Auto Healing, 버전 롤백, 오토스케일링 같은 기능이 비로소 작동합니다.
Auto Healing과 ReplicaSet이 실제로 하는 일
컨트롤러의 핵심 역할 중 하나는 Auto Healing입니다. 여기서 Auto Healing이란 특정 노드에서 파드가 죽거나 노드 자체가 다운됐을 때, 컨트롤러가 이를 감지해 다른 노드에서 파드를 자동으로 다시 실행하는 기능입니다. 파드를 직접 띄우면 이게 안 되고, 컨트롤러를 통해 파드를 만들어야만 이 기능이 활성화됩니다.
Auto Healing을 담당하는 대표적인 리소스가 ReplicaSet(레플리카셋)입니다. ReplicaSet이란 지정한 개수만큼 파드 복사본을 항상 유지해 주는 오브젝트로, selector의 matchLabels 또는 matchExpressions를 통해 어떤 파드를 관리할지 범위를 정합니다. 실습에서 replicas를 2로 잡아두고 파드 하나를 강제로 지워봤을 때 수 초 안에 새 파드가 생성되는 걸 직접 확인했습니다. 이 경험 이후로는 운영 환경에서 절대 파드를 단독으로 띄우면 안 된다는 게 몸에 새겨졌습니다.
다만, 실무에서 ReplicaSet을 직접 작성하는 경우는 거의 없습니다. 버전 관리와 업데이트 전략까지 포함된 Deployment(디플로이먼트)가 내부적으로 ReplicaSet을 관리하기 때문에, 대부분의 상황에서는 Deployment만 쓰게 됩니다.
컨트롤러가 제공하는 주요 기능을 정리하면 다음과 같습니다.
- Auto Healing: 파드 또는 노드 장애 시 다른 노드에서 자동 재실행
- Software Update: Recreate 또는 RollingUpdate 전략으로 무중단 또는 재시작 배포
- Job: 일회성 혹은 반복 작업을 위한 파드 실행 후 자동 삭제
- AutoScale: HPA·VPA·CA를 통한 자동 용량 조정
Deployment 롤링업데이트와 HPA 오토스케일링
Deployment에서 제가 가장 인상 깊었던 건 RollingUpdate(롤링업데이트) 전략입니다. RollingUpdate란 기존 버전의 파드를 한 번에 내리지 않고, 새 버전 파드를 순차적으로 올리면서 교체하는 방식으로, 서비스 중단 없이 배포가 가능합니다. 반대로 Recreate 방식은 기존 파드를 전부 내린 다음 새 파드를 띄우기 때문에 배포 중 잠깐 서비스가 끊깁니다. 처음 실습할 때 Recreate로 배포했다가 실제로 접속이 끊기는 걸 경험했고, 그때 RollingUpdate의 가치를 제대로 느꼈습니다.
Deployment는 업데이트할 때마다 이전 ReplicaSet을 히스토리로 남겨두기 때문에, 문제가 생기면 특정 리비전으로 롤백할 수 있습니다. revisionHistoryLimit 값을 설정하면 몇 개까지 이력을 보관할지 조정할 수 있고, kubectl rollout undo 명령어로 원하는 버전으로 되돌릴 수 있습니다.
HPA(HorizontalPodAutoscaler)도 직접 구성해 봤는데, 생각보다 설정이 간단했습니다. HPA란 CPU나 메모리 같은 메트릭 사용량을 모니터링하다가 부하가 임계치를 넘으면 파드 수를 자동으로 늘리고, 부하가 줄면 다시 줄여주는 오토스케일링 오브젝트입니다. 단, HPA가 동작하려면 먼저 Metrics Server(메트릭스 서버)를 클러스터에 설치해야 합니다. 메트릭스 서버란 각 노드와 파드의 CPU·메모리 사용량을 실시간으로 수집해 쿠버네티스 API에 제공하는 컴포넌트입니다. 이 서버 없이 HPA를 만들어놓으면 스케일링이 전혀 동작하지 않으니, 순서를 꼭 지켜야 합니다.
Deployment의 resources 항목에서 requests(최소 보장 자원)와 limits(최대 사용 자원)를 지정해 두면, HPA가 이 requests 값을 기준으로 사용률(%)을 계산합니다. averageUtilization을 50으로 잡으면 평균 CPU 사용률이 50%를 넘는 순간 파드가 추가로 생성됩니다(출처: Kubernetes 공식 문서).
StatefulSet과 Ingress, 그리고 Helm이 필요한 이유
Deployment가 Stateless(스테이트리스) 앱에 적합하다면, 데이터베이스처럼 상태를 유지해야 하는 앱에는 StatefulSet(스테이트풀셋)이 필요합니다. StatefulSet이란 파드마다 고유한 네트워크 ID와 스토리지를 부여해 주는 리소스로, 마스터-슬레이브 구조처럼 각 파드의 역할이 구분된 Stateful 앱을 위해 설계됐습니다.
StatefulSet은 반드시 Headless Service(헤드리스 서비스)와 함께 써야 합니다. Headless Service란 clusterIP: None으로 설정해 클러스터 IP를 부여하지 않는 서비스로, DNS 조회 시 개별 파드의 IP를 직접 반환합니다. 덕분에 파드이름.서비스이름.네임스페이스.svc.cluster.local 형식으로 특정 파드에 직접 접근할 수 있습니다. MariaDB 마스터-슬레이브 실습에서 슬레이브가 마스터 파드에 직접 접속해 복제를 시작하는 설정을 이 DNS 방식으로 처리했는데, 일반 서비스로는 로드밸런싱이 개입해서 원하는 파드를 지정할 수가 없었습니다.
StatefulSet에 볼륨을 붙일 때는 공용 PVC 하나를 연결하면 안 됩니다. 제가 처음에 volumes에 PVC를 공용으로 연결했다가 파드들이 같은 디스크를 공유하는 문제가 생겼습니다. volumeClaimTemplates를 사용해야 파드마다 독립적인 PVC가 자동 생성됩니다. 이 구조를 이해하고 나서야 DB StatefulSet 설정이 비로소 제대로 동작했습니다.
마스터-슬레이브 복제 설정을 YAML로 직접 작성해 보면 ConfigMap, StatefulSet, Headless Service, 초기화 스크립트까지 손으로 다 써야 합니다. 이때 Helm(헬름)의 가치를 실감합니다. Helm이란 쿠버네티스 애플리케이션을 패키지 단위로 배포하고 관리할 수 있게 해주는 도구로, 복잡한 멀티 리소스 구성을 values.yml 파일 하나와 install 명령어 한 줄로 처리해 줍니다(출처: Helm 공식 사이트).
마지막으로 Ingress(인그레스)는 외부 트래픽을 클러스터 내부 서비스로 라우팅하는 게이트웨이 역할을 합니다. 경로 기반 라우팅으로 /a 요청은 svc-a로, /b 요청은 svc-b로 분기할 수 있고, 도메인 기반 라우팅도 가능합니다. 규모가 작으면 nginx reverse proxy로도 충분하지만, 쿠버네티스 환경에서 프론트와 백엔드를 분리 운영할 때는 Ingress 컨트롤러를 쓰는 게 관리 측면에서 훨씬 깔끔합니다.
컨트롤러, Deployment, StatefulSet, HPA, Ingress까지 처음에는 개념이 파편적으로 흩어져 있는 것 같았는데, 실습을 반복하면서 각 리소스가 어떤 문제를 해결하려고 존재하는지 맥락이 잡혔습니다. 개념만 읽을 때는 와닿지 않던 부분이 직접 장애를 내보고 복구해 보면서 명확해졌습니다. 다음 단계로는 Helm 차트를 직접 작성해 보거나, Kafka 같은 분산 시스템을 StatefulSet으로 구성해 보는 걸 권합니다. 실제 운영 시나리오에 가까운 실습일수록 개념이 훨씬 빠르게 정착됩니다.