Kubernetes Engine으로 배포 관리 (정리)

Peter·2023년 5월 10일
쿠버네티스
0

2023 클라우드 스터디 잼 쿠버네티스 입문

목록 보기
5/6
post-thumbnail

DevOps 방식에서는 정기적으로 여러 배포를 사용해 애플리케이션 배포 시나리오를 관리한다. 애플리케이션 배포 시나리오에는 지속적 배포, Blue/Green 배포, Canary배포가 있다.

배포 소개

이기종 배포(heterogeneous deployment)에서는 2개 이상의 인프라 환경 또는 리전을 연결한다. 배포 특성에 따라 '하이브리드', '다중 클라우드', '공용/사설'이라고 부른다.

단일 환경 또는 리전에 한정된 배포에는 다양한 문제가 발생할 수 있다.
1. 여유 리소스 부족: 컴퓨팅, 네트워킹, 저장소 리소스가 모자랄 수 있다.
2. 제한된 지리적 범위: 단일 환경에서의 배포를 위해서는 지리적으로 서로 멀리 떨어진 사용자들이 하나의 배포에 액세스 해야 한다. -> 이러한 사용자의 트래픽은 특정 위치까지 전 세계를 돌아서 이동한다.
3. 제한된 가용성: 웹 규모의 트래픽 패턴에서는 애플리케이션의 내결함성 및 탄력성이 상당히 요구된다.
4. 공급업체 고착화: 공급업체 수준의 플랫폼 및 인프라 추상화로 인해 애플리케이션 이식이 어려울 수 있다.
5. 유연하지 않은 리소스: 특정 컴퓨팅, 저장소 또는 네트워킹 오퍼링 집합으로 리소스가 제한될 수 있다.

이기종 배포는 이러한 문제를 해결하는 데 도움이 될 수 있다.

이 실습에서 사용할 샘플 코드 가져오기

  1. 컨테이너와 배포를 만들고 실행하기 위한 샘플 코드를 가져옵니다.
gsutil -m cp -r gs://spls/gsp053/orchestrate-with-kubernetes .
cd orchestrate-with-kubernetes/kubernetes

이 코드는 Google Cloud Storage(GCS)에서 파일을 다운로드하여 현재 작업 디렉토리에 저장하고, 저장된 디렉토리로 이동하는 과정을 설명합니다. 명령어의 각 부분을 분석하면 다음과 같습니다:

gsutil: Google Cloud Storage를 사용하기 위한 명령 줄 도구입니다. 이 도구를 사용하여 GCS 버킷과 상호 작용할 수 있습니다.

-m: 이 옵션은 병렬 처리를 사용하여 파일을 복사함으로써 전체 작업 속도를 향상시킵니다.

cp: 파일을 복사하는 명령어입니다. 여기서는 GCS 버킷에서 로컬 디렉토리로 파일을 복사합니다.

-r: 이 옵션은 복사 작업을 재귀적으로 수행하여 서브디렉토리와 그 안의 파일까지 복사합니다.

gs://spls/gsp053/orchestrate-with-kubernetes: GCS 버킷의 파일 경로입니다. 이 경로에 있는 파일과 디렉토리를 복사할 것입니다.

.: 로컬 디렉토리의 대상 경로입니다. 이 경우 현재 작업 디렉토리를 나타냅니다.

cd: 디렉토리를 변경하는 명령어입니다. 이 명령어를 사용하여 디렉토리를 이동할 수 있습니다.

orchestrate-with-kubernetes/kubernetes: 이동할 디렉토리의 경로입니다.

결론적으로 이 코드는 gs://spls/gsp053/orchestrate-with-kubernetes GCS 버킷의 파일과 디렉토리를 현재 작업 디렉토리에 복사한 후, 복사된 orchestrate-with-kubernetes/kubernetes 디렉토리로 이동합니다.

  1. 노드 3개로 클러스터를 만듭니다. 이 작업은 완료하는 데 몇 분 정도 걸릴 수 있습니다.

    클러스터(cluster)란 여러 대의 컴퓨터 또는 서버가 서로 연결되어 하나의 시스템처럼 동작하는 컴퓨터 그룹을 의미합니다. 이러한 클러스터는 일반적으로 높은 가용성, 내구성, 처리 성능 및 확장성을 제공하기 위해 사용됩니다. 클러스터는 하나의 컴퓨터에서 실행되는 작업을 여러 컴퓨터로 분산시켜 처리 시간을 줄이거나, 여러 컴퓨터의 리소스를 통합하여 더 큰 작업을 처리할 수 있도록 합니다.

