Resource
쿠버네티스 리소스와 선언적 상태 관리
쿠버네티스 공식 문서의 개념을 차례대로 읽어가며 정리한 내용입니다.
이번에는 리소스(Resource)의 개념과 역할, 그리고 Kubernetes가 리소스를 통해 어떻게 클러스터를 관리하는지 알아봅니다.
리소스란 무엇인가
Kubernetes에서 리소스는 클러스터의 원하는 상태를 표현하기 위해 API에 정의된 객체이다.
- 리소스는 선언적 방식으로 정의되며, etcd에 저장된다.
- 리소스 자체는 실행되지 않으며, 단지 상태를 기술할 뿐이다.
Kubernetes에서 리소스Resource란 클러스터의 상태를 표현하기 위해 Kubernetes API에 정의된 객체Object를 의미합니다.
리소스를 이해하는 핵심은 **"리소스는 실행되는 것이 아니라 상태를 기술하는 것"**이라는 점입니다.
예를 들어, Deployment 리소스를 생성한다고 해서 즉시 컨테이너가 실행되는 것이 아닙니다.
대신 "이런 컨테이너가 3개 실행되어야 한다"는 원하는 상태desired state를 선언하는 것입니다.
리소스의 핵심 특징
리소스는 다음과 같은 특징을 가집니다:
-
선언적 정의
YAML또는JSON형태로 작성됩니다- 명령형이 아닌 선언형 방식으로 상태를 기술합니다
-
API 서버를 통한 관리
Kubernetes API Server를 통해 생성·조회·수정·삭제됩니다- 모든 리소스 조작은
RESTful API를 통해 이루어집니다
-
영구 저장
etcd에 저장되는 선언적 데이터입니다- 클러스터의 단일 진실 공급원Single Source of Truth 역할을 합니다
-
수동적 특성
- 스스로 실행되거나 동작하지 않습니다
- 컨트롤러가 리소스를 읽고 해석하여 실제 동작을 수행합니다
-
상태 지향
- "현재 상태"가 아니라 "원하는 상태desired state"를 기술합니다
Kubernetes는 현재 상태를 원하는 상태로 수렴시키는 방식으로 동작합니다
즉, 리소스는 **"클러스터가 이렇게 되었으면 한다"**라는 요구사항을 구조화된 데이터로 표현한 것입니다.
리소스의 역할
리소스는 Kubernetes 시스템에서 다음과 같은 중요한 역할을 수행합니다.
1. 사용자와 Kubernetes 사이의 유일한 인터페이스
Kubernetes와 상호작용하는 모든 방법은 결국 리소스를 통해 이루어집니다.
kubectl명령어도 내부적으로 리소스를 생성/수정합니다Helm차트도 결국 리소스의 템플릿입니다- CI/CD 파이프라인도 리소스를 배포합니다
2. 시스템 동작의 기준이 되는 단일 진실의 원천
단일 진실의 원천Single Source of Truth: 시스템의 모든 데이터가 하나의 출처에서 관리되는 원칙
etcd에 저장된 리소스는 클러스터의 유일한 진실입니다:
- 컨트롤러는 리소스를 읽고 그에 따라 동작합니다
- 충돌이 발생하면
etcd의 리소스가 항상 우선합니다 - 노드가 재시작되어도 리소스는 유지됩니다
3. 자동화와 복구의 기준이 되는 상태 정의서
Kubernetes의 자가 치유self-healing 능력은 리소스 덕분에 가능합니다:
Pod가 죽으면Deployment리소스를 보고 다시 생성합니다- 노드가 장애나면 다른 노드에
Pod를 재배치합니다 - 리소스에 정의된 상태와 현재 상태를 지속적으로 비교하고 조정합니다
중요:
Kubernetes는 리소스를 기준으로 동작하며, 리소스가 없다면Kubernetes는 아무것도 하지 않습니다.
이것이 바로 Kubernetes가 선언적 시스템인 이유입니다. 사용자는 "어떻게 할지"가 아니라 "무엇이 되어야 하는지"만 선언하면 됩니다.
리소스의 개념적 카테고리
Kubernetes리소스는 공식적인 계층 구조를 강제하지 않지만, 기능에 따라 개념적으로 분류할 수 있다.
Kubernetes는 리소스를 엄격한 계층으로 분류하지 않습니다. 하지만 실무에서 리소스를 이해하고 관리하기 위해서는 개념적 분류가 유용합니다.
대부분의 Kubernetes UI 도구(Lens, K9s, Rancher 등)에서 보이는 리소스 분류는 이러한 개념적 카테고리를 시각화한 것입니다.
워크로드 리소스 (Workload Resources)
워크로드 리소스는 애플리케이션의 실행 방식을 정의한다.
워크로드 리소스는 클러스터에서 실제로 실행되는 애플리케이션을 관리합니다.
이들은 다음을 정의합니다:
- 무엇을 실행할 것인가 (컨테이너 이미지)
- 몇 개를 실행할 것인가 (레플리카 수)
- 어떻게 재시작할 것인가 (재시작 정책)
- 어디서 실행할 것인가 (노드 선택)
주요 워크로드 리소스:
| 리소스 | 용도 | 특징 |
|---|---|---|
Pod | 가장 작은 배포 단위 | 하나 이상의 컨테이너 그룹 |
Deployment | 무상태 애플리케이션 | 롤링 업데이트, 롤백 지원 |
StatefulSet | 상태 유지 애플리케이션 | 안정적인 네트워크 ID, 순서 보장 |
DaemonSet | 노드당 하나의 Pod | 로깅, 모니터링 에이전트에 적합 |
Job | 일회성 작업 | 완료되면 종료 |
CronJob | 주기적 작업 | cron 형식의 스케줄 |
예시:
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 3 # 3개의 Pod 실행
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
네트워크 리소스 (Network Resources)
네트워크 리소스는 Pod 간, 그리고 외부와의 통신 방식을 정의한다.
Kubernetes에서 네트워킹은 복잡한 주제이지만, 네트워크 리소스를 통해 선언적으로 관리할 수 있습니다.
이들은 다음을 정의합니다:
- 내부 통신: Pod 간 통신 방식
- 외부 노출: 클러스터 외부로 서비스 노출
- 트래픽 라우팅: 요청을 어떻게 분산할 것인가
- 보안 정책: 어떤 통신을 허용/차단할 것인가
주요 네트워크 리소스:
| 리소스 | 용도 | 특징 |
|---|---|---|
Service | Pod 그룹에 대한 안정적인 엔드포인트 | ClusterIP, NodePort, LoadBalancer 타입 |
Ingress | HTTP/HTTPS 라우팅 | 도메인 기반 라우팅, TLS 종료 |
NetworkPolicy | Pod 간 통신 제어 | 방화벽 규칙과 유사 |
EndpointSlice | Service의 네트워크 엔드포인트 | 대규모 클러스터 성능 개선 |
스토리지 리소스 (Storage Resources)
스토리지 리소스는 데이터의 영속성을 보장한다.
컨테이너는 기본적으로 임시적ephemeral입니다. Pod가 재시작되면 데이터가 사라집니다.
스토리지 리소스는 이 문제를 해결합니다.
이들은 다음을 정의합니다:
- 어떤 스토리지가 필요한지 (용량, 성능)
- 어떤 방식으로 연결되는지 (ReadWriteOnce, ReadWriteMany)
- 어떻게 프로비저닝되는지 (정적, 동적)
주요 스토리지 리소스:
| 리소스 | 용도 | 특징 |
|---|---|---|
PersistentVolume (PV) | 실제 스토리지 리소스 | 클러스터 수준 리소스 |
PersistentVolumeClaim (PVC) | 스토리지 요청 | 네임스페이스 수준 리소스 |
StorageClass | 동적 프로비저닝 정책 | 스토리지 타입 정의 |
VolumeSnapshot | 볼륨 스냅샷 | 백업 및 복제에 사용 |
스토리지 라이프사이클:
설정 리소스 (Configuration Resources)
설정 리소스는 애플리케이션 코드와 설정을 분리한다.
12-Factor App의 원칙 중 하나는 "설정을 환경에 저장하라"입니다.
Kubernetes는 이를 리소스로 구현합니다.
이들은 다음을 관리합니다:
- 환경 설정: 데이터베이스 URL, 기능 플래그 등
- 민감 정보: 비밀번호, API 키, 인증서 등
주요 설정 리소스:
| 리소스 | 용도 | 특징 |
|---|---|---|
ConfigMap | 일반 설정 데이터 | 평문으로 저장 |
Secret | 민감한 데이터 | Base64 인코딩 (암호화 아님!) |
주의:
Secret은 기본적으로 암호화되지 않고 Base64로만 인코딩됩니다.
프로덕션 환경에서는 etcd 암호화 또는 외부 시크릿 관리 도구(Vault, Sealed Secrets 등)를 사용해야 합니다.
예시:
# ConfigMap
apiVersion: v1
kind: ConfigMap
metadata:
name: app-config
data:
database_url: "postgres://db:5432/myapp"
log_level: "info"
---
# Secret
apiVersion: v1
kind: Secret
metadata:
name: app-secret
type: Opaque
data:
password: cGFzc3dvcmQxMjM= # base64 encoded
클러스터 구조 리소스 (Cluster-Level Resources)
클러스터 구조 리소스는 클러스터의 범위와 경계를 정의한다.
이들은 클러스터의 물리적 또는 논리적 구조를 나타냅니다.
주요 클러스터 구조 리소스:
| 리소스 | 용도 | 범위 |
|---|---|---|
Namespace | 논리적 격리 | 리소스 그룹화, 접근 제어 |
Node | 물리적/가상 머신 | 실제 컴퓨팅 리소스 |
ResourceQuota | 리소스 사용량 제한 | 네임스페이스별 할당량 |
LimitRange | 리소스 범위 제한 | Pod/Container별 제한 |
Namespace의 역할:
- 멀티 테넌시: 여러 팀이 같은 클러스터 사용
- 환경 분리: dev, staging, production
- 리소스 격리: 네트워크 정책, 할당량 적용
확장 리소스 (Extension Resources)
확장 리소스는 Kubernetes 자체를 확장할 수 있게 한다.
Kubernetes의 가장 강력한 기능 중 하나는 확장성입니다.
사용자가 직접 새로운 리소스 타입을 정의할 수 있습니다.
주요 확장 리소스:
| 리소스 | 용도 | 특징 |
|---|---|---|
CustomResourceDefinition (CRD) | 새로운 리소스 타입 정의 | API 확장 |
Custom Resource (CR) | CRD의 인스턴스 | 도메인 특화 객체 |
실제 사용 예:
- Prometheus Operator:
ServiceMonitor,PrometheusRule등의 CRD 제공 - Cert-Manager:
Certificate,Issuer등의 CRD로 인증서 자동 관리 - Istio:
VirtualService,DestinationRule등으로 서비스 메시 구성
# CRD 정의 예시
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
name: databases.example.com
spec:
group: example.com
names:
kind: Database
plural: databases
scope: Namespaced
versions:
- name: v1
served: true
storage: true
---
# Custom Resource 사용 예시
apiVersion: example.com/v1
kind: Database
metadata:
name: my-database
spec:
type: postgresql
version: "14"
storage: 100Gi
CRD를 사용하면 Kubernetes를 플랫폼의 플랫폼으로 만들 수 있습니다.
도메인 특화 개념을 Kubernetes 네이티브 방식으로 관리할 수 있게 됩니다.
리소스 구조 시각화
전체 리소스 카테고리를 한눈에 볼 수 있도록 시각화하면 다음과 같습니다:
리소스의 생명주기
리소스가 어떻게 생성되고 관리되는지 이해하는 것도 중요합니다:
이 다이어그램에서 볼 수 있듯이:
- 사용자는 리소스만 정의합니다
- API 서버는 리소스를 저장합니다
- 컨트롤러들이 리소스를 감시하고 실제 동작을 수행합니다
정리
Kubernetes 리소스에 대해 알아본 내용을 정리하면:
-
리소스는 상태 정의 객체입니다
- 실행되는 것이 아니라 원하는 상태를 선언합니다
- 컨트롤러가 리소스를 읽고 실제 동작을 수행합니다
-
모든
Kubernetes동작은 리소스를 기준으로 이루어집니다- 리소스가 없으면
Kubernetes는 아무것도 하지 않습니다 etcd에 저장된 리소스가 단일 진실의 원천Single Source of Truth입니다
- 리소스가 없으면
-
리소스는 기능에 따라 분류할 수 있습니다
- 워크로드, 네트워크, 스토리지, 설정, 클러스터 구조, 확장 리소스
- 이는 공식 분류가 아닌 개념적 분류입니다
-
리소스를 통해
Kubernetes를 확장할 수 있습니다- CRD를 사용하여 새로운 리소스 타입을 정의할 수 있습니다
- 도메인 특화 개념을
Kubernetes네이티브 방식으로 관리할 수 있습니다