GSP053

개요

DevOps 업무에는 정기적으로 다수의 배포를 사용하여 '지속적 배포', '블루-그린 배포', '카나리아 배포' 등과 같은 애플리케이션 배포 시나리오를 관리하는 일이 포함됩니다. 이 실습에서는 다양한 이기종 배포를 사용하는 일반적인 시나리오를 수행할 수 있도록 컨테이너를 확장하고 관리하는 방법을 학습합니다.

목표

이 실습에서는 다음 작업을 실행하는 방법을 알아봅니다.

• kubectl 도구 사용
• 배포 yaml 파일 만들기
• 배포 시작, 업데이트, 확장하기
• 배포를 업데이트하고 배포 스타일 알아보기

기본 요건

학습 효과를 극대화하기 위해 이 실습에서는 다음을 권장합니다.

• 다음 Google Cloud Skills Boost 실습 완료:
  • Docker 소개
  • 노드 Kubernetes 시작
• Linux 시스템 관리 기술을 보유
• DevOps 이론(지속적 배포 개념)을 이해

배포 소개

이기종 배포에서는 일반적으로 특정한 기술적 요구 또는 운영상의 요구를 충족하기 위해 2개 이상의 상이한 인프라 환경 또는 리전을 연결합니다. 이기종 배포는 배포 특성에 따라 '하이브리드', '멀티 클라우드' 또는 '퍼블릭-프라이빗'이라고 부릅니다.

이 실습에서 이기종 배포는 여러 리전에 걸친 단일 클라우드 환경이나 다중 퍼블릭 클라우드 환경(멀티 클라우드), 또는 온프레미스와 퍼블릭 클라우드가 조합된 환경(하이브리드 또는 퍼블릭-프라이빗)에 대한 배포를 포함합니다.

배포를 단일 환경 또는 리전에 한정할 경우 다음과 같은 다양한 비즈니스 및 기술적 어려움이 발생할 수 있습니다.

• 여유 리소스 부족: 단일 환경, 특히 온프레미스 환경에서는 프로덕션 요구를 충족시킬 수 있는 컴퓨팅, 네트워킹, 스토리지 리소스가 모자랄 수 있습니다.
• 제한된 지리적 도달범위: 단일 환경에 배포할 경우 지리적으로 서로 멀리 떨어진 사용자들이 하나의 배포에 액세스해야 합니다. 이러한 트래픽은 배포 위치에 도달하기 위해 전 세계를 돌아서 이동하기도 합니다.
• 제한된 가용성: 웹 규모의 트래픽 패턴으로 인해 애플리케이션에서 내결함성과 탄력성을 유지하는 데 어려움을 겪을 수 있습니다.
• 공급업체 종속: 공급업체 수준의 플랫폼 및 인프라 추상화로 인해 애플리케이션 포팅이 어려울 수 있습니다.
• 유연하지 않은 리소스: 특정 컴퓨팅, 스토리지 또는 네트워킹 제품군에서만 리소스를 사용할 수 있도록 제한될 수 있습니다.

이기종 배포는 이러한 문제를 해결하는 데 도움이 될 수 있지만, 프로그래매틱하며 결정론적인 프로세스와 절차를 사용해서 아키텍처를 구성해야 합니다. 일회성 또는 임시 배포 절차는 배포 또는 프로세스의 취약성을 높이고 내결함성을 저하시킬 수 있습니다. 임시 프로세스는 데이터 손실 또는 트래픽 누락을 일으킬 수 있습니다. 올바른 배포 프로세스는 반복 가능해야 하며, 입증된 프로비저닝, 구성, 유지 관리 방식을 사용해야 합니다.

이기종 배포를 위한 3가지 일반적인 시나리오는 다음과 같습니다.

• 멀티 클라우드 배포
• 온프레미스 데이터 프론팅
• 지속적 통합/지속적 배포(CI/CD) 프로세스

