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

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

개요

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

공유 VPC는 영역 및 리전 클러스터 모두에 사용할 수 있습니다. 공유 VPC를 사용하는 클러스터는 이전 네트워크를 사용할 수 없으며, 별칭 IP가 사용 설정되어 있어야 합니다.

새 클러스터를 만들 때 공유 VPC를 구성할 수 있습니다. Google Kubernetes Engine은 공유 VPC 모델에 대한 기존 클러스터 전환을 지원하지 않습니다.

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

예시 정보

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

이 가이드의 예시에서는 특정 이름 및 주소 범위를 사용하여 일반적 절차를 보여줍니다. 원하는 경우 자신의 요구에 맞게 이름 및 주소 범위를 변경할 수 있습니다. 또한 연습에서는 us-central1리전 및 us-central1-a 영역이 사용됩니다. 원하는 경우 자신의 요구에 맞게 리전 및 영역을 변경할 수 있습니다.

시작하기 전에

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

  • Google Cloud 조직이 있어야 합니다.
  • 조직에 3개의 Google Cloud 프로젝트가 있어야 합니다.
  • 공유 VPC에서 사용하는 다양한 ID 및 액세스 관리(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 도구 또는 Google Cloud Console을 사용하여 프로젝트 ID 및 번호를 찾을 수 있습니다.

Console

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

    홈페이지로 이동

  2. 프로젝트 선택기에서 호스트 프로젝트로 선택한 프로젝트를 선택합니다.

  3. 프로젝트 정보에서 프로젝트 이름, 프로젝트 ID, 프로젝트 번호를 볼 수 있습니다. 나중을 위해 ID와 번호를 기록해 둡니다.

  4. 서비스 프로젝트로 선택한 각 프로젝트의 동일한 작업을 수행합니다.

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

프로젝트에서 Google Kubernetes Engine API 사용 설정

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

Google Cloud Console 또는 gcloud 도구를 사용하여 Google Kubernetes Engine API를 사용 설정할 수 있습니다.

Console

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

gcloud

3개의 프로젝트에 대해 Google Kubernetes Engine 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개의 서브넷 만들기

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

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

Console

  1. Cloud Console에서 VPC 네트워크 페이지로 이동합니다.
    VPC 네트워크 페이지로 이동
  2. 프로젝트 선택도구에서 호스트 프로젝트를 선택합니다.
  3. VPC 네트워크 만들기를 클릭합니다.
  4. 이름shared-net을 입력합니다.
  5. 서브넷 생성 모드 아래에서 커스텀을 선택합니다.
  6. 새 서브넷 상자의 이름tier-1을 입력합니다.
  7. 리전에서 us-central1을 선택합니다.
  8. IP 주소 범위10.0.4.0/22를 입력합니다.
  9. 보조 IP 범위 만들기를 클릭합니다. 서브넷 범위 이름tier-1-services를 입력하고, 보조 IP 범위10.0.32.0/20을 입력합니다.
  10. IP 범위 추가를 클릭합니다. 서브넷 범위 이름tier-1-pods를 입력하고, 보조 IP 범위10.4.0.0/14를 입력합니다.
  11. + 서브넷 추가를 클릭합니다.
  12. 이름tier-2를 입력합니다.
  13. 리전에서 us-central1을 선택합니다.
  14. IP 주소 범위172.16.4.0/22를 입력합니다.
  15. 보조 IP 범위 만들기를 클릭합니다. 서브넷 범위 이름tier-2-services를 입력하고, 보조 IP 범위172.16.16.0/20을 입력합니다.
  16. IP 범위 추가를 클릭합니다. 서브넷 범위 이름tier-2-pods를 입력하고, 보조 IP 범위172.20.0.0/14를 입력합니다.
  17. 만들기를 클릭합니다.

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 us-central1 \
    --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 us-central1 \
    --secondary-range tier-2-services=172.16.16.0/20,tier-2-pods=172.20.0.0/14

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

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

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

서비스 계정 유형 서비스 계정 이름
GKE service-service-project-1-num@container-engine-robot.iam.gserviceaccount.com
service-service-project-2-num@container-engine-robot.iam.gserviceaccount.com
Google API service-project-1-num@cloudservices.gserviceaccount.com
service-project-2-num@cloudservices.gserviceaccount.com

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

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

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

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

Console

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

  1. Cloud Console에서 공유 VPC 페이지로 이동합니다.

    공유 VPC 페이지로 이동

  2. 프로젝트 선택도구에서 호스트 프로젝트를 선택합니다.

  3. 공유 VPC 설정을 클릭합니다. 호스트 프로젝트 사용 설정 화면이 표시됩니다.

  4. 저장하고 계속하기를 클릭합니다. 서브넷 선택 페이지가 표시됩니다.

  5. 공유 모드 아래에서 개별 서브넷을 선택합니다.

  6. 공유할 서브넷 아래에서 tier-1tier-2를 선택합니다. 다른 체크박스는 모두 지웁니다.

  7. 계속을 클릭합니다. 권한 부여 페이지가 표시됩니다.

  8. 서비스 프로젝트 연결 아래에서 첫 번째 서비스 프로젝트 및 두 번째 서비스 프로젝트를 선택합니다. 서비스 프로젝트 연결 아래에서 다른 체크박스는 모두 지웁니다.

  9. Kubernetes Engine 액세스 아래에서 사용 설정을 선택합니다.

  10. 저장을 클릭합니다. 새 페이지가 표시됩니다.

  11. 개별 서브넷 권한 아래에서 tier-1을 선택합니다.

  12. 오른쪽 창에서 두 번째 서비스 프로젝트에 속하는 서비스 계정을 삭제합니다. 즉, service-project2-num이 포함된 서비스 계정을 삭제합니다.

  13. 오른쪽 창에서 첫 번째 서비스 프로젝트에 속하는 Kubernetes Engine 및 Google API 서비스 계정 이름을 찾습니다. 목록에서 서비스 계정 이름을 모두 확인할 수 있습니다. 둘 중 하나라도 목록에 없으면, 구성원 추가 아래에 서비스 계정 이름을 입력하고 추가를 클릭합니다.

  14. 가운데 창의 개별 서브넷 권한 아래에서 tier-2를 선택하고 tier-1을 선택 해제합니다.

  15. 오른쪽 창에서 첫 번째 서비스 프로젝트에 속하는 서비스 계정을 삭제합니다. 즉, service-project-1-num이 포함된 서비스 계정을 삭제합니다.

  16. 오른쪽 창에서 두 번째 서비스 프로젝트에 속하는 Kubernetes Engine 및 Google API 서비스 계정 이름을 찾습니다. 목록에서 서비스 계정 이름을 모두 확인할 수 있습니다. 둘 중 하나라도 목록에 없으면, 구성원 추가 아래에 서비스 계정 이름을 입력하고 추가를 클릭합니다.

gcloud

  1. 호스트 프로젝트에서 공유 VPC를 사용 설정합니다.

    gcloud compute shared-vpc enable host-project-id
    
  2. 첫 번째 서비스 프로젝트를 호스트 프로젝트에 연결합니다.

    gcloud compute shared-vpc associated-projects add service-project-1-id \
        --host-project host-project-id
    
  3. 두 번째 서비스 프로젝트를 호스트 프로젝트에 연결합니다.

    gcloud compute shared-vpc associated-projects add service-project-2-id \
        --host-project host-project-id
    
  4. tier-1 서브넷의 IAM 정책을 가져옵니다.

    gcloud compute networks subnets get-iam-policy tier-1 \
       --project host-project-id \
       --region us-central1
    

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

  5. 다음 내용이 포함된 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 값입니다.

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

    gcloud compute networks subnets set-iam-policy tier-1 \
        tier-1-policy.yaml \
        --project host-project-id \
        --region us-central1
    
  7. tier-2 서브넷의 IAM 정책을 가져옵니다.

    gcloud compute networks subnets get-iam-policy tier-2 \
        --project host-project-id \
        --region us-central1
    

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

  8. 다음 내용이 포함된 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 값입니다.

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

    gcloud compute networks subnets set-iam-policy tier-2 \
        tier-2-policy.yaml \
        --project host-project-id \
        --region us-central1
    

GKE 클러스터가 호스트 프로젝트에 방화벽 리소스를 만들고 관리하도록 하려면 다음 태스크 중 하나를 수행하면 됩니다.

  • 호스트 프로젝트에서 Compute Security Admin 역할을 부여합니다.
  • compute.firewalls.*compute.networks.updatePolicy 권한이 있는 커스텀 역할을 서비스 프로젝트의 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 네트워크 사용자 특정 서브넷 또는 전체 호스트 프로젝트
service-service-project-num@container-engine-robot.iam.gserviceaccount.com 호스트 서비스 에이전트 사용자 호스트 프로젝트의 GKE 서비스 계정

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

각 서비스 프로젝트의 GKE 서비스 계정에는 호스트 프로젝트의 호스트 서비스 에이전트 사용자 역할에 대한 binding이 있어야 합니다. GKE 서비스 계정은 다음 형식을 사용합니다. 여기서 service-project-num은 서비스 프로젝트의 프로젝트 번호입니다.

service-service-project-num@container-engine-robot.iam.gserviceaccount.com

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

Console

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

gcloud

  1. 첫 번째 프로젝트의 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
    
  2. 두 번째 프로젝트의 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 범위 확인

클러스터를 만들 때는 클러스터의 Pod 및 서비스에 사용할 서브넷 및 보조 IP 범위를 지정해야 합니다. IP 범위를 사용하지 못하게 되는 이유는 몇 가지가 있습니다. 클러스터를 만들 때 Cloud Console을 사용하거나 gcloud 명령줄 도구를 사용하는지에 관계없이 사용 가능한 IP 범위를 지정해야 합니다.

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

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

gcloud

gcloud container subnets list-usable \
    --project service-project-id \
    --network-project host-project-id

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

이 명령어의 출력은 다음과 비슷합니다.

PROJECT   REGION       NETWORK      SUBNET          RANGE
xpn-host  us-central1  empty-vpc    empty-subnet    10.0.0.0/21
xpn-host  us-east1     some-vpc     some-subnet     10.0.0.0/19
    ┌──────────────────────┬───────────────┬─────────────────────────────┐
    │ SECONDARY_RANGE_NAME │ IP_CIDR_RANGE │            STATUS           │
    ├──────────────────────┼───────────────┼─────────────────────────────┤
    │ pods-range           │ 10.2.0.0/21   │ usable for pods or services │
    │ svc-range            │ 10.1.0.0/21   │ usable for pods or services │
    └──────────────────────┴───────────────┴─────────────────────────────┘
xpn-host  us-central1  shared-net   tier-2          172.16.4.0/22
    ┌──────────────────────┬────────────────┬─────────────────────────────┐
    │ SECONDARY_RANGE_NAME │ IP_CIDR_RANGE  │            STATUS           │
    ├──────────────────────┼────────────────┼─────────────────────────────┤
    │ tier-2-services      │ 172.16.16.0/20 │ usable for pods or services │
    │ tier-2-pods          │ 172.20.0.0/14  │ usable for pods or services │
    └──────────────────────┴────────────────┴─────────────────────────────┘
xpn-host  us-central1  shared-net   tier-1          10.0.4.0/22
    ┌──────────────────────┬───────────────┬─────────────────────────────┐
    │ SECONDARY_RANGE_NAME │ IP_CIDR_RANGE │            STATUS           │
    ├──────────────────────┼───────────────┼─────────────────────────────┤
    │ tier-1-services      │ 10.0.32.0/20  │ unusable                    │
    │ tier-1-pods          │ 10.4.0.0/14   │ usable for pods             │
    │ tier-1-extra         │ 10.8.0.0/14   │ usable for pods or services │
    └──────────────────────┴───────────────┴─────────────────────────────┘

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

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

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

보조 범위 참고 사항

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

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

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

Console

  1. Cloud Console에서 Google Kubernetes Engine 메뉴로 이동합니다.

    Google Kubernetes Engine 메뉴로 이동

  2. 프로젝트 선택기에서 첫 번째 서비스 프로젝트를 선택합니다.

  3. 클러스터 만들기 버튼을 클릭합니다.

  4. 클러스터 이름tier-1-cluster를 입력합니다.

  5. 위치 유형으로 영역을 선택합니다.

  6. 영역 드롭다운 목록에서 us-central1-a를 선택합니다.

  7. 탐색창의 클러스터에서 네트워킹을 클릭합니다.

  8. VPC 기반 트래픽 라우팅 사용 설정(별칭 IP 사용)을 선택합니다.

  9. 보조 범위 자동 생성을 선택 취소합니다.

  10. 나와 공유된 네트워크(호스트 프로젝트: ...)를 선택합니다.

  11. 네트워크shared-net을 선택합니다.

  12. 노드 서브넷으로 tier-1을 선택합니다.

  13. Pod 보조 CIDR 범위tier-1-pods를 선택합니다.

  14. 서비스 보조 CIDR 범위tier-1-services를 선택합니다.

  15. 만들기를 클릭합니다.

  16. 만들기가 완료되면 클러스터 목록에서 tier-1-cluster를 클릭합니다.

  17. 노드 풀 아래에서 인스턴스 그룹의 이름을 클릭합니다. 예: gke-tier-1-cluster-default-pool-5c5add1f-grp.

  18. 인스턴스 목록에서 노드의 내부 IP 주소가 tier-2 서브넷의 기본 범위인 10.0.4.0/22에 있는지 확인합니다.

gcloud

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

gcloud container clusters create tier-1-cluster \
    --project service-project-1-id \
    --zone=us-central1-a \
    --enable-ip-alias \
    --network projects/host-project-id/global/networks/shared-net \
    --subnetwork projects/host-project-id/regions/us-central1/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-...  us-central1-a  ... 10.0.4.2
gke-tier-1-cluster-...  us-central1-a  ... 10.0.4.3
gke-tier-1-cluster-...  us-central1-a  ... 10.0.4.4

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

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

Console

  1. Cloud Console에서 Google Kubernetes Engine 메뉴로 이동합니다.

    Google Kubernetes Engine 메뉴로 이동

  2. 프로젝트 선택기에서 두 번째 서비스 프로젝트를 선택합니다.

  3. 클러스터 만들기 버튼을 클릭합니다.

  4. 클러스터 이름tier-2-cluster를 입력합니다.

  5. 위치 유형으로 영역을 선택합니다.

  6. 영역 드롭다운 목록에서 us-central1-a를 선택합니다.

  7. 탐색창의 클러스터에서 네트워킹을 클릭합니다.

  8. VPC 기반 트래픽 라우팅 사용 설정(별칭 IP 사용)을 선택합니다.

  9. 보조 범위 자동 생성을 선택 취소합니다.

  10. 나와 공유된 네트워크(호스트 프로젝트: ...)를 선택합니다.

  11. 네트워크shared-net을 선택합니다.

  12. 노드 서브넷으로 tier-2를 선택합니다.

  13. Pod 보조 CIDR 범위tier-2-pods를 선택합니다.

  14. 서비스 보조 CIDR 범위tier-2-services를 선택합니다.

  15. 만들기를 클릭합니다.

  16. 만들기가 완료되면 클러스터 목록에서 tier-2-cluster를 클릭합니다.

  17. 노드 풀 아래에서 인스턴스 그룹의 이름을 클릭합니다. 예: gke-tier-2-cluster-default-pool-5c5add1f-grp.

  18. 인스턴스 목록에서 노드의 내부 IP 주소가 tier-2 서브넷의 기본 범위인 172.16.4.0/22에 있는지 확인합니다.

gcloud

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

gcloud container clusters create tier-2-cluster \
    --project service-project-2-id \
    --zone=us-central1-a \
    --enable-ip-alias \
    --network projects/host-project-id/global/networks/shared-net \
    --subnetwork projects/host-project-id/regions/us-central1/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-...  us-central1-a  ... 172.16.4.2
gke-tier-2-cluster-...  us-central1-a  ... 172.16.4.3
gke-tier-2-cluster-...  us-central1-a  ... 172.16.4.4

방화벽 규칙 만들기

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

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

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

Console

  1. Cloud Console에서 방화벽 페이지로 이동합니다.

    방화벽 규칙 페이지로 이동

  2. 프로젝트 선택도구에서 호스트 프로젝트를 선택합니다.

  3. VPC 네트워킹 메뉴에서 방화벽 규칙 만들기를 클릭합니다.

  4. 이름my-shared-net-rule을 입력합니다.

  5. 네트워크shared-net을 선택합니다.

  6. 트래픽 방향으로 수신을 선택합니다.

  7. 일치 시 작업으로 허용을 선택합니다.

  8. 대상으로 네트워크의 모든 인스턴스를 선택합니다.

  9. 소스 필터IP 범위를 선택합니다.

  10. 소스 IP 범위0.0.0.0/0을 입력합니다.

  11. 프로토콜 및 포트지정된 프로토콜 및 포트를 선택합니다. 상자에 tcp:22를 입력합니다.

  12. 만들기를 클릭합니다.

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를 사용하여 노드에 연결합니다.

Console

  1. Cloud Console에서 Google Kubernetes Engine 메뉴로 이동합니다.

    방화벽 규칙 페이지로 이동

  2. 프로젝트 선택기에서 첫 번째 서비스 프로젝트를 선택합니다.

  3. tier-1-cluster를 클릭합니다.

  4. 노드 풀 아래에서 인스턴스 그룹의 이름을 클릭합니다. 예: gke-tier-1-cluster-default-pool-faf87d48-grp.

  5. 노드 목록에서 노드의 내부 IP 주소를 기록해 둡니다. 이러한 주소는 10.0.4.0/22 범위에 있습니다.

  6. 노드 중 하나의 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 us-central1-a \

여기서 node-name은 노드 중 하나의 이름입니다.

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

  1. SSH 명령줄 창에서 CoreOS 도구 상자를 시작합니다.

    /usr/bin/toolbox
    
  2. 도구 상자 셸에서 동일 클러스터에 있는 다른 노드 중 하나를 핑합니다. 예를 들면 다음과 같습니다.

    ping 10.0.4.4
    

    해당 노드 및 다른 노드가 모두 10.0.4.0/22 범위에 있기 때문에 ping 명령어가 성공합니다.

  3. 이제 다른 서비스 프로젝트에 있는 클러스터의 노드 중 하나에 핑을 시도합니다. 예를 들면 다음과 같습니다.

    ping 172.16.4.3
    

    방화벽 규칙에서 ICMP(인터넷 제어 메시지 프로토콜) 트래픽이 허용되지 않기 때문에 이번에는 ping 명령어가 실패합니다.

  4. 도구 상자 셸이 아닌 일반적인 명령어 프롬프트에서 ICMP를 허용하도록 방화벽 규칙을 업데이트하세요.

    gcloud compute firewall-rules update my-shared-net-rule \
       --project host-project-id \
       --allow tcp:22,icmp
    
  5. 도구 상자 셸에서 노드에 다시 핑을 수행합니다. 예를 들면 다음과 같습니다.

    ping 172.16.4.3
    

    이번에는 ping 명령어가 성공합니다.

추가 방화벽 규칙 만들기

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

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

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에 있는 모든 노드, Pod 또는 서비스의 트래픽 전송을 허용합니다.

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에 부여하려면 다음 중 하나를 수행합니다.

  • 호스트 프로젝트에서 Compute Security Admin 역할을 부여합니다.
  • compute.firewalls.*compute.networks.updatePolicy 권한이 있는 커스텀 역할을 서비스 프로젝트의 GKE 서비스 계정에 부여합니다.

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

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

비공개 클러스터에 공유 VPC를 사용할 수 있습니다. 이를 위해서는 특별한 설정이 필요하지 않습니다. 하지만 제어 영역(마스터) CIDR 범위가 공유 네트워크에 있는 다른 예약된 범위와 겹치지 않는지 확인해야 합니다.

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

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

Console

  1. Cloud Console에서 Google Kubernetes Engine 메뉴로 이동합니다.

    Google Kubernetes Engine 메뉴로 이동

  2. 클러스터 만들기 버튼을 클릭합니다.

  3. 클러스터 이름private-cluster-vpc를 입력합니다.

  4. 탐색창의 클러스터에서 네트워킹을 클릭합니다.

  5. 비공개 클러스터를 클릭합니다.

  6. 외부 IP 주소를 사용하여 마스터에 액세스 체크박스가 선택되어 있는지 확인합니다.

  7. 마스터 IP 범위172.16.0.16/28로 설정합니다.

  8. 네트워크 드롭다운 목록에서 이전에 만든 VPC 네트워크를 선택합니다.

  9. 노드 서브넷 드롭다운 목록에서 이전에 만든 공유 서브넷을 선택합니다.

  10. VPC 기반 트래픽 라우팅 사용(별칭 IP 사용) 체크박스가 선택되어 있는지 확인합니다.

  11. 원하는 대로 클러스터를 구성합니다.

  12. 만들기를 클릭합니다.

gcloud

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

gcloud container clusters create private-cluster-vpc \
    --project project-id \
    --enable-ip-alias \
    --network projects/host-project/global/networks/shared-net \
    --subnetwork shared-subnetwork \
    --cluster-secondary-range-name c0-pods \
    --services-secondary-range-name c0-services \
    --enable-private-nodes \
    --master-ipv4-cidr 172.16.0.0/28

IP 주소 예약

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

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

gcloud 명령줄 도구에서 다음 명령어를 사용하여 내부 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개의 클러스터를 삭제합니다.

Console

  1. Cloud Console에서 Google Kubernetes Engine 메뉴로 이동합니다.

    Google Kubernetes Engine 메뉴로 이동

  2. 프로젝트 선택기에서 첫 번째 서비스 프로젝트를 선택합니다.

  3. tier-1-cluster를 선택하고 삭제를 클릭합니다.

  4. 프로젝트 선택기에서 두 번째 서비스 프로젝트를 선택합니다.

  5. tier-2-cluster를 선택하고 삭제를 클릭합니다.

gcloud

gcloud container clusters delete tier-1-cluster \
    --project service-project-1-id \
    --zone us-central1-a

gcloud container clusters delete tier-2-cluster \
    --project service-project-2-id \
    --zone us-central1-a

공유 VPC 사용 중지

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

Console

  1. Cloud Console에서 공유 VPC 페이지로 이동합니다.

    공유 VPC 페이지로 이동

  2. 프로젝트 선택도구에서 호스트 프로젝트를 선택합니다.

  3. 공유 VPC 사용 중지를 클릭합니다.

  4. 텍스트 상자에 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

방화벽 규칙 삭제

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

Console

  1. Cloud Console에서 방화벽 페이지로 이동합니다.

    방화벽 규칙 페이지로 이동

  2. 프로젝트 선택도구에서 호스트 프로젝트를 선택합니다.

  3. 규칙 목록에서 my-shared-net-rule, my-shared-net-rule-2, my-shared-net-rule-3을 선택합니다.

  4. 삭제를 클릭합니다.

gcloud

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

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

공유 네트워크 삭제

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

Console

  1. Cloud Console에서 VPC 네트워크 페이지로 이동합니다.

    VPC 네트워크 페이지로 이동

  2. 프로젝트 선택도구에서 호스트 프로젝트를 선택합니다.

  3. 네트워크 목록에서 share-net을 선택합니다.

  4. VPC 네트워크 삭제를 클릭합니다.

gcloud

gcloud compute networks subnets delete tier-1 \
    --project host-project-id \
    --region us-central1

gcloud compute networks subnets delete tier-2 \
    --project host-project-id \
    --region us-central1

gcloud compute networks delete shared-net --project host-project-id

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

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

Console

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

    IAM 페이지로 이동

  2. 프로젝트 선택도구에서 호스트 프로젝트를 선택합니다.

  3. 구성원 목록에서 service-service-project-1-num@container-engine-robot.iam.gserviceaccount.com에 Kubernetes Engine 호스트 서비스 에이전트 사용자 역할이 부여되었음을 나타내는 행을 선택합니다.

  4. service-service-project-2-num@container-engine-robot.iam.gserviceaccount.com에 Kubernetes Engine 호스트 서비스 에이전트 사용자 역할이 부여되었음을 나타내는 행을 선택합니다.

  5. 삭제를 클릭합니다.

gcloud

  1. 첫 번째 서비스 프로젝트의 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
    
  2. 두 번째 서비스 프로젝트의 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
    

알려진 문제

부하 분산기 생성에 대한 방화벽 이벤트

Kubernetes 서비스 계정에 방화벽 관리 권한이 부여되지 않은 경우 Kubernetes 서비스 컨트롤러가 필요한 방화벽 변경에 따라 이벤트를 만들지 못할 수 있습니다. 이것은 Kubernetes 버전 1.9 이하의 RBAC 권한 문제 때문입니다. 서비스 컨트롤러에 이벤트를 발생시킬 수 있는 기능이 없습니다.

이 문제를 해결하려면 이벤트 생성을 허용하는 RBAC 정책이 포함된 다음 YAML 파일을 적용합니다.

Kubernetes 1.10 이상을 기준으로 하는 클러스터에는 이미 이러한 RBAC 정책이 적용되어 있습니다.

문제해결

승인 거부됨

증상

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 서비스 계정이 존재하지 않습니다. 예를 들어 삭제되었을 수 있습니다.

  • 호스트 프로젝트의 Google Kubernetes Engine 서비스 계정에는 호스트 프로젝트에 Kubernetes Engine 서비스 에이전트(container.serviceAgent) 역할이 없습니다. binding이 실수로 삭제되었을 수 있습니다.

  • 서비스 프로젝트의 Google Kubernetes Engine 서비스 계정에 호스트 프로젝트의 호스트 서비스 에이전트 사용자 역할이 없습니다.

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

  • 호스트 프로젝트에서 Kubernetes Engine API가 사용 설정되지 않은 경우, 사용 설정합니다. 그러면 호스트 프로젝트의 Google Kubernetes Engine 서비스 계정이 생성되고 호스트 프로젝트의 Google Kubernetes Engine 서비스 계정에 호스트 프로젝트의 Kubernetes Engine 서비스 에이전트(container.serviceAgent) 역할이 부여됩니다.

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

다음 단계