공유 VPC를 사용하여 클러스터 설정

Autopilot Standard

이 가이드에서는 별도의 프로젝트에서 공유 VPC를 사용하는 2개의 Google Kubernetes Engine(GKE) 클러스터를 만드는 방법을 설명합니다. GKE 네트워킹에 대한 일반적인 정보는 네트워크 개요를 참조하세요.

개요

공유 VPC를 사용하면 하나의 프로젝트를 호스트 프로젝트로 지정하고, 서비스 프로젝트라고 부르는 다른 프로젝트를 호스트 프로젝트에 연결할 수 있습니다. 호스트 프로젝트에서 네트워크, 서브넷, 보조 주소 범위, 방화벽 규칙, 기타 네트워크 리소스를 만듭니다. 그런 다음 보조 범위를 포함하여 선택된 서브넷을 서비스 프로젝트와 공유합니다. 서비스 프로젝트에서 실행되는 구성요소는 공유 VPC를 사용해서 다른 서비스 프로젝트에서 실행 중인 구성요소와 통신할 수 있습니다.

Autopilot 클러스터와 영역 및 리전 Standard 클러스터에서 공유 VPC를 사용할 수 있습니다.

공유 VPC를 사용하는 Standard 클러스터는 이전 네트워크를 사용할 수 없으며, VPC 기반 트래픽 라우팅이 사용 설정되어 있어야 합니다. Autopilot 클러스터는 항상 VPC 기반 트래픽 라우팅을 사용 설정합니다.

새 클러스터를 만들 때 공유 VPC를 구성할 수 있습니다. GKE는 기존 클러스터의 공유 VPC 모델로의 변환을 지원하지 않습니다.

공유 VPC를 사용할 때는 특정 할당량 및 제한이 적용됩니다. 예를 들어 프로젝트에 있는 네트워크 수에 대한 할당량이 있고, 호스트 프로젝트에 연결할 수 있는 서비스 프로젝트 수에 대한 제한이 있습니다. 자세한 내용은 할당량 및 제한을 참조하세요.

예시 정보

이 가이드의 예시에서는 공유 VPC 개요에 설명된 것처럼 2계층 웹 애플리케이션을 위한 인프라를 설정합니다.

시작하기 전에

공유 VPC를 사용하여 클러스터 설정을 시작하기 전에

Google Cloud 조직이 있어야 합니다.
조직에 3개의 Google Cloud 프로젝트가 있어야 합니다.
공유 VPC에서 사용하는 다양한 Identity and Access Management(IAM) 역할을 비롯한 공유 VPC 개념에 익숙해져야 합니다. 공유 VPC 관리자가 이 가이드의 태스크를 수행해야 합니다.
조직, 폴더 또는 프로젝트에 적용되는 조직 정책 제약 조건을 이해했는지 확인합니다. 어떤 프로젝트가 공유 VPC 호스트 프로젝트가 될 수 있는지, 어떤 서브넷을 공유할 수 있는지 조직 정책 관리자가 제약 조건을 정의했을 수 있습니다. 자세한 내용은 조직 정책 제약 조건을 참조하세요.

이 가이드의 연습을 수행하기 전에

프로젝트 중 하나를 호스트 프로젝트로 선택합니다.
서비스 프로젝트로 사용할 프로젝트 2개를 선택합니다.

각 프로젝트에는 이름, ID, 번호가 있습니다. 일부 경우에는 이름과 ID가 동일합니다. 이 가이드에서는 다음과 같은 친숙한 이름을 사용하여 프로젝트를 참조합니다.

별칭	프로젝트 ID 자리표시자	프로젝트 번호 자리표시자
호스트 프로젝트	`HOST_PROJECT_ID`	`HOST_PROJECT_NUM`
첫 번째 서비스 프로젝트	`SERVICE_PROJECT_1_ID`	`SERVICE_PROJECT_1_NUM`
두 번째 서비스 프로젝트	`SERVICE_PROJECT_2_ID`	`SERVICE_PROJECT_2_NUM`

프로젝트 ID 및 번호 찾기

gcloud CLI 또는 Google Cloud Console을 사용하여 프로젝트 ID 및 번호를 찾을 수 있습니다.

콘솔

Google Cloud Console의 홈페이지로 이동합니다.

홈페이지로 이동
프로젝트 선택기에서 호스트 프로젝트로 선택한 프로젝트를 선택합니다.
프로젝트 정보에서 프로젝트 이름, 프로젝트 ID, 프로젝트 번호를 볼 수 있습니다. 나중을 위해 ID와 번호를 기록해 둡니다.
서비스 프로젝트로 선택한 각 프로젝트의 동일한 작업을 수행합니다.

gcloud

다음 명령어를 사용하여 프로젝트를 나열합니다.

gcloud projects list

출력에 프로젝트 이름, ID, 번호가 표시됩니다. 나중을 위해 ID와 번호를 기록해 둡니다.

PROJECT_ID        NAME        PROJECT_NUMBER
host-123          host        1027xxxxxxxx
srv-1-456         srv-1       4964xxxxxxxx
srv-2-789         srv-2       4559xxxxxxxx

프로젝트에서 GKE API 사용 설정

이 가이드의 연습을 계속하기 전에 프로젝트 3개 모두에서 GKE API가 사용 설정되었는지 확인합니다. 프로젝트에서 API를 사용 설정하면 해당 프로젝트에 대한 GKE 서비스 계정이 생성됩니다. 이 가이드의 나머지 태스크를 수행하기 위해서는 각 프로젝트에 GKE 서비스 계정이 있어야 합니다.

Google Cloud 콘솔 또는 Google Cloud CLI를 사용하여 GKE API를 사용 설정할 수 있습니다.

콘솔

Google Cloud 콘솔의 API 및 서비스 페이지로 이동합니다.

API 및 서비스로 이동합니다.
프로젝트 선택기에서 호스트 프로젝트로 선택한 프로젝트를 선택합니다.
Kubernetes Engine API가 API 목록에 있으면 이미 사용 설정된 것이므로 아무 것도 수행할 필요가 없습니다. 목록에 없으면 API 및 서비스 사용을 클릭합니다. Kubernetes Engine API를 검색합니다. Kubernetes Engine API 카드를 클릭하고 사용을 클릭합니다.
서비스 프로젝트로 선택한 프로젝트마다 이 단계를 반복합니다. 각 작업을 완료하려면 시간이 걸릴 수 있습니다.

gcloud

3개의 프로젝트에 GKE API를 사용 설정합니다. 각 작업을 완료하려면 시간이 걸릴 수 있습니다.

gcloud services enable container.googleapis.com --project HOST_PROJECT_ID
gcloud services enable container.googleapis.com --project SERVICE_PROJECT_1_ID
gcloud services enable container.googleapis.com --project SERVICE_PROJECT_2_ID

네트워크 및 2개의 서브넷 만들기