다음 실습에서는 이기종 배포에 대한 몇 가지 일반적인 사용 사례와 함께 이를 달성하기 위해 Kubernetes 및 기타 인프라 리소스를 사용하는 잘 설계된 접근 방법을 연습합니다.

설정 및 요건

실습 시작 버튼을 클릭하기 전에

다음 안내를 확인하세요. 실습에는 시간 제한이 있으며 일시중지할 수 없습니다. 실습 시작을 클릭하면 타이머가 시작됩니다. 이 타이머에는 Google Cloud 리소스를 사용할 수 있는 시간이 얼마나 남았는지 표시됩니다.

실무형 실습을 통해 시뮬레이션이나 데모 환경이 아닌 실제 클라우드 환경에서 직접 실습 활동을 진행할 수 있습니다. 실습 시간 동안 Google Cloud에 로그인하고 액세스하는 데 사용할 수 있는 새로운 임시 사용자 인증 정보가 제공됩니다.

이 실습을 완료하려면 다음을 준비해야 합니다.

• 표준 인터넷 브라우저 액세스 권한(Chrome 브라우저 권장)

참고: 이 실습을 실행하려면 시크릿 모드 또는 시크릿 브라우저 창을 사용하세요. 개인 계정과 학생 계정 간의 충돌로 개인 계정에 추가 요금이 발생하는 일을 방지해 줍니다.

• 실습을 완료하기에 충분한 시간---실습을 시작하고 나면 일시중지할 수 없습니다.

참고: 계정에 추가 요금이 발생하지 않도록 하려면 개인용 Google Cloud 계정이나 프로젝트가 이미 있어도 이 실습에서는 사용하지 마세요.

실습을 시작하고 Google Cloud 콘솔에 로그인하는 방법

1. 실습 시작 버튼을 클릭합니다. 실습 비용을 결제해야 하는 경우 결제 수단을 선택할 수 있는 팝업이 열립니다. 왼쪽에는 다음과 같은 항목이 포함된 실습 세부정보 패널이 있습니다.

   • Google Cloud 콘솔 열기 버튼
   • 남은 시간
   • 이 실습에 사용해야 하는 임시 사용자 인증 정보
   • 필요한 경우 실습 진행을 위한 기타 정보

2. Google Cloud 콘솔 열기를 클릭합니다(Chrome 브라우저를 실행 중인 경우 마우스 오른쪽 버튼으로 클릭하고 시크릿 창에서 링크 열기를 선택합니다).

   실습에서 리소스가 가동되면 다른 탭이 열리고 로그인 페이지가 표시됩니다.

   팁: 두 개의 탭을 각각 별도의 창으로 나란히 정렬하세요.

   참고: 계정 선택 대화상자가 표시되면 다른 계정 사용을 클릭합니다.

3. 필요한 경우 아래의 사용자 이름을 복사하여 로그인 대화상자에 붙여넣습니다.

   {{{user_0.username | "Username"}}}

   실습 세부정보 패널에서도 사용자 이름을 확인할 수 있습니다.

4. 다음을 클릭합니다.

5. 아래의 비밀번호를 복사하여 시작하기 대화상자에 붙여넣습니다.

   {{{user_0.password | "Password"}}}

   실습 세부정보 패널에서도 비밀번호를 확인할 수 있습니다.

6. 다음을 클릭합니다.

   중요: 실습에서 제공하는 사용자 인증 정보를 사용해야 합니다. Google Cloud 계정 사용자 인증 정보를 사용하지 마세요. 참고: 이 실습에 자신의 Google Cloud 계정을 사용하면 추가 요금이 발생할 수 있습니다.

7. 이후에 표시되는 페이지를 클릭하여 넘깁니다.

   • 이용약관에 동의합니다.
   • 임시 계정이므로 복구 옵션이나 2단계 인증을 추가하지 않습니다.
   • 무료 체험판을 신청하지 않습니다.

