POD배포 전략: rollingUpdate vs Recreate

Rolling Update란?

Rolling Update는 Kubernetes에서 Deployment를 업데이트하는 기본 전략으로, 애플리케이션을 다운타임 없이 새로운 버전으로 점진적으로 교체하는 방법. Pod을 점진적으로 교체하면서 무중단 배포(Zero Downtime Deployment)를 수행하는 방식

strategy:
  rollingUpdate:
    maxSurge: 25%
    maxUnavailable: 25%
  type: RollingUpdate

✅ 1. type: RollingUpdate

• 업데이트 전략을 Rolling Update(롤링 업데이트) 방식으로 설정.
• 한 번에 모든 Pod을 종료하는 것이 아니라, 새로운 Pod을 점진적으로 생성하고 기존 Pod을 순차적으로 종료함.

✅ 2. maxSurge: 25%

• 현재 실행 중인 ReplicaSet 개수보다 25% 더 많은 Pod을 추가로 생성 가능.
• 예를 들어, replicas: 4인 경우 최대 1개(4의 25%)의 추가 Pod을 동시에 생성 가능.

✅ 3. maxUnavailable: 25%

• 업데이트 중에 사용할 수 없는 Pod의 최대 비율(%).
• 예를 들어, replicas: 4인 경우 최대 1개(4의 25%)의 Pod이 다운될 수 있음.
• 즉, 새 Pod이 준비되면 기존 Pod을 차례로 제거하는 방식.

---

🚀 동작 방식 예제 (replicas: 4일 때)

단계 기존 Pod 새로운 Pod 설명

시작	4개	0개	배포 전 상태
1단계	3개	1개 생성	maxUnavailable: 25% → 1개 종료 가능, maxSurge: 25% → 1개 추가 생성 가능
2단계	2개	2개 생성	새 Pod 1개가 정상 동작하면 기존 Pod 1개 추가 종료
3단계	1개	3개 생성	동일한 과정 반복
4단계	0개	4개 생성 완료	모든 Pod이 새 버전으로 교체 완료

---

✅ 정리

- maxSurge: 25% → 최대 25% 추가 생성 가능 (최대 Pod 개수 증가 허용)

-  maxUnavailable: 25% → 최대 25%까지 기존 Pod 종료 가능

- 새 Pod이 정상적으로 준비되면 기존 Pod을 하나씩 제거하며 교체 진행

- 무중단 배포(Zero Downtime)를 위한 점진적인 업데이트 방식 

- RollingUpdate를 적용하면 트래픽 손실 없이 점진적으로 새로운 버전의 애플리케이션이 배포 가능

 

 

---

 

Recreate로 변경하면 기존 모든 Pod을 한 번에 삭제한 후 새로운 Pod을 생성하는 방식

---

📌 Recreate 전략 설정

strategy:
  type: Recreate

✅ Recreate의 특징

1. 모든 기존 Pod을 한 번에 삭제한 후, 새 Pod을 생성
2. 무중단 배포가 불가능함 (배포 중에 서비스 다운 가능)
3. 데이터가 저장되지 않는 Stateless 애플리케이션에서는 사용 가능
4. Stateful하거나 중요한 서비스(Persistent Volume을 사용하는 DB 등)에서는 권장되지 않음

---

🚀 Recreate vs RollingUpdate 비교

전략 기존 Pod 삭제 방식 새로운 Pod 생성 방식 무중단 배포

RollingUpdate	하나씩 삭제	하나씩 추가	✅ 가능
Recreate	전부 삭제	전부 새로 생성	❌ 불가능

---

🛠 적용 시 고려해야 할 점

• 데이터 손실 가능성 🚨 → 기존 Pod이 모두 삭제되므로, 데이터를 저장하는 애플리케이션(DB, 캐시 등)에 사용하면 안 됨
• 일시적 서비스 중단 발생 🛑 → 모든 Pod이 삭제된 후 새 Pod이 생성되므로, 새 Pod이 뜨는 동안 서비스가 중단됨
• 단순한 배포가 필요할 때 유용 💡 → 예를 들어, 기존 애플리케이션을 완전히 종료하고 새로운 버전을 띄우는 방식이 필요할 때 사용 가능

