클라우드 엔지니어는 기능이 자주 추가되는 중요한 애플리케이션을 유지보수하는 작업을 담당합니다. 사용자 영향 및 애플리케이션 다운타임을 최소화하면서 새로운 기능과 업데이트를 출시해야 합니다. 애플리케이션은 컨테이너화되어 Kubernetes에 배포됩니다. 일부 경우에는 사용자 수요 변화에 따라 수직 확장 및 축소가 필요합니다. 또한 인터넷에서 애플리케이션으로 전송되는 트래픽을 제어해야 합니다. 애플리케이션을 유지보수 및 업데이트할 때 고려할 사항은 다음과 같습니다.

• 클러스터의 배포 매니페스트를 어떻게 만들까요?
• 배포에서 포드 수를 수동으로 확장하려면 어떻게 해야 할까요?
• 애플리케이션에 대한 인바운드 트래픽을 제어하는 서비스를 만들려면 어떻게 해야 할까요?
• 사용자 중단을 최소화하여 업데이트를 출시하려면 어떻게 해야 할까요?
• 전체 출시를 완료하기 전 새 기능을 테스트하기 위해 카나리아 배포를 수행하려면 어떻게 해야 할까?

Azure Kubernetes Service(AKS) 사용에 익숙한 클라우드 전문가는 YAML 매니페스트 파일을 사용하여 AKS에서 Kubernetes 배포를 실행한 경험이 있을 것입니다. DevOps 파이프라인을 사용해서 애플리케이션 코드와 컨테이너를 Kubernetes 클러스터에 제공했을 가능성이 높습니다.

수요에 따라 포드 수를 확장하려면 매니페스트 파일을 수동으로 변경하거나 kubectl 명령어를 사용하면 됩니다. 애플리케이션에 대한 인바운드 트래픽을 제어하기 위해서는 DevOps 파이프라인에서 부하 분산기 배포 계획을 작성하고 실행합니다. 컨테이너 이미지를 업데이트해야 할 경우에는 DevOps 파이프라인을 실행하여 컨테이너 이미지를 제공하고 kubectl 명령어를 사용해서 배포 출시를 트리거합니다.

카나리아 업데이트를 실행하려면 Prometheus를 설치하고, 파이프라인을 구성하고, 매니페스트 파일을 추가하고, 배포 파이프라인을 실행해야 합니다.

이 점을 염두에 두고 이제 배포를 만들고, 확장하고, 업데이트하기 위해 Google Kubernetes Engine(GKE)의 배포 매니페스트를 만드는 방법을 살펴봅니다.

개요

이 실습에서는 배포 매니페스트 사용의 기본사항에 대해 알아봅니다. 매니페스트는 여러 포드에서 사용할 수 있는 배포에 필요한 구성이 포함된 파일입니다. 매니페스트는 간단히 변경할 수 있습니다.

목표

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

• 배포 매니페스트를 만들고, 클러스터에 배포하고, 노드가 비활성화되면 포드 재예약 확인하기
• 배포의 포드 수동 확장 및 축소 트리거하기
• 배포 출시(새 버전으로의 순차적 업데이트) 및 롤백 트리거하기
• 카나리아 배포 수행하기

실습 설정

실습 액세스하기

각 실습에서는 정해진 기간 동안 새 Google Cloud 프로젝트와 리소스 집합이 무료로 제공됩니다.

1. 시크릿 창을 사용하여 Qwiklabs에 로그인합니다.

2. 실습 사용 가능 시간(예: 1:15:00)을 참고하여 해당 시간 내에 완료합니다.
   일시중지 기능은 없습니다. 필요한 경우 다시 시작할 수 있지만 처음부터 시작해야 합니다.

3. 준비가 되면 실습 시작을 클릭합니다.

4. 실습 사용자 인증 정보(사용자 이름 및 비밀번호)를 기록해 두세요. Google Cloud Console에 로그인합니다.

5. Google Console 열기를 클릭합니다.

6. 다른 계정 사용을 클릭한 다음, 안내 메시지에 이 실습에 대한 사용자 인증 정보를 복사하여 붙여넣습니다.
   다른 사용자 인증 정보를 사용하는 경우 오류가 발생하거나 요금이 부과됩니다.

7. 약관에 동의하고 리소스 복구 페이지를 건너뜁니다.

