📌 [Deployment 심화편 #2] Deployment의 동작 원리와 트러블슈팅

 

1️⃣ 개요

 

쿠버네티스에서 Deployment는 Pod의 개수를 유지하고, 애플리케이션을 무중단 배포할 수 있도록 지원하는 핵심 리소스입니다.

하지만 실무에서는 Deployment가 예상과 다르게 동작하는 경우가 발생할 수 있습니다.

 

예를 들어,

• 새로운 버전 배포 시 Pod가 갱신되지 않는 문제

• 롤백이 정상적으로 수행되지 않는 문제

• Deployment가 관리하는 ReplicaSet이 예상보다 많거나 적은 문제

 

이번 글에서는 Deployment의 동작 원리를 이해하고, 실무에서 자주 발생하는 문제와 해결 방법을 정리하겠습니다. 🚀

 

---

2️⃣ Deployment의 동작 원리

 

✅ 1. Deployment의 기본 구성 요소

 

Deployment는 Pod를 직접 관리하는 것이 아니라, ReplicaSet을 통해 Pod를 생성하고 유지합니다.

 

📌 Deployment의 주요 동작 과정

 

1️⃣ 사용자가 Deployment를 생성하면 ReplicaSet이 자동으로 생성됨

2️⃣ ReplicaSet이 Deployment에서 설정한 개수만큼 Pod를 생성하고 유지

3️⃣ 새로운 버전으로 업데이트할 경우 새로운 ReplicaSet을 생성하여 기존 ReplicaSet을 점진적으로 교체

 

📌 Deployment → ReplicaSet → Pod 구조

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
        - name: my-container
          image: nginx

✅ Deployment는 내부적으로 ReplicaSet을 생성하여 Pod 개수를 관리합니다.

 

---

3️⃣ Deployment 관련 주요 문제와 해결 방법

 

📌 Deployment 문제 해결 가이드

 

문제 유형	증상	원인	해결 방법
Pod이 업데이트되지 않음	kubectl apply를 실행했지만 새로운 버전이 반영되지 않음	- Pod의 이미지 태그가 latest로 설정됨- imagePullPolicy: IfNotPresent로 인해 캐시된 이미지 사용	- kubectl set image 명령어로 강제 업데이트- imagePullPolicy: Always 설정
롤백이 정상적으로 수행되지 않음	kubectl rollout undo를 실행했지만 이전 버전으로 돌아가지 않음	- 이전 ReplicaSet이 삭제됨- Deployment 전략이 RollingUpdate로 설정됨	- kubectl rollout history로 이전 버전 확인- Deployment 전략을 Recreate로 변경 후 재배포
Pod이 계속 재시작됨	kubectl get pods 실행 시 CrashLoopBackOff 상태	- 애플리케이션 내부 오류- Liveness Probe 설정 오류	- kubectl logs로 로그 확인- Liveness Probe 조건 수정
Deployment가 관리하는 ReplicaSet이 많거나 적음	kubectl get rs 실행 시 예상보다 많은/적은 ReplicaSet 존재	- Deployment 업데이트 시 새로운 ReplicaSet이 계속 생성됨- 오래된 ReplicaSet이 자동으로 삭제되지 않음	- kubectl rollout history로 버전 확인 후 정리- revisionHistoryLimit 값을 설정하여 오래된 ReplicaSet 자동 삭제

✅ Deployment가 예상과 다르게 동작하는 경우, kubectl describe deployment 및 kubectl get rs를 활용하여 상태를 확인해야 합니다.

 

---

4️⃣ Deployment가 예상과 다르게 업데이트되지 않을 때 해결 방법

 

Deployment를 업데이트했지만 Pod가 새로운 버전으로 갱신되지 않는 경우, 주로 이미지 캐싱 문제일 가능성이 높습니다.

 

📌 1. 강제로 Deployment 업데이트 (이미지 캐싱 문제 해결)

kubectl set image deployment my-deployment my-container=nginx:1.24

✅ 이 명령어를 실행하면 새로운 ReplicaSet이 생성되고, 기존 Pod가 점진적으로 교체됩니다.

 

📌 2. imagePullPolicy: Always 설정하여 항상 최신 이미지 사용

containers:
  - name: my-container
    image: nginx:latest
    imagePullPolicy: Always

✅ 이 설정을 적용하면 항상 새로운 이미지를 다운로드하여 업데이트됩니다.

 

---

5️⃣ Deployment 롤백이 정상적으로 수행되지 않을 때 해결 방법

 

Deployment를 업데이트했지만 롤백이 정상적으로 수행되지 않는 경우, 이전 ReplicaSet이 삭제되었거나, Deployment 전략이 RollingUpdate로 설정되었을 가능성이 높습니다.

 

📌 1. 현재 배포된 Deployment의 버전 확인

kubectl rollout history deployment my-deployment

 

📌 2. 이전 버전으로 롤백 실행

kubectl rollout undo deployment my-deployment

 

📌 3. 특정 버전으로 롤백 실행

kubectl rollout undo deployment my-deployment --to-revision=2

✅ Deployment의 revisionHistoryLimit 값을 조정하면 오래된 ReplicaSet이 유지되어 롤백이 용이합니다.

 

📌 4. revisionHistoryLimit 설정 (오래된 ReplicaSet 유지)

spec:
  revisionHistoryLimit: 5  # 최근 5개의 Deployment 기록 유지

✅ 이 설정을 적용하면 최신 5개의 버전 기록이 유지되며, 롤백이 쉬워집니다.

 

---

6️⃣ Deployment가 관리하는 ReplicaSet이 많거나 적을 때 해결 방법

 

Deployment를 업데이트할 때, 이전 버전의 ReplicaSet이 계속 남아 있는 경우가 있습니다.

이는 Deployment의 revisionHistoryLimit 값을 설정하여 해결할 수 있습니다.

 

📌 1. 현재 ReplicaSet 목록 확인

kubectl get rs

 

📌 2. 불필요한 ReplicaSet 삭제

kubectl delete rs my-replicaset-old

 

📌 3. revisionHistoryLimit 설정하여 자동 정리

spec:
  revisionHistoryLimit: 3  # 최근 3개의 ReplicaSet만 유지

✅ 이 설정을 적용하면 오래된 ReplicaSet이 자동으로 삭제됩니다.

 

---

🔥 7️⃣ 결론

 

✔ Deployment는 ReplicaSet을 관리하며, Pod 개수를 유지하고 새로운 버전 배포 및 롤백을 쉽게 수행할 수 있음

✔ Pod이 업데이트되지 않을 경우, kubectl set image 명령어나 imagePullPolicy: Always를 활용해야 함

✔ 롤백이 정상적으로 수행되지 않을 경우, kubectl rollout history를 확인하고 revisionHistoryLimit을 설정해야 함

✔ Deployment가 관리하는 ReplicaSet이 많거나 적을 경우, kubectl get rs 및 kubectl delete rs를 활용하여 정리해야 함

 

이 글을 통해 Deployment의 동작 원리와 트러블슈팅 방법을 익히고, 안정적인 애플리케이션 배포를 수행할 수 있길 바랍니다. 🚀