[Kubernetes] 리소스 종류

쿠버네티스 리소스 종류

쿠버네티스(Kubernetes)는 클러스터 환경에서 컨테이너화된 워크로드 및 서비스를 간편하고 효율적으로 배포·운영할 수 있도록 하는 컨테이너 오케스트레이션 플랫폼임.

쿠버네티스는 다양한 “리소스(자원) 유형”을 정의하여, 각각의 목적과 기능에 따라 애플리케이션 및 인프라를 구성 및 관리함.

 

리소스 개념

1. Kubernetes Resource

쿠버네티스 API에서 관리되는 모든 “객체(Object)”를 가리킴.

Pod, Service, Deployment, ConfigMap, Secret 등이 대표적임.

 

2. 리소스 스펙(Spec)과 상태(Status)

쿠버네티스 오브젝트마다 “스펙(Spec)” 필드를 통해 원하는 상태(Desired State)를 정의함.

실제 시스템이 인식하는 현재 상태(Current State)는 “상태(Status)” 필드로 확인할 수 있음.

 

3. 상태(State) 조정 메커니즘

쿠버네티스 컨트롤 플레인은 사용자가 정의한 스펙(Spec)에 따라 자동으로 클러스터 상태를 맞춤.

 

워크로드 리소스

1. Pod

쿠버네티스에서 배포할 수 있는 가장 작은 단위이자 기본 실행 단위.

하나 이상의 컨테이너를 묶어 하나의 네트워크 네임스페이스(일반적으로 localhost 공유) 및 스토리지 볼륨 등을 공유함.

동일 Pod 내 컨테이너들은 localhost로 통신 가능(127.0.0.1 공유).

일반적으로 “하나의 주 애플리케이션 컨테이너 + 부수적인 사이드카 컨테이너” 형태를 많이 사용함.

Pod 자체는 불안정(휘발성)한 존재이므로, 보통 직접 Pod를 생성·관리하기보다는 상위 리소스(Deployment 등)를 통해 관리함.

 

2. ReplicaSet

Pod의 개수를 일정하게 유지(Scaling)하도록 관리하는 컨트롤러 리소스임.

스펙에서 지정한 replicas 값만큼 Pod가 항상 유지되도록 함.

하지만, 일반적으로 ReplicaSet을 직접 정의하기보다는 Deployment를 사용함.

Deployment가 내부적으로 ReplicaSet을 생성 및 관리함.

 

3. Deployment

가장 널리 사용되는 워크로드 리소스 컨트롤러임.

선언적 방식으로 애플리케이션(Deployment)이 원하는 상태를 정의하면, Deployment가 내부적으로 ReplicaSet을 생성·관리하여 원하는 수의 Pod가 실행되도록 함.

Rolling Update, Rollback, 파드 수량 확장/축소(Scale) 등의 기능을 제공함.

대부분의 무상태(stateless) 애플리케이션은 Deployment로 관리함.

 

4. StatefulSet

상태를 갖는(stateful) 애플리케이션을 위한 리소스 컨트롤러임.

예를 들면, 데이터베이스, 캐시, 메시지 큐 등.

각 Pod에 고유한 ID(이름, 순번 등)를 부여하며, Pod가 재시작되더라도 동일한 네트워크 정체성(Pod 이름, 호스트네임), 스토리지 볼륨을 이어받음.

순차적 배포(ordered deployment), 순차적 업그레이드 등을 제공함.

 

5. DaemonSet

모든(또는 특정) 노드에서 1개씩 반드시 실행되어야 하는 Pod를 관리함.

예를 들면, 로그 수집 에이전트(Fluentd, Logstash), 모니터링 데몬(Prometheus Node Exporter) 등.

노드가 새로 추가될 때 자동으로 해당 DaemonSet의 Pod가 생성되며, 노드가 제거되면 해당 Pod도 함께 제거됨.

 

6. Job / CronJob

Job: 특정 작업(작업 개수 또는 완료 횟수)을 한 번 실행하고 종료될 때 사용하는 리소스 컨트롤러

예를 들면, 일회성 배치 작업, 데이터 변환 작업

Pod가 정상 종료되면 Job도 완료됨.

 

CronJob: 특정 스케줄(크론 표현식)에 따라 Job을 주기적으로 실행하기 위한 리소스

예를 들면, 매일 자정에 DB 백업 작업 실행

CronJob 스펙에는 스케줄 주기(schedule)와 보관 정책, 동시 실행 정책(Concurrent Policy) 등을 정의할 수 있음.

 

7. HorizontalPodAutoscaler (HPA)

CPU 사용률, 메모리 사용률 등 다양한 메트릭에 따라 자동으로 Pod의 수를 늘리거나 줄이는 오토스케일링(Autoscaling) 리소스임.

일반적으로 Deployment, ReplicaSet, StatefulSet 등에 연결되어 Pod를 동적으로 조정함.

 

서비스 디스커버리와 로드 밸런싱

1. Service

쿠버네티스 내에서 Pod 간의 통신을 위한 고정된 엔드포인트(IP, DNS 이름 등)를 제공하고, 로드 밸런싱을 수행함.

