쿠버네티스(K8s)란? 개념, 장점, 도커와의 차이점 완벽 정리

컨테이너가 수십 개로 늘어나면 운영의 한계에 부딪힙니다. 사람이 일일이 감시하고 대응하기엔 서비스 규모와 변화 속도가 너무 빠르기 때문입니다. 이럴 때 필요한 것이 바로 쿠버네티스입니다. 이 글에서는 입문자도 쉽게 이해할 수 있도록 쿠버네티스의 핵심 개념부터 도커와의 차이, 실무 활용법까지 명확하게 정리해 드리겠습니다.

‍

쿠버네티스(k8s)란?

쿠버네티스(Kubernetes)는 컨테이너화된 애플리케이션의 배포, 확장, 관리를 자동으로 처리해주는 오픈소스 플랫폼입니다. 줄여서 K8s라고도 부르며, 그리스어로 '조타수'를 뜻합니다. 배의 방향을 잡고 항해를 이끄는 사람처럼 쿠버네티스는 복잡한 컨테이너 환경의 방향을 잡아주는 역할을 합니다.

‍

컨테이너 오케스트레이션, 왜 필요할까요?

애플리케이션 실행 환경은 물리 서버 → 가상머신(VM) → 컨테이너로 발전해왔습니다. 컨테이너는 애플리케이션과 실행에 필요한 모든 구성 요소를 하나의 가벼운 패키지로 묶은 것입니다. VM에 비해 사이즈가 작아 배포가 빠르고 성능 손실이 거의 없습니다.

하지만 컨테이너가 수십, 수백 개로 늘어나면 사람이 일일이 관리하기는 불가능합니다. 오케스트라의 지휘자처럼, 컨테이너를 언제 만들고, 어디에 배치하고, 문제가 생기면 어떻게 복구할지 자동으로 결정하는 것이 바로 '컨테이너 오케스트레이션'입니다.

‍

구글에서 탄생한 쿠버네티스의 목적

쿠버네티스는 구글 엔지니어들이 개발한 플랫폼입니다. 구글은 2003년경부터 내부적으로 'Borg'라는 대규모 클러스터 관리 시스템을 운영하며, Google 검색, Gmail, YouTube 등의 인프라를 관리해왔습니다. 일주일에 20억 개 이상의 컨테이너 배포를 처리하며 축적된 15년 이상의 경험을 바탕으로, 2014년 6월 쿠버네티스를 오픈소스로 공개했습니다.

이듬해인 2015년 7월 v1.0이 출시되었고, 현재는 CNCF(Cloud Native Computing Foundation)에 의해 관리되고 있습니다. 목적은 명확합니다. 누구나 대규모 컨테이너 환경을 안정적이고 효율적으로 운영할 수 있도록 돕는 것입니다.

‍

그렇다면 쿠버네티스를 도입하면 구체적으로 어떤 이점이 있을까요?

쿠버네티스 쓰는 이유, 도입 시 얻는 장점은 무엇일까요?

‍

장애를 스스로 복구하는, 자가 치유(Self-healing)

컨테이너가 갑자기 멈추거나 오류가 발생하면, 쿠버네티스는 이를 자동으로 감지해 재시작하거나 새 컨테이너로 교체합니다. ReplicaSet이 항상 설정한 수의 파드(Pod)를 유지하므로, 일부에 문제가 생겨도 전체 서비스에는 영향이 없습니다. 복구 과정은 사용자에게 노출되지 않아, 서비스 중단 없이 문제가 해결됩니다.

‍

접속자가 몰려도 거뜬한, 자동 확장(Auto-scaling)

서비스에 접속자가 갑자기 폭주하면 쿠버네티스는 CPU나 메모리 사용량을 기반으로 컨테이너를 자동으로 늘립니다. HPA(Horizontal Pod Autoscaler)는 파드 수를, VPA(Vertical Pod Autoscaler)는 파드의 리소스 할당을, Cluster Autoscaler는 노드 수까지 자동으로 조절합니다. 반대로 트래픽이 줄면 불필요한 리소스를 줄여 비용도 절약합니다. 사람이 직접 서버를 추가하거나 줄일 필요 없이, 시스템이 수요에 따라 유연하게 대응합니다.

‍

트래픽을 골고루 나누는, 로드 밸런싱(Load Balancing)