gcloud container clusters create bootcamp \
  --machine-type e2-small \
  --num-nodes 3 \
  --scopes "https://www.googleapis.com/auth/projecthosting,storage-rw"

이 코드는 Google Cloud SDK의 명령어입니다. Google Kubernetes Engine(GKE)에서 'bootcamp'이라는 이름의 새로운 클러스터를 생성하도록 지시합니다. 명령어의 각 부분을 분석하면 다음과 같습니다:

gcloud: Google Cloud SDK의 CLI 도구입니다. 이 도구를 사용하여 Google Cloud Platform에서 다양한 작업을 수행할 수 있습니다.

container: gcloud의 하위 명령어로, Kubernetes 컨테이너 관련 작업을 수행하는데 사용됩니다.

clusters: 컨테이너 클러스터와 관련된 작업을 수행하는 하위 명령어입니다.

create: 새로운 리소스를 생성하는 명령어입니다. 여기서는 새로운 클러스터를 생성하게 됩니다.

bootcamp: 생성될 새 클러스터의 이름입니다.

--machine-type e2-small: 클러스터의 머신 유형을 설정합니다. 여기서는 "e2-small"이라는 머신 유형이 사용됩니다.

--num-nodes 3: 클러스터에 있는 노드의 수를 설정합니다. 이 클러스터에는 3개의 노드가 포함됩니다.

--scopes "https://www.googleapis.com/auth/projecthosting,storage-rw": 클러스터가 사용할 수 있는 API 스코프를 설정합니다. 이 명령어에서는 두 가지 스코프가 설정되어 있습니다:

https://www.googleapis.com/auth/projecthosting: 프로젝트 호스팅과 관련된 권한을 부여합니다.
storage-rw: 저장소에 대한 읽기 및 쓰기 권한을 부여합니다.
결론적으로 이 코드는 Google Cloud에서 bootcamp이라는 이름의 새로운 Kubernetes 클러스터를 생성하고, 이 클러스터에는 "e2-small" 머신 유형의 3개의 노드가 포함되며, 프로젝트 호스팅과 저장소 읽기/쓰기에 대한 권한이 부여됩니다.

작업 1. 배포 객체에 관해 알아보기

배포객체란

배포 객체(Deployment)는 Kubernetes에서 애플리케이션을 관리하고 배포하는 데 사용되는 리소스입니다. Deployment는 일반적으로 애플리케이션의 상태를 선언적으로 관리하며, 사용자가 원하는 상태를 지정할 수 있게 해줍니다. Kubernetes는 지정된 상태를 만족하도록 배포 객체를 관리하고, 자동으로 복구, 확장, 롤백 등을 처리합니다.

  1. kubectl의 explain 명령어를 통해 배포 객체에 관해 알 수 있습니다.
kubectl explain deployment
  1. --recursive 옵션을 사용하여 모든 필드를 볼 수도 있습니다.
kubectl explain deployment --recursive
  1. 실습을 진행하는 과정에서 explain 명령어를 사용하면 배포 객체의 구조를 이해하고 개별 필드의 기능을 이해하는 데 도움이 됩니다.
kubectl explain deployment.metadata.name

작업 2. 배포 만들기

  1. deployments/auth.yaml 구성 파일을 업데이트합니다.

  2. 편집기를 시작합니다.

  3. 배포의 containers 섹션에 있는 image를 다음과 같이 변경합니다.

  4. auth.yaml 파일을 저장하고 <Esc>를 누릅니다.

  5. 이제 간단한 배포를 만들겠습니다. 배포 구성 파일을 검사합니다.

kubectl create 명령어를 실행하여 인증 배포를 만들면 배포 매니페스트의 데이터에 따라 하나의 포드가 생성됩니다. 즉, replicas 필드에 지정된 숫자를 변경하여 포드의 수를 조정할 수 있습니다.

  1. kubectl create를 사용하여 배포 객체를 만듭니다.
kubectl create -f deployments/auth.yaml

이 코드는 kubectl 명령어를 사용하여 Kubernetes 클러스터에서 리소스를 생성하는 것을 설명합니다. 명령어의 각 부분을 분석하면 다음과 같습니다:

kubectl: Kubernetes 클러스터와 상호 작용하기 위한 커맨드 라인 도구입니다. 이 도구를 사용하여 클러스터의 리소스를 관리할 수 있습니다.

