쿠버네티스
Kubernetes (K8s)
쿠버네티스란?
- 수많은 컨테이너 자동 배치·확장·복구
- 클라우드 시대의 관제탑
- 대규모 운영 표준
쿠버네티스를 쓰기 시작하면 운영 담당자의 일이 '서버에 접속해 명령을 치는 일'에서 '원하는 상태를 파일에 적어두는 일'로 바뀝니다. '주문 API 3벌, 메모리 1GB, 8080 포트'라고 선언해 두면 컨트롤러가 몇 초 간격으로 실제 상태와 선언을 비교해 차이를 메웁니다. 사람이 절차를 지시하는 대신 목표치를 적어 두는 방식이라, 새벽에 컨테이너 하나가 죽어도 당직자보다 시스템이 먼저 움직입니다. 장애 대응이 '복구 작업'에서 '차이 메우기'로 바뀌는 것이 실무에서 체감하는 가장 큰 변화입니다.
구성 단위는 층으로 나뉩니다. 컨테이너 한두 개를 묶은 최소 단위가 파드(Pod), 파드를 몇 벌 유지할지 책임지는 것이 디플로이먼트(Deployment), 바깥에서 들어오는 접속을 나눠주는 것이 서비스(Service)입니다. 오토스케일링도 저절로 되는 게 아니라 'CPU 사용률 70% 초과 시 최대 10벌까지' 같은 기준을 걸어야 작동합니다. 도커와 혼동하는 경우가 많은데, 도커는 컨테이너를 만들고 실행하는 도구, 쿠버네티스는 그 컨테이너를 여러 서버에 걸쳐 배차하는 도구로 층이 다릅니다. 직접 설치하는 대신 EKS·GKE·AKS 같은 관리형을 쓰면 제어 영역 운영 부담을 클라우드에 넘길 수 있습니다.
현장에서 가장 자주 어긋나는 지점은 '쿠버네티스를 얹으면 알아서 안 죽는다'는 기대입니다. 헬스체크(liveness·readiness probe)를 제대로 걸지 않으면 프로세스는 살아 있고 응답만 못 하는 파드를 정상으로 판단해 계속 트래픽을 보냅니다. 리소스 request/limit을 비워 두면 파드 하나가 메모리를 다 먹고 같은 노드의 다른 파드까지 끌고 내려갑니다. 컨테이너가 열 개 남짓인 조직이 무리해서 도입하면 앱을 만드는 인력보다 클러스터를 돌보는 인력이 더 필요해지는 역전이 벌어집니다. 상태를 가진 DB를 별 준비 없이 파드로 올리는 것 역시 흔한 사고 원인이고, 마이너 버전 지원 기간이 1년 남짓이라 정기 업그레이드 계획도 함께 세워야 합니다.
구글이 내부 시스템 '보그(Borg)'의 경험을 바탕으로 2014년 오픈소스로 공개했으며, 조 베다·브렌던 번스·크레이그 매클러키가 주도했습니다.
가상의 사례로 살펴보겠습니다. 온라인 커머스 A사(임직원 180명, 연 거래액 1,200억 원)는 대형 프로모션 때마다 주문 서버가 버티지 못했습니다. 장비를 미리 두 배로 깔아두는 방식이라 평소엔 서버 절반이 놀았는데도, 지난해 연말 행사에서 27분간 결제 페이지가 멈춘 일이 있었습니다. 인프라팀 4명이 6개월간 쿠버네티스 전환을 진행했습니다.
- 인프라팀장은 전체 이전 대신 주문·결제·상품조회 3개 API부터 손댔습니다. '한 번에 다 옮기면 되돌릴 방법이 없다'며 전체 트래픽의 15%만 신규 클러스터로 흘려보냈습니다.
- 백엔드 개발자들은 파드마다 CPU 0.5코어·메모리 1GB 상한을 붙였습니다. 상한 없이 올린 첫 주에 정산 배치가 메모리를 8GB까지 먹고 같은 노드의 상품조회 API까지 끌고 내려갔기 때문입니다.
- SRE 담당자는 오토스케일링 기준을 'CPU 65%를 넘으면 30초 안에 최대 20벌'로 다시 잡았습니다. 처음엔 90%로 뒀다가 늘어나는 속도가 트래픽을 못 따라가 두 번 밀렸습니다.
- 헬스체크가 단순 응답만 보던 탓에 DB 연결이 끊긴 파드가 계속 정상으로 잡혔습니다. 개발리드가 'DB까지 찔러보는 체크로 바꿉시다'라고 정리해 readiness probe를 다시 짰습니다.
- 6개월 뒤 프로모션에서는 피크 8분 만에 파드가 6벌에서 19벌로 늘며 중단 없이 넘겼고, 평시 서버 대수가 40% 줄어 월 인프라 비용은 2,300만 원에서 1,450만 원으로 내려갔습니다.
- 컨테이너가 많고 확장이 잦을 때
- 대규모·고가용 서비스
- 자동 배치·복구가 필요할 때
- 작은 서비스(과한 복잡성)
- 운영 역량·인력이 부족할 때
- 단순 배포로 충분한 경우