서버 운영에서 가장 중요한 목표 중 하나는 서비스 중단 없이 Application을 업데이트하는 것입니다.

실제 운영 환경에서는 새로운 기능 추가, 보안 패치 적용, 버그 수정 등으로 인해 Application Version 변경이 계속 발생합니다.

하지만 단순히 기존 Server를 종료하고 새로운 Version을 배포하면 서비스 중단이 발생할 수 있습니다.

예를 들어 쇼핑몰 서비스에서 배포 시간 동안 Server가 멈춘다면 사용자는 접속 오류를 경험하게 됩니다.

Kubernetes에서는 이러한 문제를 해결하기 위해 다양한 Deployment Strategy를 제공합니다.

대표적인 방식은 다음과 같습니다.

배포 방식	특징
Rolling Update	기존 Pod를 순차적으로 교체
Recreate	기존 Pod 종료 후 새 Pod 실행
Blue Green	새 환경 준비 후 전환
Canary	일부 사용자에게 먼저 적용

Deployment Strategy를 이해하면 Kubernetes 환경에서 안정적인 서비스 배포와 운영 자동화를 구성할 수 있습니다.

Kubernetes Deployment Strategy가 필요한 이유

Application 운영에서는 지속적인 변경이 필요합니다.

예:

기존 Version:

Application v1

↓

새로운 Version:

Application v2

문제:

기존 Pod 종료

↓

새로운 Pod 시작

↓

서비스 중단 발생

Production 환경에서는 이러한 방식이 적합하지 않습니다.

따라서 Kubernetes는 배포 과정에서도 서비스 상태를 유지하는 구조를 제공합니다.

Kubernetes Rolling Update란?

Rolling Update는 Kubernetes Deployment의 기본 배포 방식입니다.

기존 Pod를 한 번에 모두 종료하지 않고 새로운 Version의 Pod를 순차적으로 생성하면서 교체합니다.

구조:

기존 Pod v1

Pod v1

Pod v1

Pod v1

↓

새로운 Pod 생성

Pod v2

Pod v1

Pod v1

↓

순차 교체

Pod v2

Pod v2

Pod v2

↓

업데이트 완료

서비스 중단 없이 Version 변경이 가능합니다.

Kubernetes Rolling Update 동작 과정

예를 들어 3개의 Replica를 가진 Application이 있다고 가정합니다.

기존:

Application v1

• Pod 3개

업데이트 시작:

1단계

새로운 v2 Pod 생성

↓

2단계

기존 v1 Pod 하나 종료

↓

3단계

다음 v2 Pod 생성

↓

4단계

모든 Pod 교체 완료

사용자는 배포 과정을 인식하지 못하고 계속 서비스를 이용할 수 있습니다.

Kubernetes maxSurge 설정

maxSurge는 업데이트 과정에서 추가로 생성할 수 있는 Pod 개수를 설정합니다.

예:

replicas: 5

maxSurge: 2

의미:

기존 Pod 5개

↓

최대 2개 추가 가능

↓

최대 7개까지 실행

배포 속도를 높일 수 있습니다.

Kubernetes maxUnavailable 설정

maxUnavailable은 업데이트 중 사용할 수 없는 Pod 개수를 지정합니다.

예:

replicas: 5

maxUnavailable: 1

의미:

최대 1개 Pod만 서비스 불가능 상태 허용

서비스 안정성을 유지합니다.

Kubernetes Recreate Strategy란?

Recreate 방식은 기존 Pod를 모두 종료한 후 새로운 Pod를 생성합니다.

구조:

기존 Pod 종료

↓

서비스 중단

↓

새로운 Pod 생성

↓

서비스 재개

장점:

• 구조 단순
• Version 충돌 방지

단점:

• 서비스 중단 발생

개발 환경이나 중단 가능한 Application에서 사용합니다.

Kubernetes Blue Green Deployment란?