하나의 컨테이너에 요청이 집중되면 과부하가 걸리고 응답 속도가 느려집니다. 쿠버네티스의 Service 리소스는 들어오는 트래픽을 여러 컨테이너(파드)에 골고루 분배해 특정 컨테이너에 부하가 몰리지 않도록 합니다. 외부 트래픽 유입을 위해 Ingress(도메인/경로 기반 라우팅)나 LoadBalancer 리소스를 활용할 수도 있습니다. 덕분에 사용자는 항상 빠르고 안정적인 서비스를 경험할 수 있습니다.

‍

무중단 배포와 자동 롤백 (Rolling Update &Automated Rollback)

쿠버네티스는 새로운 버전을 배포할 때 Rolling Update, Blue-Green, Canary 등 다양한 무중단 배포 전략을 지원합니다. 새 버전을 점진적으로 반영하면서도 사용자에게는 안정적인 서비스를 제공할 수 있고, 배포 중 문제가 발생하면 이전의 안정된 버전으로 자동 롤백해 서비스 중단 없이 빠르게 복구합니다. YAML 파일로 시스템 상태를 선언적으로 관리할 수 있어, ArgoCD 같은 GitOps 도구와 연계하면 코드 변경과 동시에 자동 배포도 가능합니다.

‍

이러한 기능들이 어떻게 가능한 걸까요? 쿠버네티스의 내부 구조를 살펴보면 그 이유를 알 수 있습니다.

쿠버네티스의 4가지 핵심 구성 요소와작동 원리를 알려드릴게요

‍

1. 컨트롤 플레인과 워커 노드, 전체 시스템을 관리하는 두뇌와 일꾼의 구조

쿠버네티스의 가장 기본 단위는 '클러스터'입니다. 클러스터는 여러 개의 노드(Node)로 구성되며, 크게 컨트롤 플레인(Control Plane)과 워커 노드(Worker Node)로 나뉩니다.

• 컨트롤 플레인은 '두뇌' 역할을 합니다. 어떤 작업을 어느 노드에 배치할지 결정하고(kube-scheduler), 전체 시스템의 상태를 모니터링하며(kube-controller-manager), 명령을 내립니다(kube-api-server). 클러스터의 모든 설정 데이터는 etcd라는 저장소에 보관됩니다.
• 워커 노드는 '일꾼'입니다. 컨트롤 플레인이 내린 명령에 따라 실제 컨테이너를 실행하고 애플리케이션을 구동합니다. 각 워커 노드에는 kubelet(노드 에이전트)이 상주하며 컨테이너의 생성, 삭제, 상태 모니터링을 담당하고, kube-proxy가 파드 간 네트워크 통신과 외부 트래픽 라우팅을 처리합니다.

‍

2. 파드(Pod), 일꾼이 처리하는 '최소 단위의 업무'

파드는 쿠버네티스의 최소 배포 단위입니다. 하나의 파드 안에 하나 또는 여러 개의 컨테이너가 함께 들어갑니다. 같은 파드 안의 컨테이너들은 같은 네트워크(IP 주소)와 저장 공간을 공유합니다. 쉽게 비유하면, 파드는 한 장의 작업 지시서이고, 그 안의 컨테이너는 그 지시서에 적힌 개별 업무라고 생각하면 됩니다.

‍

3. 디플로이먼트, 업무들을 유지할 수 있게 만드는 명령서

디플로이먼트(Deployment)는 '파드를 몇 개 유지해라'라는 명령서입니다. 예를 들어 '이 파드를 항상 3개 유지해라'고 설정하면, 하나가 죽어도 쿠버네티스가 자동으로 새 파드를 만들어 3개를 복원합니다. 내부적으로는 ReplicaSet이 파드 수를 관리하며, 업데이트도 간단합니다. 새 버전을 순차적으로 배포하다가 문제가 생기면 이전 버전으로 자동 롤백할 수 있습니다.

‍

4. 서비스, 외부 노출과 고정 주소

파드는 생성되고 삭제될 때마다 IP 주소가 바뀝니다. 서비스(Service)는 이런 파드들 앞에 고정된 접근 주소를 부여해, 파드가 재시작되더라도 항상 일관된 방식으로 접근할 수 있게 합니다(서비스 디스커버리). 외부에서든 내부 파드에서든 이 고정 주소를 통해 안정적으로 통신할 수 있습니다. 마치 회사의 대표전화번호처럼, 담당자가 바뀌어도 번호는 그대로인 것과 같습니다.

