클라우드 설계자의 다중 계층 아키텍처 설계에는 컴퓨팅 레이어가 포함됩니다. 일반적으로 조직의 컴퓨팅 요구사항을 충족하기 위해 컨테이너를 배포합니다. 클라우드 설계자는 다음 사항을 고려하여 설계를 완성합니다.

• Kubernetes를 사용하여 컨테이너를 배포하고 중앙에서 관리하려면 어떻게 해야 할까요?
• 클러스터에서 컨테이너를 그룹화하려면 어떻게 해야 할까요?
• 클러스터가 성능과 효율성에 맞게 최적화되었는지 어떻게 확인할 수 있나요?

Amazon Web Services(AWS)에서 Amazon Elastic Kubernetes Service(EKS)를 통해 컨테이너를 배포합니다. EKS는 Kubernetes를 통해 컨테이너 예약, 애플리케이션 가용성 관리, 클러스터 데이터 저장을 담당하는 Kubernetes 컨트롤 플레인 노드의 가용성과 확장성을 관리합니다. AWS EKS의 컨테이너화된 아키텍처는 다음과 같이 표시됩니다.

이제 컨테이너를 할당할 영역별 Google Kubernetes Engine(GKE) 클러스터를 만드는 방법을 살펴보겠습니다.

개요

이번 실습에서는 각각 하나의 웹 서버를 포함하는 컨테이너 여러 개를 포함하는 Google Kubernetes Engine 클러스터를 만듭니다. 클러스터 앞에 부하 분산기를 배치하고 콘텐츠를 확인해보겠습니다.

목표

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

• Kubernetes Engine을 사용하여 Kubernetes 클러스터 프로비저닝
• kubectl을 사용하여 Docker 컨테이너 배포 및 관리

작업 1. Google Cloud에 로그인

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

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

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

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

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

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

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

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

작업 2. 필요한 API가 사용 설정되어 있는지 확인

1. Google Cloud 프로젝트 이름을 기록해 둡니다. 이 값은 Google Cloud 콘솔의 상단 바에 표시되며, qwiklabs-gcp-에 16진수 숫자가 붙은 형식입니다.

2. Google Cloud 콘솔의 탐색 메뉴()에서 API 및 서비스를 클릭합니다.

3. 사용 설정된 API 목록을 아래로 스크롤하여 다음 API가 모두 사용 설정되어 있는지 확인합니다.

• Kubernetes Engine API
• Container Registry API

둘 중 하나의 API라도 목록에 없으면 상단에서 API 및 서비스 사용 설정을 클릭합니다. 위의 API를 이름으로 검색하고 현재 프로젝트에 각 API를 사용 설정합니다. (위에서 기록한 GCP 프로젝트 이름을 참고하세요.)

작업 3. Kubernetes Engine 클러스터 시작

1. Google Cloud 콘솔의 오른쪽 상단 툴바에서 Cloud Shell 활성화 버튼을 클릭합니다.

   

2. 계속을 클릭합니다.

3. 편의상 Qwiklabs가 할당한 영역을 MY_ZONE이라는 환경 변수에 배치합니다. Cloud Shell 프롬프트에 이 부분 명령어를 입력합니다.

   export MY_ZONE=

   명령어 뒤에 Qwiklabs가 할당한 영역을 입력합니다. 모두 입력하면 전체 명령어는 다음과 같습니다.

   export MY_ZONE=us-central1-a

4. Kubernetes Engine이 관리하는 Kubernetes 클러스터를 시작합니다. 클러스터 이름을 webfrontend로 지정하고 2개의 노드를 실행하도록 구성합니다.

   gcloud container clusters create webfrontend --zone $MY_ZONE --num-nodes 2

   Kubernetes Engine에서 가상 머신을 프로비저닝하므로 클러스터를 생성하는 데 몇 분 정도 걸립니다.

5. 클러스터가 생성되면 kubectl version 명령어를 사용하여 Kubernetes의 설치 버전을 확인합니다.

   kubectl version

   gcloud container clusters create 명령어를 사용하면 kubectl이 자동으로 인증됩니다.

6. GCP 콘솔에서 실행 중인 노드를 확인합니다. 탐색 메뉴()에서 Compute Engine > VM 인스턴스를 클릭합니다.

   이제 Kubernetes 클러스터를 사용할 수 있습니다.

   내 진행 상황 확인하기를 클릭하여 목표를 확인합니다. Kubernetes Engine 클러스터 시작

작업 4. 컨테이너 실행 및 배포