이 섹션에서는 다음 태스크를 수행합니다.

호스트 프로젝트에서 이름이 shared-net인 네트워크를 만듭니다.
tier-1과 tier-2라는 2개의 서브넷을 만듭니다.
서비스 및 포드를 위해 각각 하나씩 총 2개의 보조 주소 범위를 각 서브넷에 만듭니다.

콘솔

Google Cloud 콘솔에서 VPC 네트워크 페이지로 이동합니다.

VPC 네트워크로 이동
프로젝트 선택기에서 호스트 프로젝트를 선택합니다.
VPC 네트워크 만들기를 클릭합니다.
이름에 shared-net를 입력합니다.
서브넷 생성 모드 아래에서 커스텀을 선택합니다.
새 서브넷 상자의 이름에 tier-1을 입력합니다.
리전에서 리전을 선택합니다.
IP 스택 유형에서 IPv4(단일 스택)를 선택합니다.
IPv4 범위에 10.0.4.0/22를 입력합니다.
보조 IPv4 범위 만들기를 클릭합니다. 서브넷 범위 이름에 tier-1-services를 입력하고, 보조 IPv4 범위에 10.0.32.0/20를 입력합니다.
IP 범위 추가를 클릭합니다. 서브넷 범위 이름에 tier-1-pods을 입력하고, 보조 IPv4 범위에 10.4.0.0/14를 입력합니다.
서브넷 추가를 클릭합니다.
이름에 tier-2를 입력합니다.
리전에서 이전 서브넷에 선택한 리전과 동일한 리전을 선택합니다.
IPv4 범위에 172.16.4.0/22를 입력합니다.
보조 IPv4 범위 만들기를 클릭합니다. 서브넷 범위 이름에 tier-2-services를 입력하고, 보조 IPv4 범위에 172.16.16.0/20를 입력합니다.
IP 범위 추가를 클릭합니다. 서브넷 범위 이름에 tier-2-pods를 입력하고, 보조 IPv4 범위에 172.20.0.0/14를 입력합니다.
만들기를 클릭합니다.

gcloud

호스트 프로젝트에서 이름이 shared-net인 네트워크를 만듭니다.

gcloud compute networks create shared-net \
    --subnet-mode custom \
    --project HOST_PROJECT_ID

새 네트워크에서 이름이 tier-1인 서브넷을 만듭니다.

gcloud compute networks subnets create tier-1 \
    --project HOST_PROJECT_ID \
    --network shared-net \
    --range 10.0.4.0/22 \
    --region COMPUTE_REGION \
    --secondary-range tier-1-services=10.0.32.0/20,tier-1-pods=10.4.0.0/14

이름이 tier-2인 다른 서브넷을 만듭니다.

gcloud compute networks subnets create tier-2 \
    --project HOST_PROJECT_ID \
    --network shared-net \
    --range 172.16.4.0/22 \
    --region COMPUTE_REGION \
    --secondary-range tier-2-services=172.16.16.0/20,tier-2-pods=172.20.0.0/14

COMPUTE_REGION을 Compute Engine 리전으로 바꿉니다.

서비스 프로젝트에서 서비스 계정 이름 확인

서비스 프로젝트는 2개가 있으며, 각 항목에는 여러 개의 서비스 계정이 포함됩니다. 이 섹션에서는 GKE 서비스 계정과 Google API 서비스 계정을 설명합니다. 다음 섹션에서는 이러한 서비스 계정의 이름이 필요합니다.

다음 표에는 두 서비스 프로젝트의 GKE 및 Google API 서비스 계정 이름이 나와 있습니다.

서비스 계정 유형	서비스 계정 이름
GKE	service-`SERVICE_PROJECT_1_NUM`@container-engine-robot.iam.gserviceaccount.com
GKE	service-`SERVICE_PROJECT_2_NUM`@container-engine-robot.iam.gserviceaccount.com
Google API	`SERVICE_PROJECT_1_NUM`@cloudservices.gserviceaccount.com
Google API	`SERVICE_PROJECT_2_NUM`@cloudservices.gserviceaccount.com

공유 VPC 사용 설정 및 역할 부여

이 섹션의 태스크를 수행하려면 조직에서 공유 VPC 관리자 역할을 정의해야 합니다.

이 섹션에서는 다음 태스크를 수행합니다.

호스트 프로젝트에서 공유 VPC를 사용 설정합니다.
서비스 프로젝트 두 개를 호스트 프로젝트에 연결합니다.
서비스 프로젝트에 속하는 서비스 계정에 적절한 IAM 역할을 부여합니다.
- 첫 번째 서비스 프로젝트에서 서비스 계정 두 개에 호스트 프로젝트의 tier-1 서브넷에 대한 Compute Network User 역할을 부여합니다.
- 두 번째 서비스 프로젝트에서 2개의 서비스 계정에 호스트 프로젝트의 tier-2 서브넷에 대한 Compute Network User 역할을 부여합니다.

콘솔

다음 단계를 수행하여 공유 VPC를 사용 설정하고, 서비스 프로젝트를 연결하고, 역할을 부여하세요.

Google Cloud 콘솔의 공유 VPC 페이지로 이동합니다.

공유 VPC로 이동
프로젝트 선택기에서 호스트 프로젝트를 선택합니다.
공유 VPC 설정을 클릭합니다. 호스트 프로젝트 사용 설정 화면이 표시됩니다.
저장하고 계속하기를 클릭합니다. 서브넷 선택 페이지가 표시됩니다.
공유 모드 아래에서 개별 서브넷을 선택합니다.
공유할 서브넷 아래에서 tier-1 및 tier-2를 선택합니다. 다른 체크박스는 모두 지웁니다.
계속을 클릭합니다. 권한 부여 페이지가 표시됩니다.
서비스 프로젝트 연결 아래에서 첫 번째 서비스 프로젝트 및 두 번째 서비스 프로젝트를 선택합니다. 서비스 프로젝트 연결 아래에서 다른 체크박스는 모두 지웁니다.
Kubernetes Engine 액세스 아래에서 사용 설정을 선택합니다.
저장을 클릭합니다. 새 페이지가 표시됩니다.
개별 서브넷 권한 아래에서 tier-1을 선택합니다.
오른쪽 창에서 두 번째 서비스 프로젝트에 속하는 서비스 계정을 삭제합니다. 즉, SERVICE_PROJECT_2_NUM이 포함된 서비스 계정을 삭제합니다.
오른쪽 창에서 첫 번째 서비스 프로젝트에 속하는 Kubernetes Engine 및 Google API 서비스 계정 이름을 찾습니다. 목록에서 서비스 계정 이름을 모두 확인할 수 있습니다. 둘 중 하나라도 목록에 없으면, 구성원 추가 아래에 서비스 계정 이름을 입력하고 추가를 클릭합니다.
가운데 창의 개별 서브넷 권한 아래에서 tier-2를 선택하고 tier-1을 선택 해제합니다.
오른쪽 창에서 첫 번째 서비스 프로젝트에 속하는 서비스 계정을 삭제합니다. 즉, SERVICE_PROJECT_1_NUM이 포함된 서비스 계정을 삭제합니다.
오른쪽 창에서 두 번째 서비스 프로젝트에 속하는 Kubernetes Engine 및 Google API 서비스 계정 이름을 찾습니다. 목록에서 서비스 계정 이름을 모두 확인할 수 있습니다. 둘 중 하나라도 목록에 없으면, 구성원 추가 아래에 서비스 계정 이름을 입력하고 추가를 클릭합니다.