‍

여기까지 읽으셨다면 도커와 쿠버네티스의 차이가 궁금하실 수 있습니다.

도커와 쿠버네티스, 어떤 차이이고 무슨 관계일까요?

도커와 쿠버네티스는 경쟁 관계가 아니라 역할이 다른 파트너입니다. 도커는 컨테이너를 '만드는' 도구이고, 쿠버네티스는 그 컨테이너를 '관리하는' 도구입니다. 요리에 비유하면, 도커는 재료를 담는 '밀폐 용기'이고, 쿠버네티스는 그 용기들을 정리하고 필요한 재료를 꺼내주는 '스마트 냉장고'입니다.

‍

그런데 이런 파트너 관계에도 불구하고, '쿠버네티스가 도커 지원을 중단했다'는 이야기를 들어보신 적 있으실 겁니다. 실제로 무슨 일이 있었던 걸까요?

‍

쿠버네티스 도커 지원 중단, 왜 일어났고 대체재는?

많은 분들이 '쿠버네티스가 도커를 버렸다'고 오해하지만, 정확히는 쿠버네티스가 도커를 '컨테이너 런타임'으로 사용하는 것을 중단한 것입니다. 쿠버네티스는 CRI(Container Runtime Interface)라는 표준 인터페이스로 컨테이너 런타임과 통신하는데, 도커는 CRI 이전에 만들어진 기술이라 이를 지원하지 않았습니다. 그래서 쿠버네티스는 '도커심(dockershim)'이라는 어댑터를 중간에 두고 연결해왔습니다.

하지만 이 도커심이 유지보수 부담과 불필요한 복잡성을 키웠고, 특정 벤더에 종속적인 코드를 유지하는 것은 오픈소스 철학에도 맞지 않았습니다. 결국 2022년 v1.24에서 도커심이 완전히 제거되었습니다.

대체재는 containerd와 CRI-O 같은 CRI 호환 런타임입니다. containerd는 원래 도커 내부에서 쓰이던 런타임이므로, 기존 사용자 입장에서 실질적인 차이는 거의 없습니다. 또한 도커로 빌드한 이미지는 OCI 표준을 준수하기 때문에 쿠버네티스에서 그대로 실행됩니다. 개발 환경에서 도커를 쓰는 것에는 전혀 문제가 없으니 걱정하지 않으셔도 됩니다.

‍

기업 사례: 실제로는 어떻게 활용될까요?

Spotify, 마이크로서비스 전환과 빠른 배포로 CPU활용률 2-3배 향상

• 도입 상황: Spotify는 음악 스트리밍 서비스 초기부터 마이크로서비스와 컨테이너를 사용해왔습니다. 처음에는 자체 오케스트레이션 도구인 Helios를 쓰다가, 더 큰 커뮤니티 지원과 효율을 위해 쿠버네티스로 전환했습니다.
• 결과: 기존에 새 서비스를 만들어 프로덕션에 올리기까지 1시간 이상 걸리던 작업이 수 분 내로 단축되었습니다. 추가로 자동 스케일링 덕분에 CPU 활용률이 평균 2~3배 향상되었습니다. 현재는 쿠버네티스 위에서 초당 1,000만 건 이상의 요청을 처리하고 있습니다.

‍

Airbnb, 트래픽 폭주 대응하고 비용 절감, 배포 속도 10배 향상

• 도입 상황: Airbnb는 초기에 Amazon EC2 기반의 모놀리식 아키텍처를 사용했지만, 성수기마다 급증하는 트래픽과 느린 배포 속도로 한계를 겪었습니다.
• 결과: 쿠버네티스 도입 후, 성수기 트래픽이 300% 증가해도 Auto Scaling(HPA, VPA, Cluster Autoscaler)을 통해 유연하게 인프라를 확장할 수 있게 되었고, 리소스를 필요한 만큼만 사용하면서 서버 비용도 크게 절감했습니다. 하루 400만 개 이상의 컨테이너를 안정적으로 배포하며, 배포 속도도 기존 대비 10배 이상 빨라졌습니다.

‍

사례에서 보듯 효과는 분명하지만, 도입 전에 반드시 점검해야 할 것들이 있습니다.

쿠버네티스 도입 전, 이 3가지는 꼭 체크하세요

1. 인프라 환경 체크