1. Cloud Shell 프롬프트에서 nginx 컨테이너의 단일 인스턴스를 실행합니다. (Nginx는 널리 사용되는 웹 서버입니다.)

   kubectl create deploy nginx --image=nginx:1.17.10

   Kubernetes에서는 모든 컨테이너가 포드에서 실행됩니다. 이러한 kubectl create 명령어 사용으로 Kubernetes가 nginx 컨테이너를 포함하는 단일 포드로 구성된 배포를 만들었습니다. Kubernetes 배포는 지정된 수의 포드를 유지하고 실행 중인 노드 중에 장애가 발생하더라도 계속 실행합니다. 이 명령어에서는 포드 수를 기본값(1)으로 실행했습니다.

2. nginx 컨테이너를 실행하는 포드를 확인합니다.

   kubectl get pods

3. nginx 컨테이너를 인터넷에 노출합니다.

   kubectl expose deployment nginx --port 80 --type LoadBalancer

   Kubernetes에서 공개 IP 주소가 연결된 서비스와 외부 부하 분산기를 만들었습니다. 서비스 수명 동안 IP 주소가 동일하게 유지됩니다. 이 공개 IP 주소로의 네트워크 트래픽은 모두 서비스 뒤에 있는 포드로 라우팅됩니다. 이 경우에는 nginx 포드입니다.

4. 새 서비스를 확인합니다.

   kubectl get services

   표시된 외부 IP 주소를 사용하여 원격으로 nginx 컨테이너를 테스트하고 접속할 수 있습니다.

   서비스에 사용할 External-IP 필드를 채우는 데 몇 초 정도 걸릴 수 있습니다. 이는 정상적인 현상입니다. 필드가 채워질 때까지 몇 초 간격으로 kubectl get services 명령어를 다시 실행하기만 하면 됩니다.

5. 새 웹브라우저 탭을 열고 클러스터의 외부 IP 주소를 주소 표시줄에 붙여넣습니다. Nginx 브라우저의 기본 홈페이지가 표시됩니다.

6. 서비스에서 실행 중인 포드 수를 늘립니다.

   kubectl scale deployment nginx --replicas 3

   애플리케이션의 인기가 더 높아지기 전에 사용할 수 있는 리소스를 늘리고 싶을 때 배포를 늘리면 좋습니다.

7. Kubernetes가 포드 수를 업데이트했는지 확인합니다.

   kubectl get pods

8. 외부 IP 주소가 변경되지 않았는지 확인합니다.

   kubectl get services

9. 클러스터의 외부 IP 주소를 확인했던 웹브라우저 탭으로 돌아갑니다. 페이지를 새로고침하여 nginx 웹 서버가 계속 응답하고 있는지 확인합니다.

내 진행 상황 확인하기를 클릭하여 목표를 확인합니다. 컨테이너 실행 및 배포

수고하셨습니다

이번 실습에서는 Kubernetes Engine에서 Kubernetes 클러스터를 구성했습니다. 애플리케이션을 포함하는 여러 포드로 클러스터를 채우고 애플리케이션을 노출하고 애플리케이션을 확장했습니다.

Kubernetes는 오픈소스이므로 컨테이너화된 환경은 이식성과 적응성이 뛰어납니다. 따라서 Kubernetes 배포는 모든 플랫폼에서 유사합니다.

두 서비스의 유사점과 차이점을 간략하게 살펴보겠습니다.

유사점:

• GKE와 EKS는 모두 관리형 Kubernetes 서비스로, 고객이 클라우드에서 컨테이너화된 애플리케이션을 배포, 관리, 확장할 수 있도록 해줍니다.
• Google Cloud와 AWS 모두 Kubernetes 서비스를 Platform as a Service(PaaS)로 제공합니다.
• GKE 및 EKS는 배포에 YAML 파일을 사용할 수 있습니다.
• GKE와 EKS 모두 컨테이너와 배포에 동일한 원칙을 적용하여 클러스터를 채웁니다.
• GKE와 EKS 모두 kubectl을 사용하여 Docker 컨테이너를 배포하고 관리합니다.

차이점:

• Kubernetes 구현과 관련하여 GKE와 EKS 간에는 상대적으로 차이가 없습니다. 차이는 인프라의 프로비저닝과 서비스 관리에 있습니다.
• Google GKE는 GKE Autopilot 기능을 제공하며 이 기능을 통해 사용자는 기본 인프라를 관리할 필요 없이 최적화된 완전 관리형 Kubernetes 환경을 이용할 수 있습니다. 이 과정에서는 Autopilot 기능을 다루지 않습니다. 자세한 내용은 여기를 참조하세요.

실습 종료하기

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

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

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

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

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

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

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