GSP053

개요
DevOps 업무에는 정기적으로 다수의 배포를 사용하여 '지속적 배포', '블루-그린 배포', '카나리아 배포' 등과 같은 애플리케이션 배포 시나리오를 관리하는 일이 포함됩니다. 이 실습에서는 다양한 이기종 배포를 사용하는 일반적인 시나리오를 수행할 수 있도록 컨테이너를 확장하고 관리하는 방법을 학습합니다.
목표
이 실습에서는 다음 작업을 실행하는 방법을 알아봅니다.
-
kubectl
도구 사용하기
- 배포
yaml
파일 만들기
- 배포 시작, 업데이트, 확장하기
- 배포를 업데이트하고 배포 스타일 알아보기
기본 요건
학습 효과를 극대화하기 위해 이 실습에서는 다음을 권장합니다.
- 다음 Google Cloud Skills Boost 실습 완료:
- Linux 시스템 관리 기술 보유
- DevOps 이론(지속적 배포 개념) 이해
배포 소개
이기종 배포에서는 일반적으로 특정한 기술적 요구 또는 운영상의 요구를 충족하기 위해 2개 이상의 상이한 인프라 환경 또는 리전을 연결합니다. 이기종 배포는 배포 특성에 따라 '하이브리드', '멀티 클라우드' 또는 '퍼블릭-프라이빗'이라고 부릅니다.
이 실습에서 이기종 배포는 여러 리전에 걸친 단일 클라우드 환경이나 다중 퍼블릭 클라우드 환경(멀티 클라우드), 또는 온프레미스와 퍼블릭 클라우드가 조합된 환경(하이브리드 또는 퍼블릭-프라이빗)에 대한 배포를 포함합니다.
배포를 단일 환경 또는 리전에 한정할 경우 다음과 같은 다양한 비즈니스 및 기술적 어려움이 발생할 수 있습니다.
-
여유 리소스 부족: 단일 환경, 특히 온프레미스 환경에서는 프로덕션 요구를 충족시킬 수 있는 컴퓨팅, 네트워킹, 스토리지 리소스가 모자랄 수 있습니다.
-
제한된 지리적 도달범위: 단일 환경에 배포할 경우 지리적으로 서로 멀리 떨어진 사용자들이 하나의 배포에 액세스해야 합니다. 이러한 트래픽은 배포 위치에 도달하기 위해 전 세계를 돌아서 이동하기도 합니다.
-
제한된 가용성: 웹 규모의 트래픽 패턴으로 인해 애플리케이션에서 내결함성과 복원력을 유지하는 데 어려움을 겪을 수 있습니다.
-
공급업체 종속: 공급업체 수준의 플랫폼 및 인프라 추상화로 인해 애플리케이션 포팅이 어려울 수 있습니다.
-
유연하지 않은 리소스: 특정 컴퓨팅, 스토리지 또는 네트워킹 제품군에서만 리소스를 사용할 수 있도록 제한될 수 있습니다.
이기종 배포는 이러한 문제를 해결하는 데 도움이 될 수 있지만, 프로그래매틱하며 결정론적인 프로세스와 절차를 사용해서 아키텍처를 구성해야 합니다. 일회성 또는 임시 배포 절차는 배포 또는 프로세스의 취약성을 높이고 내결함성을 저하시킬 수 있습니다. 임시 프로세스는 데이터 손실 또는 트래픽 누락을 일으킬 수 있습니다. 올바른 배포 프로세스는 반복 가능해야 하며, 입증된 프로비저닝, 구성, 유지 관리 방식을 사용해야 합니다.
이기종 배포를 위한 3가지 일반적인 시나리오는 다음과 같습니다.
- 멀티 클라우드 배포
- 온프레미스 데이터 프론팅
- 지속적 통합/지속적 배포(CI/CD) 프로세스
다음 실습에서는 이기종 배포에 대한 몇 가지 일반적인 사용 사례와 함께 이를 달성하기 위해 Kubernetes 및 기타 인프라 리소스를 사용하는 잘 설계된 접근 방법을 연습합니다.
설정 및 요건
실습 시작 버튼을 클릭하기 전에
다음 안내를 확인하세요. 실습에는 시간 제한이 있으며 일시중지할 수 없습니다. 실습 시작을 클릭하면 타이머가 시작됩니다. 이 타이머는 Google Cloud 리소스를 사용할 수 있는 시간이 얼마나 남았는지를 표시합니다.
실무형 실습을 통해 시뮬레이션이나 데모 환경이 아닌 실제 클라우드 환경에서 실습 활동을 진행할 수 있습니다. 실습 시간 동안 Google Cloud에 로그인하고 액세스하는 데 사용할 수 있는 새로운 임시 사용자 인증 정보가 제공됩니다.
이 실습을 완료하려면 다음을 준비해야 합니다.
- 표준 인터넷 브라우저 액세스 권한(Chrome 브라우저 권장)
참고: 이 실습을 실행하려면 시크릿 모드(권장) 또는 시크릿 브라우저 창을 사용하세요. 개인 계정과 학습자 계정 간의 충돌로 개인 계정에 추가 요금이 발생하는 일을 방지해 줍니다.
- 실습을 완료하기에 충분한 시간(실습을 시작하고 나면 일시중지할 수 없음)
참고: 이 실습에는 학습자 계정만 사용하세요. 다른 Google Cloud 계정을 사용하는 경우 해당 계정에 비용이 청구될 수 있습니다.
실습을 시작하고 Google Cloud 콘솔에 로그인하는 방법
-
실습 시작 버튼을 클릭합니다. 실습 비용을 결제해야 하는 경우 결제 수단을 선택할 수 있는 대화상자가 열립니다.
왼쪽에는 다음과 같은 항목이 포함된 실습 세부정보 창이 있습니다.
- Google Cloud 콘솔 열기 버튼
- 남은 시간
- 이 실습에 사용해야 하는 임시 사용자 인증 정보
- 필요한 경우 실습 진행을 위한 기타 정보
-
Google Cloud 콘솔 열기를 클릭합니다(Chrome 브라우저를 실행 중인 경우 마우스 오른쪽 버튼으로 클릭하고 시크릿 창에서 링크 열기를 선택합니다).
실습에서 리소스가 가동되면 다른 탭이 열리고 로그인 페이지가 표시됩니다.
팁: 두 개의 탭을 각각 별도의 창으로 나란히 정렬하세요.
참고: 계정 선택 대화상자가 표시되면 다른 계정 사용을 클릭합니다.
-
필요한 경우 아래의 사용자 이름을 복사하여 로그인 대화상자에 붙여넣습니다.
{{{user_0.username | "Username"}}}
실습 세부정보 창에서도 사용자 이름을 확인할 수 있습니다.
-
다음을 클릭합니다.
-
아래의 비밀번호를 복사하여 시작하기 대화상자에 붙여넣습니다.
{{{user_0.password | "Password"}}}
실습 세부정보 창에서도 비밀번호를 확인할 수 있습니다.
-
다음을 클릭합니다.
중요: 실습에서 제공하는 사용자 인증 정보를 사용해야 합니다. Google Cloud 계정 사용자 인증 정보를 사용하지 마세요.
참고: 이 실습에 자신의 Google Cloud 계정을 사용하면 추가 요금이 발생할 수 있습니다.
-
이후에 표시되는 페이지를 클릭하여 넘깁니다.
- 이용약관에 동의합니다.
- 임시 계정이므로 복구 옵션이나 2단계 인증을 추가하지 않습니다.
- 무료 체험판을 신청하지 않습니다.
잠시 후 Google Cloud 콘솔이 이 탭에서 열립니다.
참고: Google Cloud 제품 및 서비스에 액세스하려면 탐색 메뉴를 클릭하거나 검색창에 제품 또는 서비스 이름을 입력합니다.
Cloud Shell 활성화
Cloud Shell은 다양한 개발 도구가 탑재된 가상 머신으로, 5GB의 영구 홈 디렉터리를 제공하며 Google Cloud에서 실행됩니다. Cloud Shell을 사용하면 명령줄을 통해 Google Cloud 리소스에 액세스할 수 있습니다.
-
Google Cloud 콘솔 상단에서 Cloud Shell 활성화
를 클릭합니다.
-
다음 창을 클릭합니다.
- Cloud Shell 정보 창을 통해 계속 진행합니다.
- 사용자 인증 정보를 사용하여 Google Cloud API를 호출할 수 있도록 Cloud Shell을 승인합니다.
연결되면 사용자 인증이 이미 처리된 것이며 프로젝트가 학습자의 PROJECT_ID, (으)로 설정됩니다. 출력에 이 세션의 PROJECT_ID를 선언하는 줄이 포함됩니다.
Your Cloud Platform project in this session is set to {{{project_0.project_id | "PROJECT_ID"}}}
gcloud
는 Google Cloud의 명령줄 도구입니다. Cloud Shell에 사전 설치되어 있으며 명령줄 자동 완성을 지원합니다.
- (선택사항) 다음 명령어를 사용하여 활성 계정 이름 목록을 표시할 수 있습니다.
gcloud auth list
-
승인을 클릭합니다.
출력:
ACTIVE: *
ACCOUNT: {{{user_0.username | "ACCOUNT"}}}
To set the active account, run:
$ gcloud config set account `ACCOUNT`
- (선택사항) 다음 명령어를 사용하여 프로젝트 ID 목록을 표시할 수 있습니다.
gcloud config list project
출력:
[core]
project = {{{project_0.project_id | "PROJECT_ID"}}}
참고: gcloud
전체 문서는 Google Cloud에서 gcloud CLI 개요 가이드를 참고하세요.
영역 설정
을 로컬 영역으로 대체하고 다음 명령어를 실행하여 작업할 Google Cloud 영역을 설정합니다.
gcloud config set compute/zone {{{ project_0.default_zone | ZONE }}}
이 실습에서 사용할 샘플 코드 가져오기
- 실습 버킷에서 컨테이너와 배포를 만들고 실행하기 위한 샘플 코드를 가져옵니다.
gcloud storage cp -r gs://spls/gsp053/kubernetes .
cd kubernetes
- 노드 3개가 포함된 클러스터를 만듭니다. 이 작업을 완료하는 데 몇 분 정도 시간이 걸릴 수 있습니다.
gcloud container clusters create bootcamp \
--machine-type e2-small \
--num-nodes 3 \
--scopes "https://www.googleapis.com/auth/projecthosting,storage-rw"
작업 1. 배포 객체에 관해 알아보기
시작하려면 배포 객체를 살펴보세요.
-
kubectl
의 explain
명령어를 통해 배포 객체에 관해 알아볼 수 있습니다.
kubectl explain deployment
-
--recursive
옵션을 사용하여 모든 필드를 볼 수도 있습니다.
kubectl explain deployment --recursive
- 실습을 진행하는 과정에서 explain 명령어를 사용하면 배포 객체의 구조와 개별 필드의 기능을 이해하는 데 도움이 됩니다.
kubectl explain deployment.metadata.name
작업 2. 배포 만들기
-
fortune-app
배포를 만듭니다. 배포 구성 파일을 검사합니다.
cat deployments/fortune-app-blue.yaml
출력:
# orchestrate-with-kubernetes/kubernetes/deployments/fortune-app-blue.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: fortune-app-blue
spec:
replicas: 3
selector:
matchLabels:
app: fortune-app
template:
metadata:
labels:
app: fortune-app
track: stable
version: "1.0.0"
spec:
containers:
- name: fortune-app
# The new, centralized image path
image: "us-central1-docker.pkg.dev/qwiklabs-resources/spl-lab-apps/fortune-service:1.0.0"
ports:
- name: http
containerPort: 8080
...
배포가 3개의 복제본을 생성하고 있으며 여기에 fortune-service 컨테이너 버전 1.0.0을 사용하고 있음을 알 수 있습니다.
-
kubectl create
를 사용하여 배포 객체를 만듭니다.
kubectl create -f deployments/fortune-app-blue.yaml
- 배포를 만들면 생성 여부를 확인할 수 있습니다.
kubectl get deployments
- 배포가 생성되면 Kubernetes에서는 배포용
ReplicaSet
를 만듭니다. 배포용 ReplicaSet
가 생성되었는지 확인할 수 있습니다.
kubectl get replicasets
이름이 fortune-app-blue-xxxxxxx
형식인 ReplicaSet
가 표시됩니다.
- 배포의 일부로 생성된 포드를 확인하세요.
kubectl get pods
- 이제
fortune-app
배포를 외부로 노출하는 서비스를 만듭니다.
kubectl create -f services/fortune-app.yaml
- 외부 IP를 가져온 다음
/version
엔드포인트를 curl하여 fortune-app
과 상호작용합니다.
kubectl get services frontend
참고: 서비스의 External-IP 필드 값이 채워지는 데 몇 초 정도 걸릴 수 있습니다. 이는 정상적인 현상입니다. 필드가 채워질 때까지 몇 초마다 위의 명령어를 다시 실행합니다.
curl http://<EXTERNAL-IP>/version
{"version":"1.0.0"}
을 나타내는 JSON 응답이 반환됩니다.
-
kubectl
의 출력 템플릿 기능을 이용해 curl을 한 줄 명령어로 사용할 수도 있습니다.
curl http://`kubectl get svc fortune-app -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version
완료된 작업 테스트하기
아래의 내 진행 상황 확인하기를 클릭하여 실습 진행 상황을 확인하세요. Kubernetes 클러스터와 fortune-app 배포 및 서비스를 성공적으로 생성하면 평가 점수가 표시됩니다.
Kubernetes 클러스터 및 배포 만들기(fortune-app)
배포 확장하기
이제 배포가 생성되었으므로 확장할 수 있습니다. spec.replicas
필드를 업데이트하면 됩니다.
- replicas 필드를 가장 쉽게 업데이트하는 방법은
kubectl scale
명령어를 사용하는 것입니다.
kubectl scale deployment fortune-app-blue --replicas=5
참고: 새 포드가 모두 시작되기까지 1분 정도 걸릴 수 있습니다.
- 현재
fortune-app-blue
포드가 5개 실행되고 있는지 확인합니다.
kubectl get pods | grep fortune-app-blue | wc -l
- 이제 애플리케이션을 다시 축소합니다.
kubectl scale deployment fortune-app-blue --replicas=3
- 포드 개수가 맞는지 다시 확인합니다.
kubectl get pods | grep fortune-app-blue | wc -l
Kubernetes 배포와 포드 그룹을 관리하고 확장 또는 축소하는 방법을 알아보았습니다.
작업 3. 순차적 업데이트
배포에서 이미지를 새 버전으로 업데이트할 때 순차적 업데이트 메커니즘을 활용할 수 있습니다.
순차적 업데이트 트리거하기
- 순차적 업데이트를 트리거하려면 '그린' 배포의 구성을 적용하기만 하면 됩니다. Kubernetes는 기존 배포(
fortune-app-blue
)를 파악할 수 있을 만큼 스마트하며 새 파일의 변경사항을 기존 배포에 '롤'합니다.
kubectl edit deployment fortune-app-blue
- 편집기에서
image
줄을 찾고 버전 태그를 1.0.0
에서 2.0.0
으로 변경합니다. 키보드에서 i
를 눌러 '삽입 모드'로 들어가 파일을 수정할 수 있습니다.
-
먼저 이미지 태그를 변경합니다.
- 다음 줄을 찾습니다.
image: "us-central1-docker.pkg.dev/qwiklabs-resources/spl-lab-apps/fortune-service:1.0.0"
- 다음을
image: "us-central1-docker.pkg.dev/qwiklabs-resources/spl-lab-apps/fortune-service:2.0.0"
으로 변경합니다.
-
그다음 환경 변수를 업데이트합니다.
-
env
섹션과 APP_VERSION
변수를 찾습니다.
-
value: "1.0.0"
을 value: "2.0.0"
으로 변경
-
편집기를 저장하고 닫습니다. Esc
키를 누른 다음 :wq
를 입력하고 Enter
키를 누르면 됩니다. 이렇게 하면 올바른 배포에 순차적 업데이트가 트리거되고 기록이 제대로 기록됩니다. 이렇게 하면 올바른 배포에 순차적 업데이트가 트리거되고 기록이 제대로 기록됩니다.
-
Kubernetes에서 생성한 새로운 ReplicaSet
를 확인합니다.
kubectl get replicaset
- 출시 기록에 새로운 항목이 표시될 수도 있습니다.
kubectl rollout history deployment/fortune-app-blue
순차적 업데이트 일시중지하기
- 다음 명령어를 실행하여 출시를 일시중지합니다.
kubectl rollout pause deployment/fortune-app-blue
- 현재 출시 상태를 확인합니다.
kubectl rollout status deployment/fortune-app-blue
참고: 상태 명령어는 'deployment "fortune-app-blue" successfully rolled out'을 즉시 보고할 수 있습니다. 이는 예상된 동작이며 일시중지 명령어가 성공했음을 나타냅니다. 버전 업데이트가 완료되었다는 의미는 아닙니다.
- 각 포드의 버전을 확인합니다. 1.0.0 및 2.0.0 포드가 혼합되어 표시되며, 출시가 중간에 일시중지되었음을 확인할 수 있습니다.
for p in $(kubectl get pods -l app=fortune-app -o=jsonpath='{.items[*].metadata.name}'); do echo $p && curl -s http://$(kubectl get pod $p -o=jsonpath='{.status.podIP}')/version; echo; done
-
Ctrl+C
를 눌러 루프를 종료합니다.
순차적 업데이트 재개하기
- 아래와 같이
resume
명령어를 사용하여 출시를 계속 진행합니다.
kubectl rollout resume deployment/fortune-app-blue
- 출시가 완료되면
status
명령어를 실행할 때 다음이 표시됩니다.
kubectl rollout status deployment/fortune-app-blue
업데이트 롤백하기
새 버전에서 버그가 발견되었다고 가정해 보겠습니다.
-
rollout
명령어를 사용하여 이전 버전으로 롤백합니다.
kubectl rollout undo deployment/fortune-app-blue
참고: 롤백이 완료되는 데 잠시 시간이 걸릴 수 있습니다.
- 모든 포드가 버전 1.0.0으로 롤백되었는지 확인합니다.
curl http://`kubectl get svc fortune-app -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version
좋습니다. Kubernetes 배포를 위한 순차적 업데이트를 수행하는 방법을 알아보았습니다.
작업 4. 카나리아 배포
프로덕션 환경에서 일부 사용자를 대상으로 새 배포를 테스트하려면 카나리아 배포를 사용하세요.
카나리아 배포 만들기
- 먼저
fortune-app-canary.yaml
파일을 사용하여 새 버전의 새로운 카나리아 배포를 만듭니다.
cat deployments/fortune-app-canary.yaml
- 이제 카나리아 배포를 만듭니다.
kubectl create -f deployments/fortune-app-canary.yaml
- 카나리아 배포를 만들면 두 가지 배포가 생성됩니다. 다음 명령어로 확인합니다.
kubectl get deployments
fortune-app
서비스에는 fortune-app-blue
(프로덕션) 및 fortune-app-canary
배포 모두의 포드와 일치하는 app: fortune-app
선택기가 있습니다.
카나리아 배포 확인하기
- 서비스에 요청을 보내 제공되는 버전을 확인할 수 있습니다.
for i in {1..10}; do curl -s http://`kubectl get svc fortune-app -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version; echo;
done
- 이 명령어를 여러 번 실행하면 대부분의 요청은 버전 1.0.0에서 처리되고 소규모 하위 집합은 2.0.0에서 처리됨을 알 수 있습니다.
완료된 작업 테스트하기
아래의 내 진행 상황 확인하기를 클릭하여 실습 진행 상황을 확인하세요. 카나리아 배포를 성공적으로 만든 경우 평가 점수가 표시됩니다.
카나리아 배포
작업 5. 블루-그린 배포
블루-그린 배포의 경우 두 개의 개별 배포를 만들고 서비스 선택기를 업데이트하여 배포 간에 트래픽을 전환합니다.
서비스
- 먼저 서비스가 '블루' 버전(1.0.0)만 가리키도록 업데이트합니다.
kubectl apply -f services/fortune-app-blue-service.yaml
블루-그린 배포를 사용한 업데이트
- 이제 버전 2.0.0의 새로운 '그린' 배포를 만듭니다.
kubectl create -f deployments/fortune-app-green.yaml
- 그린 배포가 시작되면 제공되는 현재 버전이 여전히 1.0.0인지 확인합니다.
curl http://`kubectl get svc fortune-app -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version
- 이제 서비스가 새 '그린' 버전을 가리키도록 업데이트합니다.
kubectl apply -f services/fortune-app-green-service.yaml
- 서비스가 업데이트되면 '그린' 배포가 즉시 사용됩니다. 이제 항상 버전 2.0.0이 제공되고 있는지 확인할 수 있습니다.
curl http://`kubectl get svc fortune-app -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version
블루-그린 롤백
- 롤백하려면 '블루' 배포의 서비스 매니페스트를 다시 적용하면 됩니다.
kubectl apply -f services/fortune-app-blue-service.yaml
- 서비스를 업데이트하면 롤백이 성공적으로 완료됩니다. 이제 버전 1.0.0이 사용되고 있는지 확인합니다.
curl http://`kubectl get svc fortune-app -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version
수고하셨습니다. 지금까지 블루-그린 배포의 개념과 한 번에 버전 전환을 마쳐야 하는 애플리케이션에 업데이트를 배포하는 방법을 알아보았습니다.
블루-그린 배포
수고하셨습니다.
kubectl
명령줄 도구, 그리고 YAML 파일에 설정된 여러 가지 배포 구성 스타일을 다양하게 사용하여 배포를 시작하고 업데이트하고 확장해 보았습니다.
Google Cloud 교육 및 자격증
Google Cloud 기술을 최대한 활용하는 데 도움이 됩니다. Google 강의에는 빠른 습득과 지속적인 학습을 지원하는 기술적인 지식과 권장사항이 포함되어 있습니다. 기초에서 고급까지 수준별 학습을 제공하며 바쁜 일정에 알맞은 주문형, 실시간, 가상 옵션이 포함되어 있습니다. 인증은 Google Cloud 기술에 대한 역량과 전문성을 검증하고 입증하는 데 도움이 됩니다.
설명서 최종 업데이트: 2025년 8월 18일
실습 최종 테스트: 2025년 8월 18일
Copyright 2025 Google LLC. All rights reserved. Google 및 Google 로고는 Google LLC의 상표입니다. 기타 모든 회사명 및 제품명은 해당 업체의 상표일 수 있습니다.