
이전 글 : 2025.10.14 - [클라우드] - [쿠버네티스] (1/3) Cloud Native와 Kubernetes란?
이전 글에서는 Cloud Native의 개념과 쿠버네티스의 전체적인 아키텍처(Control Plane, Worker Node)에 대해 정리했다.
이번 글에서는 실제 쿠버네티스를 사용할 때 가장 자주 마주치는 주요 오브젝트(Object)들을 정리해보고자 한다.
1. 쿠버네티스 오브젝트(Object)란?
쿠버네티스에서 오브젝트(Object)란 클러스터의 상태를 나타내는 영속적인 개체로, "어떤 컨테이너화된 애플리케이션이 실행되고 있는지", "어떤 노드에서 실행되는지", "어떤 정책이 적용되는지" 등을 정의한다.
오브젝트는 YAML 파일 형태로 정의하며, kubectl apply 명령어로 클러스터에 적용한다. 쿠버네티스는 사용자가 정의한 Desired State(원하는 상태)를 유지하려 지속적으로 동작한다.
쿠버네티스의 모든 오브젝트는 apiVersion, kind, metadata, spec 이렇게 4가지 필드를 기본으로 가진다.
# 기본 오브젝트 구조 예시
apiVersion: v1
kind: Pod # 오브젝트 종류
metadata:
name: my-pod # 오브젝트 이름
labels:
app: my-app
spec: # 원하는 상태 정의
containers:
- name: my-container
image: nginx:latest
2. Pod
Pod는 쿠버네티스에서 배포할 수 있는 가장 작은 단위다. 하나 이상의 컨테이너로 구성되며, 같은 Pod 안의 컨테이너들은 네트워크(IP)와 스토리지를 공유한다.
- Pod의 특징
- Pod는 기본적으로 일회성(ephemeral)이다. 삭제되면 데이터는 사라진다.
- 각 Pod는 클러스터 내에서 고유한 IP 주소를 부여받는다.
- 보통 Pod를 직접 생성하기보다는 Deployment 같은 상위 오브젝트를 통해 관리한다.
# Pod 생성 예시
apiVersion: v1
kind: Pod
metadata:
name: nginx-pod
spec:
containers:
- name: nginx
image: nginx:1.25
ports:
- containerPort: 80
3. Deployment
Deployment는 Pod를 선언적으로 관리해주는 오브젝트다. "이 애플리케이션의 Pod를 3개 유지해라"처럼 원하는 상태를 정의하면, 쿠버네티스가 알아서 Pod를 생성하고 장애가 발생하면 자동으로 복구해준다.
- Deployment가 하는 일
- ReplicaSet을 통해 Pod 개수를 자동으로 유지
- Rolling Update: 무중단으로 새 버전 배포
- Rollback: 이전 버전으로 손쉽게 되돌리기
Deployment → ReplicaSet → Pod 의 계층 구조로 동작하며, 사용자는 Deployment만 관리하면 된다.
* ReplicaSet은 지정된 수의 Pod 복제본이 항상 실행되도록 보장하는 오브젝트로, 보통 Deployment를 통해 간접적으로 사용한다.
# Deployment 생성 예시
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 3 # Pod 3개 유지
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.25
4. Service
Pod는 재시작될 때마다 IP가 바뀐다. 그렇다면 외부에서 어떻게 Pod에 안정적으로 접근할 수 있을까? 이 문제를 해결하는 것이 바로 Service다. Service는 고정된 IP(ClusterIP)와 DNS 이름을 제공하여 Pod에 안정적으로 접근할 수 있게 해준다. 또한 내부적으로 로드밸런싱 역할도 수행한다.
📌 Service의 종류
| 타입 | 설명 | 사용 예시 |
ClusterIP |
클러스터 내부에서만 접근 가능한 기본 타입 | 내부 서비스 간 통신 |
NodePort |
각 노드의 특정 포트를 외부에 노출 | 테스트, 간단한 외부 접근 |
LoadBalancer |
클라우드 제공자의 로드밸런서를 외부에 노출 | AWS, GCP 등 클라우드 환경 |
ExternalName |
외부 DNS 이름을 클러스터 내부에 매핑 | 외부 서비스 연동 |
# ClusterIP Service 예시
apiVersion: v1
kind: Service
metadata:
name: nginx-service
spec:
selector:
app: nginx # 이 레이블을 가진 Pod에 연결
ports:
- protocol: TCP
port: 80
targetPort: 80
type: ClusterIP
5. ConfigMap & Secret
애플리케이션이 동작할 때 환경마다 다른 설정값(DB 주소, API URL 등)이 필요하다. 이 설정값들을 컨테이너 이미지 안에 넣지 않고 분리해서 관리하는 방법이 ConfigMap과 Secret이다.
- ConfigMap
일반적인 설정 데이터를 Key-Value 형태로 저장한다. 환경변수나 파일 형태로 Pod에 주입할 수 있다.
- Secret
비밀번호, API 키, 토큰 등 민감한 정보를 저장한다. ConfigMap과 달리 Base64 인코딩으로 저장된다.
(완전한 암호화는 아니므로 운영 환경에서는 별도 암호화 솔루션 적용을 권장)
# ConfigMap 생성 예시
apiVersion: v1
kind: ConfigMap
metadata:
name: app-config
data:
DB_HOST: "mysql-service"
DB_PORT: "3306"
APP_ENV: "production"
6. Namespace
Namespace는 하나의 클러스터 안에서 리소스를 논리적으로 격리하는 단위다. 예를 들어 개발 환경(dev), 스테이징 환경(staging), 운영 환경(prod)을 같은 클러스터 안에서 분리해서 관리할 수 있다.
- 기본적으로
default,kube-system,kube-public등의 Namespace가 존재한다. - Namespace 간에는 기본적으로 네트워크 통신이 허용되지만, NetworkPolicy로 제한할 수 있다.
- 리소스 사용량(CPU, 메모리)을 Namespace 단위로 제한(ResourceQuota)할 수 있다.
# Namespace 생성
apiVersion: v1
kind: Namespace
metadata:
name: dev
# 특정 Namespace에 리소스 배포
kubectl apply -f deployment.yaml -n dev
7. 주요 오브젝트 한눈에 보기
지금까지 살펴본 주요 오브젝트들을 한 번에 정리하면 아래와 같다.
| 오브젝트 | 역할 | 특징 |
| Pod | 컨테이너 실행 최소 단위 | 일회성, 고유 IP |
| Deployment | Pod 선언적 관리 | 롤링 업데이트, 롤백, 자동 복구 |
| Service | Pod 네트워크 접근점 | 고정 IP/DNS, 로드밸런싱 |
| ConfigMap | 설정 데이터 분리 관리 | 환경변수, 파일로 주입 |
| Secret | 민감 정보 저장 | Base64 인코딩 |
| Namespace | 리소스 논리적 격리 | 환경 분리, 권한 관리 |
📌 이번 글 정리
- 쿠버네티스 오브젝트는 YAML로 정의하고,
kubectl apply로 적용한다. - Pod는 최소 배포 단위, Deployment는 Pod를 선언적으로 관리한다.
- Service는 Pod에 대한 안정적인 접근과 로드밸런싱을 담당한다.
- ConfigMap / Secret으로 설정값과 민감 정보를 이미지와 분리한다.
- Namespace로 클러스터 내 환경을 논리적으로 분리할 수 있다.
다음 글에서는 실제로 로컬 환경에서 쿠버네티스를 실습하는 내용으로 이어가겠다.
'클라우드' 카테고리의 다른 글
| [쿠버네티스] (3/3) minikube로 로컬 쿠버네티스 실습 (0) | 2026.04.17 |
|---|---|
| [쿠버네티스] (1/3) Cloud Native와 Kubernetes란? (0) | 2025.10.14 |
| [Docker] Docker 2. 이미지 생성 (2) | 2025.04.08 |
| [Docker] Docker 1. 개념과 용어 (0) | 2025.03.04 |