초기 로그인 단계를 완료하면 프로젝트 대시보드가 표시됩니다.

Google Cloud Shell 활성화하기

Google Cloud Shell은 다양한 개발 도구가 탑재된 가상 머신으로, 5GB의 영구 홈 디렉터리를 제공하며 Google Cloud에서 실행됩니다.

Google Cloud Shell을 사용하면 명령줄을 통해 Google Cloud 리소스에 액세스할 수 있습니다.

1. Cloud 콘솔의 오른쪽 상단 툴바에서 'Cloud Shell 열기' 버튼을 클릭합니다.

   

2. 계속을 클릭합니다.

환경을 프로비저닝하고 연결하는 데 몇 분 정도 소요됩니다. 연결되면 사용자가 미리 인증되어 프로젝트가 PROJECT_ID로 설정됩니다. 예:

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

• 다음 명령어를 사용하여 사용 중인 계정 이름을 나열할 수 있습니다.

gcloud auth list

출력:

Credentialed accounts: - @.com (active)

출력 예시:

Credentialed accounts: - google1623327_student@qwiklabs.net

• 다음 명령어를 사용하여 프로젝트 ID를 나열할 수 있습니다.

gcloud config list project

출력:

[core] project =

출력 예시:

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

작업 1. 배포 매니페스트를 만들고 클러스터에 배포하기

이 작업에서는 클러스터 내부의 포드를 위한 배포 매니페스트를 만듭니다.

실습용 GKE 클러스터에 연결

1. Cloud Shell에서 다음 명령어를 입력하여 영역 및 클러스터 이름의 환경 변수를 설정합니다.

export my_zone={{{project_0.default_zone|Zone}}} export my_cluster=standard-cluster-1

2. Cloud Shell에서 kubectl 명령줄 자동 완성을 구성합니다.

source <(kubectl completion bash)

3. Cloud Shell에서 다음 명령어를 사용하여 kubectl 명령줄 도구의 클러스터 액세스를 구성합니다.

gcloud container clusters get-credentials $my_cluster --zone $my_zone

4. Cloud Shell에서 다음 명령어를 입력하여 실습 Cloud Shell에 저장소를 클론합니다.

git clone https://github.com/GoogleCloudPlatform/training-data-analyst

5. 작업 디렉터리로 연결되는 바로가기, 즉 소프트 링크를 생성합니다.

ln -s ~/training-data-analyst/courses/ak8s/v1.1 ~/ak8s

6. 이 실습의 샘플 파일이 포함된 디렉터리로 이동합니다.

cd ~/ak8s/Deployments/

배포 매니페스트 만들기

제공된 샘플 배포 매니페스트인 nginx-deployment.yaml을 사용하여 배포를 만듭니다. 이 배포는 각 포드에 TCP 포트 80에서 수신 대기하는 단일 nginx 컨테이너가 있는 3개의 포드 복제본을 실행하도록 구성됩니다.

apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment labels: app: nginx spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.7.9 ports: - containerPort: 80

1. 매니페스트를 배포하려면 다음 명령어를 실행합니다.

kubectl apply -f ./nginx-deployment.yaml

2. 배포 목록을 보려면 다음 명령어를 실행합니다.

kubectl get deployments

출력은 다음 예와 같이 표시됩니다.

출력:

NAME READY UP-TO-DATE AVAILABLE AGE nginx-deployment 0/3 3 0 3s

3. 몇 초 동안 기다렸다가 명령어에 의해 보고된 CURRENT 배포에 대해 나열된 수가 DESIRED 배포의 수와 일치할 때까지 명령어를 반복 실행합니다.

최종 출력은 다음 예와 같이 표시됩니다.

출력:

NAME READY UP-TO-DATE AVAILABLE AGE nginx-deployment 3/3 3 3 42s

내 진행 상황 확인하기를 클릭하여 목표를 확인합니다. 매니페스트 nginx 배포 생성 및 배포

작업 2. 배포의 포드 수를 수동으로 확장 및 축소하기

포드 인스턴스를 종료하려 할 때가 있고, 10개의 포드를 실행하려 할 때가 있습니다. Kubernetes에서 특정 포드를 원하는 인스턴스 수만큼 확장할 수 있습니다. 인스턴스를 종료하려면 0으로 조정합니다.

