쿠버네티스(Kubernetes)가 대체 뭔데? with Docker

백엔드 개발을 하다보면 반드시 만나게 되는 도커, 쿠버네티스

지금까지는 개발에 집중하다가 이제는 서버 지식이 상당히 필요해져서 정리해본다.

도커도 잘 모르지만 쿠버네티스는 더더욱 모르기에 정리해보려고한다.

---

Kubernetes(K8s)란?

https://kubernetes.io/

Production-Grade Container Orchestration

컨테이너화 된 애플리케이션의 배포, 확장, 관리를 자동화 하는 오픈소스 시스템

 

컨테이너

애플리케이션을 실행하는 데 필요한 모든 요소(소스 코드, 라이브러리, 실행환경 등)를 하나의 독립된 패키지(컨테이너)로 구성한 것

 

가상머신과 컨테이너

가상머신(VM): 별도의 OS를 각각 가상화하여 동작

 - 무겁고 자원 소모가 큼, 부팅 속도가 느림

컨테이너(Container): 호스트 OS 커널을 공유하여 애플리케이션과 필요한 라이브러리만 격리된 환경에서 실행

 - 가볍고 빠름, 자원 사용 효율성 높음, 부팅 속도 빠름

 

* 앱을 기준으로 생각하였을 때, 가상머신은 하나의 가상 머신에 여러 개의 앱이 올라 갈 수 있지만, 컨테이너는 가상머신보다 베어메탈 하드웨어를 더 효율적으로 사용하여 앱 하나당 하나의 환경을 개별 배포가 가능하다.

➡️ 컨테이너 기술의 발달로 인해 환경차이에 따른 오류를 최소화 하고 배포와 관리가 매우 간단해짐

 

쿠버네티스를 사용하는 이유(= 도커와의 차이점)

컨테이너의 대표적인 도커 기술이 있는데, 왜 도커와 별개로 쿠버네티스를 사용하는 지에 대한 의문이 들었다.

	Docker	K8s
정의	컨테이너 이미지 생성·배포·실행을 담당하는 컨테이너 런타임 플랫폼	여러 호스트에 분산된 컨테이너를 자동으로 배치·관리·스케일링하는 오케스트레이션 플랫폼
주요 역할	애플리케이션을 “컨테이너” 단위로 패키징하고 실행	컨테이너(또는 Pod)를 클러스터 수준에서 스케줄링·로드밸런싱·자동 복구
운영 범위	단일 호스트(서버)	다중 호스트(클러스터)
스케일링 방식	수동 (docker run/docker-compose)	자동 (HPA, Cluster Autoscaler)
상태 관리	없음 (컨테이너 상태 확인 후 직접 재시작)	Self‑healing (비정상 컨테이너 자동 교체)
로드 밸런싱	별도 설정 필요	내장 (Service → ClusterIP/LoadBalancer)
업데이트 전략	수동 롤링 업데이트	롤링 업데이트·롤백 자동 지원
학습 난이도	낮음	중간~높음
사용 사례	개발·테스트 환경, 소규모 서비스	프로덕션급 마이크로서비스, 복잡한 분산 애플리케이션

 

 

결론적으로,

 

도커는 애플리케이션을 패키징, 배포, 실행하는 플랫폼이다. 애플리케이션을 전체 환경으로 패키징 하여 이미지(image)를 도커 중앙저장소(Docker Hub)로 전송할 수 있다. 이 이미지는 사용자들이 다운받아서 실행하면 이미지에 저장된 환경으로 실행 할 수 있다.

 

쿠버네티스는 시스템에 배포 가능한 애플리케이션 구성 요소가 많아지면서 컨테이너를 쉽게 배포하고 관리할 수 있게 해주는 소프트웨어 시스템이다. 도커 기반 컨테이너를 관리할 수 있고, rkt 기반 컨테이너도 관리 할 수 있다. 도커 기반 컨테이너를 관리한다는 것은 도커 런타임을 사용한다는 것이다. 따라서, 정리하면 쿠버네티스는 도커를 '이용한다'고 볼 수 있다.

클러스터에 노드가 몇 개가 있든 쿠버네티스에서 애플리케이션을 배포하는 것은 항상 동일하게 사용 할 수 있다.

 

쿠버네티스 용어 정리

용어	설명	주요 역할/특징
Cluster 클러스터	여러 대의 노드(서버)를 하나로 묶어 컨테이너를 실행·관리하는 단위	컨테이너 오케스트레이션 단위
Node 노드	컨테이너를 실제로 실행하는 워커 머신(VM 또는 물리서버)	kubelet·kube‑proxy 실행
Pod 파드	하나 이상의 컨테이너를 그룹화한 최소 배포 단위	동일 IP·스토리지 공유
Namespace 네임스페이스	클러스터 내 리소스 격리·조직화	리소스 이름 충돌 방지
Deployment	ReplicaSet 관리, 롤링 업데이트·롤백 제공	선언적 앱 배포 관리
ReplicaSet	지정한 수의 Pod 복제본 유지	고가용성 보장
StatefulSet	상태 저장 워크로드용, 순서·고유 ID 보장	데이터베이스 등
DaemonSet	모든(또는 특정) 노드에 Pod 배포	로그 수집·모니터링 에이전트
Service	Pod 집합에 안정적 네트워크 접근 제공	로드밸런싱·서비스 검색
Ingress	외부 트래픽 → 클러스터 내부 서비스 라우팅	HTTP(S) 라우팅·TLS 종료
ConfigMap	비밀이 아닌 설정 데이터 저장	환경변수·파일 마운트
Secret	암호·토큰 등 민감 정보 저장	환경변수·볼륨으로 주입
Volume	Pod 내 컨테이너 간 공유 스토리지	임시 또는 영구 스토리지
PersistentVolume (PV)	클러스터 수준에서 프로비저닝된 영구 스토리지	스토리지 추상화
PersistentVolumeClaim (PVC)	PV 요청 및 바인딩	동적 프로비저닝 지원
kubelet	각 노드에서 Pod 상태 관리·보고	컨테이너 라이프사이클 실행

 

