쿠버네티스 리소스 종류 정리

쿠버네티스를 처음 만졌을 때 가장 먼저 막혔던 건 명령어가 아니라 용어였습니다.

Pod, Deployment, Service, ConfigMap, Ingress, PVC, HPA… kubectl get 뒤에 붙일 수 있는 이름이 끝도 없이 나왔습니다. 분명 각각 역할이 있을 텐데, 처음에는 이게 다 무슨 사이인지 감이 잡히지 않았습니다.

한참을 그냥 외우다시피 쓰다가, 결국 한 번은 머릿속을 정리하고 넘어가야겠다 싶었습니다. 그래서 자주 쓰는 리소스를 역할별로 묶어, 나중에 다시 꺼내볼 수 있게 정리해 두기로 했습니다. 이 글은 그 공부 노트입니다.

그 전에, 쿠버네티스에서 “리소스”란 무엇인가

비유하자면 쿠버네티스는 컨테이너를 대신 운영해 주는 관리자입니다.

우리는 이 관리자에게 직접 명령을 내리는 대신, “이런 상태였으면 좋겠다”라고 상태가 담긴 명세서를 건넵니다.

이 명세서 하나하나가 ‘리소스’ 입니다.

# "nginx 컨테이너를 3개 띄워줘" 라는 명세서 한 장
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3

명세서를 제출하면 쿠버네티스는 현재 상태를 계속 그 명세서에 맞추려 노력합니다. 파드가 하나 죽으면 다시 띄우고, 3개로 적어두면 끝까지 3개를 유지하려 합니다. 이걸 선언적(declarative) 운영이라고 부릅니다.

그래서 리소스 종류를 안다는 건, 결국 “관리자에게 건넬 수 있는 명세서가 어떤 종류가 있는가”를 아는 것과 같습니다.

1. 워크로드 — 컨테이너를 실제로 굴리는 것들

가장 핵심입니다. 실제로 컨테이너(애플리케이션)를 띄우는 리소스들입니다.

리소스 설명 비고
Pod 컨테이너를 담는 최소 단위. 보통 직접 만들기보다 아래 리소스들이 만들어 줍니다 != container / k8s 최소 단위지만 ‘컨테이너를 담는’ 단위 입니다.
ReplicaSet Pod를 지정한 개수만큼 유지. 보통 직접 쓰지 않습니다  
Deployment 상태가 없는(stateless) 앱의 표준. 무중단 배포가 핵심  
StatefulSet 데이터를 보존해야 하는 앱(DB 등). 안정적인 이름과 저장소를 보장  
DaemonSet 모든 노드에 하나씩. 로그 수집기, 모니터링 에이전트 등  
Job / CronJob 한 번 실행하고 끝나는 작업 / 주기적으로 도는 작업  

우선 대비되는 두 개념을 이해해보면….

웹 서버처럼 그냥 여러 개 떠 있으면 되는 앱은 Deployment, DB처럼 각자 자기 데이터를 가진 앱은 StatefulSet.

Pod는 모든 워크로드의 알맹이입니다. Deployment를 만들면 그 안에서 ReplicaSet이 만들어지고, 다시 그 안에서 Pod가 만들어지는 구조입니다. 그래서 실무에서는 Pod를 직접 만지기보다 Deployment를 다루는 경우가 훨씬 많습니다.

2. 네트워킹 — 파드를 서로, 그리고 바깥과 연결

파드는 죽었다 살아나면 IP가 바뀝니다. 그래서 파드 IP를 직접 가리키면 금방 깨집니다. 이 문제를 해결하는 게 네트워킹 리소스들입니다.

리소스 한 줄 설명
Service 여러 파드 앞에 고정된 이름과 IP를 붙여주는 입구
Endpoints / EndpointSlice Service 뒤에 실제로 연결된 파드 IP 목록 (보통 자동 관리)
Ingress 바깥 HTTP 요청을 도메인/경로 기준으로 알맞은 Service로 보내는 L7 라우터
Gateway API Ingress의 다음 세대. Gateway, HTTPRoute 등으로 더 유연하게
NetworkPolicy 파드 사이 트래픽을 막거나 허용하는 방화벽

Service는 종류가 몇 가지로 나뉩니다. 처음에는 이 정도만 구분하면 충분합니다.

ClusterIP     : 클러스터 안에서만 접근 (기본값)
NodePort      : 노드의 특정 포트로 바깥에서 접근
LoadBalancer  : 클라우드 로드밸런서를 붙여 바깥에 노출
ExternalName  : 외부 도메인으로 이어주는 별명

비유하면 Service는 건물 안내데스크, Ingress는 정문 경비실입니다. 바깥 손님(요청)이 정문(Ingress)에서 “3층 영업팀이요”라고 말하면, 경비실이 해당 부서 안내데스크(Service)로 보내주는 식입니다.

3. 설정과 저장소 — 앱에 값과 데이터를 주입

컨테이너 이미지에 설정값이나 비밀번호를 박아 넣으면 환경이 바뀔 때마다 이미지를 다시 만들어야 합니다. 이걸 분리해 주는 리소스들입니다.

리소스 한 줄 설명
ConfigMap 평범한 설정값(환경변수, 설정파일 내용)을 담는 곳
Secret 비밀번호, 토큰처럼 민감한 값을 담는 곳
PersistentVolume (PV) 실제 저장 공간 그 자체
PersistentVolumeClaim (PVC) “이만큼의 저장소를 주세요”라는 요청서
StorageClass 저장소를 자동으로 만들어 주는 방식 정의