Blue Green 방식은 두 개의 환경을 준비하고 Traffic을 전환하는 배포 방식입니다.

구조:

Blue 환경

Application v1 실행

↓

Green 환경

Application v2 준비

↓

Traffic 변경

↓

Green 활성화

장점:

• 빠른 Rollback 가능
• 안정적인 배포

단점:

• 두 환경 운영 비용 발생

중요한 서비스에서 활용됩니다.

Kubernetes Canary Deployment란?

Canary Deployment는 새로운 Version을 일부 사용자에게 먼저 적용하는 방식입니다.

구조:

기존 Version

↓

90% Traffic

새로운 Version

↓

10% Traffic

↓

문제 확인

↓

전체 전환

실제 운영에서 위험을 줄이는 방법입니다.

Kubernetes Deployment Strategy 비교

방식	장점	단점
Rolling Update	기본 지원, 안정적	업데이트 시간 필요
Recreate	간단한 구조	서비스 중단
Blue Green	빠른 전환	비용 증가
Canary	위험 감소	구성 복잡

서비스 중요도에 따라 선택합니다.

Kubernetes Rollback 구조

배포 후 문제가 발생하면 이전 Version으로 되돌릴 수 있습니다.

예:

Application v2 배포

↓

오류 발생

↓

Rollback 실행

↓

Application v1 복구

Kubernetes Deployment는 Revision 기록을 관리합니다.

Kubernetes 배포 장애 사례

실제 운영에서는 다음 문제가 발생할 수 있습니다.

문제	원인
새 Pod 실행 실패	Image 오류
업데이트 중 서비스 오류	Readiness Probe 문제
Rollback 실패	Version 관리 문제
Resource 부족	Node 용량 부족

배포 전 검증 과정이 중요합니다.

Kubernetes Deployment와 Probe 관계

안정적인 배포를 위해 Health Check가 필요합니다.

구조:

새로운 Pod 생성

↓

Readiness Probe 확인

↓

정상 상태 확인

↓

Traffic 연결

Probe가 없다면 정상적으로 실행되지 않은 Pod에도 Traffic이 전달될 수 있습니다.

Kubernetes Deployment 운영 전략

Production 환경에서는 다음 구조를 많이 사용합니다.

개발 환경:

Rolling Update

↓

테스트

↓

Canary

↓

Production 적용

서비스 중요도에 따라 배포 방식을 선택합니다.

Kubernetes Deployment Strategy 장점

장점	설명
무중단 배포	서비스 유지
Rollback 지원	빠른 복구
자동 관리	운영 효율 증가
안정성 향상	배포 위험 감소

Kubernetes Deployment Strategy는 Cloud Native 운영의 핵심입니다.

자주 묻는 질문

Kubernetes 기본 배포 방식은 무엇인가요?

Deployment에서는 기본적으로 Rolling Update 방식이 사용됩니다.

Rolling Update 중 서비스가 중단되나요?

정상적으로 설정하면 서비스 중단 없이 업데이트할 수 있습니다.

Blue Green과 Rolling Update 차이는 무엇인가요?

Rolling Update는 기존 환경을 순차 변경하고 Blue Green은 새로운 환경을 만든 후 Traffic을 전환합니다.

마무리

Kubernetes Deployment Strategy는 Application Version 변경 과정에서 안정적인 서비스를 유지하기 위한 핵심 운영 방식입니다.

구성 요소	역할
Rolling Update	순차 배포
Recreate	전체 재배포
Blue Green	환경 전환
Canary	부분 적용

Deployment Strategy를 이해하면 Kubernetes 환경에서 장애 위험을 줄이고 안정적인 Production 배포 환경을 구축할 수 있습니다.

다음 글에서는 Kubernetes 배포 안정성을 높이는 Kubernetes Rollback 완벽 가이드! 장애 발생 시 이전 Version 복구 구조 이해하기를 알아보겠습니다.