[Infra] Kubernetes 기초

고수가 되고 싶은 감자·6일 전

Infra cloud devops k8s kubernetes 인프라

Kubernetes 기초 개념과 핵심 리소스 총정리

도커를 접하게 되며 생각했다.

"도커로 컨테이너 띄우는 거 엄청 편한데, 굳이 왜 쿠버네티스(k8s)까지 배워서 써야 하지?"

하지만 서비스 규모가 커져서 컨테이너가 10개, 50개, 100개로 늘어나고 서버가 여러 대로 쪼개지는 순간 현실적인 지옥이 시작된다.

어느 서버에 여유 공간(CPU/메모리)이 있는지 일일이 확인해서 띄워야 하고,
새벽에 특정 서버의 컨테이너가 죽으면 자다 깨서 수동으로 재기동해야 하며,
트래픽이 몰릴 때마다 수동으로 컨테이너를 늘리고 로드밸런서에 붙여줘야 한다.

이 모든 반복적이고 귀찮은 운영 작업을 "자동화된 시스템"에 맡기기 위해 탄생한 것이 바로 쿠버네티스(Kubernetes)다.

쿠버네티스의 기본 아키텍처와 실무에서 다루는 핵심 리소스들을 정리해 본다.

1. 클러스터 아키텍처: 두뇌와 일꾼

쿠버네티스는 여러 대의 물리/가상 서버를 묶어 마치 "하나의 거대한 컴퓨터"처럼 동작하게 만든다.

컨트롤 플레인: 클러스터의 관리자이자 두뇌. 직접 앱을 실행하지 않고, 명령을 받고 워커 노드들을 감시하고 스케줄링한다. (AWS EKS를 쓰면 이 부분을 AWS가 돈 받고 완전 관리해 준다.)
워커 노드: 실제 컨테이너들이 배포되어 사용자 트래픽을 처리하는 일꾼 서버. (AWS EC2 인스턴스)

2. 쿠버네티스의 핵심 : "선언적 상태"

쿠버네티스를 이해하는 가장 중요한 핵심은 "선언적"이라는 말이다.

명령형 (과거 방식): "지금 당장 컨테이너 1개 더 띄워라."
선언형 (쿠버네티스 방식): "내가 원하는 상태는 웹 서버 파드가 항상 3개 유지되는 것이다."

YAML 파일로 "원하는 상태"를 선언해 두면, 쿠버네티스는 24시간 루프를 돌며 "현재 상태"가 "원하는 상태"와 일치하는지 감시한다.

서버가 다운되거나 컨테이너가 에러로 꺼져서 파드가 2개로 줄어들면, 관리자가 개입하지 않아도 쿠버네티스가 즉시 빈 서버를 찾아 새 파드를 띄워 3개로 맞춘다. 이것이 바로 셀프 힐링이다.

3. 실무 쿠버네티스 핵심 리소스 맵 (5대 분류)

쿠버네티스는 모든 대상을 리소스라는 단위로 다룬다. 자주 사용하는 리소스들은 목적에 따라 크게 5가지로 나뉜다.

[쿠버네티스 리소스 생태계]
  ├── 1. 워크로드 (Workload)      : 컨테이너를 어떤 형태로 띄울 건지?
  ├── 2. 설정 & 보안 (Config)      : 환경변수와 비밀번호 분리
  ├── 3. 스토리지 (Storage)        : 영구 데이터 보존
  ├── 4. 네트워크 (Network)        : 내부 통신 및 외부 노출
  └── 5. 운영 & 격리 (Governance)  : 구획 분리 및 권한

① 워크로드 (Workload)

리소스	설명	주요 사용처
Pod	쿠버네티스의 가장 작은 배포 단위. 1개 이상의 컨테이너를 감싼 캡슐.	직접 띄우기보다는 상위 리소스에 의해 관리됨
Deployment	파드의 수량 유지와 무중단 롤링 업데이트를 보장하는 관리자.	일반적인 백엔드 API, 프론트엔드 웹 서버 (Stateless)
StatefulSet	파드의 고유 이름(순번)과 고유 디스크를 영구 보장하는 관리자.	DB(MySQL, PostgreSQL), Kafka, Redis (Stateful)
DaemonSet	"모든 노드에 무조건 1개씩 띄워라!"	Fluent Bit(로그 수집), Prometheus Node Exporter
Job / CronJob	계속 켜두는 게 아니라 "한 번 실행되고 끝나면 종료"되는 작업.	DB 마이그레이션, 일일 정산 배치 스크립트

