쿠버네티스 디플로이먼트 배포 방식의 종류

[jokbalkiller]

🥷🏻 글을 읽고 꼭 대답할 수 있어야 하는 질문

2. 롤링업데이트시 운영되는 POD의 총 개수는 고정되나요?
3. 롤링 업데이트 시 속도를 조절 할 수 있나요?
4. 삭제할때 어떤 POD가 삭제되나요?

📚 목차

1. POD 오브젝트의 종류
2. Rolling Update
3. Blue, Green
4. Canary
5. 실제 사용 현황과 인사이트

📖 핵심 내용

1. POD를 띄울수 있는 오브젝트 종류

쿠버네티스에는 POD를 올릴 수 있는 다양한 오브젝트들이 존재합니다. 게임의 2차전직처럼 POD에 각각의 특성들이 합쳐져 진화된 것이라고 생각하면 이해가 쉽습니다. 간단하게 설명하면 다음과 같습니다.

POD + 무조건 딱 한번만 돌아 = Job(eg, 한번만 실행되는 스크립트)
POD + 복제인데 상태값이 다 달라서 따로 구분해 = StatefulSet(eg,DB와 같이 여러개가 존재해도 안에 담고있는 데이터가 달라 따로 구분)
POD + 상태저장 그런거없고 그냥 똑같은거 무한복제 = Deployment(eg,프론트엔드,백엔드와 같은 앱들은 보통 특정 상태값을 저장하지 않고 단순 API만 처리)
POD + 노드마다 한개씩만 들어가서 죽지마 = DemonSet(eg,매트릭 비트,kube-proxy 처럼 노드마다 딱 한개씩만 있어도 되는것들)

키포인트1. 프론트엔드, 백엔드는 왜 주로 Deployment 로 띄워지나요?

그중에서도 이번 글은 Deployment의 배포 방식을 다룹니다.

2. Rolling Update(Default)

Rolling은 Deployment의 기본 배포 방식으로 사실 이외 나머지 배포 방법은 프로세스적으로 유저들이 고안해낸 배포 방식인뿐 쿠버네티스가 직접 지원하는 옵션은 롤링뿐입니다. 반대로 말하면 롤링업데이트를 하라고 디플로이먼트가 존재한다고 말할 수있습니다. 이정도로 매우 중요한 배포방식입니다.
롤링 업데이트는 여러개가 띄워진 POD 에서 조금씩 점진적으로 새로운 이미지의 POD 로 변경하는 방식입니다.

이제 Deployment에서 롤링업데이트와 관련된 주요 옵션 2가지를 소개합니다. 해당 옵션값에는 N 혹은 N%가 들어갈 수 있습니다.

max_surge: 업데이트 시작 시 설정된 replicas 개수를 초과하여 생성할 수 있는 새 Pod(New)의 최대 개수 또는 비율(아무것도 넣어주지 않으면 25%), 쉽게 말하면 New 를 한번에 생성하는 개수
max_unavailable : 업데이트 시작 시 삭제될 수 있는 기존 Pod(Old)의 최대 개수 또는 비율(아무것도 넣어주지 않으면 25%), 그냥 단순하게 old 가 한번에 지워지는 개수라고 생각하면 쉽다.

여기서 포인트는 해당 옵션값들은 레플리카의 총 개수보다 같거나 많게 줄 수 없습니다. 즉 100%를 넣어주거나 N값을 총 레플리카 개수로 보다 같거나 많게 주면 에러가 발생합니다. 다음 2가지의 경우 실행조차 안되지만 가정을 해보겠습니다.

Case 1. max_surge = 100%, 혹은 총 레프리카 수
롤링 업데이트가 시작하면 기존에 돌고있는 Old Pod는 그대로 존재하면서 똑같은 수만큼 New Pod가 뜨게됩니다. 전체를 똑같이 복사하여 통째로 바꿔버리게 되기에 Blue, Green 배포와 같게되며 매우 큰 리소스를 사용하기 때문에 점진적 배포를 목적으로 설계한 취지에 맞지 않습니다.

Case 2. max_unavailable = 100%, 혹은 총 레프리카 수
롤링 업데이트가 시작하면 기존에 돌고있던 Old Pod가 하나도 남지않고 동시에 모두 삭제됩니다. 이는 서비스의 중단이므로 무중단 배포를 목적으로 설계한 취지와 맞지 않습니다.

키포인트2. 롤링 업데이트의 2가지의 옵션 값은 최소 최대 어떻게 지정할 수 있으며 그 의미는?

위 2가지를 어떻게 설정하냐에 따라 같은 롤링 업데이트여도 특성이 달라지게 되고 인프라가 매우 골때리는 부분으로 바뀝니다. 이후 과정은 옵션에 따라 알고리즘 처럼 replicas의 개수만큼 모두 New가 될 때가지 반복 진헹됩니다.

Case 1

    replicas: 4
    strategy {
      rolling_update {
        max_surge       = "0"
        max_unavailable = "1"
      }
      type = "RollingUpdate"
    }

