쉬운 설명
한두 개의 컨테이너는 사람이 손으로 띄울 수 있지만, 마이크로서비스 환경에서는 수십~수백 개가 됩니다. 서버 한 대가 꺼지면 그 위의 컨테이너들을 다른 서버로 옮겨야 하고, 트래픽이 늘면 자동으로 더 띄워야 합니다. 사람이 매번 하면 운영이 불가능합니다. 쿠버네티스는 이 일을 자동화한 도구입니다.
핵심 발상은 '원하는 상태를 선언하면, 시스템이 그 상태로 수렴하게 한다'는 것입니다. '이 앱 컨테이너 5개가 떠 있어야 한다'고 적어 두면 K8s가 그 수를 맞춰 띄우고, 하나가 죽으면 자동으로 새로 띄웁니다. 배포·스케일·복구·롤백이 모두 같은 원리 위에서 돕니다.
주요 개념 몇 가지. ① Pod(컨테이너 한두 개를 묶은 최소 단위), ② Deployment(원하는 Pod 수와 버전을 선언), ③ Service(Pod 묶음에 안정적인 네트워크 주소 제공), ④ Ingress(외부 트래픽을 서비스로 라우팅), ⑤ ConfigMap·Secret(설정·비밀 관리), ⑥ Namespace(논리적 분리). 처음엔 단어가 많아 보이지만, 익히면 비슷한 패턴의 반복입니다.
K8s는 강력하지만 복잡합니다. 작은 팀에는 과할 수도 있어, 매니지드 서비스(EKS·GKE·AKS)나 더 단순한 대안(Fly.io·Render·Cloud Run·Railway)을 먼저 고려하는 게 보통입니다. 매니지드를 쓰면 K8s의 가장 어려운 부분(컨트롤 플레인 운영)을 클라우드가 대신 책임집니다.
장단점이 분명합니다. 장점: 표준화된 운영 모델, 풍부한 에코시스템(모니터링·로그·시크릿·서비스 메시), 멀티 클라우드 가능. 단점: 학습 곡선이 가파름, 작은 변경도 여러 파일을 건드릴 수 있음, 비용이 잘못 관리되면 폭증. 그래서 '진짜 K8s가 필요한가'를 먼저 묻는 게 중요합니다 — 컨테이너 몇 개 운영이면 더 가벼운 도구로 충분합니다.
비유로 보면
쿠버네티스는 큰 호텔의 객실 자동 관리 시스템과 비슷합니다. 손님(트래픽)이 늘면 객실(컨테이너)을 더 열고, 한 객실에 문제가 생기면 손님을 다른 객실로 옮기고, 한 층 전체가 점검 중이면 다른 층으로 트래픽을 돌립니다. 호텔 매니저(사람)는 큰 그림만 보고, 일상적인 객실 관리는 시스템이 알아서 합니다.
어디에서 만나나
대규모 마이크로서비스 운영(넷플릭스·우버·에어비앤비), 머신러닝 학습 클러스터, 멀티 클라우드·하이브리드 환경, 자체 PaaS를 만드는 큰 회사. 한편 작은 팀·단순한 앱에는 Cloud Run·Render·Railway 같은 더 가벼운 대안이 점점 매력적입니다.
작은 예시
큰 SNS 서비스에서 새벽 광고 시간대에 트래픽이 평소의 10배가 됩니다. K8s가 이를 감지해 앱 컨테이너를 자동으로 50개에서 500개로 늘리고, 새벽이 지나면 다시 50개로 줄입니다. 운영팀은 평소에 푹 잘 수 있습니다.
자주 하는 오해
한 줄 정리
K8s의 진짜 가치는 '자동 복구와 표준 운영'에 있습니다. 하지만 그 가치는 어느 규모를 넘어야 비로소 비용보다 커집니다. 작게 시작하고 필요할 때 옮기는 전략이 거의 항상 안전합니다.