create: 새로운 리소스를 생성하는 명령어입니다. 여기서는 Kubernetes 리소스를 생성하게 됩니다.

-f: 이 옵션은 리소스 구성 파일을 지정하는 데 사용됩니다. 이 파일에는 리소스의 세부 정보와 구성이 포함되어 있습니다.

deployments/auth.yaml: 리소스 구성 파일의 경로입니다. 이 파일은 YAML 포맷으로 작성되어 있으며, Kubernetes 리소스의 세부 정보와 구성을 담고 있습니다.

결론적으로 이 코드는 deployments/auth.yaml 파일을 사용하여 Kubernetes 클러스터에서 리소스를 생성합니다. 이 리소스 구성 파일은 일반적으로 Deployment, Pod, Service 등과 같은 Kubernetes 리소스에 대한 세부 정보와 구성을 포함하고 있습니다. 해당 파일에 따라 여러 종류의 리소스가 생성될 수 있습니다.

  1. 배포를 만들면 생성 여부를 확인할 수 있습니다.

  2. 배포가 생성되면, Kubernetes에서는 배포에 관한 ReplicaSet를 만듭니다. 배포에 관한 ReplicaSet가 생성되었는지 확인할 수 있습니다.

  3. 마지막으로, 배포의 일부로 생성된 포드를 볼 수 있습니다. ReplicaSet가 생성될 때 Kubernetes에서 단일 포드를 생성합니다.

  4. 이제 인증을 배포하기 위한 서비스를 만들 차례입니다. 서비스 매니페스트 파일은 이미 살펴보았으므로 여기서는 자세히 설명하지 않겠습니다. kubectl create 명령어를 사용하여 인증 서비스를 만듭니다.

  5. 이제 같은 방법으로 hello 배포를 만들고 노출합니다.

  6. 한번 더 frontend 배포를 만들고 노출합니다.

  7. 외부 IP를 가져와서 프런트엔드와 연결함으로써 프런트엔드와 상호작용합니다.

  8. kubectl의 출력 템플릿 기능을 사용하여 curl을 한 줄 명령어로 사용할 수도 있습니다.

배포 확장

배포확장이란

배포 확장(Deployment scaling)은 Kubernetes의 Deployment 리소스에서 애플리케이션 인스턴스 수를 증가시키거나 감소시키는 과정입니다. 배포 확장을 통해 애플리케이션의 트래픽 수요에 맞게 처리 능력을 조절할 수 있습니다. 이를 통해 트래픽이 많을 때는 더 많은 인스턴스를 통해 요청을 처리하고, 트래픽이 적을 때는 더 적은 인스턴스를 사용하여 리소스를 절약할 수 있습니다.

Deployment는 애플리케이션의 여러 인스턴스를 관리하며, 각 인스턴스는 Kubernetes의 Pod로 실행됩니다. 배포 확장은 Pod의 수를 조절함으로써 이루어집니다.

배포 확장은 kubectl 명령어를 사용하여 수행할 수 있습니다. 예를 들어, 다음 명령어는 my-deployment라는 이름의 Deployment의 인스턴스 수를 5개로 확장합니다:

kubectl scale deployment my-deployment --replicas=5

이렇게 하면 Kubernetes는 지정된 수의 Pod를 유지하도록 Deployment를 자동으로 조절합니다. 이 과정은 수동으로 수행할 수도 있고, 자동으로 수행할 수도 있습니다. 자동 배포 확장의 경우, Horizontal Pod Autoscaler(HPA)를 사용하여 특정 메트릭(예: CPU 사용률)에 따라 Pod의 수를 자동으로 조절할 수 있습니다.

  1. kubectl explain 명령어를 다시 사용하여 이 필드에 관한 설명을 볼 수 있습니다.
  2. replicas 필드를 가장 쉽게 업데이트하는 방법은 kubectl scale 명령어를 사용하는 것입니다.
  3. 현재 hello 포드가 5개 실행되고 있는지 확인합니다.
  4. 이제 애플리케이션을 다시 축소합니다.
  5. 포드 개수가 맞는지 다시 확인합니다.

작업 3. 순차적 업데이트

순차적 업데이트란

쿠버네티스(Kubernetes)에서 순차적 업데이트는 롤링 업데이트(rolling update)라는 용어로 더 잘 알려져 있습니다. 롤링 업데이트를 사용하면 새로운 버전의 애플리케이션을 점진적으로 배포하면서 동시에 기존 버전을 제거할 수 있습니다. 이로 인해 사용자는 업데이트 중에도 지속적으로 서비스를 사용할 수 있습니다.

