GSP766

개요

Google Kubernetes Engine(GKE) 클러스터를 기반으로 빌드된 Google Cloud 인프라의 비용 최적화 솔루션을 고려할 때 요금이 청구되는 리소스를 효과적으로 활용하고 있는지 확인하는 것이 중요합니다. 일반적으로 사용자 또는 팀을 일대일 비율로 클러스터에 할당하는 실수를 저지르기 쉬우며 이로 인해 클러스터 급증이 발생합니다.

멀티테넌시 클러스터는 여러 사용자 또는 여러 팀이 격리된 상태로 적당한 양의 리소스를 공유하면서 워크로드에 대해 하나의 클러스터를 공유할 수 있게 해줍니다. 이는 네임스페이스를 만들어 구현할 수 있습니다. 네임스페이스를 사용하면 여러 가상 클러스터가 동일한 물리적 클러스터에 존재할 수 있습니다.

이 실습에서는 리소스 사용률을 최적화하고 사실상 비용을 최적화하기 위해 여러 네임스페이스를 사용하여 멀티 테넌트 클러스터를 설정하는 방법을 알아봅니다.

목표

이 실습에서는 다음 작업을 수행하는 방법을 배웁니다.

• GKE 클러스터에서 여러 네임스페이스 만들기
• 네임스페이스 액세스에 대한 역할 기반 액세스 제어 구성
• 여러 네임스페이스 간에 적당한 양의 리소스를 공유할 수 있도록 Kubernetes 리소스 할당량 구성
• 네임스페이스별 리소스 사용량을 파악할 수 있도록 Monitoring 대시보드 조회 및 구성
• 네임스페이스별 리소스 사용률에 대한 세분화된 측정항목을 파악할 수 있도록 Looker Studio에서 GKE 측정 보고서 생성

설정 및 요건

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

다음 안내를 확인하세요. 실습에는 시간 제한이 있으며 일시중지할 수 없습니다. 실습 시작을 클릭하면 타이머가 시작됩니다. 이 타이머는 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 제품 및 서비스에 액세스하려면 탐색 메뉴를 클릭하거나 검색창에 제품 또는 서비스 이름을 입력합니다.

시작

실습 시작 버튼을 누르면 파란색 실습 리소스 프로비저닝 메시지와 남은 예상 시간이 표시됩니다. 그런 다음 멀티 테넌트 클러스터 관리를 테스트하는 데 사용할 환경이 생성되고 구성됩니다. 약 5분 후에 클러스터가 생성되고, BigQuery 데이터 세트가 복사되며, 팀을 나타내는 서비스 계정이 생성됩니다.

완료되면 더 이상 메시지가 표시되지 않습니다.

이 시작 프로세스가 완료되고 메시지가 삭제될 때까지 기다린 후 실습을 진행하세요.

Cloud Shell 활성화

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

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

2. 다음 창을 클릭합니다.

   • 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에 사전 설치되어 있으며 명령줄 자동 완성을 지원합니다.

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

gcloud auth list

4. 승인을 클릭합니다.

출력:

ACTIVE: * ACCOUNT: {{{user_0.username | "ACCOUNT"}}} To set the active account, run: $ gcloud config set account `ACCOUNT`

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

gcloud config list project

출력:

[core] project = {{{project_0.project_id | "PROJECT_ID"}}} 참고: gcloud 전체 문서는 Google Cloud에서 gcloud CLI 개요 가이드를 참고하세요.

작업 1. 필수 파일 다운로드

1. 이 실습의 일부 단계에서 yaml 파일을 사용하여 Kubernetes 클러스터를 구성합니다. Cloud Shell의 Cloud Storage 버킷에서 이 파일을 다운로드합니다.

gsutil -m cp -r gs://spls/gsp766/gke-qwiklab ~

2. 현재 작업 디렉터리를 gke-qwiklab으로 변경합니다.

cd ~/gke-qwiklab

작업 2. 네임스페이스 확인 및 만들기

• 다음을 실행하여 기본 컴퓨팅 영역을 설정하고 제공된 클러스터 multi-tenant-cluster를 인증합니다.

export ZONE={{{project_0.default_zone|placeholder}}} gcloud config set compute/zone ${ZONE} && gcloud container clusters get-credentials multi-tenant-cluster

기본 네임스페이스

기본적으로 Kubernetes 클러스터에는 4개의 시스템 네임스페이스가 있습니다.

1. 다음을 실행하여 현재 클러스터 네임스페이스의 전체 목록을 가져올 수 있습니다.

kubectl get namespace

출력은 다음과 비슷합니다.

NAME STATUS AGE default Active 5m kube-node-lease Active 5m kube-public Active 5m kube-system Active 5m