이 작업에서는 Google Cloud 콘솔 및 Cloud Shell에서 포드를 확장 및 축소합니다.

콘솔에서 포드 확장 및 축소

1. Google Cloud 콘솔 탭으로 전환합니다.
2. 탐색 메뉴()에서 Kubernetes Engine > 워크로드를 클릭합니다.
3. nginx-deployment(사용자의 배포)를 클릭하여 배포 세부정보 페이지를 엽니다.
4. 상단에서 작업 > 확장 > 복제본 수정을 클릭합니다.
5. 1을 입력하고 확장을 클릭합니다.

이 작업으로 클러스터가 축소됩니다. 관리형 포드 아래에 업데이트 중인 포드 상태가 표시됩니다. 새로고침을 클릭해야 할 수 있습니다.

Cloud Shell에서 포드 확장 및 축소

1. Cloud Shell 브라우저 탭으로 다시 전환합니다.
2. Cloud Shell에서 배포의 포드 목록을 보려면 다음 명령어를 실행합니다.

kubectl get deployments

출력:

NAME READY UP-TO-DATE AVAILABLE AGE nginx-deployment 1/1 1 1 3m

3. 포드 백업을 3개의 복제본으로 확장하려면 다음 명령어를 실행합니다.

kubectl scale --replicas=3 deployment nginx-deployment

4. 배포의 포드 목록을 보려면 다음 명령어를 실행합니다.

kubectl get deployments

출력:

NAME READY UP-TO-DATE AVAILABLE AGE nginx-deployment 3/3 3 3 4m

작업 3. 배포 출시 및 배포 롤백 트리거하기

배포의 출시는 배포의 포드 템플릿(.spec.template)이 변경된 경우에만 트리거됩니다(예: 템플릿의 라벨 또는 컨테이너 이미지가 업데이트된 경우). 배포 확장과 같은 다른 업데이트는 출시를 트리거하지 않습니다.

이 작업에서는 배포 출시를 트리거한 다음 배포 롤백을 트리거합니다.

배포 출시 트리거

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

kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 --record

그러면 배포의 컨테이너 이미지가 nginx v1.9.1로 업데이트됩니다.

2. 출시 상태를 보려면 다음 명령어를 실행합니다.

kubectl rollout status deployment.v1.apps/nginx-deployment

출력은 다음 예와 같이 표시됩니다.

출력:

Waiting for rollout to finish: 1 out of 3 new replicas updated... Waiting for rollout to finish: 1 out of 3 new replicas updated... Waiting for rollout to finish: 1 out of 3 new replicas updated... Waiting for rollout to finish: 2 out of 3 new replicas updated... Waiting for rollout to finish: 2 out of 3 new replicas updated... Waiting for rollout to finish: 2 out of 3 new replicas updated... Waiting for rollout to finish: 1 old replicas pending termination... Waiting for rollout to finish: 1 old replicas pending termination... deployment "nginx-deployment" successfully rolled out

3. 변경된 것을 확인하려면 배포 목록을 가져옵니다.

kubectl get deployments

출력은 다음 예와 같이 표시됩니다.

출력:

NAME READY UP-TO-DATE AVAILABLE AGE nginx-deployment 3/3 3 3 6m

내 진행 상황 확인하기를 클릭하여 목표를 확인합니다. 배포의 nginx 버전 업데이트

4. 배포의 출시 기록을 봅니다.

kubectl rollout history deployment nginx-deployment

출력은 다음 예와 같이 표시됩니다. 출력이 정확히 일치하지 않을 수 있습니다.

출력:

deployments "nginx-deployment" REVISION CHANGE-CAUSE 1 2 kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 --record=true

배포 롤백 트리거

객체의 출시를 롤백하려면 kubectl rollout undo 명령어를 사용하면 됩니다.

1. 이전 버전의 nginx 배포로 롤백하려면 다음 명령어를 실행합니다.

kubectl rollout undo deployments nginx-deployment

2. 배포의 업데이트된 출시 기록을 봅니다.

kubectl rollout history deployment nginx-deployment

출력은 다음 예와 같이 표시됩니다. 출력이 정확히 일치하지 않을 수 있습니다.

출력:

