| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | |
| 7 | 8 | 9 | 10 | 11 | 12 | 13 |
| 14 | 15 | 16 | 17 | 18 | 19 | 20 |
| 21 | 22 | 23 | 24 | 25 | 26 | 27 |
| 28 | 29 | 30 |
- JWT
- 스프링 부트
- Routing Key
- 쿠버네티스
- CORS
- dockerhub
- @Transactional
- 컨테이너
- JPA
- kafka
- redis
- Dead Letter Queue
- AWS
- @ComponentScan
- docker compose
- DI
- Spring
- Web
- docker
- DLQ
- 지연 로딩
- MSA
- securitycontextholderfilter
- JdbcTemplate
- Spring Data JPA
- 페이징
- Spring Container
- 서블릿 컨테이너
- mybatis
- JPQL
- Today
- Total
look-forest
디플로이먼트(Deployment), 서비스(Service)를 활용해 서버 띄워보기 본문
디플로이먼트(Deployment)란?
파드를 묶음으로 쉽게 관리할 수 있는 기능이다.
실무에서는 보토 서버를 작동시킬 때 파드를 수동 배포하지 않고. 디플로이먼트를 활용한다.
그리고 앞서 파드를 여러개 띄울 때의 한계를 살펴보았듯이, 여러 파드를 띄우거나 관리하는데 디플로이먼트가 유용하다.
디플로이먼트의 장점
- 파드의 수를 지정하는 대로 여러 개의 파드를 쉽게 생성할 수 있음
- 파드가 비정상적으로 종료된 경우, 알아서 새로 파드를 생성해 파드 수를 유지한다.
- 동일한 구성의 여러 파드를 일괄적으로 일시 중지, 삭제, 업데이트 하기 쉽다.
디플로이먼트의 구조

디플로이먼트가 레플리카셋을 관리하고, 레플리카셋이 여러 파드를 관리하는 구조이다.
- 레플리카(Replica): 복제본
- 레플리카셋(ReplicaSet): 복제본끼리의 묶음
[예제] 디플로이먼트를 활용해 springboot 서버 3대 띄워보기
1. 매니페스트 파일 수정하기
apiVersion: apps/v1
kind: Deployment
# Deployment 기본 정보
metadata:
name: spring-deployment # Deployment 이름
# Deployment 세부 정보
spec:
replicas: 3 # 생성할 파드의 복제본 개수
selector:
matchLabels:
app: backend-app # 아래에서 정의한 Pod 중 'app: backend-app'이라는 값을 가진 파드를 선택
# 배포할 Pod 정의
template:
metadata:
labels: # 레이블 (= 카테고리)
app: backend-app
spec:
containers:
- name: spring-container # 컨테이너 이름
image: spring-server # 컨테이너를 생성할 때 사용할 이미지
imagePullPolicy: IfNotPresent # 로컬에서 이미지를 먼저 가져온다. 없으면 레지스트리에서 가져온다.
ports:
- containerPort: 8080 # 컨테이너에서 사용하는 포트를 명시적으로 표현
2. 매니페스트 파일을 기반으로 디플로이먼트 생성하기
$ kubectl apply -f spring-deployment.yaml
3. 디플로이먼트, 레플리카셋, 파드가 잘 생성됐는지 확인
$ kubectl get deployment
$ kubectl get replicaset
$ kubectl get pods

전체 구조

실제 요청을 보낼 때는 각 서버에 균등하게 트래픽이 분배되어야 의미가 있다.
쿠버네티스에서는 서비스(Service)가 여러 파드에 균등하게 요청을 분배해주는 LB의 역할을 한다.
서비스(Service)란?
외부로부터 요청을 받는 역할. 트래픽을 받아 파드에 균드하게 분배해주는 LB 역할.
사실 실제 서비스에서 파드에 요청을 보낼 때, 포트 포워딩이나 파드 내로 직접 접근해서 요청을 보내진 않는다.
서비스를 통해서 요청을 보내는게 일반적이다.
서비스의 구조