gcloud

호스트 프로젝트에서 공유 VPC를 사용 설정합니다. 사용되는 명령어는 사용자에게 있는 필요한 관리 역할에 따라 달라집니다.

조직 수준에서 공유 VPC 관리자 역할이 있는 경우
```
gcloud compute shared-vpc enable HOST_PROJECT_ID
```
폴더 수준에서 공유 VPC 관리자 역할이 있는 경우
```
gcloud beta compute shared-vpc enable HOST_PROJECT_ID
```

첫 번째 서비스 프로젝트를 호스트 프로젝트에 연결합니다.

gcloud compute shared-vpc associated-projects add SERVICE_PROJECT_1_ID \
    --host-project HOST_PROJECT_ID

두 번째 서비스 프로젝트를 호스트 프로젝트에 연결합니다.

gcloud compute shared-vpc associated-projects add SERVICE_PROJECT_2_ID \
    --host-project HOST_PROJECT_ID

tier-1 서브넷의 IAM 정책을 가져옵니다.

gcloud compute networks subnets get-iam-policy tier-1 \
   --project HOST_PROJECT_ID \
   --region COMPUTE_REGION

출력에 etag 필드가 포함됩니다. etag 값을 기록해 둡니다.

다음 내용이 포함된 tier-1-policy.yaml이라는 파일을 만듭니다.

bindings:
- members:
  - serviceAccount:SERVICE_PROJECT_1_NUM@cloudservices.gserviceaccount.com
  - serviceAccount:service-SERVICE_PROJECT_1_NUM@container-engine-robot.iam.gserviceaccount.com
  role: roles/compute.networkUser
etag: ETAG_STRING

ETAG_STRING을 앞에서 기록해 둔 etag 값으로 바꿉니다.

tier-1 서브넷의 IAM 정책을 설정합니다.

gcloud compute networks subnets set-iam-policy tier-1 \
    tier-1-policy.yaml \
    --project HOST_PROJECT_ID \
    --region COMPUTE_REGION

tier-2 서브넷의 IAM 정책을 가져옵니다.

gcloud compute networks subnets get-iam-policy tier-2 \
    --project HOST_PROJECT_ID \
    --region COMPUTE_REGION

출력에 etag 필드가 포함됩니다. etag 값을 기록해 둡니다.

다음 내용이 포함된 tier-2-policy.yaml이라는 파일을 만듭니다.

bindings:
- members:
  - serviceAccount:SERVICE_PROJECT_2_NUM@cloudservices.gserviceaccount.com
  - serviceAccount:service-SERVICE_PROJECT_2_NUM@container-engine-robot.iam.gserviceaccount.com
  role: roles/compute.networkUser
etag: ETAG_STRING

ETAG_STRING을 앞에서 기록해 둔 etag 값으로 바꿉니다.

tier-2 서브넷의 IAM 정책을 설정합니다.

gcloud compute networks subnets set-iam-policy tier-2 \
    tier-2-policy.yaml \
    --project HOST_PROJECT_ID \
    --region COMPUTE_REGION

방화벽 리소스 관리

서비스 프로젝트의 GKE 클러스터가 호스트 프로젝트의 방화벽 리소스를 만들고 관리하도록 하려면 서비스 프로젝트의 GKE 서비스 계정에 다음 전략 중 하나를 사용하여 적절한 IAM 권한을 부여해야 합니다.

서비스 프로젝트의 GKE 서비스 계정에 호스트 프로젝트에 대한 Compute Security Admin 역할을 부여합니다.

콘솔

Google Cloud Console에서 IAM 페이지로 이동합니다.

IAM으로 이동
호스트 프로젝트를 선택합니다.
액세스 권한 부여를 클릭한 다음 서비스 프로젝트의 GKE 서비스 계정 주 구성원인 service-SERVICE_PROJECT_NUM@container-engine-robot.iam.gserviceaccount.com을 입력합니다.
드롭다운 목록에서 Compute Security Admin 역할을 선택합니다.
저장을 클릭합니다.

gcloud

서비스 프로젝트의 GKE 서비스 계정에 호스트 프로젝트 내에서 Compute Security Admin 역할을 부여합니다.

gcloud projects add-iam-policy-binding HOST_PROJECT_ID \
    --member=serviceAccount:service-SERVICE_PROJECT_NUM@container-engine-robot.iam.gserviceaccount.com \
    --role=roles/compute.securityAdmin

다음을 바꿉니다.

HOST_PROJECT_ID: 공유 VPC 호스트 프로젝트 ID입니다.
SERVICE_PROJECT_NUM: GKE 서비스 계정이 포함된 서비스 프로젝트의 ID입니다.

세분화된 방식의 경우 compute.networks.updatePolicy, compute.firewalls.list, compute.firewalls.get, compute.firewalls.create, compute.firewalls.update, compute.firewalls.delete 권한만 포함된 커스텀 IAM 역할을 만듭니다. 서비스 프로젝트의 GKE 서비스 계정에 호스트 프로젝트에 대한 해당 커스텀 역할을 부여합니다.

콘솔

앞에서 언급한 IAM 권한이 포함된 호스트 프로젝트 내에 커스텀 역할을 만듭니다.

Google Cloud 콘솔에서 역할 페이지로 이동합니다.

역할 페이지로 이동
페이지 상단의 드롭다운 목록을 사용하여 호스트 프로젝트를 선택합니다.
역할 만들기를 클릭합니다.
역할의 제목, 설명, ID, 역할 실행 단계를 입력합니다. 역할을 만든 후에는 역할 이름을 변경할 수 없습니다.
권한 추가를 클릭합니다.
compute.networks를 필터링하고 이전에 언급된 IAM 권한을 선택합니다.
모든 필수 권한을 선택한 후 추가를 클릭합니다.
만들기를 클릭합니다.

호스트 프로젝트 내에서 새로 생성된 커스텀 역할을 서비스 프로젝트의 GKE 서비스 계정에 부여합니다.

Google Cloud Console에서 IAM 페이지로 이동합니다.

IAM으로 이동
호스트 프로젝트를 선택합니다.
액세스 권한 부여를 클릭한 다음 서비스 프로젝트의 GKE 서비스 계정 주 구성원인 service-SERVICE_PROJECT_NUM@container-engine-robot.iam.gserviceaccount.com을 입력합니다.
새로 만든 커스텀 역할의 제목을 필터링하여 선택합니다.
저장을 클릭합니다.