롤링 업데이트는 쿠버네티스의 Deployment 리소스를 사용하여 관리할 수 있습니다. Deployment는 애플리케이션의 여러 인스턴스를 관리하며, 각 인스턴스는 쿠버네티스의 Pod로 실행됩니다. 롤링 업데이트를 수행할 때, Deployment는 새로운 버전의 애플리케이션을 실행하는 새로운 Pod를 점진적으로 생성하고, 동시에 기존 버전의 애플리케이션을 실행하는 기존 Pod를 종료합니다.

롤링 업데이트를 수행하려면, Deployment의 구성 파일에서 새로운 애플리케이션 버전을 지정하고 kubectl apply 명령어를 사용하여 변경 사항을 적용하면 됩니다. 롤링 업데이트를 사용하여 애플리케이션을 업데이트할 때, 쿠버네티스는 업데이트 전략에 따라 Pod의 순차적인 업데이트를 처리합니다. 롤링 업데이트 전략은 maxUnavailable 및 maxSurge와 같은 파라미터를 통해 조절할 수 있습니다. 이러한 파라미터를 사용하면 업데이트 속도와 동시에 실행되는 Pod의 최대 수를 지정할 수 있습니다.

순차적 업데이트 트리거하기

  1. 배포를 업데이트하려면 다음 명령어를 실행합니다.
  2. 배포의 containers 섹션에 있는 image를 다음과 같이 변경합니다.
  3. 저장 후 종료합니다.
    편집기에서 저장하면, 업데이트된 배포가 클러스터에 저장되고 Kubernetes에서 순차적 업데이트가 시작됩니다.
  4. Kubernetes에서 생성한 새로운 ReplicaSet를 확인합니다.
  5. 출시 기록에 새로운 항목이 표시될 수도 있습니다.

순차적 업데이트 일시중지하기

  1. 지금 중지해보세요.
  2. 현재 출시 상태를 확인합니다.
  3. 포드에서 직접 확인할 수도 있습니다.

순차적 업데이트 재개하기

출시가 일시중지되었으므로 일부 포드는 새 버전이고 일부 포드는 이전 버전입니다.
1. resume 명령어를 사용하여 출시를 계속 진행할 수 있습니다.
2. 출시가 완료되면 status 명령어를 실행할 때 다음이 표시됩니다.

업데이트 롤백하기

새 버전에서 버그가 발견되었다고 가정해 보겠습니다. 새 버전에 문제가 있는 것으로 간주되므로 새 포드에 연결된 모든 사용자가 문제를 경험하게 됩니다.

이전 버전으로 롤백하여 문제를 조사한 다음 제대로 수정된 버전을 출시할 수 있습니다.

  1. rollout 명령어를 사용하여 이전 버전으로 롤백합니다.
  2. 기록에서 롤백을 확인합니다.
  3. 마지막으로, 모든 포드가 이전 버전으로 롤백되었는지 확인합니다.

작업 4. Canary 배포

Canary 배포란

Canary 배포는 소프트웨어 개발에서 새로운 버전의 애플리케이션을 점진적으로 테스트하고 배포하는 전략입니다. 이 전략의 이름은 "탄광의 캐나리"에 기반한데, 과거 탄광에서 광부들이 가스 유출을 감지하기 위해 캐나리를 사용한 것에서 유래했습니다. 마찬가지로, Canary 배포는 새로운 버전의 애플리케이션에 문제가 있는지 감지하기 위한 전략입니다.

Canary 배포의 주요 아이디어는 전체 사용자에게 새 버전을 바로 적용하는 대신, 먼저 일부 사용자에게 새 버전을 제공합니다. 이를 통해 새로운 버전의 성능과 안정성을 평가하고, 문제가 발견되면 빠르게 수정하거나 롤백할 수 있습니다. 일부 사용자에게 새로운 버전이 성공적으로 동작하면, 점진적으로 더 많은 사용자에게 새 버전을 확장할 수 있습니다.

쿠버네티스(Kubernetes)에서 Canary 배포를 구현하는 방법 중 하나는 두 개의 별도의 Deployment를 사용하는 것입니다. 하나의 Deployment는 기존 버전의 애플리케이션을 실행하고, 다른 Deployment는 새로운 버전의 애플리케이션을 실행합니다. 이렇게 하면 두 버전의 애플리케이션을 동시에 실행할 수 있습니다. 또한, 서비스 리소스를 사용하여 두 Deployment의 트래픽을 제어할 수 있습니다. 예를 들어, 일부 사용자가 새 버전의 애플리케이션에 액세스하도록 서비스의 로드 밸런싱 규칙을 구성할 수 있습니다.