쿠버네티스는 온프레미스, 퍼블릭 클라우드, 하이브리드 환경 모두에서 실행할 수 있습니다. 하지만 도입 전에 현재 인프라가 쿠버네티스와 호환되는지, 네트워크 구성은 적절한지, 관리형 서비스(EKS, GKE, AKS)를 쓸지 직접 구축할지를 먼저 검토해야 합니다.

2. 학습 곡선 인정

쿠버네티스는 강력한 도구이지만, 학습 곡선이 존재합니다. YAML 설정 파일, 클러스터 구성, 네트워크 개념 등 새로운 지식을 익혀야 합니다. 팀 내에 쿠버네티스 경험자가 있는지, 없다면 교육과 적응 기간을 얼마나 확보할 수 있는지 현실적으로 판단해야 합니다.

3. 비용 vs 효율

쿠버네티스 자체는 오픈소스로 무료이지만, 클러스터 운영에는 인프라 비용과 인력 비용이 듭니다. 소규모 서비스라면 과도한 인프라가 될 수 있고, 대규모 서비스라면 자동화로 인한 비용 절감 효과가 큽니다. 우리 서비스의 규모와 성장 계획에 맞춰 ROI를 따져보세요.

‍

그럼에도 불구하고 많은 기업이 쿠버네티스를 선택하는 이유가 있습니다. 단순한 트렌드가 아니라, 업계 표준이 되어가고 있기 때문입니다.

클라우드 네이티브 시대, 쿠버네티스가 표준입니다

AWS, Google Cloud, Azure 모두 관리형 쿠버네티스 서비스(EKS, GKE, AKS)를 제공하고 있고, CNCF(Cloud Native Computing Foundation)를 중심으로 거대한 에코시스템이 형성되면서 쿠버네티스는 단순한 컨테이너 관리 도구를 넘어 클라우드 네이티브의 사실상 표준으로 자리 잡았습니다.

쿠버네티스의 가장 큰 강점 중 하나는 이식성입니다. 온프레미스, 퍼블릭 클라우드, 하이브리드 환경 어디에서든 동일한 명령어와 방식으로 애플리케이션을 배포할 수 있습니다. 특정 클라우드 벤더에 종속되지 않기 때문에, 멀티 클라우드 전략이나 향후 인프라 전환 시에도 유연하게 대응할 수 있습니다.

여기에 보안, 네트워킹, 서비스 메시, CI/CD, AI/ML 워크로드까지 최신 클라우드 기술 대부분이 쿠버네티스 위에서 만들어지고 있습니다. Istio, Prometheus, ArgoCD, Kubeflow 같은 핵심 도구들이 모두 이 생태계에서 태어났습니다. 쿠버네티스를 도입한다는 건 하나의 도구를 선택하는 것이 아니라, 이 거대한 생태계 전체에 올라타는 것입니다.

‍

쿠버네티스가 자동으로 운영을 맡아준다고 해도, 그 안에서 무슨 일이 일어나는지 들여다볼 수 있어야 합니다. 여기서 모니터링의 역할이 시작됩니다.

쿠버네티스 모니터링, 와탭으로 시작하세요

쿠버네티스가 장애 복구, 확장, 배포를 자동으로 처리해줘도, 왜 문제가 생겼는지, 리소스를 얼마나 쓰고 있는지는 사람이 직접 확인해야 합니다. 하지만 쿠버네티스의 다양한 리소스들은 각기 다른 데이터 수집 방식을 필요로 하고, 단순히 데이터를 나열하는 것만으로는 가시성을 확보할 수 없습니다.

와탭은 컨트롤 플레인부터 애플리케이션까지 전 영역의 메트릭스, 트레이스, 로그, 이벤트를 한 화면에서 통합 관제할 수 있어, 문제 해결 시간을 단축하고 비용 최적화까지 빠르게 판단할 수 있습니다.

1. 컨테이너 맵 기반의 통합 모니터링

‍컨테이너 뷰와 Pod 뷰를 모두 제공하는 컨테이너 맵으로 실시간 상태를 직관적으로 파악할 수 있습니다. 그룹화와 필터링 등 다양한 시각화 옵션을 지원하며, 메트릭스·트레이스·로그 상관 분석을 통해 근본 원인 추적(Root Cause Analysis)까지 가능합니다.

2. 대규모 클러스터의 실시간 모니터링과 합리적인 비용