gcloud

앞에서 언급한 IAM 권한이 포함된 호스트 프로젝트 내에 커스텀 역할을 만듭니다.

gcloud iam roles create ROLE_ID \
    --title="ROLE_TITLE" \
    --description="ROLE_DESCRIPTION" \
    --stage=LAUNCH_STAGE \
    --permissions=compute.networks.updatePolicy,compute.firewalls.list,compute.firewalls.get,compute.firewalls.create,compute.firewalls.update,compute.firewalls.delete \
    --project=HOST_PROJECT_ID

호스트 프로젝트 내에서 새로 생성된 커스텀 역할을 서비스 프로젝트의 GKE 서비스 계정에 부여합니다.
```
gcloud projects add-iam-policy-binding HOST_PROJECT_ID \
    --member=serviceAccount:service-SERVICE_PROJECT_NUM@container-engine-robot.iam.gserviceaccount.com \
    --role=projects/HOST_PROJECT_ID/roles/ROLE_ID
```
다음을 바꿉니다.
- ROLE_ID: 역할의 이름입니다(예: gkeFirewallAdmin).
- ROLE_TITLE은 역할의 별칭입니다(예: GKE Firewall Admin).
- ROLE_DESCRIPTION은 역할에 대한 간단한 설명입니다(예: GKE service account FW permissions).
- LAUNCH_STAGE: 수명 주기에서 역할의 출시 단계입니다(예: ALPHA, BETA 또는 GA).
- HOST_PROJECT_ID: 공유 VPC 호스트 프로젝트 ID입니다.
- SERVICE_PROJECT_NUM: GKE 서비스 계정이 포함된 서비스 프로젝트의 ID입니다.

둘 이상의 서비스 프로젝트에 클러스터가 있는 경우 전략 중 하나를 선택하고 각 서비스 프로젝트의 GKE 서비스 계정에 이를 반복해야 합니다.

서브넷에 부여되는 역할 요약

다음은 서브넷에서 부여되는 역할의 요약입니다.

서비스 계정	역할	서브넷
service-`SERVICE_PROJECT_1_NUM`@container-engine-robot.iam.gserviceaccount.com	Compute 네트워크 사용자	tier-1
`SERVICE_PROJECT_1_NUM`@cloudservices.gserviceaccount.com	Compute 네트워크 사용자	tier-1
service-`SERVICE_PROJECT_2_NUM`@container-engine-robot.iam.gserviceaccount.com	Compute 네트워크 사용자	tier-2
`SERVICE_PROJECT_2_NUM`@cloudservices.gserviceaccount.com	Compute 네트워크 사용자	tier-2

Kubernetes Engine 액세스

서비스 프로젝트를 연결할 때 Kubernetes Engine 액세스를 사용하면 호스트 프로젝트에서 네트워크 관리 작업을 수행할 수 있는 권한이 서비스 프로젝트의 GKE 서비스 계정에 부여됩니다.

Kubernetes Engine 액세스를 사용 설정하지 않고 서비스 프로젝트를 연결한 경우, 호스트 프로젝트와 서비스 프로젝트에서 이미 Kubernetes Engine API를 사용하도록 설정했다면 호스트 프로젝트에서 다음 IAM 역할 바인딩을 추가하여 서비스 프로젝트의 GKE 서비스 계정에 권한을 직접 할당할 수 있습니다.

구성원	역할	리소스
service-`SERVICE_PROJECT_NUM`@container-engine-robot.iam.gserviceaccount.com	Compute 네트워크 사용자	특정 서브넷 또는 전체 호스트 프로젝트
service-`SERVICE_PROJECT_NUM`@container-engine-robot.iam.gserviceaccount.com	호스트 서비스 에이전트 사용자	호스트 프로젝트의 GKE 서비스 계정

호스트 서비스 에이전트 사용자 역할 부여

각 서비스 프로젝트의 GKE 서비스 계정에는 호스트 프로젝트의 호스트 서비스 에이전트 사용자 역할에 대한 결합이 있어야 합니다. GKE 서비스 계정의 형식은 다음과 같습니다.

service-SERVICE_PROJECT_NUM@container-engine-robot.iam.gserviceaccount.com

여기서 SERVICE_PROJECT_NUM은 서비스 프로젝트의 프로젝트 번호입니다.

이 결합을 통해 서비스 프로젝트의 GKE 서비스 계정은 마치 호스트 프로젝트의 GKE 서비스 계정인 것처럼 호스트 프로젝트에서 네트워크 관리 작업을 수행할 수 있습니다. 이 역할은 서비스 프로젝트의 GKE 서비스 계정에만 부여될 수 있습니다.

콘솔

Google Cloud 콘솔을 사용한 경우에는 호스트 서비스 에이전트 사용자 역할을 명시적으로 부여할 필요가 없습니다. 이 작업은 사용자가 Google Cloud 콘솔을 사용해서 호스트 프로젝트에 서비스 프로젝트를 연결할 때 자동으로 수행되었습니다.

gcloud

첫 번째 프로젝트의 GKE 서비스 계정에 호스트 서비스 에이전트 사용자 역할을 부여합니다. 이 역할은 호스트 프로젝트에 부여됩니다.

gcloud projects add-iam-policy-binding HOST_PROJECT_ID \
    --member serviceAccount:service-SERVICE_PROJECT_1_NUM@container-engine-robot.iam.gserviceaccount.com \
    --role roles/container.hostServiceAgentUser

두 번째 프로젝트의 GKE 서비스 계정에 호스트 서비스 에이전트 사용자 역할을 부여합니다. 이 역할은 호스트 프로젝트에 부여됩니다.

gcloud projects add-iam-policy-binding HOST_PROJECT_ID \
    --member serviceAccount:service-SERVICE_PROJECT_2_NUM@container-engine-robot.iam.gserviceaccount.com \
    --role roles/container.hostServiceAgentUser

사용 가능한 서브넷 및 보조 IP 주소 범위 확인

클러스터를 만들 때는 클러스터의 포드 및 서비스에 사용할 서브넷 및 보조 IP 주소 범위를 지정해야 합니다. IP 주소 범위를 사용하지 못하게 되는 이유는 몇 가지가 있습니다. 클러스터를 만들 때 Google Cloud 콘솔을 사용하거나 gcloud CLI를 사용하는지에 관계없이 사용 가능한 IP 주소 범위를 지정해야 합니다.

아직 사용 중이 아닌 IP 주소 범위는 새 클러스터의 서비스에 사용할 수 있습니다. 새 클러스터의 포드에 지정하는 IP 주소 범위는 사용되지 않은 범위이거나, 다른 클러스터의 포드와 공유된 범위일 수 있습니다. GKE에서 생성되어 관리되는 IP 주소 범위는 사용자의 클러스터에서 사용할 수 없습니다.