• default - 네임스페이스가 별도로 지정되지 않은 경우 사용되는 기본 네임스페이스
• kube-node-lease - 각 클러스터 노드의 하트비트와 연결된 임대 객체를 관리함
• kube-public - 클러스터 전체에서 모든 사용자가 볼 수 있거나 읽을 수 있어야 하는 리소스에 사용됨
• kube-system - Kubernetes 시스템에서 생성된 구성요소에 사용됨

모든 요소가 네임스페이스에 속하는 것은 아닙니다. 예를 들어 노드, 영구 볼륨, 네임스페이스 자체는 네임스페이스에 속하지 않습니다.

2. 다음을 실행하여 네임스페이스 범위 리소스의 전체 목록을 확인합니다.

kubectl api-resources --namespaced=true

전체 목록이 생성될 때 네임스페이스 범위 리소스가 네임스페이스와 연결되어야 합니다. --namespace 플래그를 포함하거나 yaml의 메타데이터 필드에 네임스페이스를 표시하면 이를 연결할 수 있습니다.

3. 네임스페이스의 리소스를 표시하기 위해 kubectl get 하위 명령어를 사용하여 네임스페이스를 지정할 수도 있습니다. 예를 들면 다음과 같습니다.

kubectl get services --namespace=kube-system

이렇게 하면 kube-system 네임스페이스의 모든 서비스가 출력됩니다.

새 네임스페이스 만들기

참고: 추가 네임스페이스를 만들 때 시스템 네임스페이스용으로 예약된 'kube'를 이름의 프리픽스로 추가하지 마세요.

1. team-a 및 team-b의 네임스페이스 2개를 만듭니다.

kubectl create namespace team-a && \ kubectl create namespace team-b

이제 kubectl get namespace의 출력에 2개의 새 네임스페이스가 포함됩니다.

namespace/team-a created namespace/team-b created

--namespace 태그를 지정하면 제공된 네임스페이스에서 클러스터 리소스를 만들 수 있습니다. 배포 또는 포드와 같은 리소스의 이름은 해당 네임스페이스 내에서만 고유하면 됩니다.

2. 예를 들어 다음을 실행하면 team-a 네임스페이스와 team-b 네임스페이스에서 동일한 이름을 사용하는 포드가 배포됩니다.

kubectl run app-server --image=quay.io/centos/centos:9 --namespace=team-a -- sleep infinity && \ kubectl run app-server --image=quay.io/centos/centos:9 --namespace=team-b -- sleep infinity

3. kubectl get pods -A를 사용하여 app-server라는 이름의 포드 2개가 팀 네임스페이스별로 하나씩 있는지 확인합니다.

kubectl get pods -A

출력:

NAMESPACE NAME READY STATUS RESTARTS AGE kube-system event-exporter-gke-8489df9489-k2blq 2/2 Running 0 3m41s kube-system fluentd-gke-fmt4v 2/2 Running 0 113s kube-system fluentd-gke-n9dvn 2/2 Running 0 79s kube-system fluentd-gke-scaler-cd4d654d7-xj78p 1/1 Running 0 3m37s kube-system gke-metrics-agent-4jvn8 1/1 Running 0 3m33s kube-system gke-metrics-agent-b4vvw 1/1 Running 0 3m27s kube-system kube-dns-7c976ddbdb-gtrct 4/4 Running 0 3m41s kube-system kube-dns-7c976ddbdb-k9bgk 4/4 Running 0 3m kube-system kube-dns-autoscaler-645f7d66cf-jwqh5 1/1 Running 0 3m36s kube-system kube-proxy-gke-new-cluster-default-pool-eb9986d5-tpql 1/1 Running 0 3m26s kube-system kube-proxy-gke-new-cluster-default-pool-eb9986d5-znm6 1/1 Running 0 3m33s kube-system l7-default-backend-678889f899-xvt5t 1/1 Running 0 3m41s kube-system metrics-server-v0.3.6-64655c969-jtl57 2/2 Running 0 3m kube-system prometheus-to-sd-d6dpf 1/1 Running 0 3m27s kube-system prometheus-to-sd-rfdlv 1/1 Running 0 3m33s kube-system stackdriver-metadata-agent-cluster-level-79f9ddf6d6-7ck2w 2/2 Running 0 2m56s team-a app-server 1/1 Running 0 33s team-b app-server 1/1 Running 0 33s

내 진행 상황 확인하기를 클릭하여 위 작업을 올바르게 수행했는지 확인합니다. 네임스페이스 만들기

4. kubectl describe를 사용하고 --namespace 태그로 네임스페이스를 지정하여 새로 생성된 각 포드에 대한 추가 세부정보를 확인합니다.

kubectl describe pod app-server --namespace=team-a

5. 한 네임스페이스의 리소스만 사용하여 작업하려면 모든 명령어에 --namespace 플래그를 사용하는 대신 kubectl 컨텍스트에서 한 번만 설정하면 됩니다.

kubectl config set-context --current --namespace=team-a