[예제] 서비스를 활용해 백엔드 서버와 통신해보기
1. 매니페스트 파일 추가하기
apiVersion: v1
kind: Service
# Service 기본 정보
metadata:
name: spring-service # Service 이름
# Service 세부 정보
spec:
type: NodePort # Service의 종류
selector:
app: backend-app # 실행되고 있는 파드 중 'app: backend-app'이라는 값을 가진 파드와 서비스를 연결
ports:
- protocol: TCP # 서비스에 접속하기 위한 프로토콜
port: 8080 # 쿠버네티스 내부에서 Service에 접속하기 위한 포트 번호
targetPort: 8080 # 매핑하기 위한 파드의 포트 번호
nodePort: 30000 # 외부에서 사용자들이 접근하게 될 포트 번호
- Service의 종류
- NodePort: 쿠버네티스 내부에서 해당 서비스에 접속하기 위한 포트를 열고 외부에서 접속 가능하게 한다.
- ClusterIP: 쿠버네티스 내부에서만 통신할 수 있는 IP를 부여 (외부에서 요청 불가)
- LoadBalancer: 외부의 로드밸런스(ELB 등)를 활용해 외부에서 접속할 수 있도록 연결

2. 매니페스트 파일을 기반으로 서비스 생성하기
$ kubectl apply -f spring-service.yaml
3. 서비스가 잘 생성되는지 확인
$ kubectl get service

디플로이먼트의 장점 활용하기
디플로이먼트를 활용한 서버 개수 조절 방법
1. 매니패스트 파일에서 개수를 수정

2. 변경 사항을 적용
kubectl apply 명령어는 새롭게 오브젝트(디플로이먼트, 파드 등)를 생성할 때도 사용하고, 변경 사항을 적용시킬 때도 사용한다.
$ kubectl apply -f spring-deployment.yaml
서버가 죽었을 때 자동 복구(Self-Healing)
쿠버네티스는 파드 내의 컨테이너가 종료되면 자동으로 컨테이너를 재시작시킨다. 이를 셀프 힐링(Self-Healing)이라고 한다.
실행되고 있는 파드를 kill로 비정상 종료시켜도 파드는 여전히 5개가 동작한다. 다만 restart 개수가 늘어난다.
파드 내 컨테이너가 작동하지 않음을 인식하고 컨테이너를 새로 만들어 서버를 재시작 시킨 것이다.

새로운 버전의 서버로 업데이트 시키기
백엔드에 기능을 추가해서 서버 업데이트할 경우, 쿠버네티스에서는 새로운 버전의 서버를 어떻게 업데이트 시킬까?
1. jar로 이미지를 만드니까 다시 빌드
$ ./gradlew clean build
2. 빌드된 jar를 기반으로 이미지 새로 빌드
$ docker build -t spring-server:1.0 .
3. 매니페스트 파일 수정

4. 매니페스트파일 재적용
$ kubectl apply -f spring-deployment.yaml
정리
쿠버네티스의 핵심 개념

- Pod: 일반적으로 쿠버네티스에서 하나의 프로그램을 실행시키는 단위(쿠버네티스에서 가장 작은 단위)
- Deployment: 파드를 묶음으로 쉽게 괸리할 수 있는 기능
- ReplicaSet: Deployment는 ReplicaSet을 관리하고, ReplicaSet이 Pod 복제본 수를 유지
- Service: 외부로부터 트래픽 수신 및 여러 Pod로 분산(LB역할)
- Service 정의 파일의 `selector` 필드는 특정 레이블을 가진 Pod들을 찾아 트래픽 전달 대상으로 지정
참고 자료 & 이미지 출처
비전공자도 이해할 수 있는 쿠버네티스 입문/실전
'Infra > Kubernetes' 카테고리의 다른 글
| AWS EC2에서 쿠버네티스를 활용해 서버 배포하기 (0) | 2026.02.02 |
|---|---|
| 볼륨(Volume)을 활용해 DB 띄워보기 (0) | 2026.02.01 |
| 컨피그맵(ConfigMap), 시크릿(Secret)을 활용해 환경변수 관리하기 (0) | 2026.01.31 |
| 파드(Pod)를 활용해 서버 띄워보기 (0) | 2026.01.26 |
| 쿠버네티스란? (0) | 2026.01.26 |