잠시 후 Google Cloud 콘솔이 이 탭에서 열립니다.

참고: Google Cloud 제품 및 서비스 목록이 있는 메뉴를 보려면 왼쪽 상단의 탐색 메뉴를 클릭합니다.

Cloud Shell 활성화

Cloud Shell은 다양한 개발 도구가 탑재된 가상 머신으로, 5GB의 영구 홈 디렉터리를 제공하며 Google Cloud에서 실행됩니다. Cloud Shell을 사용하면 명령줄을 통해 Google Cloud 리소스에 액세스할 수 있습니다.

1. Google Cloud 콘솔 상단에서 Cloud Shell 활성화 를 클릭합니다.

연결되면 사용자 인증이 이미 처리된 것이며 프로젝트가 PROJECT_ID로 설정됩니다. 출력에 이 세션의 PROJECT_ID를 선언하는 줄이 포함됩니다.

Your Cloud Platform project in this session is set to YOUR_PROJECT_ID

gcloud는 Google Cloud의 명령줄 도구입니다. Cloud Shell에 사전 설치되어 있으며 명령줄 자동 완성을 지원합니다.

2. (선택사항) 다음 명령어를 사용하여 활성 계정 이름 목록을 표시할 수 있습니다.

gcloud auth list

3. 승인을 클릭합니다.

4. 다음과 비슷한 결과가 출력됩니다.

출력:

ACTIVE: * ACCOUNT: student-01-xxxxxxxxxxxx@qwiklabs.net To set the active account, run: $ gcloud config set account `ACCOUNT`

5. (선택사항) 다음 명령어를 사용하여 프로젝트 ID 목록을 표시할 수 있습니다.

gcloud config list project

출력:

[core] project = <project_ID>

출력 예시:

[core] project = qwiklabs-gcp-44776a13dea667a6 참고: gcloud 전체 문서는 Google Cloud에서 gcloud CLI 개요 가이드를 참조하세요.

영역 설정

을 로컬 영역으로 대체하고 다음 명령어를 실행하여 작업할 Google Cloud 영역을 설정합니다.

gcloud config set compute/zone {{{ project_0.default_zone | ZONE }}}

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

1. 컨테이너와 배포를 만들고 실행하기 위한 샘플 코드를 가져옵니다.

gsutil -m cp -r gs://spls/gsp053/orchestrate-with-kubernetes . cd orchestrate-with-kubernetes/kubernetes

2. 노드 3개가 포함된 클러스터를 만듭니다. 이 작업을 완료하는 데 몇 분 정도 시간이 걸릴 수 있습니다.

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

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

시작하려면 배포 객체를 살펴보세요.

1. kubectl의 explain 명령어를 통해 배포 객체에 관해 알아볼 수 있습니다.

kubectl explain deployment

2. --recursive 옵션을 사용하여 모든 필드를 볼 수도 있습니다.

kubectl explain deployment --recursive

3. 실습을 진행하는 과정에서 explain 명령어를 사용하면 배포 객체의 구조와 개별 필드의 기능을 이해하는 데 도움이 됩니다.

kubectl explain deployment.metadata.name

작업 2. 배포 만들기

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

vi deployments/auth.yaml

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

i

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

... containers: - name: auth image: "kelseyhightower/auth:1.0.0" ...

4. auth.yaml 파일을 저장하고 <Esc>를 누른 후 다음을 입력합니다.

:wq

5. <Enter> 키를 누르면 간단한 배포가 생성됩니다. 배포 구성 파일을 검사합니다.

cat deployments/auth.yaml

출력:

apiVersion: apps/v1 kind: Deployment metadata: name: auth spec: replicas: 1 selector: matchLabels: app: auth template: metadata: labels: app: auth track: stable spec: containers: - name: auth image: "kelseyhightower/auth:1.0.0" ports: - name: http containerPort: 80 - name: health containerPort: 81 ...

