Kubernetes 객체 이해 (Pod / Deployment / Service)

1. 문제 / 필요성

앞선 글에서 Kubernetes는 상태를 유지하는 시스템이며 Controller가 Desired State와 Current State를 계속 맞춘다고 정리했다.

그렇다면 다음 질문이 자연스럽게 나온다.

이 “상태”는 어떤 단위로 정의되는가

• Pod을 직접 관리하면 되는가
• 왜 Deployment를 사용하는가
• Service는 왜 필요한가

이 글에서는 Kubernetes 객체를 단순 기능이 아니라 구조 안에서 어떤 역할을 하는지 기준으로 정리한다.

---

2. Kubernetes 객체를 보는 기준

Kubernetes 객체는 각각 기능이 아니라 역할이 분리된 구조다.

이 기준으로 보면 다음과 같이 나뉜다.

• Pod → 실행 결과
• Deployment → 상태 정의
• Service → 연결 유지

“무엇을 실행하느냐”가 아니라 “어떤 역할을 담당하느냐”

---

3. Pod: 실행 단위지만 관리 대상은 아님

3.1 Pod란

Pod은 Kubernetes에서 컨테이너를 실행하는 가장 작은 단위다.

하지만 단순히 “컨테이너 묶음”이 아니라 실행 환경 단위에 가깝다.

[출처]: https://www.fairwinds.com/blog/getting-started-with-kubernetes-architecture-basics-definitions

Pod 내부에서는 다음이 공유된다.

• 네트워크 (IP, Port)
  • 하나의 Pod은 하나의 IP를 가짐
  • Pod 내부 컨테이너들은 localhost로 서로 통신
• 스토리지 (Volume)
  • 여러 컨테이너가 동일한 Volume 공유 가능
• 생명주기
  • 함께 생성되고 함께 종료됨

3.2 Pod의 동작 방식

Pod은 생성되면 다음 과정을 따른다.

1. API Server에 Pod 정의 저장
2. Scheduler가 Node 선택
3. Kubelet이 PodSpec 수신
4. Container Runtime이 컨테이너 실행

Pod은 “한 번 생성된 이후 상태를 스스로 유지하지 않는다”

3.3 Pod의 한계

① Pod은 “일회성 객체”

Pod은 생성되면 끝이다.

• 특정 Node에 스케줄링됨
• 해당 Node에 종속됨
• Node가 죽으면 Pod도 사라짐

Pod 자체에는 “재생성” 개념이 없음

② 상태 유지 기능 없음

Pod은 다음을 할 수 없다.

• 개수 유지 불가능
• 장애 복구 불가능
• 자동 재시작 불가능
  • Pod 3개 실행 → 1개 죽음 → 2개로 유지됨 (자동 복구 없음)

③ Controller 없이 유지 불가

Kubernetes에서 상태 유지는 항상 Controller가 담당한다.

하지만 Pod 단독으로 생성하면:

• 어떤 Controller도 붙지 않음
• Desired State 자체가 없음

④ 변경이 불가능한 구조

Pod은 생성 이후 변경이 제한적이다.

• 이미지 변경 → 불가
• 설정 변경 → 불가
• 재배포 필요

“수정”이 아니라 “재생성” 구조

3.4 왜 Pod을 직접 쓰지 않는가

Pod을 직접 생성하면 다음 문제가 발생한다.

• 컨테이너가 죽으면 끝
• 개수 유지 불가능
• 수동 관리 필요

Kubernetes 구조와 맞지 않는다

---

4. Deployment: 상태를 정의하는 객체

4.1 Deployment란

Deployment는 Pod을 직접 실행하는 것이 아니라 “어떤 상태를 유지할지 정의하는 객체”다.

예:

• Pod 3개 유지
• 특정 이미지 버전 사용

4.2 왜 Deployment가 필요한가

Pod에서 본 문제를 다시 보면

• Pod은 한 번 실행되면 끝
• 장애 복구 불가능
• 개수 유지 불가능
• Node 장애 시 사라짐

“ 이 문제를 해결하려면 필요한 게 하나다.  Desired State를 정의할 수 있는 구조”

Deployment가 바로 그 역할을 한다.

4.3 Deployment 내부 구조

Deployment는 내부적으로 다음 구조로 동작한다.

[출처]: https://yankeexe.medium.com/how-rolling-and-rollback-deployments-work-in-kubernetes-8db4c4dce599

 

① Deployment

• 상태 정의 (Desired State)
• 업데이트 전략 관리

② ReplicaSet

• Pod 개수 유지
• Controller 역할 수행

③ Pod

• 실제 실행

4.4 실제 동작 흐름

Deployment를 생성하면 내부적으로 다음 일이 일어난다.

1. Deployment 생성 (Desired State 정의)
2. ReplicaSet 생성
3. ReplicaSet이 Pod 생성
4. Controller가 상태 비교
5. 부족하면 Pod 추가 생성

예시

• Desired: Pod 3개
• Current: Pod 2개