Canary 배포 전략을 사용하면 새로운 기능과 버그 수정을 안전하게 배포하면서, 사용자의 서비스 중단을 최소화할 수 있습니다.

Canary 배포 만들기

Canary 배포는 새 버전의 별도 배포와 함께 기존 안정화 배포 및 Canary 배포를 동시에 대상으로 삼는 서비스로 구성됩니다.

  1. 먼저 새 버전의 새로운 Canary 배포를 만듭니다.
  2. 이제 Canary 배포를 만듭니다.
  3. Canary 배포를 만들면 hello 및 hello-canary의 두 가지 배포가 생깁니다. 다음 kubectl 명령어로 확인하세요.

hello 서비스에서 선택기는 프로덕션 배포 및 Canary 배포의 pod에 모두 맞는 app:hello 선택기를 사용합니다. 그러나 Canary 배포가 포드 수가 더 적기 때문에 더 적은 수의 사용자에게 표시됩니다.

Canary 배포 확인하기

  1. 요청에서 제공되는 hello 버전을 확인할 수 있습니다.
  2. 이 명령어를 여러 번 실행하면, 일부 요청은 hello 1.0.0에서 제공하고 소규모 하위 집합(1/4=25%)은 2.0.0에서 제공함을 알 수 있습니다.

프로덕션 환경의 Canary 배포 - 세션 어피니티

쿠버네티스에서 세션 어피니티란

쿠버네티스(Kubernetes)에서 세션 어피니티(session affinity)는 동일한 클라이언트의 연속적인 요청이 동일한 백엔드 파드로 전송되도록 하는 로드 밸런싱 전략입니다. 이를 통해 사용자 세션 정보를 특정 파드에 저장하여 애플리케이션 상태를 관리하고 개선된 사용자 경험을 제공할 수 있습니다.

세션 어피니티를 사용하면, 특정 클라이언트의 요청이 항상 동일한 파드로 전송되므로 해당 파드는 이전 요청과 관련된 정보(예: 로그인 정보, 쇼핑 카트 상태 등)를 유지할 수 있습니다. 이로 인해 클라이언트가 다른 파드로 전환될 때 발생할 수 있는 일관성 문제나 정보 손실을 방지할 수 있습니다.

쿠버네티스에서는 서비스 리소스를 사용하여 세션 어피니티를 구성할 수 있습니다. 서비스 리소스는 클러스터 내부의 파드에 대한 추상화된 액세스를 제공하며, 클라이언트의 요청을 적절한 파드로 전달하는 역할을 합니다. 서비스의 sessionAffinity 속성을 사용하여 세션 어피니티를 설정할 수 있습니다. 예를 들어, 다음과 같이 서비스의 세션 어피니티를 설정할 수 있습니다:

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  sessionAffinity: ClientIP

위 예제에서, sessionAffinity 속성은 클라이언트 IP를 기반으로 세션 어피니티를 구성합니다. 이렇게 하면 동일한 클라이언트 IP 주소에서 발신되는 요청이 항상 동일한 파드로 전송됩니다. 세션 어피니티는 ClientIP 또는 None 값을 사용하여 설정할 수 있습니다. 기본값은 None으로, 세션 어피니티를 사용하지 않는 경우입니다.

작업 5. Blue/Green 배포

Blue/Green 배포란?

Blue/Green 배포는 소프트웨어 개발에서 애플리케이션의 새로운 버전을 무중단으로 배포하는 전략 중 하나입니다. 이 전략에서는 두 개의 동일한 프로덕션 환경이 사용되며, 하나는 "Blue"로 명명되고 다른 하나는 "Green"으로 명명됩니다. 이 두 환경은 동일한 하드웨어, 네트워크 및 구성을 공유합니다.