gcloud CLI를 사용하여 프로젝트의 사용 가능한 서브넷 및 보조 IP 주소 범위를 나열할 수 있습니다.

gcloud

gcloud container subnets list-usable \
    --project SERVICE_PROJECT_ID \
    --network-project HOST_PROJECT_ID

SERVICE_PROJECT_ID를 서비스 프로젝트의 프로젝트 ID로 바꿉니다.

--project 또는 --network-project 옵션을 생략할 경우, gcloud CLI 명령어는 활성 구성의 기본 프로젝트를 사용합니다. 호스트 프로젝트와 네트워크 프로젝트는 서로 다르므로, --project 또는 --network-project를 지정하거나 둘 다 지정해야 합니다.

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

PROJECT: xpn-host
REGION: REGION_NAME
NETWORK: shared-net
SUBNET: tier-2
RANGE: 172.16.4.0/22

SECONDARY_RANGE_NAME: tier-2-services
IP_CIDR_RANGE: 172.20.0.0/14
STATUS: usable for pods or services

SECONDARY_RANGE_NAME: tier-2-pods
IP_CIDR_RANGE: 172.16.16.0/20
STATUS: usable for pods or services

PROJECT: xpn-host
REGION: REGION_NAME
NETWORK: shared-net
SUBNET: tier-1
RANGE: 10.0.4.0/22

SECONDARY_RANGE_NAME: tier-1-services
IP_CIDR_RANGE: 10.0.32.0/20
STATUS: usable for pods or services

SECONDARY_RANGE_NAME: tier-1-pods
IP_CIDR_RANGE: 10.4.0.0/14
STATUS: usable for pods or services

list-usable 명령어는 다음 상황에서 빈 목록을 반환합니다.

서비스 프로젝트의 Kubernetes Engine 서비스 계정에 호스트 프로젝트의 호스트 서비스 에이전트 사용자 역할이 없는 경우
호스트 프로젝트의 Kubernetes Engine 서비스 계정이 없는 경우(예: 계정을 실수로 삭제한 경우)
호스트 프로젝트에서 Kubernetes Engine API가 사용 설정되지 않은 경우, 호스트 프로젝트의 Kubernetes Engine 서비스 계정이 없는 것입니다.

자세한 내용은 문제 해결 섹션을 참조하세요.

보조 범위 참고 사항

특정 서브넷에 30개의 보조 범위를 만들 수 있습니다. 각 클러스터에는 포드 및 서비스에 각각 하나씩 2개의 보조 범위가 필요합니다.

첫 번째 서비스 프로젝트에서 클러스터 만들기

첫 번째 서비스 프로젝트에서 클러스터를 만들려면 gcloud CLI 또는 Google Cloud Console을 사용하여 다음 단계를 수행합니다.

콘솔

Google Cloud 콘솔에서 Google Kubernetes Engine 페이지로 이동합니다.

Google Kubernetes Engine으로 이동
프로젝트 선택기에서 첫 번째 서비스 프로젝트를 선택합니다.
만들기를 클릭합니다.
Autopilot 또는 Standard 섹션에서 구성을 클릭합니다.
이름에 tier-1-cluster를 입력합니다.
리전 드롭다운 목록에서 서브넷에 사용한 것과 동일한 리전을 선택합니다.
탐색창에서 네트워킹을 클릭합니다.
나와 공유된 네트워크(호스트 프로젝트에서)를 선택합니다.
네트워크로 shared-net을 선택합니다.
노드 서브넷으로 tier-1을 선택합니다.
포드 보조 CIDR 범위로 tier-1-pods를 선택합니다.
서비스 보조 CIDR 범위로 tier-1-services를 선택합니다.
만들기를 클릭합니다.
만들기가 완료되면 클러스터 목록에서 tier-1-cluster를 클릭합니다.
클러스터 세부정보 페이지에서 노드 탭을 클릭합니다.
노드 풀 아래에서 검사하려는 노드 풀의 이름을 클릭합니다.
인스턴스 그룹에서 검사할 인스턴스 그룹의 이름을 클릭합니다. 예: gke-tier-1-cluster-default-pool-5c5add1f-grp.
인스턴스 목록에서 노드의 내부 IP 주소가 tier-1 서브넷의 기본 범위인 10.0.4.0/22에 있는지 확인합니다.

gcloud

첫 번째 서비스 프로젝트에서 이름이 tier-1-cluster인 클러스터를 만듭니다.

gcloud container clusters create-auto tier-1-cluster \
    --project=SERVICE_PROJECT_1_ID \
    --location=COMPUTE_REGION \
    --network=projects/HOST_PROJECT_ID/global/networks/shared-net \
    --subnetwork=projects/HOST_PROJECT_ID/regions/COMPUTE_REGION/subnetworks/tier-1 \
    --cluster-secondary-range-name=tier-1-pods \
    --services-secondary-range-name=tier-1-services

만들기가 완료되면 클러스터 노드가 tier-1 서브넷의 기본 범위인 10.0.4.0/22에 있는지 확인합니다.

gcloud compute instances list --project SERVICE_PROJECT_1_ID

출력에는 노드의 내부 IP 주소가 표시됩니다.

NAME                    ZONE           ... INTERNAL_IP
gke-tier-1-cluster-...  ZONE_NAME      ... 10.0.4.2
gke-tier-1-cluster-...  ZONE_NAME      ... 10.0.4.3
gke-tier-1-cluster-...  ZONE_NAME      ... 10.0.4.4

두 번째 서비스 프로젝트에서 클러스터 만들기

두 번째 서비스 프로젝트에서 클러스터를 만들려면 gcloud CLI 또는 Google Cloud Console을 사용하여 다음 단계를 수행합니다.

콘솔

Google Cloud 콘솔에서 Google Kubernetes Engine 페이지로 이동합니다.

Google Kubernetes Engine으로 이동
프로젝트 선택기에서 두 번째 서비스 프로젝트를 선택합니다.
만들기를 클릭합니다.
Standard 또는 Autopilot 섹션에서 구성을 클릭합니다.
이름에 tier-2-cluster를 입력합니다.
리전 드롭다운 목록에서 서브넷에 사용한 것과 동일한 리전을 선택합니다.
탐색창에서 네트워킹을 클릭합니다.
네트워크로 shared-net을 선택합니다.
노드 서브넷으로 tier-2를 선택합니다.
포드 보조 CIDR 범위로 tier-2-pods를 선택합니다.
서비스 보조 CIDR 범위로 tier-2-services를 선택합니다.
만들기를 클릭합니다.
만들기가 완료되면 클러스터 목록에서 tier-2-cluster를 클릭합니다.
클러스터 세부정보 페이지에서 노드 탭을 클릭합니다.
노드 풀 아래에서 검사하려는 노드 풀의 이름을 클릭합니다.
인스턴스 그룹에서 검사할 인스턴스 그룹의 이름을 클릭합니다. 예를 들면 gke-tier-2-cluster-default-pool-5c5add1f-grp입니다.
인스턴스 목록에서 노드의 내부 IP 주소가 tier-2 서브넷의 기본 범위인 172.16.4.0/22에 있는지 확인합니다.