→ ReplicaSet이 1개 추가 생성

Deployment는 직접 실행하지 않고, ReplicaSet을 통해 상태를 유지한다

4.5 상태 유지 구조 (Controller 연결)

Deployment는 Controller와 함께 동작한다.

Controller는 다음을 반복한다.

• 현재 상태 확인
• 원하는 상태 확인
• 차이 계산
• 수정

상황 예시

상황 1: Pod 삭제

kubectl delete pod my-pod

 

결과:

• Pod 삭제
• ReplicaSet 감지
• 새로운 Pod 생성

상황 2: Node 장애

• Node 다운
• Pod 사라짐
• 다른 Node에서 재생성

상황 3: 개수 유지

• 3개 → 2개
  → 다시 3개 생성

공통점:

상태가 유지됨

4.6 롤링 업데이트

Deployment는 단순 유지뿐 아니라 업데이트 전략도 포함한다

동작 방식

1. 새로운 Pod 생성
2. 기존 Pod 점진적 제거
3. 서비스 유지 상태로 교체

특징

• 무중단 배포 가능
• 이전 버전 유지 가능
• 롤백 가능

4.7 역할

Deployment는 다음을 담당한다.

• Pod 개수 유지
• 자동 복구
• 롤링 업데이트
• 버전 관리

“Pod을 실행하는 것이 아니라 상태를 유지한다”

4.8 왜 Deployment를 기준으로 관리하는가

Controller는 항상 Desired State 기준으로 동작한다.

• Deployment가 기준 상태 제공
• Controller가 상태 유지

실제 관리 단위는 Pod가 아니라 Deployment

---

5. Service: 연결을 유지하는 객체

5.1 문제 / 필요성

Deployment를 통해 Pod은 자동으로 유지된다. 하지만 여기서 새로운 문제가 발생한다.

Pod은 다음과 같은 특징을 가진다.

• 생성과 삭제가 반복됨
• 실행되는 Node가 계속 바뀜
• IP가 매번 새로 할당됨

Pod은 “안정적인 연결 대상이 될 수 없다”

실제 문제 상황

상황 1: Pod 재생성

• Pod A (IP: 10.0.0.1)
  → 장애 발생 → 삭제 → 새로운 Pod B 생성 (IP: 10.0.0.5)

기존 IP로는 더 이상 접근 불가능

상황 2: 스케일 아웃

• Pod 1개 → 3개로 증가

어느 Pod으로 요청을 보내야 하는지 알 수 없음

“Pod는 계속 변하기 때문에 직접 연결하면 깨진다”

5.2 Service란

Service는 Pod 앞에 위치한 고정된 네트워크 진입점이다.

• 고정된 IP 제공
• Pod 집합을 하나의 대상으로 묶음
• 요청을 적절한 Pod으로 전달

Service는 “변하는 Pod을 숨기고, 고정된 방식으로 접근하게 만든다”

5.3 구조

Client → Service → Pod

• Client는 Service만 바라봄
• 실제 Pod은 계속 바뀜

5.4 로드밸런싱 방식

Service는 여러 Pod 중 하나로 요청을 전달한다.

예:

• Pod 3개 존재
  → 요청 들어오면 하나 선택

방식:

• Round Robin (기본)
• Node 내부 규칙 기반 분산

여러 Pod가 있어도 하나의 서비스처럼 동작

5.5 Service가 해결하는 문제

Service는 다음 문제를 해결한다.

① Pod IP 변경 문제

• Pod이 바뀌어도 Service는 유지
• Client는 영향 없음

② 다중 Pod 연결

• 여러 Pod을 하나로 묶음
• 트래픽 분산

③ 서비스 안정성

• Pod 교체 중에도 연결 유지
• Deployment와 함께 동작

“실행은 계속 바뀌지만, 연결은 고정된다”

---

6. 전체 구조 정리

객체	역할	특징
Pod	실행 단위	상태 유지 불가능
Deployment	상태 정의	Controller와 함께 상태 유지
Service	연결 유지	Pod 변경을 숨김

이 구조는 하나로 정리된다.

정의 → 유지 → 실행 → 연결

---

7. 핵심 정리

• Pod은 실행 결과일 뿐 관리 대상이 아님
• Deployment가 상태를 정의하고 유지
• Service가 실행 결과를 안정적으로 연결

 Kubernetes는 “객체를 역할별로 분리해서 상태를 유지하는 구조”

---

8. 회고

Kubernetes를 처음 접하면 Pod 중심으로 이해하기 쉽다.
하지만 실제로 중요한 것은 Pod이 아니라 Pod을 어떻게 관리하는 구조인가다.

이 글에서는

• Pod → 실행
• Deployment → 상태
• Service → 연결

로 나누어 구조 기준으로 정리했다.

이 관점을 기준으로 보면

• 왜 Deployment를 써야 하는지
• 왜 Service가 필요한지
• 왜 Pod을 직접 관리하지 않는지

가 자연스럽게 이해된다.