ClusterIP(클러스터 내부 전용), NodePort(노드 IP:Port로 외부 접근), LoadBalancer(클라우드 로드밸런서와 연계) 등 여러 타입이 있음.

Selector를 통해 특정 레이블이 붙은 Pod를 자동으로 연결(Endpoints)함.

 

2. Ingress

HTTP(S) 트래픽을 로드밸런싱하고, 도메인/경로 기반의 라우팅을 지원함.

외부에서 들어오는 요청을 적절한 Service/POD로 라우팅할 수 있음.

Ingress Controller(예: NGINX Ingress Controller, HAProxy, Traefik 등)가 실제 요청 처리를 담당함.

TLS(HTTPS) 설정도 Ingress 리소스에서 지정 가능함(Secret에 TLS 인증서 등록).

 

3.3 Endpoint / EndpointSlice

Service가 내부적으로 대상 Pod들을 추적하여, IP 주소 및 포트 목록을 Endpoints 리소스로 유지함.

Kubernetes 1.17+부터는 EndpointSlice라는 새로운 메커니즘을 도입하여 대규모 클러스터에서 Endpoints의 성능 이슈를 개선함.

일반적으로 사용자가 직접 Endpoints를 수정하는 일은 드물고, Service에 의해 자동 관리됨.

 

스토리지 및 볼륨 리소스

1. PersistentVolume (PV)

클러스터에 할당된 스토리지(물리 디스크, NFS, Ceph, AWS EBS, GCP PD 등)를 추상화하여 나타내는 리소스임.

스토리지 용량, Access Mode(RWO, RWX 등), 스토리지 타입 등을 정의함.

영속적(클러스터 재시작 등에도 데이터 유지)으로 사용하기 위한 구조임.

 

2. PersistentVolumeClaim (PVC)

애플리케이션 측에서 특정 크기, Access Mode 등을 요구하며 “스토리지 할당”을 요청하는 리소스임.

PVC 스펙에 맞는 PV가 자동으로 바인딩(또는 동적 프로비저닝)되어 연결됨.

동적 프로비저닝: StorageClass를 통해 자동으로 PV를 생성해주는 메커니즘(클라우드 환경에서 많이 사용).

 

3. StorageClass

동적 프로비저닝 시 어떤 스토리지 타입(예: AWS EBS, GCE PD, Ceph RBD 등)으로, 어떤 파라미터(예: IOPS, 영역, 리플리카 등)로 PV를 생성할지 정의한 리소스임.

PVC가 StorageClass를 참조하면, 쿠버네티스가 해당 스토리지 프로비저너를 통해 PV를 자동 생성·바인딩함.

 

설정 및 보안 리소스

1. ConfigMap

애플리케이션 동작에 필요한 구성값(환경 변수, 설정 파일, 파라미터 등)들을 키-값 쌍 또는 파일 형태로 저장함.

민감하지 않은 데이터(예: 데이터베이스 호스트주소, 로깅 레벨 등)에 주로 활용함.

Pod 내에서 환경변수로 주입하거나 볼륨으로 마운트하여 사용할 수 있음.

 

2. Secret

비밀번호, API 토큰, SSH 키, TLS 인증서 등 민감 정보 저장을 위한 리소스임.

Base64로 인코딩되어 etcd에 저장되며, RBAC 정책으로 접근을 제어할 수 있음.

Pod에 주입하거나 Secret 타입(Docker config, TLS, etc.)에 따라 이미지 풀용 자격 증명 등으로 활용함.

 

3. ServiceAccount

Pod가 쿠버네티스 API 서버에 접근할 때 사용하는 “ID” 역할을 하는 리소스입니다.

디폴트로 모든 Pod는 “default ServiceAccount”를 사용하지만, 필요에 따라 별도의 ServiceAccount를 만들어 쿠버네티스 API 접근 권한을 달리 부여할 수 있음.

Pod 스펙에서 serviceAccountName을 지정하여 사용할 수 있음.

 

4. RBAC (Role, ClusterRole, RoleBinding, ClusterRoleBinding)

쿠버네티스 오브젝트에 대한 접근을 제어하는 역할 기반 접근 제어(Role-Based Access Control) 리소스.

Role/RoleBinding: 특정 네임스페이스 내 리소스 접근 권한을 정의/바인딩.

ClusterRole/ClusterRoleBinding: 클러스터 전체(모든 네임스페이스)에 대한 접근 권한을 정의/바인딩.

 

5. NetworkPolicy

쿠버네티스 네트워크 트래픽을 제한·허용하는 규칙(레이어 3/4 기반) 리소스임.

Pod 셀렉터, 네임스페이스, IP 블록 등을 기준으로 인그레스·이그레스(입출) 트래픽 정책을 설정할 수 있음.

CNI(Container Network Interface) 플러그인이 NetworkPolicy를 지원해야 적용 가능함.

예를 들면, Calico, Cilium, Weave Net 등

 

6. PodSecurityPolicy (PSP) / Pod Security Admission

PSP는 이전에 사용되던 리소스로, Pod의 보안 세부 설정(권한, Volume 종류, runAsUser 등)을 제한할 수 있었음.