② 설정 및 보안 (Config & Secret)

도커 이미지 안에 DB 비밀번호나 설정값을 하드코딩하지 않고 외부에 주입하기 위해 사용한다.

ConfigMap: 일반 텍스트 설정값을 저장하는 상자 (포트 번호, 프로필 dev/prd, 로그 레벨 등)
Secret: Base64로 인코딩된 민감한 값을 저장하는 상자 (DB 접속 비밀번호, JWT 시크릿 키, 인증서 등)

③ 스토리지 (Storage)

파드는 기본적으로 일회성이라 파드가 죽으면 내부 파일이 모두 증발한다. 데이터를 영구 저장하려면 외부 스토리지를 붙여야 한다.

PV (Persistent Volume): 실제 연결할 물리/클라우드 디스크 (e.g. AWS EBS 100GB 볼륨)
PVC (Persistent Volume Claim): 개발자가 파드에 디스크를 달기 위해 제출하는 "스토리지 신청서" ("나 20GB SSD 볼륨 줘")
StorageClass: 개발자가 PVC를 제출했을 때, 백그라운드에서 클라우드(AWS EBS 등)에 가서 디스크를 동적으로 자동 생성해 주는 공장

④ 네트워크 (Network)

Service: 파드는 죽었다 살아나면 IP가 매번 바뀐다. 서비스는 파드들 앞단에 고정 가상 IP(단일 진입점)를 제공하고 로드밸런싱을 수행한다. (ClusterIP, NodePort, LoadBalancer)
Ingress: 클러스터 외부(인터넷)에서 들어오는 HTTP/HTTPS 트래픽을 도메인이나 URL 경로에 따라 적절한 서비스로 연결해 주는 L7 관문.
NetworkPolicy: 쿠버네티스 내부 방화벽. 특정 파드 간의 트래픽만 허용하고 나머지는 차단.

⑤ 운영 및 격리 (Governance)

Namespace: 거대한 클러스터를 논리적인 '가상의 방'으로 나누는 단위 (dev, prod, monitoring, kube-system)
HPA (Horizontal Pod Autoscaler): CPU나 메모리 부하에 따라 파드 개수를 자동으로 늘리고 줄이는 오토스케일러.
RBAC (Role, RoleBinding, ServiceAccount): 누가 어떤 리소스에 접근할 수 있는지 제어하는 권한 체계.

4. 확장 리소스: CRD (Custom Resource Definition)

쿠버네티스의 진정한 강력함은 확장성에 있다.

기본 제공되는 Deployment나 Service 외에도, 개발자가 새로운 리소스 문법을 직접 정의해서 클러스터에 추가할 수 있는데 이를 CRD라고 부른다.

실무에서 자주 쓰는 KEDA의 ScaledObject나 Karpenter의 NodePool, Cert-Manager의 Certificate 등이 모두 이 CRD를 통해 쿠버네티스 생태계에 플러그인처럼 붙여서 사용하는 확장 리소스들이다.

5. 마치며

정리하자면:

쿠버네티스는 수많은 컨테이너의 배치, 확장, 장애 복구를 사람 대신 24시간 수행해 주는 컨테이너 오케스트레이션 시스템이다.
시스템은 두뇌(Control Plane)와 일꾼(Worker Node)으로 나뉘며, EKS는 두뇌 영역을 완전 관리형으로 제공한다.
명령이 아니라 원하는 상태(Desired State)를 선언하면 시스템이 스스로 상태를 맞추는 선언적 방식으로 동작한다.
실무에서는 워크로드(Deployment/StatefulSet), 설정(ConfigMap/Secret), 스토리지(PVC), 네트워크(Service/Ingress) 리소스를 조합하여 완전한 애플리케이션 플랫폼을 구축한다.

이상.