6. 이후 모든 후속 명령어는 --namespace 플래그를 지정하지 않아도 표시된 네임스페이스에 대해 실행됩니다.

kubectl describe pod app-server

다음 섹션에서는 클러스터를 구성하는 데 도움이 되도록 네임스페이스에 대한 역할 기반 액세스 제어를 구성합니다.

작업 3. 네임스페이스에서 액세스 제어

IAM 역할과 Kubernetes 기본 제공 역할 기반 액세스 제어(RBAC)의 조합 권한을 부여하면 클러스터의 네임스페이스 범위 리소스에 대한 액세스 권한을 프로비저닝할 수 있습니다. IAM 역할은 계정에 프로젝트에 대한 초기 액세스 권한을 부여하고, RBAC 권한은 클러스터의 네임스페이스 범위 리소스(포드, 배포, 서비스 등)에 대한 세분화된 액세스 권한을 부여합니다.

IAM 역할

참고: 프로젝트에서 IAM 역할을 부여하려면 프로젝트 IAM 관리자 역할을 할당해야 합니다. 이는 Qwiklabs 임시 계정에 이미 설정되어 있습니다.

Kubernetes에 대한 액세스 제어를 관리할 때 Identity and Access Management(IAM)를 사용하여 더 높은 조직 및 프로젝트 수준에서 액세스 및 권한을 관리합니다.

IAM에서는 GKE에 대한 액세스 수준을 관리하는 여러 역할을 사용자 및 서비스 계정에 할당할 수 있습니다. RBAC의 세분화된 권한은 IAM에서 이미 제공한 액세스 권한을 기반으로 하며 IAM에서 부여한 액세스 권한을 제한할 수 없습니다. 따라서 멀티 테넌트 네임스페이스 범위 클러스터의 경우 할당된 IAM 역할이 최소한의 액세스 권한을 부여해야 합니다.

다음 표에는 할당할 수 있는 일반적인 GKE IAM 역할이 나와 있습니다.

역할	설명
Kubernetes Engine 관리자	클러스터와 해당 Kubernetes API 객체를 완전히 관리할 수 있는 액세스 권한을 제공합니다. 이 역할이 있는 사용자는 모든 클러스터 및 후속 네임스페이스에서 모든 리소스를 만들고 수정하고 삭제할 수 있습니다.
Kubernetes Engine 개발자	클러스터 내 Kubernetes API 객체에 대한 액세스 권한을 제공합니다. 이 역할이 있는 사용자는 모든 클러스터 및 후속 네임스페이스에서 리소스를 만들고 수정하고 삭제할 수 있습니다.
Kubernetes Engine 클러스터 관리자	클러스터 관리에 대한 액세스 권한을 제공합니다. 이 역할이 있는 사용자는 모든 클러스터를 만들고 수정하고 삭제할 수 있으나 모든 클러스터 또는 후속 네임스페이스 내에서 직접 리소스를 만들거나 수정할 수는 없습니다.
Kubernetes Engine 뷰어	GKE 리소스에 대한 읽기 전용 액세스 권한을 제공합니다. 이 역할이 있는 사용자는 네임스페이스 및 해당 리소스에 대해 읽기 전용 액세스 권한을 가집니다.
Kubernetes Engine 클러스터 뷰어	GKE 클러스터를 가져오고 나열할 수 있는 액세스 권한입니다. 이는 클러스터의 네임스페이스 내 리소스에 액세스해야 하는 모든 사용자에게 필요한 최소한의 역할입니다.

이러한 역할은 대부분 RBAC로 제한하기에는 너무 많은 액세스 권한을 부여하지만, IAM 역할 Kubernetes Engine 클러스터 뷰어는 사용자에게 클러스터 및 네임스페이스 범위 리소스에 대한 액세스 권한만 부여합니다.

실습 프로젝트의 서비스 계정은 team-a 네임스페이스를 사용할 개발자를 나타냅니다.

• 다음을 실행하여 계정에 Kubernetes Engine 클러스터 뷰어 역할을 부여합니다.

gcloud projects add-iam-policy-binding ${GOOGLE_CLOUD_PROJECT} \ --member=serviceAccount:team-a-dev@${GOOGLE_CLOUD_PROJECT}.iam.gserviceaccount.com \ --role=roles/container.clusterViewer

Kubernetes RBAC

클러스터 내 모든 리소스 유형(포드, 서비스, 배포 등)에 대한 액세스 권한은 역할 또는 클러스터 역할에 의해 정의됩니다. 역할만 네임스페이스로 범위를 지정할 수 있습니다. 역할은 리소스와 각 리소스에 허용되는 작업을 나타내지만, 역할 바인딩은 해당 액세스 권한을 할당할 사용자 계정 또는 그룹을 나타냅니다.

현재 네임스페이스에서 역할을 만들려면 리소스 유형과 허용되는 작업 유형을 나타내는 동사를 지정합니다.