gcloud

두 번째 서비스 프로젝트에서 이름이 tier-2-cluster인 클러스터를 만듭니다.

gcloud container clusters create-auto tier-2-cluster \
    --project=SERVICE_PROJECT_2_ID \
    --location=COMPUTE_REGION \
    --network=projects/HOST_PROJECT_ID/global/networks/shared-net \
    --subnetwork=projects/HOST_PROJECT_ID/regions/COMPUTE_REGION/subnetworks/tier-2 \
    --cluster-secondary-range-name=tier-2-pods \
    --services-secondary-range-name=tier-2-services

만들기가 완료되면 클러스터 노드가 tier-2 서브넷의 기본 범위인 172.16.4.0/22에 있는지 확인합니다.

gcloud compute instances list --project SERVICE_PROJECT_2_ID

출력에는 노드의 내부 IP 주소가 표시됩니다.

NAME                    ZONE           ... INTERNAL_IP
gke-tier-2-cluster-...  ZONE_NAME      ... 172.16.4.2
gke-tier-2-cluster-...  ZONE_NAME      ... 172.16.4.3
gke-tier-2-cluster-...  ZONE_NAME      ... 172.16.4.4

방화벽 규칙 만들기

네트워크로 들어오는 트래픽과 네트워크 내 클러스터 간 트래픽을 허용하려면 방화벽을 만들어야 합니다. 다음 섹션에서는 방화벽 규칙을 만들고 업데이트하는 방법을 보여줍니다.

노드와의 SSH 연결을 사용 설정하는 방화벽 규칙 만들기: SSH를 사용하여 클러스터 외부 트래픽을 사용 설정하는 방화벽 규칙을 만드는 방법을 보여줍니다.
노드 간 핑이 이루어지도록 방화벽 규칙 업데이트: 클러스터 간 ICMP 트래픽을 허용하도록 방화벽 규칙을 업데이트하는 방법을 보여줍니다.

SSH와 ICMP는 예시로 사용된 것이며, 특정 애플리케이션의 네트워킹 요구사항을 사용 설정하는 방화벽 규칙을 만들어야 합니다.

노드와의 SSH 연결을 사용 설정하는 방화벽 규칙 만들기

호스트 프로젝트에서 shared-net 네트워크의 방화벽 규칙을 만듭니다. TCP 포트 22에서 트래픽이 들어오도록 허용하면 SSH를 사용하여 클러스터 노드에 연결할 수 있습니다.

콘솔

Google Cloud 콘솔의 방화벽 페이지로 이동합니다.

방화벽으로 이동
프로젝트 선택기에서 호스트 프로젝트를 선택합니다.
VPC 네트워킹 메뉴에서 방화벽 규칙 만들기를 클릭합니다.
이름에 my-shared-net-rule을 입력합니다.
네트워크로 shared-net을 선택합니다.
트래픽 방향으로 수신을 선택합니다.
일치 시 작업으로 허용을 선택합니다.
대상으로 네트워크의 모든 인스턴스를 선택합니다.
소스 필터로 IP 범위를 선택합니다.
소스 IP 범위에 0.0.0.0/0을 입력합니다.
프로토콜 및 포트로 지정된 프로토콜 및 포트를 선택합니다. 상자에 tcp:22를 입력합니다.
만들기를 클릭합니다.

gcloud

공유 네트워크에 대한 방화벽 규칙을 만듭니다.

gcloud compute firewall-rules create my-shared-net-rule \
    --project HOST_PROJECT_ID \
    --network shared-net \
    --direction INGRESS \
    --allow tcp:22

SSH를 사용하여 노드에 연결

TCP 포트 22에서 인그레스 트래픽을 허용하는 방화벽을 만든 후 SSH를 사용하여 노드에 연결합니다.

콘솔

Google Cloud 콘솔에서 Google Kubernetes Engine 페이지로 이동합니다.

Google Kubernetes Engine으로 이동
프로젝트 선택기에서 첫 번째 서비스 프로젝트를 선택합니다.
tier-1-cluster를 클릭합니다.
클러스터 세부정보 페이지에서 노드 탭을 클릭합니다.
노드 풀 아래에서 노드 풀 이름을 클릭합니다.
인스턴스 그룹에서 인스턴스 그룹의 이름을 클릭합니다. 예: gke-tier-1-cluster-default-pool-faf87d48-grp.
인스턴스 목록에서 노드의 내부 IP 주소를 기록해 둡니다. 이러한 주소는 10.0.4.0/22 범위에 있습니다.
노드 중 하나의 SSH를 클릭합니다. 방화벽 규칙에서 허용되는 TCP 포트 22가 SSH에 사용되기 때문에 이 작업은 성공합니다.

gcloud

첫 번째 서비스 프로젝트에서 노드를 나열합니다.

gcloud compute instances list --project SERVICE_PROJECT_1_ID

출력에는 클러스터에 있는 노드 이름이 포함됩니다.

NAME                                           ...
gke-tier-1-cluster-default-pool-faf87d48-3mf8  ...
gke-tier-1-cluster-default-pool-faf87d48-q17k  ...
gke-tier-1-cluster-default-pool-faf87d48-x9rk  ...

SSH를 사용해서 노드 중 하나에 연결합니다.

gcloud compute ssh NODE_NAME \
    --project SERVICE_PROJECT_1_ID \
    --zone COMPUTE_ZONE

다음을 바꿉니다.

NODE_NAME: 노드 중 하나의 이름입니다.
COMPUTE_ZONE: 리전 내 Compute Engine 영역의 이름입니다.

노드 간 핑이 이루어지도록 방화벽 규칙 업데이트

SSH 명령줄 창에서 CoreOS 도구 상자를 시작합니다.
```
/usr/bin/toolbox
```
도구 상자 셸에서 동일 클러스터에 있는 다른 노드 중 하나를 핑합니다. 예를 들면 다음과 같습니다.
```
ping 10.0.4.4
```
해당 노드 및 다른 노드가 모두 10.0.4.0/22 범위에 있기 때문에 ping 명령어가 성공합니다.
이제 다른 서비스 프로젝트에 있는 클러스터의 노드 중 하나에 핑을 시도합니다. 예를 들면 다음과 같습니다.
```
ping 172.16.4.3
```
방화벽 규칙에서 ICMP(인터넷 제어 메시지 프로토콜) 트래픽이 허용되지 않기 때문에 이번에는 ping 명령어가 실패합니다.
도구 상자 셸이 아닌 일반적인 명령어 프롬프트에서 ICMP를 허용하도록 방화벽 규칙을 업데이트하세요.
```
gcloud compute firewall-rules update my-shared-net-rule \
    --project HOST_PROJECT_ID \
    --allow tcp:22,icmp
```
도구 상자 셸에서 노드에 다시 핑을 수행합니다. 예를 들면 다음과 같습니다.
```
ping 172.16.4.3
```
이번에는 ping 명령어가 성공합니다.

