Workload API - Deployment

2025. 7. 3. 11:55·Cloud/Kubernetes

업데이트 전략

Recreate

: 모든 이전 버전(V1)의 Pod를 한 번에 종료하고 새 버전(V2)의 Pod로 일괄적으로 교체하는 방식

Rolling update

: 새 버전의 애플리케이션을 배포할 때 새 버전 Pod는 하나씩 늘려가고 기존 버전 Pod는 하나씩 줄여나가는 방식

 

쿠버네티스의 표준 배포 방식이다.

  • maxSurge: Rolling update를 위해 최대로 생성할 수 있는 pod 개수. 높게 설정하면 배포가 빨라진다. % 또는 개수로 지정할 수 있고, 기본값은 25%이다.

maxUnavailable=0, maxSurge=1의 롤링 업데이트

  • maxUnavailable: Rolling update 중 최대로 삭제할 수 있는 pod 개수. 높게 설정하면 배포가 빨라지지만, 한번에 많은 pod를 삭제하면 남아있는 pod로 트래픽이 집중되므로 적절히 설정해야 한다. % 또는 개수로 지정할 수 있고, 기본값은 25%이다.

maxUnavailable=1, maxSurge=0의 롤링 업데이트

Blue/Green Update

: 애플리케이션의 이전 버전(블루)과 새 버전(그린)을 동시에 운영하는 방식

 

새 버전 pod만 서비스 목적으로 접속 가능하고 이전 버전 Pod는 테스트 목적으로만 접속 가능하다.

새 버전에 문제가 생겼을 때 빠르게 대응할 수 있고, 안정적으로 배포할 수 있다.

그러나 많은 Pod가 필요하기 때문에 그만큼 많은 자원(CPU, 메모리)이 필요하다는 단점이 있다.

 

이전 버전의 yaml 파일과 새로운 버전의 yaml 파일 두 개로 운영하는데, 새로운 버전은 일반적으로 이미지 경로와 labels의 버전만 수정한다.

 

 

Blue/Green Update

Canary Update

: Blue/Green과 유사한 방식의 업데이트 전략으로, 두 가지 버전을 모두 배포하지만 초기에는 새로운 버전에 트래픽을 조금만 보내고 업데이트를 진행하면서 새로운 버전에 트래픽을 늘려나가는 방식

 

기능 테스트 후 문제가 없다고 판단되면 이전 버전을 종료하고 새로운 버전으로만 서비스를 제공한다.

 

문제점과 해결방안

일반적으로 로드밸런서를 통해 서비스의 엔드포인트를 유저들에게 노출하는데, 로드밸런서는 서버의 과부하가 일어나지 않는 가장 최적화된 방식으로 트래픽을 분산한다. 이런 로드밸런서의 트래픽 분산 방식 때문에 사용자가 새로고침 시 신버전과 구버전의 UI/UX가 번갈아 나타나 불편함이 생길 수 있다. 예를 들어, 사용자가 웹페이지를 새로고침할 때마다 다른 버전의 애플리케이션에 연결되어 일관성 없는 경험을 할 수도 있다.

 

스티키 세션을 사용해 이 문제를 해결할 수 있다.

스티키 세션은 사용자가 한번 특정 서버(특정 버전의 Pod)에 접속하면 이후 해당 사용자의 모든 요청이 계속해서 동일한 서버로만 라우팅되도록 하는 기능이다.


상세 업데이트 파라미터

minReadySeconds(최소 대기 시간 - 초)

: 파드가 Ready 상태가 된 후 Deployment가 파드 구동이 완료되었다고 판단하기까지의 최소 시간

revisionHistoryLimit(수정 버전 기록 제한)

: Deployment가 유지할 ReplicaSet 수 및 롤백 가능한 이력 수

progressDeadlineSeconds(진행 기한 시간(초))

: Recreate/RollingUpdate 처리의 타임아웃 시간. 시간이 경과하면 자동으로 롤백된다.

 

 

ex) sample-deployment-params.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sample-deployment-params
spec:
  minReadySeconds: 0
  revisionHistoryLimit: 2
  progressDeadlineSeconds: 3600
  replicas: 3
  selector:
    matchLabels:
      app: sample-app
  template:
    metadata:
      labels:
        app: sample-app
    spec:
      containers:
      - name: nginx-container
        image: nginx

스케일링

Deployment가 관리하는 ReplicaSet의 레플리카 수를 조절하는 것을 스케일링이라고 한다.

이는 ReplicaSet과 동일하게 kubectl apply -f 또는 kubectl scale 명령어를 사용하여 스케일링할 수 있다.

kubectl scale deployment sample-deployment --replicas=5

 

 

 

 

저작자표시 비영리 변경금지 (새창열림)

'Cloud > Kubernetes' 카테고리의 다른 글

Helm  (1) 2025.08.12
External IP 서비스  (0) 2025.07.07
Service API - 쿠버네티스 클러스터 네트워크와 서비스  (0) 2025.07.04
Workload API - CronJob  (0) 2025.07.04
Workload API - StatefulSet  (0) 2025.07.04
'Cloud/Kubernetes' 카테고리의 다른 글
  • External IP 서비스
  • Service API - 쿠버네티스 클러스터 네트워크와 서비스
  • Workload API - CronJob
  • Workload API - StatefulSet
lur
lur
  • lur
    공부 기록
    lur
  • 전체
    오늘
    어제
    • 분류 전체보기 (41)
      • PS (9)
        • 백준 (6)
        • 프로그래머스 (1)
        • 알고리즘 (1)
        • C++ (1)
      • Cloud (14)
        • Public Cloud (4)
        • Kubernetes (6)
        • Ansible (4)
      • CICD (4)
      • TDD (1)
      • Network (12)
      • 책 (0)
        • 대규모 시스템 설계 (0)
      • 후기 (1)
  • 블로그 메뉴

    • 홈
  • 링크

  • 공지사항

  • 인기 글

  • 태그

    BFS
    비트마스킹
    kubernetes
    blue/green update
    네트워크
    Elastic Load Blancing
    알고리즘
    Continuous Deployment
    ansible
    AWS DataBase
    Community Ansible
    dfs
    canary update
    RHAAP
    AWS
    AWS File Storage
    버전 관리 시스템
    CI/CD
    백준
    ansible playbook
  • 최근 댓글

  • 최근 글

  • hELLO· Designed By정상우.v4.10.3
lur
Workload API - Deployment
상단으로

티스토리툴바