1. 단일 규칙이 있는 역할은 kubectl create로 만들 수 있습니다.

kubectl create role pod-reader \ --resource=pods --verb=watch --verb=get --verb=list

여러 규칙이 있는 역할은 yaml 파일을 사용하여 만들 수 있습니다. 예시 파일은 실습 앞부분에서 다운로드한 파일에 포함되어 있습니다.

2. yaml 파일을 검사합니다.

cat developer-role.yaml

샘플 출력:

apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: team-a name: developer rules: - apiGroups: [""] resources: ["pods", "services", "serviceaccounts"] verbs: ["update", "create", "delete", "get", "watch", "list"] - apiGroups:["apps"] resources: ["deployments"] verbs: ["update", "create", "delete", "get", "watch", "list"]

3. 위의 역할을 적용합니다.

kubectl create -f developer-role.yaml

4. team-a-developers serviceaccount와 developer-role 간에 역할 바인딩을 만듭니다.

kubectl create rolebinding team-a-developers \ --role=developer --user=team-a-dev@${GOOGLE_CLOUD_PROJECT}.iam.gserviceaccount.com

역할 바인딩 테스트

1. 서비스 계정을 가장하는 데 사용되는 서비스 계정 키를 다운로드합니다.

gcloud iam service-accounts keys create /tmp/key.json --iam-account team-a-dev@${GOOGLE_CLOUD_PROJECT}.iam.gserviceaccount.com

내 진행 상황 확인하기를 클릭하여 위 작업을 올바르게 수행했는지 확인합니다. 네임스페이스에서 액세스 제어

2. Cloud Shell에서 +를 클릭하여 터미널에서 새 탭을 엽니다.

3. 여기서 다음을 실행하여 서비스 계정을 활성화합니다. 그러면 해당 계정으로 명령어를 실행할 수 있습니다.

gcloud auth activate-service-account --key-file=/tmp/key.json

4. 클러스터의 사용자 인증 정보를 서비스 계정으로 가져옵니다.

export ZONE={{{project_0.default_zone|placeholder}}} gcloud container clusters get-credentials multi-tenant-cluster --zone ${ZONE} --project ${GOOGLE_CLOUD_PROJECT}

5. team-a-dev로 team-a 네임스페이스의 포드를 나열할 수 있음을 확인합니다.

kubectl get pods --namespace=team-a

출력:

NAME READY STATUS RESTARTS AGE app-server 1/1 Running 0 6d

6. 하지만 team-b 네임스페이스의 포드를 나열하는 것은 제한됩니다.

kubectl get pods --namespace=team-b

출력:

Error from server (Forbidden): pods is forbidden: User "team-a-dev@a-gke-project.iam.gserviceaccount.com" cannot list resource "pods" in API group "" in the namespace "team-b": requires one of ["container.pods.list"] permission(s).

7. 첫 번째 Cloud Shell 탭으로 돌아가거나 새 탭을 엽니다.

8. 클러스터 사용자 인증 정보를 갱신하고 컨텍스트를 team-a 네임스페이스로 재설정합니다.

export ZONE={{{project_0.default_zone|placeholder}}} gcloud container clusters get-credentials multi-tenant-cluster --zone ${ZONE} --project ${GOOGLE_CLOUD_PROJECT}

작업 4. 리소스 할당량

클러스터가 멀티 테넌트 환경에서 공유되는 경우 사용자가 자신의 할당량을 초과하여 클러스터 리소스를 사용하지 못하도록 하는 것이 중요합니다. 리소스 할당량 객체(ResourceQuota)는 네임스페이스에서 리소스 소비를 제한하는 제약조건을 정의합니다. 리소스 할당량은 객체 수(포드, 서비스, 스테이트풀(Stateful) 세트 등), 스토리지 리소스의 총합계(영구 볼륨 클레임, 임시 스토리지, 스토리지 클래스 등) 또는 컴퓨팅 리소스의 총합계(CPU 및 메모리)에 대한 한도를 지정할 수 있습니다.

1. 예를 들어 다음은 team-a 네임스페이스에서 허용되는 포드 수 한도를 2로 설정하고 부하 분산기 수 한도를 1로 설정합니다.

kubectl create quota test-quota \ --hard=count/pods=2,count/services.loadbalancers=1 --namespace=team-a

2. team-a 네임스페이스에서 두 번째 포드를 만듭니다.

kubectl run app-server-2 --image=quay.io/centos/centos:9 --namespace=team-a -- sleep infinity

3. 이제 세 번째 포드를 만들어 봅니다.

kubectl run app-server-3 --image=quay.io/centos/centos:9 --namespace=team-a -- sleep infinity

다음 오류가 표시됩니다.

Error from server (Forbidden): pods "app-server-3" is forbidden: exceeded quota: test-quota, requested: count/pods=1, used: count/pods=2, limited: count/pods=2

