Yaml in Kubernets
apiVersion:
kind:
metadata:
spec
| Kind | Version |
| Pod | v1 |
| Service | v1 |
| ReplicSet | apps/v1 |
| Deployment | apps/v1 |
Pod yaml 구조
apiVersion: v1
kind: Pod
metadata:
name: myapp-pod
labels:
app: myapp
spec:
containers:
- name: nginx-container
image: nginx
Pod 관련 명령어
# Pod 목록 보기
kubectl get pods
kubectl get pods -o wide
# Pod 상세 보기
kubectl describe pod <pod-name>
# Pod YAML 초안 만들기
kubectl run <pod-name> --image=<image-name> --dry-run=client -o yaml > filename.yaml
# YAML로 Pod 생성
kubectl create -f filename.yaml
# YAML 수정 후 반영
vim filename.yaml
kubectl apply -f filename.yaml
# Pod 삭제
kubectl delete pod <pod-name>
# 로그 확인
kubectl logs <pod-name>
# Pod 내부 접속
kubectl exec -it <pod-name> -- /bin/sh
Replication Controller / ReplicaSet
1. 컨트롤러란?
컨트롤러는 Kubernetes에서 객체 상태를 계속 감시하고, 원하는 상태가 유지되도록 조치하는 구성요소이다.
즉, Kubernetes는 그냥 한 번 생성하고 끝나는 것이 아니라,
계속 상태를 확인하면서 부족하거나 문제가 생기면 자동으로 맞춰주는 방식으로 동작한다.
2. 왜 여러 Pod가 필요한가?
예를 들어 애플리케이션이 Pod 1개에서만 실행 중이라고 가정
이 경우 그 Pod가 죽으면:
- 애플리케이션이 중단되고
- 사용자는 접속할 수 없게 됨
그래서 같은 애플리케이션 Pod를 여러 개 유지하면:
- 하나가 실패해도
- 나머지 Pod가 계속 서비스할 수 있음
3. Replication Controller / ReplicaSet 의 역할
“지정한 개수만큼 Pod가 항상 실행되도록 유지한다.”
예를 들어 replicas를 3으로 설정하면:
- 정상일 때는 Pod 3개 유지
- 1개가 죽으면 새로 만들어서 다시 3개 유지
즉, Pod 개수를 자동으로 맞춰주는 관리자
Pod 가 1개여도 의미가 있다.
Pod 하나가 죽으면 새 Pod를 자동으로 다시 만들어주기 때문 -> 단일 Pod의 자동 복구 목적으로도 사용 가능
4. 차이점
Replication Controller
- 예전 방식
- 오래된 기술
apiVersion: v1
kind: ReplicationController
metadata:
name: myapp-rc
labels:
app: myapp
type: frontend
spec:
replicas: 3
template:
metadata:
name: myapp-pod
labels:
app: myapp
spec:
containers:
- name: nginx
image: nginx
selector를 생략 가능
- replicas : 몇 개의 Pod를 유지할 것인가?
- template: Replica 가 새 Pod를 만들어야 할 때 사용할 Pod 설계도
- Pod 템플릿을 이용해 나중에 Pod가 죽으면 새 Pod를 생성함
ReplicaSet
- 더 최신 방식
- 현재 권장 방식
즉, 지금은 ReplicaSet을 사용하는 것이 일반적
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: myapp-rs
labels:
app: myapp
type: frontend
spec:
replicas: 3
selector:
matchLabels:
app: myapp
template:
metadata:
labels:
app: myapp
spec:
containers:
- name: nginx
image: nginx
selector 가 필수
- selector: 어떤 Pod 들을 내가 관리 대상으로 볼 것인가?
- label = Pod에 붙인 표식 (옷에 있는 라벨이랑 똑같음)
- selector = 그 표식을 보고 대상을 고르는 조건
- Pod에 라벨링을 하고, selector 에서 해당 라벨을 보고 내가 원하는 것만 다시 재생성하는 구조
ReplicaSet = apps/v1 + selector 필수
Deployment
실제 운영 환경에서는 애플리케이션을 Pod 1개만 띄워서 끝내는 경우가 거의 없음.
예를 들어 웹 서버를 운영한다고 하면:
- 인스턴스가 여러 개 있어야 함
- 새 버전이 나오면 서비스 중단 없이 업데이트하고 싶음
- 업데이트하다가 문제 생기면 이전 버전으로 되돌리고 싶음
- 여러 변경 사항을 한 번에 반영하고 싶음
-> 이런 운영상의 요구를 해결하는 객체가 Deployment
기능
1. 여러 인스턴스 운영
웹 서버를 실제 서비스에 배포할 때는 보통 여러 개의 인스턴스를 실행해야 함.
그래야 부하 분산도 되고, 일부 인스턴스에 문제가 생겨도 서비스가 계속 가능함.
2) Rolling Update
새 버전 이미지가 나오면 기존 인스턴스를 새 버전으로 바꿔야 함.
그런데 모든 인스턴스를 한 번에 바꾸면 서비스 영향이 클 수 있음.
그래서 보통은:
- 하나 업데이트
- 정상 확인
- 다음 것 업데이트
이런 식으로 순차적으로 교체함
3) Rollback
업데이트 후 문제가 생길 수 있음.
이 경우 최근 변경을 취소하고 이전 상태로 되돌릴 수 있어야 함.
4) Pause / Resume
운영 중에는 한 번에 여러 가지를 바꾸고 싶을 수 있음.
- 이미지 버전 변경
- replicas 변경
- 리소스 설정 변경
이걸 하나씩 즉시 반영하는 대신,
- 잠시 배포를 멈추고
- 필요한 변경을 모아서 적용한 다음
- 다시 배포를 진행
하는 방식이 필요함.
Pod, ReplicaSet, Deployment 관계
| Pod | ReplicaSet | Deployment |
| 애플리케이션 하나의 실행 단위 컨테이너는 Pod 안에서 실행 |
같은 Pod 를 여러 개 유지하는 역할을 함 원하는 개수의 Pod 가 계속 유지하도록 관리 |
ReplicaSet 보다 한 단계 위에 있는 상위 객체 ReplciaSet을 관리하면서 운영에 필요한 기능까지 제공함 |
Deployment
│
│ (관리 / 업데이트 전략)
▼
ReplicaSet
│
│ (Pod 개수 유지)
▼
┌───────┬───────┬───────┬───────┐
│ Pod │ Pod │ Pod │ Pod │
└───────┴───────┴───────┴───────┘
Deployment → ReplicaSet → Pod
Deployment 가 하는 일
- 여러 Pod를 유지하게 함
- 새 버전으로 무중단 업데이트 가능하게 함
- 문제 생기면 롤백 가능하게 함
- 변경을 pause/resume 하며 제어 가능하게 함
즉 ReplicaSet이 “Pod 개수 유지”에 초점이 있다면,
Deployment는 그 위에서 배포 전략까지 관리하는 객체
Deployment Yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp-deployment
labels:
app: myapp
spec:
replicas: 3
selector:
matchLabels:
app: myapp
template:
metadata:
labels:
app: myapp
spec:
containers:
- name: nginx
image: nginx
ReplicaSet YAML과 거의 같고,
kind만 Deployment로 바꾸면 됨.
Deployment 생성 후
Deployment가 ReplicaSet을 만들고, ReplicaSet이 Pod를 만드는 구조
- Deployment 생성
- ReplicaSet 자동 생성
- Deployment가 ReplicaSet을 자동으로 만듦.
- 확인 명령: kubectl get rs
- Pod 생성
- ReplicaSet이 실제 Pod들을 생성함.
- 확인 명령: kubectl get pods
하나의 Deployment를 만들었더니
그 아래에 ReplicaSet이 생기고, 그 아래에 Pod들이 생긴다.
Deployment는 ReplcaSet보다 상위객체이므로
ReplicaSet을 직접 쓰기보다는 운영에서는 Deployment을 더 많이 사용함
!! 실습 명령어 정리
NGINX Pod 생성
kubectl run nginx --image=nginx
Pod YAML Manifest 생성 (실제 생성하지 않음)
kubectl run nginx --image=nginx --dry-run=client -o yaml
옵션 설명
- -o yaml → YAML 형식으로 출력
- --dry-run=client → 실제로 리소스를 생성하지 않음
Deployment 생성
kubectl create deployment --image=nginx nginx
Deployment YAML 파일 생성 (실제 생성하지 않음)
kubectl create deployment --image=nginx nginx --dry-run=client -o yaml
Deployment YAML 생성 후 파일로 저장
kubectl create deployment --image=nginx nginx --dry-run=client -o yaml > nginx-deployment.yaml
YAML 파일 수정 후 Deployment 생성
예를 들어 replicas 수를 추가로 수정한 뒤
kubectl create -f nginx-deployment.yaml
Kubernetes 1.19 이상에서 replicas 옵션 사용
Kubernetes 1.19 이상에서는 --replicas 옵션을 직접 사용할 수 있음.
예: replicas 4개 Deployment 생성 YAML 만들기
kubectl create deployment --image=nginx nginx --replicas=4 --dry-run=client -o yaml > nginx-deployment.yaml
'Infra > K8S' 카테고리의 다른 글
| [CKA 준비] Scheduling (0) | 2026.04.11 |
|---|---|
| [CKA 준비] Core Concepts - 3 (0) | 2026.03.15 |
| [CKA 준비] Core Conecepts - 1 (4) | 2026.03.04 |
| KEDA 필요성, HPA 와의 차이점 (0) | 2026.01.18 |