배포가 하나의 복제본을 생성하고 있으며 여기에 인증 컨테이너 버전 1.0.0을 사용하고 있음을 알 수 있습니다.

kubectl create 명령어를 실행하여 인증 배포를 만들면 배포 매니페스트 데이터를 준수하는 포드 하나가 만들어집니다. 즉, replicas 필드의 숫자를 변경하여 포드 개수를 조정할 수 있습니다.

6. kubectl create를 사용하여 배포 객체를 만듭니다.

kubectl create -f deployments/auth.yaml

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

kubectl get deployments

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

kubectl get replicasets

이름이 auth-xxxxxxx 형식인 ReplicaSet가 표시됩니다.

9. 배포의 일부로 생성된 포드를 확인하세요. ReplicaSet가 생성될 때 Kubernetes에서 포드를 하나 생성합니다.

kubectl get pods

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

10. kubectl create 명령어를 사용하여 인증 서비스를 만듭니다.

kubectl create -f services/auth.yaml

11. hello 배포 만들기와 노출도 위와 동일하게 진행합니다.

kubectl create -f deployments/hello.yaml kubectl create -f services/hello.yaml

12. 한 번 더 프런트엔드 배포를 만들고 노출합니다.

kubectl create secret generic tls-certs --from-file tls/ kubectl create configmap nginx-frontend-conf --from-file=nginx/frontend.conf kubectl create -f deployments/frontend.yaml kubectl create -f services/frontend.yaml 참고: 프런트엔드용 ConfigMap을 만들었습니다.

13. 외부 IP를 가져온 다음 curl 명령어를 사용하여 프런트엔드와 상호작용합니다.

kubectl get services frontend 참고: 서비스의 External-IP 필드 값이 채워지는 데 몇 초 정도 걸릴 수 있습니다. 이는 정상적인 현상입니다. 필드가 채워질 때까지 몇 초마다 위의 명령어를 다시 실행합니다. curl -ks https://<EXTERNAL-IP>

그러면 hello 응답을 받게 됩니다.

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

curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`

완료된 작업 테스트하기

아래의 내 진행 상황 확인하기를 클릭하여 실습 진행 상황을 확인하세요. Kubernetes 클러스터와 인증, Hello, 프런트엔드 배포를 성공적으로 만든 경우 평가 점수가 표시됩니다.

Kubernetes 클러스터 및 배포 만들기(인증, Hello, 프런트엔드)

배포 확장하기

이제 배포가 생성되었으므로 확장할 수 있습니다. spec.replicas 필드를 업데이트하면 됩니다.

1. kubectl explain 명령어를 다시 사용하여 이 필드에 관한 설명을 봅니다.

kubectl explain deployment.spec.replicas

2. replicas 필드를 가장 쉽게 업데이트하는 방법은 kubectl scale 명령어를 사용하는 것입니다.

kubectl scale deployment hello --replicas=5 참고: 새 포드가 모두 시작되기까지 1분 정도 걸릴 수 있습니다.

배포가 업데이트되면 Kubernetes가 연결된 ReplicaSet를 자동으로 업데이트하고 새로운 포드를 시작하여 포드의 총개수를 5로 만듭니다.

3. 현재 hello 포드가 5개 실행되고 있는지 확인합니다.

kubectl get pods | grep hello- | wc -l

4. 이제 애플리케이션을 다시 축소합니다.

kubectl scale deployment hello --replicas=3

5. 포드 개수가 맞는지 다시 확인합니다.

kubectl get pods | grep hello- | wc -l

Kubernetes 배포와 포드 그룹을 관리하고 확장 또는 축소하는 방법을 알아보았습니다.

작업 3. 순차적 업데이트

배포에서 이미지를 새 버전으로 업데이트할 때 순차적 업데이트 메커니즘을 활용할 수 있습니다. 배포가 새 버전으로 업데이트되면 새 ReplicaSet가 생성되고, 이전 ReplicaSet의 복제본이 감소하면서 새 ReplicaSet의 복제본 수가 천천히 증가합니다.

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

1. 배포를 업데이트하려면 다음 명령어를 실행합니다.

kubectl edit deployment hello

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

... containers: image: kelseyhightower/hello:2.0.0 ...

3. 저장 후 종료합니다.

업데이트된 배포가 클러스터에 저장되고 Kubernetes에서 순차적 업데이트가 시작됩니다.

4. Kubernetes에서 생성한 새로운 ReplicaSet를 확인합니다.

kubectl get replicaset

5. 출시 기록에 새로운 항목이 표시될 수도 있습니다.

kubectl rollout history deployment/hello

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

실행 중인 출시에 문제가 발생하면 일시중지하여 업데이트를 중지합니다.

1. 다음 명령어를 실행하여 출시를 일시중지합니다.

kubectl rollout pause deployment/hello

2. 현재 출시 상태를 확인합니다.

kubectl rollout status deployment/hello

3. 포드에서 직접 확인할 수도 있습니다.

kubectl get pods -o jsonpath --template='{range .items[*]}{.metadata.name}{"\t"}{"\t"}{.spec.containers[0].image}{"\n"}{end}'

순차적 업데이트 재개하기

출시가 일시중지되었으므로 일부 포드는 새 버전에 있고 다른 포드는 이전 버전에 있습니다.

1. 아래와 같이 resume 명령어를 사용하여 출시를 계속 진행합니다.

kubectl rollout resume deployment/hello

2. 출시가 완료되면 status 명령어를 실행할 때 다음이 표시됩니다.

kubectl rollout status deployment/hello

출력:

deployment "hello" successfully rolled out

업데이트 롤백하기

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

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

1. rollout 명령어를 사용하여 이전 버전으로 롤백합니다.

kubectl rollout undo deployment/hello

2. 기록에서 롤백을 확인합니다.

kubectl rollout history deployment/hello

3. 마지막으로 모든 포드가 이전 버전으로 롤백되었는지 확인합니다.

kubectl get pods -o jsonpath --template='{range .items[*]}{.metadata.name}{"\t"}{"\t"}{.spec.containers[0].image}{"\n"}{end}'

좋습니다. Kubernetes 배포를 위한 순차적 업데이트를 수행하는 방법과 다운타임 없이 애플리케이션을 업데이트하는 방법을 알아보았습니다.

작업 4. 카나리아 배포

프로덕션 환경에서 일부 사용자를 대상으로 새 배포를 테스트하려면 카나리아 배포를 사용하세요. 카나리아 배포를 사용하면 작은 규모의 일부 사용자에게만 변경사항을 출시하여 신규 출시로 발생할 수 있는 위험을 완화할 수 있습니다.

카나리아 배포 만들기

카나리아 배포는 새 버전이 포함된 별도의 배포와 기존의 안정화된 배포 및 카나리아 배포를 모두 타겟팅하는 서비스로 구성됩니다.

1. 먼저 새 버전의 새로운 카나리아 배포를 만듭니다.

cat deployments/hello-canary.yaml

출력:

apiVersion: apps/v1 kind: Deployment metadata: name: hello-canary spec: replicas: 1 selector: matchLabels: app: hello template: metadata: labels: app: hello track: canary # Use ver 2.0.0 so it matches version on service selector version: 2.0.0 spec: containers: - name: hello image: kelseyhightower/hello:2.0.0 ports: - name: http containerPort: 80 - name: health containerPort: 81 ...

2. 이제 카나리아 배포를 만듭니다.

kubectl create -f deployments/hello-canary.yaml

3. 카나리아 배포를 만들면 hello와 hello-canary라는 두 가지 배포가 생성됩니다. 다음 kubectl 명령어를 사용하여 확인합니다.

kubectl get deployments

hello 서비스에서 app:hello 선택자는 프로덕션 배포 포드와 카나리아 배포 포드 모두와 일치하는 포드를 사용합니다. 그러나 카나리아 배포가 포드 수가 더 적기 때문에 더 적은 수의 사용자에게 표시됩니다.

카나리아 배포 확인하기

1. 다음과 같이 요청을 처리하는 hello 버전을 확인할 수 있습니다.

curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version

2. 이 명령어를 여러 번 실행하면 일부 요청은 hello 1.0.0에서 처리되고 소규모 하위 집합(1/4=25%)은 2.0.0에서 처리됨을 알 수 있습니다.

완료된 작업 테스트하기

아래의 내 진행 상황 확인하기를 클릭하여 실습 진행 상황을 확인하세요. 카나리아 배포를 성공적으로 만든 경우 평가 점수가 표시됩니다.

카나리아 배포

프로덕션 환경의 카나리아 배포 - 세션 어피니티

이 실습에서 Nginx 서비스로 전송된 각 요청은 모두 카나리아 배포에서 처리될 가능성이 있었습니다. 따라서 특정 사용자가 카나리아 배포를 이용하지 않도록 하려면 다른 접근 방식이 필요합니다. 예를 들어, 애플리케이션의 UI가 변경되어 특정 사용자에게 혼동을 주지 않으려는 경우가 있을 수 있습니다. 이와 같은 경우에는 해당 사용자를 한 배포 또는 다른 배포에 '고정'해야 합니다.

서비스와 함께 세션 어피티니를 만들면 동일한 사용자에게 항상 동일한 버전을 제공할 수 있습니다. 아래 예시에서 서비스는 이전과 동일하지만 새로운 sessionAffinity 필드가 추가되고 값이 ClientIP로 설정되었습니다. IP 주소가 동일한 모든 클라이언트는 동일한 버전의 hello 애플리케이션으로 요청을 보내게 됩니다.

kind: Service apiVersion: v1 metadata: name: "hello" spec: sessionAffinity: ClientIP selector: app: "hello" ports: - protocol: "TCP" port: 80 targetPort: 80

이를 테스트하기 위한 환경은 설정하기 어렵기 때문에 여기에서는 테스트할 필요가 없지만, 프로덕션 환경의 카나리아 배포에는 sessionAffinity를 사용할 수 있습니다.

작업 5. 블루-그린 배포

순차적 업데이트는 오버헤드, 성능 영향, 다운타임을 최소화하여 애플리케이션을 배포할 수 있기 때문에 가장 좋은 업데이트 방식입니다. 그러나 새 버전의 배포가 모두 완료된 다음에만 해당 버전을 가리키도록 부하 분산기를 수정하는 것이 도움이 되는 경우가 있습니다. 이 경우에는 블루-그린 배포가 도움이 됩니다.

Kubernetes에서는 이전의 '블루' 버전 배포와 새로운 '그린' 버전 배포를 만들어 이러한 작업을 수행할 수 있습니다. '블루' 버전으로 기존의 hello 배포를 사용합니다. 라우터 역할을 하는 서비스를 통해 배포에 액세스하게 됩니다. 새 '그린' 버전이 실행되면 서비스를 업데이트하여 해당 버전을 사용하도록 전환할 수 있습니다.

참고: 블루-그린 배포의 주요 단점은 애플리케이션을 호스팅하는 데 필요한 리소스가 클러스터에 최소 2배 이상 있어야 한다는 점입니다. 그러므로 애플리케이션의 두 버전을 한 번에 배포하기에 앞서 클러스터에 충분한 리소스가 있는지 확인하세요.

서비스

기존의 hello 서비스를 사용하되 app:hello, version: 1.0.0 선택자를 보유하도록 서비스를 업데이트하세요. 선택자는 기존의 '블루' 배포에 일치하게 되며, '그린' 배포는 다른 버전을 사용하기 때문에 일치하지 않게 됩니다.

• 먼저 서비스를 업데이트합니다.

kubectl apply -f services/hello-blue.yaml 참고: resource service/hello is missing이라는 경고는 자동으로 패치되므로 무시하세요.

블루-그린 배포를 사용한 업데이트

블루-그린 배포 스타일을 지원하기 위해 새 버전용으로 새로운 '그린' 배포를 만들어 보겠습니다. 그러면 이 그린 배포가 버전 라벨과 이미지 경로를 업데이트합니다.

apiVersion: apps/v1 kind: Deployment metadata: name: hello-green spec: replicas: 3 selector: matchLabels: app: hello template: metadata: labels: app: hello track: stable version: 2.0.0 spec: containers: - name: hello image: kelseyhightower/hello:2.0.0 ports: - name: http containerPort: 80 - name: health containerPort: 81 resources: limits: cpu: 0.2 memory: 10Mi livenessProbe: httpGet: path: /healthz port: 81 scheme: HTTP initialDelaySeconds: 5 periodSeconds: 15 timeoutSeconds: 5 readinessProbe: httpGet: path: /readiness port: 81 scheme: HTTP initialDelaySeconds: 5 timeoutSeconds: 1

1. 그린 배포를 만듭니다.

kubectl create -f deployments/hello-green.yaml

2. 그린 배포가 생성되고 제대로 시작되면 현재 1.0.0 버전이 아직 사용되고 있는지 확인합니다.

curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version

3. 이제 서비스가 새 버전을 가리키도록 업데이트합니다.

kubectl apply -f services/hello-green.yaml

4. 서비스가 업데이트되면 '그린' 배포가 즉시 사용됩니다. 이제 항상 새 버전이 사용되고 있음을 확인할 수 있습니다.

curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version

블루-그린 롤백

필요에 따라 동일한 방법을 사용해 이전 버전으로 롤백할 수 있습니다.

1. '블루' 배포가 아직 실행 중일 때 서비스를 이전 버전으로 다시 업데이트하면 됩니다.

kubectl apply -f services/hello-blue.yaml

2. 서비스를 업데이트하면 롤백이 성공적으로 완료됩니다. 올바른 버전이 사용되고 있는지 다시 확인합니다.

curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version

수고하셨습니다. 지금까지 블루-그린 배포의 개념과 한 번에 버전 전환을 마쳐야 하는 애플리케이션에 업데이트를 배포하는 방법을 알아보았습니다.

수고하셨습니다

kubectl 명령줄 도구, 그리고 YAML 파일에 설정된 여러 가지 배포 구성 스타일을 다양하게 사용하여 배포를 시작하고 업데이트하고 확장해 보았습니다. 이 실습 경험을 바탕으로 이제 이러한 기술을 DevOps 작업에 능숙하게 적용할 수 있을 것입니다.

다음 단계/더 학습하기

• Kubernetes를 사용한 배포 패턴

• Google Cloud 문서의 DevOps 솔루션 및 DevOps 가이드

• Kubernetes 웹사이트에서 Kubernetes 커뮤니티 구성원들과 교류하세요.

Google Cloud 교육 및 자격증

Google Cloud 기술을 최대한 활용하는 데 도움이 됩니다. Google 강의에는 빠른 습득과 지속적인 학습을 지원하는 기술적인 지식과 권장사항이 포함되어 있습니다. 기초에서 고급까지 수준별 학습을 제공하며 바쁜 일정에 알맞은 주문형, 실시간, 가상 옵션이 포함되어 있습니다. 인증은 Google Cloud 기술에 대한 역량과 전문성을 검증하고 입증하는 데 도움이 됩니다.

설명서 최종 업데이트: 2024년 4월 2일

실습 최종 테스트: 2023년 8월 14일

Copyright 2025 Google LLC All rights reserved. Google 및 Google 로고는 Google LLC의 상표입니다. 기타 모든 회사명 및 제품명은 해당 업체의 상표일 수 있습니다.