이 가이드에서는 노드 자동 프로비저닝을 사용하여 멀티 테넌트 Google Kubernetes Engine (GKE) 클러스터를 확장하는 방법과 워크로드 아이덴티티를 사용하여 Cloud Storage 버킷과 같은 리소스에 대한 테넌트 액세스를 제어하는 방법을 보여줍니다. 이 가이드는 개발자 및 설계자를 대상으로 하며 Kubernetes와 GKE에 대한 기본적인 지식이 있다고 가정합니다. 소개가 필요한 경우 GKE 개요를 참조하세요.
클러스터 멀티테넌시는 비용을 줄이거나 전체 테넌트의 작업을 표준화하기 위해 구현하는 경우가 많습니다. 비용 절감을 완전히 실현하려면 클러스터 리소스를 효율적으로 사용하도록 클러스터 크기를 조정해야 합니다. 또한 추가된 클러스터 노드가 적절한 크기인지 확인하여 클러스터가 자동 확장될 때 리소스 낭비를 최소화해야 합니다.
이 가이드에서는 노드 자동 프로비저닝을 사용하여 클러스터를 확장합니다. 노드 자동 프로비저닝을 사용하면 클러스터 리소스 사용을 최적화할 수 있으므로 대기 중인 워크로드에 가장 적합한 클러스터 노드를 추가하여 비용을 관리할 수 있습니다.
목표
- 노드 자동 프로비저닝 및 워크로드 아이덴티티가 사용 설정된 GKE 클러스터를 만듭니다.
- 멀티테넌시의 클러스터를 설정합니다.
- 클러스터에 작업을 제출하여 노드 자동 프로비저닝이 최적화된 크기의 노드를 만들고 삭제하는 방법을 보여줍니다.
- taint와 라벨을 사용하여 각 테넌트의 전용 노드 풀을 만들도록 노드 자동 프로비저닝을 지시합니다.
- 워크로드 아이덴티티를 사용하여 Cloud Storage 버킷과 같은 테넌트별 리소스에 대한 액세스를 제어합니다.
비용
이 문서에서는 비용이 청구될 수 있는 다음과 같은 Google Cloud 구성요소를 사용합니다.
프로젝트 사용량을 기준으로 예상 비용을 산출하려면 가격 계산기를 사용하세요.
시작하기 전에
- Google Cloud 계정에 로그인합니다. Google Cloud를 처음 사용하는 경우 계정을 만들고 Google 제품의 실제 성능을 평가해 보세요. 신규 고객에게는 워크로드를 실행, 테스트, 배포하는 데 사용할 수 있는 $300의 무료 크레딧이 제공됩니다.
-
Google Cloud Console의 프로젝트 선택기 페이지에서 Google Cloud 프로젝트를 선택하거나 만듭니다.
-
Google Cloud Console의 프로젝트 선택기 페이지에서 Google Cloud 프로젝트를 선택하거나 만듭니다.
-
Google Cloud 콘솔에서 Cloud Shell을 활성화합니다.
Google Cloud 콘솔 하단에서 Cloud Shell 세션이 시작되고 명령줄 프롬프트가 표시됩니다. Cloud Shell은 Google Cloud CLI가 사전 설치된 셸 환경으로, 현재 프로젝트의 값이 이미 설정되어 있습니다. 세션이 초기화되는 데 몇 초 정도 걸릴 수 있습니다.
- Cloud Shell에서 GKE용 API와 및 Cloud Build API를 사용 설정합니다.
gcloud services enable container.googleapis.com \ cloudbuild.googleapis.com이 작업은 완료하는 데 몇 분 정도 걸릴 수 있습니다.
환경 준비
이 섹션에서는 이 가이드에서 필요한 코드를 가져오고, 가이드 전반에 사용하는 값으로 환경을 설정합니다.
Cloud Shell에서 이 가이드에 사용할 환경 변수를 정의합니다.
export PROJECT_ID=$(gcloud config get-value project)이 가이드의 코드가 포함된 GitHub 저장소를 클론합니다.
git clone https://github.com/GoogleCloudPlatform/solutions-gke-autoprovisioning저장소 디렉터리로 변경합니다.
cd solutions-gke-autoprovisioningGoogle 프로젝트 ID로 Kubernetes YAML 작업 구성 파일을 업데이트합니다.
sed -i "s/MY_PROJECT/$PROJECT_ID/" manifests/bases/job/base-job.yamlCloud Build 작업을 제출하여 컨테이너 이미지를 빌드합니다.
gcloud builds submit pi/ --tag gcr.io/$PROJECT_ID/generate-pi이미지는 pi 근사치를 생성하는 Go 프로그램입니다. 이 컨테이너 이미지는 나중에 사용합니다.
Cloud Build가 이미지를 프로젝트의 Container Registry로 내보냅니다.
GKE 클러스터 만들기
이 섹션에서는 노드 자동 프로비저닝 및 워크로드 아이덴티티가 사용 설정된 GKE 클러스터를 만듭니다. 클러스터 생성 프로세스의 세부정보는 다음과 같습니다.
- 클러스터의 CPU 및 메모리 한도를 지정합니다. 노드 자동 프로비저닝은 클러스터에서 노드를 추가하거나 삭제할 때 이러한 한도를 준수합니다. 자세한 내용은 GKE 문서의 노드 자동 프로비저닝 사용 설정을 참조하세요.
- 자동 프로비저닝된 노드 풀 내의 노드에서 사용되는 기본 서비스 계정과 범위를 지정합니다. 이 설정을 사용하여 프로비저닝된 노드의 액세스 권한을 제어할 수 있습니다. 자세한 내용은 GKE 문서의 자동 프로비저닝된 노드의 ID 기본값 설정을 참조하세요.
- 사용률을 우선 고려하는 자동 확장 프로필을 설정합니다. 이 프로필은 사용하지 않는 리소스를 최소화하기 위해 클러스터를 빠르게 축소하도록 클러스터 자동 확장 처리에 지시합니다. 이렇게 하면 일괄 워크로드 또는 작업 중심 워크로드의 리소스 효율성에 도움이 될 수 있습니다. 설정은 클러스터의 모든 노드 풀에 적용됩니다.
- 워크로드 풀을 지정하여 워크로드 아이덴티티를 사용 설정합니다.
클러스터를 만들려면 다음 안내를 따르세요.
서비스 계정을 만듭니다.
gcloud iam service-accounts create nap-sa이 서비스 계정은 자동 프로비저닝된 노드에서 사용됩니다.
새 서비스 계정에 Container Registry에서 사용하는 Cloud Storage 버킷에서 이미지를 가져올 수 있는 권한을 부여합니다.
gsutil iam ch \ serviceAccount:nap-sa@$PROJECT_ID.iam.gserviceaccount.com:objectViewer \ gs://artifacts.$PROJECT_ID.appspot.com노드 자동 프로비저닝 및 워크로드 아이덴티티가 사용 설정된 GKE 클러스터를 만듭니다.
gcloud container clusters create multitenant \ --release-channel=regular \ --zone=us-central1-c \ --num-nodes=2 \ --machine-type=n1-standard-2 \ --workload-pool=${PROJECT_ID}.svc.id.goog \ --autoscaling-profile=optimize-utilization \ --enable-autoprovisioning \ --autoprovisioning-service-account=nap-sa@${PROJECT_ID}.iam.gserviceaccount.com \ --autoprovisioning-scopes=\ https://www.googleapis.com/auth/devstorage.read_write,\ https://www.googleapis.com/auth/cloud-platform \ --min-cpu 1 \ --min-memory 1 \ --max-cpu 50 \ --max-memory 256 \ --enable-network-policy \ --enable-ip-alias기본 클러스터 이름과 컴퓨팅 영역을 설정합니다.
gcloud config set container/cluster multitenant gcloud config set compute/zone us-central1-c
멀티테넌시의 클러스터 설정
멀티 테넌트 Software as a service(SaaS) 앱을 실행하는 경우 일반적으로 테넌트를 분리해야 합니다. 테넌트를 분리하면 손상된 테넌트의 손상을 최소화할 수 있습니다. 또한 테넌트에 클러스터 리소스를 균등하게 할당하고 각 테넌트가 소비하는 리소스를 추적할 수 있습니다. Kubernetes는 테넌트 간의 완벽한 보안 격리를 보장하지 않지만 특정 사용 사례에서 충분한 보안성을 발휘하는 기능을 제공합니다. GKE 멀티테넌시 기능에 대한 자세한 내용은 GKE 문서의 개요 및 권장사항 가이드를 참조하세요.
예시 앱에서는 tenant1 및 tenant2라는 두 개의 테넌트를 만듭니다. 각 테넌트와 해당 Kubernetes 리소스를 자체 네임스페이스로 분리합니다.
다른 네임스페이스와의 통신을 차단하여 테넌트 격리를 적용하는 간단한 네트워크 정책을 만듭니다. 나중에 노드 taint 및 nodeSelector 필드를 사용하여 서로 다른 테넌트의 Pod가 동일한 노드에 예약되지 않도록 합니다. 전용 노드에서 테넌트 워크로드를 실행하여 추가적인 분리 수준을 제공할 수 있습니다.
Kustomize를 사용하여 클러스터에 제출하는 Kubernetes 매니페스트를 관리합니다. Kustomize를 사용하면 여러 용도로 YAML 파일을 결합하고 맞춤설정할 수 있습니다.
tenant1의 네임스페이스, 서비스 계정, 네트워크 정책 리소스를 만듭니다.kubectl apply -k manifests/setup/tenant1출력은 다음과 같이 표시됩니다.
namespace/tenant1-ns created serviceaccount/tenant1-ksa created networkpolicy.networking.k8s.io/tenant1-deny-from-other-namespaces created
tenant2의 클러스터 리소스를 만듭니다.kubectl apply -k manifests/setup/tenant2
노드 자동 프로비저닝 동작 확인
GKE 클러스터는 하나 이상의 노드 풀 중 하나로 구성됩니다. 노드 풀에 있는 모든 노드의 머신 유형이 동일합니다. 즉, CPU와 메모리의 양이 동일합니다. 워크로드 리소스 요구사항이 가변적이면 클러스터 내에 서로 다른 머신 유형이 있는 여러 노드 풀을 여러 개 사용하는 것이 좋습니다. 이러한 방식으로 클러스터 자동 확장 처리는 가장 적합한 유형의 노드를 추가할 수 있으므로 리소스 효율성을 높이고 비용을 낮출 수 있습니다. 하지만 많은 노드 풀을 유지보수하면 관리 오버헤드가 추가됩니다. 전용 노드 풀에서 테넌트 워크로드를 실행하려는 경우에도 멀티 테넌트 클러스터에서는 실용적이지 않을 수 있습니다.
대신 노드 자동 프로비저닝을 사용하여 클러스터 자동 확장 처리를 확장할 수 있습니다. 노드 자동 프로비저닝을 사용 설정하면 클러스터 자동 확장 처리가 대기 중인 Pod의 사양에 따라 새 노드 풀을 자동으로 만들 수 있습니다. 따라서 클러스터 자동 확장 처리는 가장 적합한 유형의 노드를 만들 수 있지만 노드 풀을 직접 만들거나 관리할 필요가 없습니다. 노드 자동 프로비저닝을 사용하면 클러스터가 과도하게 프로비저닝되지 않고 효율적으로 자동 확장되므로 비용을 절감할 수 있습니다.
또한 대기 중인 pod에 워크로드 분리 제약조건이 있는 경우 노드 자동 프로비저닝은 제약조건을 충족하는 노드를 만들 수 있습니다. 이렇게 하면 노드 자동 프로비저닝을 사용하여 단일 테넌트만 사용할 노드 풀을 자동으로 만들 수 있습니다.
이 섹션에서는 다양한 작업을 클러스터에 제출하여 노드 자동 프로비저닝의 동작을 확인합니다. 이 작업은 앞에서 만든 generate-pi 이미지를 사용합니다.
간단한 작업 제출
먼저 간단한 작업을 클러스터에 제출합니다. 작업은 테넌트별 제약조건을 지정하지 않습니다. 클러스터에 작업의 CPU 및 메모리 요청을 처리할 충분한 여유 용량이 있습니다. 따라서 작업이 기본 노드 풀의 기존 노드 중 하나로 예약되어야 합니다. 추가 노드가 프로비저닝되지 않습니다.
클러스터의 노드 풀을 나열합니다.
gcloud container node-pools list기본 풀 하나가 표시됩니다.
작업 구성을 콘솔에 출력합니다.
kubectl kustomize manifests/jobs/simple-job/출력은 다음과 같이 표시됩니다.
apiVersion: batch/v1 kind: Job metadata: name: pi-job spec: ...
구성은 노드 taint 또는 선택기를 지정하지 않습니다.
작업을 제출합니다.
kubectl apply -k manifests/jobs/simple-job/클러스터의 노드 풀을 확인합니다.
watch -n 5 gcloud container node-pools list여전히 기본 풀 하나가 표시됩니다. 새 노드 풀이 생성되지 않습니다.
약 30초 후에
Control+C를 눌러 노드 풀 감시를 중지합니다.클러스터의 노드를 확인합니다.
kubectl get nodes -w생성되는 새 노드가 없습니다.
1분 동안 지켜본 후
Control+C를 눌러 중지합니다.클러스터의 작업을 나열합니다.
kubectl get jobs --all-namespaces출력은 다음과 같이 표시됩니다.
NAMESPACE NAME COMPLETIONS DURATION AGE default pi-job 1/1 14s 21m
Completions열의1/1값은 총 1개의 작업 중 1개의 작업이 완료되었음을 나타냅니다.
테넌트별 제약조건이 있는 작업 제출
이 섹션에서는 다른 작업을 제출하여 노드 자동 프로비저닝이 워크로드 분리 제약조건을 확인합니다. 작업 구성에는 테넌트별 노드 선택기 및 테넌트별 톨러레이션(toleration)이 포함됩니다. 선택기의 키-값 쌍과 일치하는 라벨이 있는 노드에만 작업을 예약할 수 있습니다. 톨러레이션(toleration)은 노드에 예약될 수 있는 작업도 제한하는 노드 taint와 함께 작동합니다. 노드 자동 프로비저닝을 사용하는 권장사항은 워크로드 분리에 노드 선택기와 톨러레이션(toleration)을 모두 포함하는 것입니다.
기본 노드 풀에 선택기 제약조건을 충족하는 노드가 없으므로 이 작업을 기본 노드 풀에 예약할 수 없습니다. 따라서 노드 자동 프로비저닝은 선택기 요구사항을 충족하는 노드 라벨이 포함된 새 노드 풀을 만듭니다. 노드 자동 프로비저닝은 작업 구성의 톨러레이션(toleration)과 일치하는 노드에 테넌트별 taint도 추가합니다. 일치하는 톨러레이션(toleration)이 있는 Pod만 풀의 노드에 예약될 수 있으므로 테넌트 워크로드를 추가로 분리할 수 있습니다.
클러스터의 노드 풀을 나열합니다.
gcloud container node-pools list기본 풀 하나가 표시됩니다.
작업 구성을 콘솔에 출력합니다.
kubectl kustomize manifests/jobs/one-tenant/구성에는 테넌트별 노드 선택기 요구사항과 톨러레이션(toleration)이 포함됩니다. 출력은 다음과 같이 표시됩니다.
apiVersion: batch/v1 kind: Job metadata: name: tenant1-pi-job spec: ...
작업을 제출합니다.
kubectl apply -k manifests/jobs/one-tenant/클러스터의 노드 풀을 확인합니다.
watch -n 5 gcloud container node-pools list잠시 후 새 노드 풀이 표시됩니다. 출력은 다음과 같이 표시됩니다.
NAME MACHINE_TYPE DISK_SIZE_GB default-pool n1-standard-2 100 nap-n1-standard-1-15jwludl n1-standard-1 100
노드 풀 이름은 프리픽스
nap-로 시작됩니다. 이는 노드 자동 프로비저닝에 의해 생성되었음을 나타냅니다. 노드 풀 이름에는 풀에 있는 노드의 머신 유형도 포함됩니다(예:n1-standard-1).클러스터의 노드를 확인합니다.
kubectl get nodes -w약 1분 후 목록에 새 노드가 표시됩니다. 노드 이름은
nap-노드 풀 이름을 포함합니다. 새 노드의 초기 상태는Not Ready입니다. 잠시 후 새 노드의 상태가Ready로 변경되어 이제 노드가 대기 중인 작업을 수락할 수 있습니다.노드 감시를 중지하려면
Control+C를 누릅니다.노드 taint를 나열합니다.
kubectl get nodes -o custom-columns=NAME:.metadata.name,TAINTS:.spec.taints새 노드에는 키-값 쌍
tenant: tenant1에 대한NoScheduletaint가 있습니다. 따라서tenant: tenant1에 대한 톨러레이션(toleration)이 있는 Pod만 노드에 예약할 수 있습니다.클러스터의 작업을 확인합니다.
kubectl get jobs -w --all-namespaces잠시 후
tenant1-pi-job이1/1완료로 표시됩니다.작업 감시를 중지하려면
Control+C를 누릅니다.클러스터의 노드 풀을 확인합니다.
watch -n 5 gcloud container node-pools list잠시 후
nap-풀이 삭제되고 클러스터에 다시 기본 노드 풀만 있는 것을 확인할 수 있습니다. 풀 제약조건과 일치하는 대기 중인 작업이 더 이상 없으므로 노드 자동 프로비저닝이nap-노드 풀을 삭제했습니다.노드 풀 감시를 중지하려면
Control+C를 누릅니다.
테넌트 제약조건이 있는 큰 작업 2개 제출
이 섹션에서는 테넌트별 제약조건이 있는 작업 2개를 제출하고 각 작업에 대한 리소스 요청도 늘립니다. 다시 한 번, 이러한 작업은 노드 선택기 제약조건으로 인해 기본 노드 풀에 예약할 수 없습니다. 작업마다 고유한 선택기 제약조건이 있으므로 노드 자동 프로비저닝은 새 노드 풀 2개를 만듭니다. 이렇게 하면 노드 자동 프로비저닝을 사용하여 테넌트 작업을 분리할 수 있습니다. 작업의 리소스 요청 수가 이전 작업에 비해 더 많으므로 노드 자동 프로비저닝은 이전보다 머신 유형이 더 큰 노드 풀을 만듭니다.
클러스터의 노드 풀을 나열합니다.
gcloud container node-pools list기본 풀 하나가 표시됩니다.
결합된 구성을 인쇄합니다.
kubectl kustomize manifests/jobs/two-tenants/이 구성에는 두 개의 개별 작업이 포함됩니다. 각 작업에는 테넌트별 노드 선택기와 내결함성이 있으며 리소스 요청이 증가합니다.
출력은 다음과 같이 표시됩니다.
apiVersion: batch/v1 kind: Job metadata: name: tenant1-larger-pi-job spec: ...
작업을 제출합니다.
kubectl apply -k manifests/jobs/two-tenants/클러스터의 노드 풀을 확인합니다.
watch -n 5 gcloud container node-pools list잠시 후 추가 노드 풀 2개가 표시됩니다. 출력은 다음과 같이 표시됩니다.
NAME MACHINE_TYPE DISK_SIZE_GB default-pool n1-standard-2 100 nap-n1-standard-2-6jxjqobt n1-standard-2 100 nap-n1-standard-2-z3s06luj n1-standard-2 100
노드 풀 이름에는 해당 이름이 노드 자동 프로비저닝에 의해 생성되었음을 나타내는
nap-라는 프리픽스가 붙습니다. 노드 풀 이름에는 풀에 있는 노드의 머신 유형도 포함됩니다(예:n1-standard-2).노드 감시를 중지하려면
Control+C를 누릅니다.클러스터의 노드를 확인합니다.
kubectl get nodes -w약 1분 후에 목록에 새로운 노드 2개가 표시됩니다. 노드 이름에는 연결된
nap-노드 풀의 이름이 포함됩니다. 새 노드의 초기 상태는Not Ready입니다. 잠시 후 새 노드의 상태가Ready로 변경되어 이제 노드가 대기 중인 작업을 수락할 수 있습니다.노드 감시를 중지하려면
Control+C를 누릅니다.노드 taint를 나열합니다.
kubectl get nodes -o custom-columns=NAME:.metadata.name,TAINTS:.spec.taints새 노드는
NoScheduletaint를 갖습니다. 하나는 키-값 쌍이tenant: tenant1, 다른 하나는tenant: tenant2입니다. 해당 테넌트가 있는 pod만 노드에 예약할 수 있습니다.클러스터의 작업을 확인합니다.
kubectl get jobs -w --all-namespaces잠시 후
tenant1-larger-pi-job및tenant2-larger-pi-job가 각각1/1완료로 변경됩니다. 이는 작업이 성공적으로 완료되었다는 의미입니다.작업 감시를 중지하려면
Control+C를 누릅니다.클러스터의 노드 풀을 확인합니다.
watch -n 5 gcloud container node-pools list잠시 후
nap-풀이 둘 다 삭제되고 클러스터에 다시 한번 기본 노드 풀 하나만 있는 것을 볼 수 있습니다. 풀 제약조건과 일치하는 대기 중인 작업이 더 이상 없으므로 노드 자동 프로비저닝은nap-노드 풀을 삭제했습니다.노드 풀 감시를 중지하려면
Control+C를 누릅니다.
Google Cloud 리소스에 대한 액세스 제어
클러스터 내에서 테넌트 분리를 유지하는 것 외에도 일반적으로 Cloud Storage 버킷 또는 Pub/Sub 주제와 같은 Google Cloud 리소스에 대한 테넌트 액세스를 제어하려고 합니다. 예를 들어 테넌트마다 다른 테넌트가 액세스할 수 없는 Cloud Storage 버킷이 필요할 수 있습니다.
워크로드 아이덴티티를 사용하면 Kubernetes 서비스 계정과 Google Cloud 서비스 계정 간의 매핑을 만들 수 있습니다. 그런 다음 적절한 Identity and Access Management(IAM) 역할을 Google Cloud 서비스 계정에 할당할 수 있습니다. 이러한 방식으로 최소 권한의 원칙을 적용하여 테넌트 작업이 할당된 리소스에 액세스할 수 있지만 다른 테넌트가 소유한 리소스에 액세스하지 못하도록 할 수 있습니다.
GKE 워크로드 ID 설정
Kubernetes 서비스 계정과 생성한 Google Cloud 서비스 계정 간의 매핑을 구성합니다.
tenant1에 대한 Google Cloud 서비스 계정을 만듭니다.gcloud iam service-accounts create tenant1-gsatenant1의 Kubernetes 서비스 계정에tenant1의 해당 Google Cloud 서비스 계정을 사용할 수 있는 IAM 권한을 부여합니다.gcloud iam service-accounts add-iam-policy-binding \ tenant1-gsa@${PROJECT_ID}.iam.gserviceaccount.com \ --role roles/iam.workloadIdentityUser \ --member "serviceAccount:${PROJECT_ID}.svc.id.goog[tenant1-ns/tenant1-ksa]"Google Cloud 서비스 계정으로 Kubernetes 서비스 계정에 주석을 달아 서비스 계정 간 매핑을 완료합니다.
kubectl annotate serviceaccount tenant1-ksa -n tenant1-ns \ iam.gke.io/gcp-service-account=tenant1-gsa@${PROJECT_ID}.iam.gserviceaccount.com
Cloud Storage 버킷에 쓰는 작업 제출
이 섹션에서는 특정 Kubernetes 서비스 계정으로 실행되는 작업으로 매핑된 Google Cloud 서비스 계정의 IAM 권한을 사용할 수 있는지 확인합니다.
tenant1을 위한 새 Cloud Storage 버킷을 만듭니다.export BUCKET=tenant1-$PROJECT_ID gsutil mb -b on -l us-central1 gs://$BUCKET버킷 이름의 서픽스로 프로젝트 ID를 사용하여 고유한 이름을 만듭니다.
Cloud Storage 버킷을 사용하도록 작업 구성 파일을 업데이트합니다.
sed -i "s/MY_BUCKET/$BUCKET/" \ manifests/jobs/write-gcs/bucket-write.yamltenant1서비스 계정에 버킷의 객체를 읽고 쓸 수 있는 권한을 부여합니다.gsutil iam ch \ serviceAccount:tenant1-gsa@$PROJECT_ID.iam.gserviceaccount.com:objectAdmin \ gs://$BUCKET작업 구성을 출력합니다.
kubectl kustomize manifests/jobs/write-gcs/출력은 다음과 같이 표시됩니다.
apiVersion: batch/v1 kind: Job metadata: name: tenant1-pi-job-gcs spec: ...
새 버킷 이름은
generate-pi컨테이너에 인수로 전달되며 작업은 적절한tenant1-ksaKubernetes 서비스 계정을 지정합니다.작업을 제출합니다.
kubectl apply -k manifests/jobs/write-gcs/이전 섹션과 같이 노드 자동 프로비저닝은 작업을 실행할 새 노드 풀과 새 노드를 만듭니다.
작업의 pod를 확인합니다.
kubectl get pods -n tenant1-ns -w이 경우에는 노드 풀 대신 Pod를 확인합니다. 여러 상태를 통해 Pod 전환을 확인합니다. 몇 분 후에 상태가
Completed로 변경됩니다. 이 상태는 작업이 성공적으로 완료되었음을 나타냅니다.감시를 중지하려면
Control+C를 누릅니다.파일이 Cloud Storage 버킷에 기록되었는지 확인합니다.
gsutil ls -l gs://$BUCKET파일 하나가 표시됩니다.
정리하려면 작업을 삭제합니다.
kubectl delete job tenant1-pi-job-gcs -n tenant1-ns다음 섹션에서 이 작업을 다시 제출합니다.
IAM 권한 취소
마지막으로 Google Cloud 서비스 계정에서 IAM 권한을 취소하면 매핑된 Kubernetes 서비스 계정이 Cloud Storage 버킷에 액세스할 수 없게 됩니다.
Cloud Storage 버킷에 쓸 수 있는 Google Cloud 서비스 계정의 권한을 취소합니다.
gsutil iam ch -d \ serviceAccount:tenant1-gsa@$PROJECT_ID.iam.gserviceaccount.com:objectAdmin \ gs://$BUCKET이전과 동일한 작업을 제출합니다.
kubectl apply -k manifests/jobs/write-gcs/작업의 pod 상태를 다시 감시합니다.
kubectl get pods -n tenant1-ns -w몇 분 후에 상태가
Error로 변경됩니다. 이 상태는 작업이 실패했음을 나타냅니다. 예상되는 오류입니다. Cloud Storage 버킷에 더 이상 쓰기 권한이 없는 Google Cloud 서비스 계정에 매핑된 Kubernetes 서비스 계정으로 작업이 실행되기 때문입니다.pod 감시를 중지하려면
Control+C를 누릅니다.버킷의 파일을 나열합니다.
gsutil ls -l gs://$BUCKET버킷에 파일 하나가 표시됩니다. 새 파일이 작성되지 않았습니다.
삭제
비용이 청구되지 않도록 하는 가장 쉬운 방법은 튜토리얼에서 만든 Google Cloud 프로젝트를 삭제하는 것입니다.
프로젝트 삭제
- Google Cloud 콘솔에서 리소스 관리 페이지로 이동합니다.
- 프로젝트 목록에서 삭제할 프로젝트를 선택하고 삭제를 클릭합니다.
- 대화상자에서 프로젝트 ID를 입력한 후 종료를 클릭하여 프로젝트를 삭제합니다.
GKE 클러스터 삭제
프로젝트를 삭제하지 않으려면 GKE 클러스터를 삭제합니다.
gcloud container clusters delete multitenant
다음 단계
- GKE 멀티 테넌트 자세히 알아보기
- 클러스터 자동 확장 처리 살펴보기
- Google Cloud에 대한 참조 아키텍처, 다이어그램, 권장사항 살펴보기. Cloud 아키텍처 센터 살펴보기