4. 리소스 할당량에 대한 세부정보는 kubectl describe를 사용하여 확인할 수 있습니다.

kubectl describe quota test-quota --namespace=team-a

출력:

Name: test-quota Namespace: team-a Resource Used Hard -------- ---- ---- count/pods 2 2 count/services.loadbalancers 0 1

여기에서 엄격한 한도 구성 및 현재 사용 중인 수량과 함께 리소스 할당량으로 제한되는 리소스 목록을 확인할 수 있습니다.

5. 다음을 실행하여 포드가 6개로 제한되도록 test-quota를 업데이트합니다.

export KUBE_EDITOR="nano" kubectl edit quota test-quota --namespace=team-a

kubectl에서 할당량을 업데이트하는 데 사용할 yaml 파일을 수정할 수 있습니다. 엄격한 할당량은 spec 아래에 있는 count/pods의 값입니다.

6. spec 아래에 있는 count/pods의 값을 6으로 변경합니다.

apiVersion: v1 kind: ResourceQuota metadata: creationTimestamp: "2020-10-21T14:12:07Z" name: test-quota namespace: team-a resourceVersion: "5325601" selfLink: /api/v1/namespaces/team-a/resourcequotas/test-quota uid: a4766300-29c4-4433-ba24-ad10ebda3e9c spec: hard: count/pods: "6" count/services.loadbalancers: "1" status: hard: count/pods: "5" count/services.loadbalancers: "1" used: count/pods: "2"

7. Ctrl+X, Y, Enter 키를 차례로 눌러 저장하고 종료합니다.

이제 업데이트된 할당량이 출력에 반영됩니다.

kubectl describe quota test-quota --namespace=team-a

출력:

Name: test-quota Namespace: team-a Resource Used Hard -------- ---- ---- count/pods 2 6 count/services.loadbalancers 0 1

CPU 및 메모리 할당량

CPU 및 메모리의 할당량을 설정할 때 요청의 합계(컨테이너가 받도록 보장되는 값) 또는 한도의 합계(컨테이너가 초과할 수 없는 값)에 대한 할당량을 지정할 수 있습니다.

이 실습에서는 클러스터에 각각 2개 코어와 8GB 메모리를 갖춘 e2-standard-2 머신이 4개 있습니다. 클러스터에 대한 샘플 리소스 할당량 yaml 파일이 제공되어 있습니다.

cpu-mem-quota.yaml

apiVersion: v1 kind: ResourceQuota metadata: name: cpu-mem-quota namespace: team-a spec: hard: limits.cpu: "4" limits.memory: "12Gi" requests.cpu: "2" requests.memory: "8Gi"

1. 파일 구성을 적용합니다.

참고: 아직 gke-qwiklab 디렉터리에 있는지 확인하세요. kubectl create -f cpu-mem-quota.yaml

이 할당량을 적용하면 모든 포드의 CPU 및 메모리 요청 합계는 각각 2cpu와 8GiB로 제한되고, 한도 합계는 각각 4cpu와 12GiB로 제한됩니다.

참고: 네임스페이스에 CPU 또는 메모리의 리소스 할당량이 있는 경우 이후 해당 네임스페이스에서 생성되는 모든 컨테이너에는 생성 시 자체 CPU 및 메모리 한도를 정의하거나, 네임스페이스에서 LimitRange로 할당된 기본값이 있어야 합니다.

2. CPU 및 메모리 할당량을 입증하기 위해 cpu-mem-demo-pod.yaml을 사용하여 새 포드를 만듭니다.

cpu-mem-demo-pod.yaml:

apiVersion: v1 kind: Pod metadata: name: cpu-mem-demo namespace: team-a spec: containers: - name: cpu-mem-demo-ctr image: nginx resources: requests: cpu: "100m" memory: "128Mi" limits: cpu: "400m" memory: "512Mi"

3. 파일 구성을 적용합니다.

kubectl create -f cpu-mem-demo-pod.yaml --namespace=team-a

4. 이 포드가 생성되면 다음을 실행하여 할당량에 반영된 CPU 및 메모리의 요청과 한도를 확인합니다.

kubectl describe quota cpu-mem-quota --namespace=team-a

출력:

Name: cpu-mem-quota Namespace: team-a Resource Used Hard -------- ---- ---- limits.cpu 400m 4 limits.memory 512Mi 12Gi requests.cpu 100m 2 requests.memory 128Mi 8Gi

내 진행 상황 확인하기를 클릭하여 위 작업을 올바르게 수행했는지 확인합니다. 리소스 할당량

작업 5. GKE 및 GKE 사용량 측정 모니터링

멀티 테넌트 클러스터는 대부분 각 테넌트의 워크로드 및 리소스 요구사항이 변경될 가능성이 있으므로 리소스 할당량을 조정해야 할 수 있습니다. Monitoring을 사용하면 각 네임스페이스가 사용 중인 리소스를 일반적인 관점에서 확인할 수 있습니다.