그러나 PSP는 쿠버네티스 1.25에서 제거(deprecated)되었고, 새롭게 Pod Security Admission이 권장됨.

Pod Security Admission은 Namespace 단위로 Pod 보안 레벨(Privileged, Baseline, Restricted)을 적용하는 방식임.

 

클러스터 관리 리소스

1. Namespace

쿠버네티스 오브젝트들을 논리적으로 구분하는 단위임.

다른 네임스페이스와 리소스 이름이 겹쳐도 충돌 없이 운영할 수 있음.

리소스 격리(접근 제어, 자원 할당량 제한) 등을 위해 사용됨.

 

2. Node

쿠버네티스 클러스터를 구성하는 물리 혹은 가상 머신(컴퓨트 리소스).

각 노드는 Kubelet 에이전트가 동작하며, Pod가 스케줄될 수 있음.

kubectl get nodes로 클러스터 내 노드들을 조회 가능.

 

3. ResourceQuota, LimitRange

ResourceQuota: 네임스페이스 단위로 CPU, 메모리, 스토리지 같은 리소스 사용량 또는 오브젝트 개수(Pod, Service 등)에 제한을 두는 리소스.

LimitRange: 네임스페이스 내 Pod/Container에 대한 기본 CPU/메모리 요청량(request)과 제한(limit)을 설정해, 자원 사용을 예측 가능하게 만드는 리소스.

 

4. Event

쿠버네티스 내부에서 발생한 여러 상태 변화, 경고, 에러 등을 추적하기 위한 리소스.

예를 들면, 새로운 Pod가 스케줄링됨, OOMKilled 발생, CrashLoopBackOff 등이 Event로 기록됨.

디버깅 및 모니터링 시 kubectl describe 명령어를 통해 Event 정보를 참조함.

 

커스텀 리소스

쿠버네티스 API를 확장하여, 사용자가 정의한 새로운 리소스 유형을 만들 수 있도록 해주는 메커니즘.

예를 들면, IngressRoute, ServiceMeshPolicy, KafkaCluster 등임.

특정 운영 요구 사항에 따라 별도의 리소스를 정의해서 쿠버네티스 API로 관리 가능.

CRD를 이용하여 Operator(애플리케이션 운영 자동화 로직)를 구현하고, 이 CRD를 통해 복잡한 애플리케이션도 쿠버네티스 방식으로 배포 및 운영할 수 있음.

대부분의 서드파티 쿠버네티스 솔루션(예: Argo CD, Istio, Prometheus Operator 등)이 CRD를 통해 기능을 확장함.

 

리소스별 관계 및 종합적인 사용 예시

1. Deployment + Service + Ingress

무상태 웹 애플리케이션을 Deployment로 관리하고, Service로 내부 로드 밸런싱 및 ClusterIP를 제공.

Ingress를 통해 외부 트래픽(도메인/HTTPS)을 받아서 해당 Service로 라우팅.

 

2. StatefulSet + PersistentVolumeClaim

DB나 메시지 큐 등 Stateful한 애플리케이션의 Pod를 StatefulSet으로 배포하고, 각 Pod별로 PVC를 바인딩하여 영속적인 볼륨을 할당.

 

3. CronJob + Secret

비밀번호가 필요한 배치 스크립트를 CronJob으로 스케줄링하고, DB 자격 증명을 Secret에 저장한 뒤 CronJob의 컨테이너에 환경 변수/마운트로 전달.

 

4. DaemonSet

모든 노드에 로그 수집 에이전트(Fluentd)나 모니터링 에이전트(Prometheus Node Exporter)를 자동 배포.

 

5. HPA(오토스케일링)

CPU, 메모리 사용률에 따라 Deployment 혹은 ReplicaSet의 Pod 수량을 자동 확장하거나 축소.

 

6. RBAC와 NetworkPolicy

내부적으로 민감한 정보나 기능에 접근하는 Pod 혹은 사용자에게 최소 권한 원칙(Least Privilege)을 적용하고, Pod 간 트래픽은 필요한 부분만 허용하도록 제한.

 

정리

쿠버네티스에서 애플리케이션 및 인프라를 구성하기 위해서는 다채로운 리소스들을 이해하고 적절히 활용해야 함.

 

Pod, Deployment, StatefulSet, DaemonSet, Job/CronJob 등의 워크로드 리소스는 애플리케이션 실행을 담당함.

Service, Ingress 등은 네트워크와 트래픽 라우팅을, PV/PVC/StorageClass는 스토리지 영속성을, ConfigMap/Secret은 설정과 보안을, RBAC/NetworkPolicy는 접근 제어를 담당함.

이 외에도 Namespace, ResourceQuota, Event, Custom Resource Definition(CRD) 등을 통해 클러스터 운영을 더욱 정교하게 관리할 수 있음.

 

올바른 리소스 설계와 조합을 통해 쿠버네티스가 제공하는 “선언적 배포(declarative deployment)”와 “상태 조정(reconciliation)” 메커니즘을 최대한 활용하면, 다양한 규모와 복잡도의 애플리케이션을 안정적이고 자동화된 방식으로 운영할 수 있음.