deployments "nginx-deployment" REVISION CHANGE-CAUSE 2 kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 --record=true 3

3. 최신 배포 버전의 세부정보 보기

kubectl rollout history deployment/nginx-deployment --revision=3

출력은 다음 예와 같이 표시됩니다. 출력이 정확히 일치하지 않을 수 있지만 현재 버전이 nginx:1.7.9로 롤백되었다는 것이 표시됩니다.

출력:

deployments "nginx-deployment" with revision #3 Pod Template: Labels: app=nginx pod-template-hash=3123191453 Containers: nginx: Image: nginx:1.7.9 Port: 80/TCP Host Port: 0/TCP Environment: Mounts: Volumes:

작업 4. 매니페스트에서 서비스 유형 정의하기

이 작업에서는 애플리케이션에 대한 인바운드 트래픽을 제어하는 서비스를 만들고 확인합니다. 서비스는 ClusterIP, NodePort 또는 LoadBalancer 유형으로 구성할 수 있습니다. 이 실습에서는 LoadBalancer를 구성합니다.

매니페스트에서 서비스 유형 정의

LoadBalancer 서비스 유형을 배포하는 매니페스트 파일 service-nginx.yaml이 제공되었습니다. 이 서비스는 app: nginx 라벨이 있는 모든 컨테이너의 TCP 포트 60000에서 포트 80으로 인바운드 트래픽을 분산하도록 구성됩니다.

apiVersion: v1 kind: Service metadata: name: nginx spec: type: LoadBalancer selector: app: nginx ports: - protocol: TCP port: 60000 targetPort: 80

• Cloud Shell에서 매니페스트를 배포하려면 다음 명령어를 실행합니다.

kubectl apply -f ./service-nginx.yaml

이 매니페스트는 서비스를 정의하고 선택기에 해당하는 포드에 적용합니다. 이 경우 매니페스트는 작업 1에서 배포한 nginx 컨테이너에 적용됩니다. 이 서비스는 서비스 이후에 생성된 모든 포드를 비롯하여 app: nginx 라벨이 있는 다른 모든 포드에도 적용됩니다.

LoadBalancer 생성 확인

1. nginx 서비스의 세부정보를 보려면 다음 명령어를 실행합니다.

kubectl get service nginx

출력은 다음 예와 같이 표시됩니다.

출력:

NAME CLUSTER_IP EXTERNAL_IP PORT(S) SELECTOR AGE nginx 10.X.X.X X.X.X.X 60000/TCP run=nginx 1m

2. 외부 IP가 표시되면 새 브라우저 탭에서 http://[EXTERNAL_IP]:60000/을 열어 네트워크 부하 분산을 통해 제공되는 서버를 확인합니다.

참고: 서비스의 ExternalIP 필드 값이 채워지는 데 몇 초 정도 걸릴 수 있습니다. 이는 정상적인 현상입니다. 필드가 채워질 때까지 몇 초마다 kubectl get services nginx 명령어를 다시 실행하면 됩니다.

내 진행 상황 확인하기를 클릭하여 목표를 확인합니다. LoadBalancer 서비스 유형을 배포하는 매니페스트 파일 배포

작업 5. 카나리아 배포 수행하기

카나리아 배포는 애플리케이션의 새 버전을 테스트하는 데 사용되는 별도의 배포입니다. 단일 서비스가 카나리아 및 일반 배포 모두를 타겟팅합니다. 또한 사용자의 하위 집합을 카나리아 버전으로 전달하여 새로운 출시의 위험을 완화할 수 있습니다.

제공되는 매니페스트 파일 nginx-canary.yaml은 기본 배포보다 최신 버전의 nginx를 실행하는 단일 포드를 배포합니다. 이 작업에서는 새 배포 파일을 사용하여 카나리아 배포를 만듭니다.

apiVersion: apps/v1 kind: Deployment metadata: name: nginx-canary labels: app: nginx spec: replicas: 1 selector: matchLabels: app: nginx template: metadata: labels: app: nginx track: canary Version: 1.9.1 spec: containers: - name: nginx image: nginx:1.9.1 ports: - containerPort: 80