GKE 사용량 측정을 사용하면 해당 리소스 사용량을 더욱 자세하게 확인할 수 있고 이후 각 테넌트와 관련된 비용을 더 정확히 파악할 수 있습니다.

Monitoring 대시보드

1. Cloud 콘솔에서 탐색 메뉴() > 모든 제품 보기를 클릭합니다. 모니터링 가능성 섹션에서 모니터링을 클릭합니다.

프로젝트의 작업공간이 구성되는 동안 잠시 기다립니다.

2. 개요 페이지가 나타나면 왼쪽 메뉴에서 대시보드를 선택합니다.

3. 대시보드 개요 페이지에서 GKE를 선택합니다.

GKE 대시보드의 테이블 모음에서 여러 리소스별로 집계된 CPU, 메모리, 디스크 사용률에 관한 자세한 내용을 확인할 수 있습니다.

예를 들어 네임스페이스 테이블은 클러스터의 네임스페이스 각각에 대한 사용률을 보여줍니다.

또한 워크로드 테이블에서 클러스터에서 실행 중인 워크로드의 사용률 데이터도 살펴볼 수 있습니다.

4. 모두 보기를 클릭합니다.

5. 필터 추가 상자에서 네임스페이스 > team-a를 선택합니다.

6. 그런 다음 적용을 클릭합니다.

그러면 team-a 네임스페이스에서 실행 중인 워크로드만 포함하도록 워크로드가 필터링됩니다.

측정항목 탐색기

1. 왼쪽 창에서 측정항목 탐색기를 선택합니다.

2. 측정항목 선택 필드에서 측정항목 드롭다운을 클릭합니다.

3. 리소스 및 측정항목 이름으로 필터링에 Kubernetes 컨테이너를 입력합니다.

4. Kubernetes 컨테이너 > 컨테이너를 클릭합니다.

5. CPU 사용 시간을 선택합니다.

6. 적용을 클릭합니다.

참고: 측정항목 필드에 cp를 입력하면 드롭다운 메뉴에 CPU 사용 시간이 옵션으로 표시됩니다.

7. kube-system 네임스페이스를 제외하려면 필터 섹션에서 필터 추가를 클릭합니다.

8. namespace_name을 라벨로 선택합니다.

9. 비교 조건으로 != (does not equal)을 선택하고 값으로 kube-system을 선택합니다.

10. 그런 다음 집계 드롭다운에서 Sum을 선택하고 기준 드롭다운에서 namespace_name을 선택한 후 확인을 클릭합니다.

    네임스페이스별 컨테이너 CPU 사용 시간을 보여주는 그래프가 표시됩니다.

GKE 사용량 측정

GKE 사용량 측정은 GKE 클러스터 리소스 사용률과 소비를 BigQuery 데이터 세트로 내보내서 Looker Studio를 사용하여 시각화할 수 있게 해줍니다. 이를 통해 리소스 사용량을 더욱 세분화하여 확인할 수 있습니다. 사용량 측정을 사용하면 리소스 할당량과 효율적인 클러스터 구성에 대해 더 많은 정보에 입각한 의사 결정을 내릴 수 있습니다.

참고: GKE 측정항목 데이터가 BigQuery를 채우는 데 몇 시간이 걸릴 수 있으므로 실습 프로젝트에는 시연용으로 시뮬레이션된 리소스 사용량 및 청구 데이터가 있는 BigQuery 데이터 세트가 포함됩니다.

다음 두 개의 데이터 세트가 프로젝트에 추가되었습니다.

cluster_dataset - 클러스터에서 GKE 사용량 측정을 사용 설정하기 전에 수동으로 생성된 데이터 세트입니다. 이 데이터 세트에는 GKE에서 생성된 2개의 테이블(gke_cluster_resource_consumption 및 gke_cluster_resource_usage)이 포함되어 있으며 클러스터 사용량 측정항목으로 지속적으로 업데이트됩니다.

billing_dataset - 청구를 위해 BigQuery 내보내기를 사용 설정하기 전에 수동으로 생성된 데이터 세트입니다. 이 데이터 세트에는 1개의 테이블(gcp_billing_export_v1_xxxx)이 포함되어 있으며 프로젝트의 일일 비용으로 매일 업데이트됩니다.

• 다음을 실행하여 클러스터에서 GKE 사용량 측정을 사용 설정하고 데이터 세트 cluster_dataset를 지정합니다.

export ZONE={{{project_0.default_zone|placeholder}}} gcloud container clusters \ update multi-tenant-cluster --zone ${ZONE} \ --resource-usage-bigquery-dataset cluster_dataset

GKE 비용 분석 테이블 만들기

