infra

로컬 쿠버네티스 실습: Deployment와 Service로 웹 애플리케이션 배포하기

mirabo01 2026. 2. 13. 09:55

로컬 쿠버네티스 실습 ① 간단한 웹 애플리케이션 배포 흐름 따라가기

minikube나 kind로 로컬 클러스터를 준비했다면,
이제는 직접 하나 올려보는 단계가 가장 중요하다.

이 글에서는 복잡한 예제 대신,

  • 컨테이너 하나
  • Deployment 하나
  • Service 하나

이 세 가지만으로
쿠버네티스에서 애플리케이션이 어떻게 배포되고 노출되는지를 처음부터 끝까지 따라가본다.
실무에서 가장 자주 반복하는 기본 흐름이기도 하다.

실습 목표와 전제

이번 글의 목표는 다음이다.

  • Deployment로 애플리케이션 배포
  • Pod 생성과 관리 방식 확인
  • Service를 통한 접근 구조 이해

전제 조건은 다음 정도면 충분하다.

  • 로컬 쿠버네티스 클러스터(minikube 또는 kind)
  • kubectl 사용 가능
  • Docker 이미지 하나

1. 예제 애플리케이션 준비

예제는 최대한 단순하게 간다.
HTTP 요청을 받으면 문자열을 반환하는 웹 서버 정도면 충분하다.

중요한 건 애플리케이션 자체가 아니라 배포 흐름이다.

실무에서도 처음 구조를 확인할 때는
항상 이런 단순한 서비스로 시작하는 편이 낫다.

2. Deployment 정의하기

쿠버네티스에서는 Pod를 직접 띄우지 않고
Deployment를 통해 관리한다.

Deployment는 다음을 한 번에 정의한다.

  • 어떤 이미지로 실행할지
  • Pod를 몇 개 유지할지
  • 업데이트 전략은 어떻게 할지

핵심 포인트

  • 처음에는 replicas를 1로 시작해도 된다
  • 설정이 바뀌면 Pod는 교체된다
  • Pod 이름은 고정되지 않는다

이 단계에서 중요한 건
Pod를 직접 컨트롤하지 않는다는 점이다.

3. Pod 상태 확인하며 흐름 이해하기

Deployment를 적용하면
쿠버네티스 내부에서는 이런 일이 순서대로 일어난다.

  1. Deployment 생성
  2. ReplicaSet 생성
  3. Pod 생성
  4. Node에 스케줄링
kubectl get deployment
kubectl get replicaset
kubectl get pod

실제로 이 명령들을 순서대로 쳐보면,
쿠버네티스 리소스 간의 관계가 눈에 들어오기 시작한다.

“아, Deployment가 직접 Pod를 만드는 게 아니구나”
이 감각을 잡는 게 중요하다.

4. Service로 Pod에 접근하기

Pod는 직접 접근 대상이 아니다.
IP도 바뀌고, 언제든 사라질 수 있다.

그래서 항상 Service를 앞에 둔다.

로컬 실습에서는 보통 다음 중 하나를 쓴다.

  • ClusterIP + 포트 포워딩
  • NodePort

이번 단계의 목적은
“Service가 Pod 앞의 고정 진입점”이라는 개념을 이해하는 것이다.

5. 실제 요청 보내보기

Service까지 준비되면
이제 실제로 요청을 보내본다.

curl http://<service-address>

이 한 번의 요청으로 다음을 확인할 수 있다.

  • Pod가 정상 실행 중인지
  • Service가 Pod로 트래픽을 전달하는지
  • 컨테이너 로그가 잘 찍히는지
kubectl logs <pod-name>

로그를 함께 보면
“요청 → Service → Pod → 컨테이너” 흐름이 연결된다.

6. Pod를 일부러 지워보자

여기서 꼭 한 번 해봐야 할 실습이 있다.

kubectl delete pod <pod-name>

잠시 후 다시 확인해보면,

kubectl get pod
  • 새로운 Pod가 자동으로 생성된다
  • 이름이 바뀐다
  • 하지만 서비스는 계속 살아 있다

이 경험이
쿠버네티스의 핵심 철학을 가장 직관적으로 보여준다.

Pod는 사라져도,
“원하는 상태”는 유지된다.

7. replicas를 늘려보며 변화 확인하기

Deployment의 replicas를 2나 3으로 늘려보면,

  • Pod 개수가 즉시 늘어난다
  • Service 뒤에 Pod가 여러 개 생긴다
  • 요청이 분산되는 구조가 된다

이 단계까지 오면
쿠버네티스의 기본적인 운영 흐름은 한 번 체험한 셈이다.

실제로 해보면 느끼는 포인트

이 실습을 직접 해보면
대부분 다음 지점에서 이해가 깊어진다.

  • Pod는 정말로 쉽게 바뀐다
  • Service 없이는 운영이 어렵다
  • Deployment가 관리의 중심이다

문서로 읽을 때보다
훨씬 구조가 단순하게 느껴질 가능성이 크다.

정리하며

이번 글에서는
가장 단순한 예제를 통해 쿠버네티스 배포 흐름 전체를 따라가봤다.

  • Deployment로 애플리케이션 관리
  • Pod는 교체 가능한 실행 단위
  • Service는 안정적인 접근 지점

다음 글에서는
이 예제를 조금 확장해서,

  • ConfigMap으로 설정 분리
  • requests/limits 적용
  • 롤링 업데이트 과정 확인

즉, “운영에 가까운 형태”로 한 단계 더 발전시키는 흐름를 정리해볼 예정이다.