Blue/Green 배포의 기본 아이디어는 다음과 같습니다:

  1. Blue 환경은 현재 프로덕션 환경으로, 작동 중인 애플리케이션의 안정적인 버전을 실행합니다.
  2. Green 환경은 새 버전의 애플리케이션을 배포하고 테스트하는 데 사용됩니다.
  3. 새 버전의 애플리케이션이 Green 환경에서 완벽하게 작동하면, 로드 밸런서의 설정을 변경하여 사용자 트래픽을 Blue 환경에서 Green 환경으로 전환시킵니다. 이로 인해 즉시 새 버전의 애플리케이션을 사용할 수 있게 됩니다.
  4. 문제가 발생하면 로드 밸런서를 사용하여 사용자 트래픽을 안정적인 Blue 환경으로 즉시 되돌릴 수 있습니다.
    Blue/Green 배포의 장점은 다음과 같습니다:
  • 무중단 배포: 새 버전이 프로덕션 환경에서 완벽하게 작동하는 것으로 확인되면, 사용자 트래픽을 빠르게 전환할 수 있습니다. 이로 인해 서비스 중단 시간이 거의 발생하지 않습니다.
  • 롤백 용이성: 문제가 발생하면 원래의 Blue 환경으로 즉시 되돌릴 수 있으므로 롤백이 간단하고 빠릅니다.

쿠버네티스(Kubernetes)에서 Blue/Green 배포를 구현하는 방법 중 하나는 두 개의 별도의 Deployment를 사용하는 것입니다. 하나의 Deployment는 기존 버전의 애플리케이션을 실행하고 (Blue), 다른 Deployment는 새로운 버전의 애플리케이션을 실행합니다 (Green). 서비스 리소스를 사용하여 두 Deployment의 트래픽을 제어할 수 있습니다. 예를 들어, 로드 밸런싱 규칙을 변경하여 사용자가 새 버전의 애플리케이션에 액세스하도록 구성할 수 있습니다.

Canary 배포와 Blue/Green 배포의 차이점

  • Canary 배포는 일부 사용자에게만 새로운 버전을 노출시키는 반면, Blue/Green 배포는 새 버전을 모든 사용자에게 한 번에 전환합니다.
  • Canary 배포는 새 버전의 성공 여부를 확인하는 데 시간을 점진적으로 확장하는 반면, Blue/Green 배포는 새 버전이 테스트를 통과한 후 빠르게 전환합니다.
  • Canary 배포는 오류 발생 시 영향을 받는 사용자 수를 최소화하는 데 초점을 맞추고, Blue/Green 배포는 즉시 롤백을 통해 문제를 해결하는 데 초점을 맞춥니다.

Blue/Green 배포를 사용하여 업데이트하기

Blue/Green 배포 스타일을 지원하기 위해 새 버전용으로 새로운 'green' 배포를 만들 것입니다. Green 배포에서 버전 라벨과 이미지 경로를 업데이트합니다.

  1. Green 배포를 만듭니다.
  2. Green 배포가 있고 제대로 시작된 경우 현재 1.0.0 버전이 아직 사용되고 있는지 확인합니다.
  3. 이제 서비스가 새 버전을 가리키도록 업데이트합니다.
  4. 서비스가 업데이트되면 'green' 배포가 즉시 사용됩니다. 이제 항상 새 버전이 사용되고 있는지 확인할 수 있습니다.

Blue/Green 롤백

필요한 경우 같은 방법으로 이전 버전으로 롤백할 수 있습니다.
1. 'blue' 배포가 아직 실행 중일 때 서비스를 이전 버전으로 다시 업데이트하면 됩니다.
2. 서비스를 업데이트하면 롤백이 성공적으로 완료됩니다. 사용 중인 버전이 정확한지 다시 확인합니다.

축하합니다. 지금까지 Blue/Green 배포의 개념과 한 번에 버전 전환을 마쳐야 하는 애플리케이션에 업데이트를 배포하는 방법을 알아보았습니다.

순차적 업데이트, Canary 배포, Blue/Green 배포 차이점

  • 순차적 업데이트 (Rolling Update): 기본 전략으로, 리소스 사용을 최적화하고 다운타임을 최소화합니다. 그러나 새 버전에 버그가 있을 경우 모든 사용자가 영향을 받을 수 있습니다.
  • Canary 배포 (Canary Deployment): 일부 사용자에게 먼저 새 버전을 제공하여 전체 사용자에게 미치는 영향을 줄입니다. A/B 테스트나 성능 평가에 유용한 방식입니다.
  • Blue/Green 배포 (Blue/Green Deployment): 동시에 두 개의 독립된 환경에서 실행되어 안전한 배포와 빠른 롤백을 지원합니다. 그러나 리소스 사용량이 많아질 수 있습니다.
profile
Peter
개발자 지망생. 일단 하고보자
이전 포스트

Managing Deployments Using Kubernetes Engine

다음 포스트

Continuous Delivery with Jenkins in Kubernetes Engine

0개의 댓글