비용 분석 테이블은 프로젝트의 청구 및 리소스 사용량 테이블에서 생성할 수 있습니다. 이 테이블은 usage_metering_query_template.sql 파일을 사용하여 클러스터 데이터 세트에서 생성됩니다. 이 템플릿은 클러스터 리소스 사용량 이해에서 다운로드할 수 있습니다.

먼저 Cloud Shell에서 몇 가지 환경 변수를 설정합니다.

1. 제공된 청구 테이블의 경로, 제공된 사용량 측정 데이터 세트, 새 비용 분석 테이블의 이름을 설정합니다.

export GCP_BILLING_EXPORT_TABLE_FULL_PATH=${GOOGLE_CLOUD_PROJECT}.billing_dataset.gcp_billing_export_v1_xxxx export USAGE_METERING_DATASET_ID=cluster_dataset export COST_BREAKDOWN_TABLE_ID=usage_metering_cost_breakdown

2. 그런 다음 이 실습을 시작할 때 다운로드한 사용량 측정 쿼리 템플릿의 경로, 생성될 사용량 측정 쿼리의 출력 파일, 데이터의 시작 날짜(데이터의 가장 빠른 날짜는 2020년 10월 26일임)를 지정합니다.

export USAGE_METERING_QUERY_TEMPLATE=~/gke-qwiklab/usage_metering_query_template.sql export USAGE_METERING_QUERY=cost_breakdown_query.sql export USAGE_METERING_START_DATE=2020-10-26

3. 이제 이러한 환경 변수와 쿼리 템플릿을 사용하여 사용량 측정 쿼리를 생성합니다.

sed \ -e "s/\${fullGCPBillingExportTableID}/$GCP_BILLING_EXPORT_TABLE_FULL_PATH/" \ -e "s/\${projectID}/$GOOGLE_CLOUD_PROJECT/" \ -e "s/\${datasetID}/$USAGE_METERING_DATASET_ID/" \ -e "s/\${startDate}/$USAGE_METERING_START_DATE/" \ "$USAGE_METERING_QUERY_TEMPLATE" \ > "$USAGE_METERING_QUERY"

4. 다음 명령어를 실행하여 이전 단계에서 렌더링한 쿼리를 사용하여 비용 분석 테이블을 설정합니다.

bq query \ --project_id=$GOOGLE_CLOUD_PROJECT \ --use_legacy_sql=false \ --destination_table=$USAGE_METERING_DATASET_ID.$COST_BREAKDOWN_TABLE_ID \ --schedule='every 24 hours' \ --display_name="GKE Usage Metering Cost Breakdown Scheduled Query" \ --replace=true \ "$(cat $USAGE_METERING_QUERY)"

5. 데이터 전송은 승인을 위한 링크를 제공해야 합니다. 이를 클릭하고 학습자 계정으로 로그인한 다음 안내에 따라 version_info를 Cloud Shell에 다시 붙여넣습니다.

그러면 전송 구성이 성공적으로 생성되었음을 나타내는 메시지가 반환됩니다.

Looker Studio에서 데이터 소스 만들기

1. Data Studio 데이터 소스 페이지를 엽니다.

2. 왼쪽 상단에서 만들기 > 데이터 소스를 클릭하여 새 데이터 소스를 추가합니다.

먼저 시작하려면 계정 설정을 완료하세요 창이 표시됩니다.

3. 국가를 선택하고 회사 이름을 입력한 다음 확인 상자를 선택하고 계속을 클릭합니다.

4. 임시 실습/계정이므로 이메일 환경설정에서 각각에 대해 아니요를 선택합니다.

5. 계속을 클릭합니다.

Looker Studio에서 지원하는 Google 커넥터 목록이 표시됩니다.

6. 목록에서 BigQuery를 선택합니다.

7. 승인 버튼을 클릭하여 Looker Studio에서 BigQuery 프로젝트에 액세스할 수 있도록 허용합니다.

8. 페이지 왼쪽 상단에서 데이터 소스의 이름을 제목 없는 데이터 소스에서 GKE 사용량으로 바꿉니다.

9. 첫 번째 열에서 커스텀 쿼리를 선택합니다.

10. 프로젝트 열에서 프로젝트 ID를 선택합니다.

11. 커스텀 쿼리 상자에 다음 쿼리를 입력하고 [PROJECT-ID]를 Qwiklabs 프로젝트 ID로 바꿉니다.

SELECT * FROM `[PROJECT-ID].cluster_dataset.usage_metering_cost_breakdown`

12. 연결을 클릭합니다.

내 진행 상황 확인하기를 클릭하여 위 작업을 올바르게 수행했는지 확인합니다. GKE 및 GKE 사용량 측정 모니터링

13. 그런 다음 오른쪽 상단을 클릭합니다.

데이터 소스가 추가되었으므로 이제 이를 사용하여 보고서를 작성해야 합니다.

1. 데이터 소스 페이지 상단에서 보고서 작성을 클릭합니다.