추가 방화벽 규칙 만들기

클러스터에서 노드, pod, 서비스 간 ��신을 허용하도록 추가 방화벽 규칙을 만들 수 있습니다.

예를 들어 다음 규칙은 모든 TCP 또는 UDP 포트에서 tier-1-cluster에 있는 모든 노드, 포드 또는 서비스의 트래픽 전송을 허용합니다.

gcloud compute firewall-rules create my-shared-net-rule-2 \
    --project HOST_PROJECT_ID \
    --network shared-net \
    --allow tcp,udp \
    --direction INGRESS \
    --source-ranges 10.0.4.0/22,10.4.0.0/14,10.0.32.0/20

다음 규칙은 모든 TCP 또는 UDP 포트에서 tier-2-cluster에 있는 모든 노드, 포드 또는 서비스의 트래픽 전송을 허용합니다.

gcloud compute firewall-rules create my-shared-net-rule-3 \
    --project HOST_PROJECT_ID \
    --network shared-net \
    --allow tcp,udp \
    --direction INGRESS \
    --source-ranges 172.16.4.0/22,172.20.0.0/14,172.16.16.0/20

Kubernetes는 또한 부하 분산기 서비스를 만들 때와 같이, 필요할 때 방화벽 리소스를 만들고 관리하려고 시도합니다. Kubernetes가 권한 문제로 인해 방화벽 규칙을 변경할 수 없음을 알게 되면 Kubernetes 이벤트가 발생하여 설정 변경 방법을 안내합니다.

Kubernetes에 방화벽 규칙 변경 권한을 부여하려면 방화벽 리소스 관리를 참조하세요.

인그레스 부하 분산기의 경우, Kubernetes가 권한 부족으로 인해 방화벽 규칙을 변경할 수 없으면 몇 분 간격으로 firewallXPNError 이벤트가 발생합니다. GLBC 1.4 이상에서는 인그레스 리소스에 networking.gke.io/suppress-firewall-xpn-error: "true" 주석을 추가하여 firewallXPNError 이벤트가 발생하지 않도록 할 수 있습니다. 언제든지 이 주석을 삭제하면 이벤트가 다시 발생합니다.

공유 VPC에서 비공개 클러스터 만들기

비공개 클러스터에 공유 VPC를 사용할 수 있습니다.

이렇게 하려면 클러스터를 만들 때 사용되는 사용자 계정 또는 서비스 계정에 호스트 프로젝트에 대한 다음 권한을 부여해야 합니다.

compute.networks.get
compute.networks.updatePeering

또한 제어 영역 IP 주소 범위가 공유 네트워크에 있는 다른 예약된 범위와 겹치지 않는지 확인해야 합니다.

2020년 1월 15일 이전에 만든 비공개 클러스터의 경우 VPC 네트워크당 최대 비공개 GKE 클러스터 수는 단일 VPC 네트워크의 피어링 연결 수로 제한됩니다. 새 비공개 클러스터는 이 제한을 제거하는 VPC 네트워크 피어링 연결을 다시 사용합니다. 이전 비공개 클러스터에서 VPC 네트워크 피어 재사용을 사용 설정하려면 클러스터를 삭제하고 다시 만들면 됩니다. 클러스터를 업그레이드해도 클러스터는 기존 VPC 네트워크 피어링 연결을 ��사용하지 않습니다.

이 섹션에서는 사전 정의된 공유 VPC 네트워크에 private-cluster-vpc라는 VPC 기반 클러스터를 만듭니다.

콘솔

Google Cloud 콘솔에서 Google Kubernetes Engine 페이지로 이동합니다.

Google Kubernetes Engine으로 이동
만들기를 클릭합니다.
Autopilot 또는 Standard 섹션에서 구성을 클릭합니다.
이름에 private-cluster-vpc를 입력합니다.
탐색창에서 네트워킹을 클릭합니다.
비공개 클러스터를 선택합니다.
(Autopilot 선택사항): 제어 영역 IP 범위를 172.16.0.16/28로 설정합니다.
네트워크 드롭다운 목록에서 이전에 만든 VPC 네트워크를 선택합니다.
노드 서브넷 드롭다운 목록에서 이전에 만든 공유 서브넷을 선택합니다.
필요에 따라 클러스터를 구성합니다.
만들기를 클릭합니다.

gcloud

다음 명령어를 실행하여 사전 정의된 공유 VPC에 private-cluster-vpc라는 클러스터를 만듭니다.

gcloud container clusters create-auto private-cluster-vpc \
    --project=PROJECT_ID \
    --location=COMPUTE_REGION \
    --network=projects/HOST_PROJECT/global/networks/shared-net \
    --subnetwork=SHARED_SUBNETWORK \
    --cluster-secondary-range-name=tier-1-pods \
    --services-secondary-range-name=tier-1-services \
    --enable-private-nodes \
    --master-ipv4-cidr=172.16.0.0/28

IP 주소 예약

공유 VPC 클러스터의 내부 및 외부 IP 주소를 예약할 수 있습니다. IP 주소가 서비스 프로젝트에 예약되어 있는지 확인합니다.

내부 IP 주소의 경우 IP 주소가 속하는 서브네트워크를 제공해야 합니다. 프로젝트 전체에서 IP 주소를 예약하려면 서브네트워크를 식별할 수 있도록 전체 리소스 URL을 사용합니다.

Google Cloud CLI에서 다음 명령어를 사용하여 내부 IP 주소를 예약할 수 있습니다.

gcloud compute addresses create RESERVED_IP_NAME \
    --region=COMPUTE_REGION \
    --subnet=projects/HOST_PROJECT_ID/regions/COMPUTE_REGION/subnetworks/SUBNETWORK_NAME \
    --addresses=IP_ADDRESS \
    --project=SERVICE_PROJECT_ID

이 명령어를 호출하려면 서브네트워크에 compute.subnetworks.use 권한이 추가되어 있어야 합니다. 호출자에게 서브네트워크의 compute.networkUser 역할을 부여하거나, 프로젝트 수준에서 compute.subnetworks.use 권한을 이용하여 호출자에게 맞춤 역할을 부여할 수 있습니다.

삭제

이 가이드의 연습을 완료한 후에는 계정에 원치 않는 요금이 청구되지 않도록 다음 태스크를 수행해 리소스를 삭제하세요.

클러스터 삭제

생성한 2개의 클러스터를 삭제합니다.

콘솔

Google Cloud 콘솔에서 Google Kubernetes Engine 페이지로 이동합니다.