PV와 PVC의 관계가 처음엔 헷갈립니다.

PVC는 “1Gi짜리 저장소 주세요”라고 적은 신청서이고, PV는 그 신청에 맞춰 실제로 배정된 창고 한 칸입니다.

앱(파드)은 PV를 직접 모릅니다. PVC라는 신청서만 들고 있으면, 쿠버네티스가 알맞은 PV를 찾아 연결해 줍니다. 덕분에 파드가 다른 노드로 옮겨가도 같은 데이터를 계속 쓸 수 있습니다.

4. 클러스터 격리와 권한 — 누가 무엇을 할 수 있는가

여러 팀, 여러 서비스가 한 클러스터를 같이 쓸 때 필요한 리소스들입니다.

리소스 한 줄 설명
Namespace 클러스터를 논리적으로 나누는 칸막이
Node 실제 컨테이너가 도는 서버(머신)
ResourceQuota / LimitRange 네임스페이스가 쓸 수 있는 자원 상한
ServiceAccount 사람이 아니라 파드(앱)에게 부여하는 신분증
Role / ClusterRole “무엇을 할 수 있다”는 권한 묶음
RoleBinding / ClusterRoleBinding 그 권한을 특정 대상에게 실제로 부여

권한 쪽은 두 단계로 나뉩니다. Role이 “이런 일을 할 수 있다”는 권한 정의라면, RoleBinding은 “그 권한을 이 사람(혹은 이 앱)에게 준다”는 연결입니다. 권한을 정의하는 것과 부여하는 것을 분리해 둔 셈입니다.

5. 스케일링과 가용성 — 자동으로 늘리고, 함부로 안 죽게

운영에 들어가면 자주 만나게 되는 리소스들입니다.

리소스 한 줄 설명
HorizontalPodAutoscaler (HPA) 부하에 따라 파드 개수를 자동으로 늘리고 줄임
VerticalPodAutoscaler (VPA) 파드 하나가 쓸 CPU/메모리 요청량을 조절 (별도 설치 필요)
PodDisruptionBudget (PDB) 노드 점검 등으로 파드를 내릴 때 최소 몇 개는 살려두게 보장

HPA가 “바쁘면 일꾼을 더 부른다”라면, PDB는 “점검한다고 일꾼을 한꺼번에 다 빼지는 마라”에 가깝습니다. 둘 다 서비스가 갑자기 끊기지 않게 하는 장치입니다.

6. CRD — 쿠버네티스 자체를 확장하는 리소스

여기까지가 쿠버네티스가 기본으로 제공하는 리소스입니다. 그런데 실제 클러스터를 보면 VirtualService, Cluster, Application 같은 낯선 이름도 보입니다.

이건 CustomResourceDefinition(CRD)으로 추가된 리소스입니다. 쿠버네티스는 “새로운 종류의 명세서를 등록하는 기능”을 열어두었고, 여러 도구가 이 기능을 써서 자기만의 리소스를 만들어 둡니다.

Istio   → VirtualService, Gateway, DestinationRule ...
CNPG    → Cluster (PostgreSQL 운영용)
ArgoCD  → Application (배포 관리용)

그래서 처음 보는 리소스 이름이 나와도 당황할 필요는 없습니다. 대부분 “어떤 도구가 CRD로 추가한 것”이고, 동작 원리는 기본 리소스와 똑같이 명세서를 제출하면 그에 맞춰 동작하는 방식입니다.

네임스페이스 스코프 vs 클러스터 스코프

리소스를 구분하는 또 하나의 중요한 기준이 있습니다. 바로 “네임스페이스에 속하는가”입니다.

  • 네임스페이스 스코프: Pod, Deployment, Service, ConfigMap 등 대부분
  • 클러스터 스코프: Node, PersistentVolume, Namespace, ClusterRole 등 클러스터 전체에 걸친 것들

이 구분은 직접 확인하는 게 가장 빠릅니다.

# 네임스페이스에 속하는 리소스 목록
kubectl api-resources --namespaced=true

# 클러스터 전체에 걸친 리소스 목록
kubectl api-resources --namespaced=false

kubectl api-resources는 지금 이 클러스터가 알고 있는 모든 리소스 종류를 보여줍니다. CRD로 추가된 것까지 전부 나오기 때문에, 새 환경을 처음 만났을 때 한 번 돌려보면 그 클러스터의 구조를 빠르게 그릴 수 있습니다.

마무리

리소스 종류가 많아 보이지만, 결국 묻는 질문은 단순합니다.

컨테이너를 어떻게 띄울까 → 워크로드 어떻게 연결할까 → 네트워킹 설정과 데이터는 어떻게 줄까 → 설정/저장소 누가 무엇을 할 수 있나 → 격리/권한 어떻게 안 죽고 견딜까 → 스케일링/가용성

처음에는 Pod, Deployment, Service, ConfigMap, PVC 다섯 개 정도만 손에 익혀도 대부분의 실습은 굴러갑니다.

헷갈릴 때는 ‘리소스 종류’에 초점을 두고 세팅해보면 좋을 것 같습니다.

This site uses Just the Docs, a documentation theme for Jekyll.