‍부하량 증가 없이 수백 대 노드를 초 단위로 모니터링할 수 있고, 합리적인 라이선스 정책으로 비용 부담을 줄여줍니다. 오브젝트 매니페스트를 화면에서 바로 비교해 명령어 없이도 설정 변경 이력을 추적할 수 있습니다.

3. 컨테이너 속 애플리케이션까지 상세 분석

‍Pod 단위의 분산 환경에서 트랜잭션의 API 호출 관계를 추적하고, 히트맵·멀티 트랜잭션 추적·MSA 분석 기능으로 Java, Node.js, Python 기반 애플리케이션까지 깊이 있게 분석합니다.

4. Prometheus/Grafana 환경의 통합 모니터링

‍기존에 Prometheus/Grafana로 구축한 모니터링 환경도 와탭의 OpenMetrics 연동 기능을 통해 하나의 플랫폼에서 통합 관제할 수 있습니다. 별도 대시보드를 오갈 필요 없이 커스텀 메트릭스까지 함께 확인하고 관리할 수 있습니다.

5. CNCF 인증 기술력, 국내외 주요 플랫폼 지원

‍KCSP 인증과 CSAP을 획득했으며, EKS·AKS·GKE는 물론 네이버 클라우드, 카카오 i 클라우드, NHN, Openshift 등 폭넓은 플랫폼을 지원합니다.

쿠버네티스 도입을 준비하고 계신다면, 와탭 무료 체험으로 모니터링부터 시작해 보세요.

쿠버네티스 모니터링 무료로 시작하기 →

‍

쿠버네티스 모니터링에 대한 자세한 내용이 궁금하시면, <한 권으로 정리한 쿠버네티스 모니터링 가이드>를 확인해보세요.

쿠버네티스 모니터링 가이드 eBook 무료 보기 →

‍

쿠버네티스 자주 묻는 질문 (FAQ)

1. 쿠버네티스와 도커는 같은 것인가요?

‍아닙니다. 도커는 컨테이너를 만들고 실행하는 도구이고, 쿠버네티스는 그 컨테이너들을 대규모로 관리하고 자동화하는 오케스트레이션 플랫폼입니다. 둘은 경쟁 관계가 아닌 보완 관계로, 주로 개발 단계에서 도커로 이미지를 빌드하고 테스트한 뒤, 운영 환경에서 쿠버네티스로 배포·관리하는 흐름으로 함께 사용됩니다.

2. 쿠버네티스 도커 지원 중단, 도커를 더 이상 쓸 수 없나요?

‍아닙니다. 쿠버네티스가 v1.24에서 제거한 것은 도커 엔진과 CRI 사이의 중간 어댑터인 dockershim입니다. 도커 내부에서도 실제 컨테이너 실행은 containerd가 담당하고 있었기 때문에, dockershim 제거 후에도 containerd를 런타임으로 직접 사용하면 동작은 동일합니다. 개발 환경에서 도커로 이미지를 빌드하고 테스트하는 것은 여전히 가능하며, 도커로 만든 이미지도 OCI 표준을 준수하므로 쿠버네티스에서 정상 실행됩니다. 대체 런타임으로는 containerd와 CRI-O가 있습니다.

3. 쿠버네티스는 소규모 서비스에도 필요한가요?

‍반드시 필요한 것은 아닙니다. 컨테이너 수가 적고 트래픽이 적은 서비스라면 도커 컴포즈나 단순한 배포 방식으로 충분할 수 있습니다. 하지만 성장을 계획하고 있다면 미리 도입을 검토하는 것도 좋은 전략입니다.

4. 쿠버네티스 모니터링은 왜 필요한가요?

‍쿠버네티스는 자동화 기능이 강력하지만, 시스템 상태를 사람이 확인하고 추적할 수 있어야 합니다. 리소스 사용량 추이, 장애 원인 분석, 비용 최적화 모두 모니터링 데이터에서 시작됩니다. 와탭처럼 메트릭스·트레이스·로그를 통합 분석하는 옵저버빌리티 플랫폼이 있으면 운영 효율이 크게 높아집니다.

5. K8s에서 '8'은 무슨 뜻인가요?

‍K8s는 Kubernetes의 약어입니다. 'K'와 's' 사이에 있는 'ubernete' 8글자를 숫자 8로 줄여서 k8s라고 표기합니다. i18n(internationalization), l10n(localization)과 같은 IT 업계의 약어 관행을 따른 것입니다.