삭제가 되자마자 다음 Old를 삭제하기 때문에 New가 뜨는데 오래 걸린다면 그 와중에 계속 삭제할 가능성이 있습니다.

업데이트 도중 최소 3개의 Pod는 항상 실행 상태를 유지합니다.
maxSurge 0 설정으로 인해 한 번에 새로운 Pod를 추가 생성하지 않고 기존 Pod를 재활용합니다. 따라서 업데이트 과정이 더 느리게 진행될 수 있습니다.
새로운 Pod를 추가로 생성하지 않으므로 클러스터 리소스를 효율적으로 사용합니다.

Case 2

    replicas: 4
    strategy {
      rolling_update {
        max_surge       = "1"
        max_unavailable = "0"
      }
      type = "RollingUpdate"
    }

Case 3

    replicas: 4
    strategy {
      rolling_update {
        max_surge       = "1"
        max_unavailable = "1"
      }
      type = "RollingUpdate"
    }

🎁 주의해야할 점
롤링 업데이트는 아무리 비율과 옵션을 잘 조절한다 하여도 결국 Old와 New Pod가 동시에 뜨는 구간이 필연적으로 발생한다. 따라서 해당 구간에서 Old, New POD가 동시에 DB 혹은 나머지 POD들에 연결되더라도 서비스에 문제가 없도록 로직을 작성하여 이미지를 만들어야하며 불가능할 경우 롤링 업데이트는 사용할 수없으며 통으로 바꿔버리는 Blue, Green 배포 방식을 사용해야한다.

Blue, Green

Deployment와 Service는 Label로 연결된다는 특성을 이용하여 Deployment를 기존과 반대인 색으로 따로 만들어 두고 서비스의 라벨만 바꾸어서 바로 교체한 하는 방식입니다. 순서는 다음과 같습니다.

1. Old Image를 가진 Backend Deployment 가 존재하며 version: blue라는 태그가 있고 Backend Service도 version: blue 태그가 존재하여 서로 매치가 잘 된 상태로 서비스가 운영되고 있습니다.
2. 그 상태에서 그대로 New Image를 가진 Backend Deployment를 추가로 생성하며 version: green 태그를 붙입니다. 기존 Backend Service는 version : blue 인 Deployment를 찾고있기에 전혀 지장이 없습니다.
3. Backend Service에서 version : green 태그 값을 변경합니다.
4. Backend Service 는 New Image를 가진 version: green 의 Backend Deployment를 찾아 연결됩니다.
5. 기존 version: blue 였던 Deployment를 삭제합니다.

🎁 주의해야할 점
해당 POD 와 결합성이 강하게 연결된 DB같은 서비스의 경우 블루 그린으로 같이 2가지를 만들어 동시에 바꿔줘야하는 경우가 필요하여 리소스및 전략이 많이 필요한 배포 방식입니다.

Canary

🎁 주의해야할 점
롤링 업데이트는 아무리 비율과 옵션을 잘 조절한다 하여도 결국 Old와 New Pod가 동시에 뜨는 구간이 필연적으로 발생한다. 따라서 해당 구간에서 Old, New POD가 동시에 DB 혹은 나머지 POD들에 연결되더라도 서비스에 문제가 없도록 로직을 작성하여 이미지를 만들어야하며 불가능할 경우 롤링 업데이트는 사용할 수없으며 통으로 바꿔버리는 Blue, Green 배포 방식을 사용해야한다.

---

💡 참고 자료:

• 링크나 참고한 자료 출처를 여기에 적어 주세요.

[suna-ji]

쿠버네티스에서 데몬셋과 에이전트의 차이점

비교

특성	데몬셋(DaemonSet)	에이전트(Agent)
Kubernetes 리소스 여부	Kubernetes에서 관리되는 리소스	Kubernetes 외부의 독립 실행형 프로그램
스케줄링 방식	모든 (또는 특정) 노드에 Pod를 자동 배포	사용자가 수동으로 설정 및 실행
사용 목적	각 노드에서 반드시 실행되어야 하는 Pod 배포	사용자 정의 작업 수행
관리 대상	Pod (Kubernetes 컨트롤러로 관리)	독립 실행형 애플리케이션으로 사용자가 직접 관리
의존성	Kubernetes API에 의존	Kubernetes API 의존 여부는 사용 목적에 따라 다름

결론

데몬셋은 Kubernetes 내부에서 노드 전반에 걸쳐 Pod를 배포하고 관리하기 위한 표준화된 리소스입니다. 반면, 에이전트는 Kubernetes 내부 또는 외부에서 실행되며 특정 작업을 수행하는 독립 실행형 프로그램으로, 사용자 요구 사항에 따라 동작이 정의됩니다.
이 두 개념은 상호 보완적일 수 있으며, 예를 들어 데몬셋을 통해 에이전트를 Pod 형태로 실행하는 시나리오도 가능합니다.