자주 사용하는 용어들

Cluster 클러스터

- 여러 대의 노드(서버)를 하나의 논리적 단위로 묶어 컨테이너 애플리케이션을 실행·관리하는 쿠버네티스의 기본 단위

    - 마스터노드: 전체 쿠버네티스 시스템을 제어하고 관리하는 쿠버네티스 컨트롤 플레인 실행

    - 워커 노드: 실제 배포되는 컨테이너 애플리케이션을 실행

- 클러스터는 상태를 유지하고 제어하지만 애플리케이션을 실행하지는 않음

 

Node 노드

- 컨테이너화된 애플리케이션을 실행하는 시스템, 도커, rkt 같은 컨테이너 런타임을 수행

- API 서버와 통신하고 노드의 컨테이너를 관리하는 Kubelet

- 애플리케이션 구성 요소 간에 네트워크 트래픽을 로드밸런싱하는 쿠버네티스 서비스 프록시(kube-porxy)

 

Pod 파드
- 쿠버네티스에서 가장 작은 배포 단위로, 하나 이상의 컨테이너를 그룹화하여 동일한 IP 주소와 스토리지 공유

 

Namespace 네임스페이스
- 하나의 클러스터를 여러 개의 가상 공간으로 분리해 리소스를 격리하고 조직화하는 기능

- 같은 이름의 리소스 충돌을 방지하고, ResourceQuota를 통해 네임스페이스별 리소스 사용 한도를 설정하며, RBAC을 이용해 접근 권한 세분화

	클러스터	네임스페이스
범위	물리/가상 서버 전체(노드 집합)	클러스터 내부의 논리적 구획
역할	컨테이너 실행 환경 제공·관리	리소스 격리·조직화
생성 단위	쿠버네티스 설치 시 단 하나(혹은 HA 구성)	필요에 따라 여러 개 생성 가능
사용 사례	전체 인프라 관리, 스케일링, 장애 복구	멀티테넌시, 환경 분리, 리소스 제한 설정

 

 

쿠버네티스의 용어들을 도식화 하면 이런 느낌이다. 사용자는 컨트롤 플레인으로 환경을 전체 제어를 하고, 각각의 워커 노드가 실행 환경을 가지고 있다.

 

쿠버네티스의 장점

모든 서버에 쿠버네티스가 설치되어 있으면 더 이상 운영팀은 배포에 신경을 쓸 이유가 없다. 실행에 필요한 모든 정보는 쿠버네티스가 가지고 있다. 컨테이너화된 애플리케이션을 대규모로 안정적이고 효율적으로 운영 할 수 있다.

 

자동 오케스트레이션

• Pod 스케줄링→가용한 노드에 자동 배치
• 롤링 업데이트·롤백 지원으로 무중단 배포
• 장애가 발생한 Pod 자동 재시작(Self‑healing)

수평적 확장(Horizontal Scaling)

• CPU·메모리 사용량에 따라 자동으로 복제본 수 조절(HPA)
• 클러스터 자동 확장/축소(Cluster Autoscaler)

리소스 최적화(Bin‑packing)

• 여러 컨테이너를 노드 자원 한계 내에서 효율적으로 배치해 인프라 비용 절감

선언적(Declarative) 관리

• YAML 매니페스트로 원하는 상태를 정의하면 쿠버네티스가 자동으로 유지

멀티클라우드·하이브리드 지원

• 벤더 락인 없이 AWS·GCP·온프레미스 등 어디서나 동일하게 운영 가능

강력한 생태계와 확장성

• Helm, Operators, CSI/CNI 플러그인 등 수백 개의 오픈소스 도구와 통합

마이크로서비스 아키텍처 최적화

• 서비스 디스커버리, 로드밸런싱, 네트워크 정책 등을 내장

 

이러한 장점들을 바탕으로 쿠버네티스를 사용하는데, 현재 겪었던 프로젝트 기반으로는 단순한 서버의 경우에는 도커 정도만 사용했었다. 그러나 많은 서버들을 동시에 운영하려면 쿠버네티스는 사실상 표준이지 않나 싶다.

 

 

 

 

참고 자료

- AWS: Kubernetes vs Docker 비교 (https://aws.amazon.com/ko/compare/the-difference-between-kubernetes-and-docker/)

- https://www.plural.sh/blog/kubernetes-terminology/

- 쿠버네티스 인 액션