참고: 이때 오류가 발생하면 데이터 전송 작업이 아직 완료되지 않은 것일 수 있습니다. 1분 후에 다시 시도합니다.

데이터 소스에서 새 보고서를 작성할 때 보고서에 데이터를 추가할지 묻는 메시지가 표시됩니다.

2. 보고서에 추가를 클릭합니다.

Data Studio 보고서 작성

이 보고서에서는 BigQuery 테이블을 기반으로 데이터 소스의 사용량 측정항목을 시각화할 수 있습니다.

간단한 테이블부터 시작합니다.

네임스페이스별 비용 분석을 보여주도록 이 테이블을 구성합니다. 테이블을 선택하면 오른쪽 패널에 해당 테이블과 관련된 데이터가 표시됩니다.

1. '자유 형식 레이아웃'을 클릭하거나 차트 추가를 클릭하고 테이블을 선택한 다음 해당 패널에서 다음을 변경합니다.

• 기간 측정기준: usage_start_time
• 측정기준: namespace
• 측정항목: cost

다른 필드는 모두 기본값 그대로 둡니다.

테이블을 네임스페이스 범위 리소스로 제한하려면 필터를 적용하면 됩니다.

2. 데이터 패널의 필터 섹션 아래에서 필터 추가를 클릭합니다. 네임스페이스에 할당되지 않은 리소스를 제외하는 필터를 만듭니다.

3. 저장을 클릭합니다.

4. 필터 추가를 다시 클릭하고 필터 만들기를 클릭하여 데이터를 요청으로 제한하는 두 번째 필터를 만듭니다.

5. 저장을 클릭하여 필터를 적용합니다. 결과 테이블은 다음과 같습니다.

그런 다음 네임스페이스별 비용 분석을 보여주는 원형 차트를 보고서에 추가합니다.

6. 만든 테이블을 마우스 오른쪽 버튼으로 클릭하고 복제를 선택합니다.

7. 보고서의 아무 곳에서나 중복 테이블 객체를 드래그합니다.

8. 그런 다음 구성 패널의 차트 유형 헤더를 클릭합니다.

9. 표시되는 옵션에서 원형 차트 아이콘을 클릭합니다.

결과 원형 차트는 다음과 같습니다.

그런 다음 리소스 유형별 비용 분석을 보여주는 도넛 차트를 추가합니다.

1. 상단 툴바에서 차트 추가를 클릭하고 (도넛)을 선택하여 도넛 차트를 만듭니다.

2. 보고서의 아무 곳에서나 차트를 드래그하고 다음을 사용하여 구성합니다.

• 기간 측정기준: usage_start_time
• 측정기준: resource_name
• 측정항목: cost

3. 필터 추가를 클릭하고 이전 차트에 적용한 2개의 필터를 선택합니다. 결과 도넛 차트는 다음과 같습니다.

4. 네임스페이스별 분석을 추가하려면 상단 툴바에서 컨트롤 추가를 클릭하고 드롭다운 목록을 선택합니다.

5. 도넛 차트 옆으로 드래그하고 다음을 사용하여 구성합니다.

• 기간 측정기준: usage_start_time
• 컨트롤 필드: namespace
• 측정항목: 없음

6. 필터 추가를 클릭합니다.

7. 목록에서 할당되지 않음(namespace 필터)을 선택합니다.

8. 도넛 차트에만 영향을 주도록 컨트롤을 구성하려면 선택기 커서를 사용하여 컨트롤 객체와 도넛 차트를 모두 선택하여 두 객체 주위에 직사각형을 그립니다.

9. 마우스 오른쪽 버튼을 클릭하고 그룹을 선택하여 그룹으로 바인딩합니다.

10. 보고서를 미리 보려면 상단 툴바에서 보기를 클릭합니다.

보기 모드에서는 도넛 차트의 보기를 특정 네임스페이스에 맞게 조정할 수 있습니다.

11. 페이지 상단의 공유 메뉴에서 보고서 다운로드를 클릭하여 전체 보고서의 사본을 PDF 파일로 다운로드합니다.

수고하셨습니다

네임스페이스를 활용하면 클러스터를 멀티 테넌트로 구성하여 리소스 사용률 저하 및 클러스터 급증의 위험을 최소화하고 추가 비용 발생을 방지할 수 있습니다. 또한 Monitoring 및 GKE 측정을 사용하면 네임스페이스별 리소스 사용률을 시각화하여 리소스 할당량 및 클러스터 구성에 대해 더 많은 정보를 기반으로 의사 결정을 내릴 수 있습니다.

다음 단계/더 학습하기

• 클러스터 멀티테넌시 문서
• GKE에서 비용에 최적화된 Kubernetes 애플리케이션을 실행하기 위한 권장사항

Google Cloud 교육 및 자격증

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

설명서 최종 업데이트: 2026년 3월 18일

실습 최종 테스트: 2026년 3월 18일

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