---

🛠 Recreate가 적합한 경우

✅ 데이터를 저장하지 않는 애플리케이션

✅ 기존 Pod과 새 Pod을 동시에 실행하면 안 되는 경우

✅ 빠르게 새로운 버전을 배포해야 하지만, 일시적 서비스 중단이 허용되는 경우

반면, 무중단 배포가 필요하면 RollingUpdate를 쓰는 것이 좋음! 

---

readinessProbe예제

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
  - name: example-container
    image: busybox
    command: ["sh", "-c", "sleep 5 && touch /tmp/ready && sleep 1d"]
    readinessProbe:
      exec:
        command:
        - cat
        - /tmp/ready
      initialDelaySeconds: 5
      periodSeconds: 10

 

동작 흐름

1. 컨테이너가 시작되면 5초 동안 대기(sleep 5).
2. /tmp/ready 파일을 생성(touch /tmp/ready).
3. 이후 cat /tmp/ready 실행 시 파일이 존재하므로 Readiness Probe 성공.
4. Kubernetes는 Pod를 Ready 상태로 변경하여 트래픽을 전달.

 

결론

• Readiness Probe는 애플리케이션이 정상적으로 시작될 때까지 트래픽을 차단하는 역할.
• cat /tmp/ready를 사용하면 특정 파일이 존재할 때만 Pod를 Ready 상태로 간주.
• 이는 애플리케이션이 완전히 초기화될 때까지 요청을 방지( 애플리케이션이 정상적으로 동작할 준비가 되기 전까지 클라이언트 요청을 받지 않도록 함)하는 데 유용함.

 

애플리케이션이 완전히 초기화될 때까지 요청을 방지하는게 왜 필요한가?

애플리케이션이 실행되었다고 해서 바로 요청을 처리할 준비가 된 것은 아님.

예를 들어:

• 데이터베이스 연결 설정이 필요할 수 있음
• 캐시를 로드해야 할 수도 있음
• 초기 설정 파일을 읽어야 할 수도 있음

이러한 초기화 과정이 끝나기 전에 애플리케이션이 클라이언트 요청을 받으면 오류가 발생할 가능성이 높습니다.

Readiness Probe를 사용하면 애플리케이션이 완전히 준비될 때까지 트래픽을 받지 않도록 할 수 있습니다.

 

예제

❌ Readiness Probe 없이 Pod 실행

1. Kubernetes가 example-pod를 실행함.
2. 컨테이너가 nginx를 실행하지만 설정이 로드되기 전이라 아직 제대로 동작하지 않음.
3. Kubernetes가 Pod를 즉시 Ready 상태로 간주하고 트래픽을 보냄.
4. 클라이언트가 요청을 보내지만 nginx가 아직 준비되지 않아 502 Bad Gateway 오류 발생.

✅ Readiness Probe 사용

1. example-pod가 실행됨.
2. nginx가 설정을 로드하는 동안 /tmp/ready 파일이 없음.
3. Kubernetes는 Readiness Probe (cat /tmp/ready)를 실행하지만 실패함 → 트래픽을 차단함.
4. nginx가 완전히 초기화된 후 /tmp/ready 파일을 생성.
5. 다음 Readiness Probe 실행 시 성공 → Kubernetes가 이제야 Pod를 Ready 상태로 변경하고 트래픽을 전달.
6. 클라이언트 요청이 들어와도 정상적인 응답을 받을 수 있음.

---

 Readiness Probe의 역할

- 애플리케이션이 완전히 준비될 때까지 트래픽을 받지 않음.

- 초기 로딩 중 클라이언트가 에러를 받는 것을 방지함.

- Kubernetes가 Pod를 정상적으로 실행 가능한 상태일 때만 서비스에 추가함.

- 이러한 기능 덕분에 서비스가 더 안정적으로 운영할 수 있음!