이전 작업에서 배포한 nginx 서비스의 매니페스트에서는 라벨 선택기를 사용하여 app: nginx 라벨이 있는 포드를 타겟팅합니다. 일반 배포와 새 카나리아 배포에는 모두 app: nginx 라벨이 있습니다. 인바운드 연결은 서비스에 의해 일반 및 카나리아 배포 포드 모두에 배포됩니다. 카나리아 배포에는 일반 배포보다 복제본(포드) 수가 적으므로 일반 배포보다 적은 수의 사용자가 사용할 수 있습니다.

1. 구성 파일을 기반으로 카나리아 배포를 만듭니다.

kubectl apply -f nginx-canary.yaml

2. 배포가 완료되면 nginx 및 nginx-canary 배포가 모두 있는지 확인합니다.

kubectl get deployments

3. 외부 LoadBalancer 서비스 IP에 연결된 브라우저 탭으로 다시 전환하고 페이지를 새로고침합니다. 표준 Welcome to nginx 페이지가 계속 표시됩니다.
4. Cloud Shell로 다시 전환하고 기본 배포를 복제본 0개로 축소합니다.

kubectl scale --replicas=0 deployment nginx-deployment

5. 현재 실행 중인 유일한 복제본이 카나리아 배포인지 확인합니다.

kubectl get deployments

6. 외부 LoadBalancer 서비스 IP에 연결된 브라우저 탭으로 다시 전환하고 페이지를 새로고침합니다. 서비스가 트래픽을 카나리아 배포로 자동 분산하고 있음을 보여주는 표준 Welcome to nginx 페이지가 계속 표시됩니다.

내 진행 상황 확인하기를 클릭하여 목표를 확인합니다. 카나리아 배포 만들기

세션 어피니티

실습에서 사용되는 서비스 구성은 단일 클라이언트의 모든 요청이 항상 동일한 포드에 연결되도록 보장하지 않습니다. 각 요청은 개별적으로 처리되며 일반 nginx 배포 또는 nginx-canary 배포에 연결할 수 있습니다.

카나리아 릴리스의 기능이 크게 변경된 경우 다른 버전 간 전환으로 인해 문제가 발생할 수 있습니다. 이를 방지하려면 클라이언트의 첫 번째 요청이 모든 후속 연결에 사용할 포드를 결정하도록 서비스 사양에서 sessionAffinity 필드를 ClientIP로 설정하면 됩니다.

예를 들면 다음과 같습니다.

apiVersion: v1 kind: Service metadata: name: nginx spec: type: LoadBalancer sessionAffinity: ClientIP selector: app: nginx ports: - protocol: TCP port: 60000 targetPort: 80

요약

이 실습에서는 GKE에서 매니페스트 파일을 사용하여 애플리케이션에 카나리아 업데이트를 배포, 확장, 실행하는 방법을 확인했습니다. 다음은 GKE와 AKS의 주요 유사점과 차이점에 대한 설명입니다.

유사점:

GKE와 EKS는 모두 관리형 Kubernetes 서비스로서, 개발자가 컨테이너화된 애플리케이션을 배포, 관리, 확장할 수 있게 해줍니다.

• Kubernetes 배포를 위한 YAML 파일의 기본 구조와 문법은 GKE와 AKS가 동일합니다.
• AKS와 GKE 모두 kubectl 명령어를 사용합니다.

차이점:

• GKE에서는 AKS 배포에서와 같이 DevOps 파이프라인을 만들 필요 없이 클러스터, 포드, 관리에 대한 속성을 지정할 수 있습니다. 이는 GKE에 매니페스트 파일을 사용한 프로비저닝 작업을 수행하는 데 필요한 백엔드 인프라가 포함되어 있기 때문입니다.

실습 종료하기

실습을 완료하면 실습 종료를 클릭합니다. Google Cloud Skills Boost에서 사용된 리소스를 자동으로 삭제하고 계정을 지웁니다.

실습 경험을 평가할 수 있습니다. 해당하는 별표 수를 선택하고 의견을 입력한 후 제출을 클릭합니다.

별점의 의미는 다음과 같습니다.

• 별표 1개 = 매우 불만족
• 별표 2개 = 불만족
• 별표 3개 = 중간
• 별표 4개 = 만족
• 별표 5개 = 매우 만족

의견을 제공하고 싶지 않다면 대화상자를 닫으면 됩니다.

의견이나 제안 또는 수정할 사항이 있다면 지원 탭을 사용하세요.

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