Google Kubernetes Engine으로 이동
프로젝트 선택기에서 첫 번째 서비스 프로젝트를 선택합니다.
tier-1-cluster를 선택하고 삭제를 클릭합니다.
프로젝트 선택기에서 두 번째 서비스 프로젝트를 선택합니다.
tier-2-cluster를 선택하고 삭제를 클릭합니다.

gcloud

gcloud container clusters delete tier-1-cluster \
    --project SERVICE_PROJECT_1_ID \
    --zone COMPUTE_ZONE

gcloud container clusters delete tier-2-cluster \
    --project SERVICE_PROJECT_2_ID \
    --zone COMPUTE_ZONE

공유 VPC 사용 중지

호스트 프로젝트에서 공유 VPC를 사용 중지합니다.

콘솔

Google Cloud 콘솔의 공유 VPC 페이지로 이동합니다.

공유 VPC로 이동
프로젝트 선택기에서 호스트 프로젝트를 선택합니다.
공유 VPC 사용 중지를 클릭합니다.
필드에 HOST_PROJECT_ID를 입력하고 사용 중지를 클릭합니다.

gcloud

gcloud compute shared-vpc associated-projects remove SERVICE_PROJECT_1_ID \
    --host-project HOST_PROJECT_ID

gcloud compute shared-vpc associated-projects remove SERVICE_PROJECT_2_ID \
    --host-project HOST_PROJECT_ID

gcloud compute shared-vpc disable HOST_PROJECT_ID

방화벽 규칙 삭제

만든 방화벽 규칙을 삭제합니다.

콘솔

Google Cloud 콘솔의 방화벽 페이지로 이동합니다.

방화벽으로 이동
프로젝트 선택기에서 호스트 프로젝트를 선택합니다.
규칙 목록에서 my-shared-net-rule, my-shared-net-rule-2, my-shared-net-rule-3을 선택합니다.
삭제를 클릭합니다.

gcloud

방화벽 규칙을 삭제합니다.

gcloud compute firewall-rules delete \
    my-shared-net-rule \
    my-shared-net-rule-2 \
    my-shared-net-rule-3 \
    --project HOST_PROJECT_ID

공유 네트워크 삭제

만든 공유 네트워크를 삭제합니다.

콘솔

Google Cloud 콘솔에서 VPC 네트워크 페이지로 이동합니다.

VPC 네트워크로 이동
프로젝트 선택기에서 호스트 프로젝트를 선택합니다.
네트워크 목록에서 share-net을 선택합니다.
VPC 네트워크 삭제를 클릭합니다.

gcloud

gcloud compute networks subnets delete tier-1 \
    --project HOST_PROJECT_ID \
    --region COMPUTE_REGION

gcloud compute networks subnets delete tier-2 \
    --project HOST_PROJECT_ID \
    --region COMPUTE_REGION

gcloud compute networks delete shared-net --project HOST_PROJECT_ID

호스트 서비스 에이전트 사용자 역할 삭제

2개의 서비스 프로젝트에서 호스트 서비스 에이전트 사용자 역할을 제거합니다.

콘솔

Google Cloud 콘솔의 IAM 페이지로 이동합니다.

IAM으로 이동
프로젝트 선택기에서 호스트 프로젝트를 선택합니다.
구성원 목록에서 service-SERVICE_PROJECT_1_NUM@container-engine-robot.iam.gserviceaccount.com에 Kubernetes Engine 호스트 서비스 에이전트 사용자 역할이 부여되었음을 나타내는 행을 선택합니다.
service-SERVICE_PROJECT_2_NUM@container-engine-robot.iam.gserviceaccount.com에 Kubernetes Engine 호스트 서비스 에이전트 사용자 역할이 부여되었음을 나타내는 행을 선택합니다.
액세스 권한 삭제를 클릭합니다.

gcloud

첫 번째 서비스 프로젝트의 GKE 서비스 계정에서 호스트 에이전트 사용자 역할을 삭제합니다.

gcloud projects remove-iam-policy-binding HOST_PROJECT_ID \
    --member serviceAccount:service-SERVICE_PROJECT_1_NUM@container-engine-robot.iam.gserviceaccount.com \
    --role roles/container.hostServiceAgentUser

두 번째 서비스 프로젝트의 GKE 서비스 계정에서 호스트 서비스 에이전트 사용자 역할을 삭제합니다.

gcloud projects remove-iam-policy-binding HOST_PROJECT_ID \
    --member serviceAccount:service-SERVICE_PROJECT_2_NUM@container-engine-robot.iam.gserviceaccount.com \
    --role roles/container.hostServiceAgentUser

문제 해결

승인 거부됨

증상

Failed to get metadata from network project. GCE_PERMISSION_DENIED: Google
Compute Engine: Required 'compute.projects.get' permission for
'projects/HOST_PROJECT_ID

가능한 원인:

Kubernetes Engine API가 호스트 프로젝트에서 사용 설정되지 않았습니다.
호스트 프로젝트의 GKE 서비스 계정이 존재하지 않습니다. 예를 들어 삭제되었을 수 있습니다.
호스트 프로젝트의 GKE 서비스 계정에 호스트 프로젝트의 Kubernetes Engine 서비스 에이전트(container.serviceAgent) 역할이 없습니다. binding이 실수로 삭제되었을 수 있습니다.
서비스 프로젝트의 GKE 서비스 계정에 호스트 프로젝트의 호스트 서비스 에이전트 사용자 역할이 없습니다.

문제를 해결하려면 다음 단계를 따르세요. 호스트 프로젝트의 GKE 서비스 계정이 있는지 확인합니다. 그렇지 않은 경우 다음을 수행합니다.

호스트 프로젝트에서 Kubernetes Engine API가 사용 설정되지 않은 경우, 사용 설정합니다. 그러면 호스트 프로젝트의 GKE 서비스 계정이 생성되고 호스트 프로젝트의 GKE 서비스 계정에 호스트 프로젝트의 Kubernetes Engine 서비스 에이전트(container.serviceAgent) 역할이 부여됩니다.
호스트 프로젝트에서 Kubernetes Engine API가 사용 설정된 경우, 호스트 프로젝트의 GKE 서비스 계정이 삭제되었거나 호스트 프로젝트에 Kubernetes Engine 서비스 에이전트(container.serviceAgent) 역할이 없는 것입니다. GKE 서비스 계정 또는 역할 결합을 복원하려면 Kubernetes Engine API를 사용 중지한 후 다시 사용 설정해야 합니다. 자세한 내용은 Google Kubernetes Engine 문제 해결을 참조하세요.

참고: 호스트 프로젝트에서 Kubernetes Engine API를 사용 중지해도 서비스 프로젝트의 기존 클러스터의 작동에는 영향이 없습니다. 하지만 서비스 프로젝트나 호스트 프로젝트에서 공유 VPC 네트워크를 사용하는 새 클러스터를 만들 수 없고 Kubernetes Engine API는 사용 중지됩니다.