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

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

개요

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

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

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

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

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

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

시작하기 전에

이 작업을 수행하기 위해서는 Cloud Platform 조직이 있어야 하고, 조직 내에 3개의 Cloud Platform 프로젝트가 있어야 합니다.

조직에서 컴퓨팅 공유 VPC 관리자 역할을 부여 받아야 합니다.

이 항목의 연습을 수행하기 전, 프로젝트 중 하나를 호스트 프로젝트로 사용하도록 선택하고, 프로젝트 중 2개를 서비스 프로젝트로 사용하도록 선택합니다. 각 프로젝트에는 이름, ID, 번호가 포함됩니다. 일부 경우에는 이름과 ID가 동일합니다. 이 항목에서는 다음과 같은 친숙한 이름을 사용하여 프로젝트를 참조합니다.

  • 호스트 프로젝트
  • 첫 번째 서비스 프로젝트
  • 두 번째 서비스 프로젝트

이 항목에서는 다음과 같은 자리표시자를 사용해서 프로젝트 ID와 번호를 참조합니다.

  • [HOST_PROJECT_ID]는 호스트 프로젝트의 프로젝트 ID입니다.
  • [HOST_PROJECT_NUM]은 호스트 프로젝트의 프로젝트 번호입니다.
  • [SERVICE_PROJECT_1_ID]는 첫 번째 서비스 프로젝트의 프로젝트 ID입니다.
  • [SERVICE_PROJECT_1_NUM]은 첫 번째 서비스 프로젝트의 프로젝트 번호입니다.
  • [SERVICE_PROJECT_2_ID]는 두 번째 서비스 프로젝트의 프로젝트 ID입니다.
  • [SERVICE_PROJECT_2_NUM]은 두 번째 서비스 프로젝트의 프로젝트 번호입니다.

프로젝트 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

콘솔

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

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

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

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]

콘솔

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

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

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

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

콘솔

  1. GCP 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. 만들기를 클릭합니다.

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

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

다음은 2개의 서비스 프로젝트에 있는 GKE 서비스 계정의 이름입니다.

  • service-[SERVICE_PROJECT_1_NUM]@container-engine-robot.iam.gserviceaccount.com
  • service-[SERVICE_PROJECT_2_NUM]@container-engine-robot.iam.gserviceaccount.com

다음은 2개의 서비스 프로젝트에 있는 Google API 서비스 계정의 이름입니다.

  • [SERVICE_PROJECT_1_NUM]@cloudservices.gserviceaccount.com
  • [SERVICE_PROJECT_2_NUM]@cloudservices.gserviceaccount.com

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

호스트 프로젝트에서 공유 VPC를 사용 설정하고 2개의 서비스 프로젝트를 호스트 프로젝트에 연결합니다. 그런 후 서비스 프로젝트에 속하는 서비스 계정에 적절한 역할을 부여합니다.

gcloud

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

gcloud 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 beta compute networks subnets get-iam-policy tier-1 \
   --project [HOST_PROJECT_ID] \
   --region us-central1

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

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

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

여기서 [ETAG_STRING]은 이전에 기록해 둔 etag 값입니다.

tier-1 서브넷에 대한 IAM 정책을 설정합니다.

gcloud beta compute networks subnets set-iam-policy tier-1 \
    tier-1-policy.yaml \
    --project [HOST_PROJECT_ID] \
    --region us-central1

이제 tier-2 서브넷에 대한 IAM 정책을 가져옵니다.

gcloud beta compute networks subnets get-iam-policy tier-2 \
   --project [HOST_PROJECT_ID] \
   --region us-central1

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

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

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

여기서 [ETAG_STRING]은 이전에 기록해 둔 etag 값입니다.

tier-2 서브넷에 대한 IAM 정책을 설정합니다.

gcloud beta compute networks subnets set-iam-policy tier-2 \
    tier-2-policy.yaml \
    --project [HOST_PROJECT_ID] \
    --region us-central1

콘솔

다음 단계에 따라 공유 VPC를 사용 설정하고, 서비스 프로젝트를 연결하고, 역할을 부여합니다.

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

위 단계의 목적은 4개의 서비스 계정에 적절한 Cloud IAM 역할을 부여하기 위한 것입니다. 첫 번째 서비스 프로젝트에 있는 2개의 서비스 계정에는 호스트 프로젝트의 tier-1 서브넷에 대해 컴퓨팅 네트워크 사용자 역할이 부여됩니다. 그리고 두 번째 서비스 프로젝트에 있는 2개의 서비스 계정에는 호스트 프로젝트의 tier-2 서브넷에 대해 컴퓨팅 네트워크 사용자 역할이 부여됩니다.

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

  • service-[SERVICE_PROJECT_1_NUM]@container-engine-robot.iam.gserviceaccount.com 서비스 계정에는 tier-1 서브넷에 대한 컴퓨팅 네트워크 사용자 역할이 부여됩니다.

  • [SERVICE_PROJECT_1_NUM]@cloudservices.gserviceaccount.com 서비스 계정에는 tier-1 서브넷에 대한 컴퓨팅 네트워크 사용자 역할이 부여됩니다.

  • service-[SERVICE_PROJECT_2_NUM]@container-engine-robot.iam.gserviceaccount.com 서비스 계정에는 tier-2 서브넷에 대한 컴퓨팅 네트워크 사용자 역할이 부여됩니다.

  • [SERVICE_PROJECT_2_NUM]@cloudservices.gserviceaccount.com 서비스 계정에는 tier-2 서브넷에 대한 컴퓨팅 네트워크 사용자 역할이 부여됩니다.

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

각 서비스 프로젝트에서 호스트 서비스 에이전트 사용자 역할을 GKE 서비스 계정에 부여해야 합니다. 그러면 서비스 프로젝트의 GKE 서비스 계정이 호스트 프로젝트의 GKE 서비스 계정을 사용하여 공유 네트워크 리소스를 구성할 수 있습니다.

호스트 서비스 에이전트 사용자 역할은 서비스 프로젝트의 서비스 계정에만 부여됩니다. 사용자에게는 부여할 수 없습니다.

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

콘솔

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

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

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

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

gcloud

gcloud beta 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 │
    └──────────────────────┴───────────────┴─────────────────────────────┘

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

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

gcloud

첫 번째 서비스 프로젝트에서 클러스터를 만듭니다.

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

콘솔

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

    Google Kubernetes Engine 메뉴로 이동

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

  3. 클러스터 만들기를 클릭합니다.

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

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

  6. 영역으로 us-central1-a를 선택합니다.

  7. 페이지 하단에서 고급 옵션을 클릭합니다.

  8. VPC 네이티브 섹션에서 VPC 네이티브 사용(별칭 IP 사용)을 선택합니다.

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

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

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

  12. 포드 보조 CIDR 범위tier-1-pods를 선택합니다.

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

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

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

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

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

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

gcloud

두 번째 서비스 프로젝트에서 클러스터를 만듭니다.

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

콘솔

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

    Google Kubernetes Engine 메뉴로 이동

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

  3. 클러스터 만들기를 클릭합니다.

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

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

  6. 영역으로 us-central1-a를 선택합니다.

  7. 페이지 하단에서 고급 옵션을 클릭합니다.

  8. VPC 네이티브 섹션에서 VPC 네이티브 사용(별칭 IP 사용)을 선택합니다.

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

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

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

  12. 포드 보조 CIDR 범위tier-2-pods를 선택합니다.

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

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

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

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

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

방화벽 규칙 만들기

호스트 프로젝트에서 shared-net 네트워크에 대한 방화벽 규칙을 만듭니다. 트래픽이 TCP 포트 22로 전송되도록 허용합니다. 이렇게 하면 SSH를 사용해서 클러스터 노드에 연결할 수 있습니다.

gcloud

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

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

콘솔

  1. GCP 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. 만들기를 클릭합니다.

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. GCP 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에 사용되기 때문에 이 작업은 성공합니다.

노드 간 핑

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 명령어가 성공합니다.

추가 방화벽 규칙 만들기

클러스터에서 노드, 포드, 서비스 간 통신을 허용하도록 추가 방화벽 규칙을 만들 수 있습니다. 예를 들어 다음 규칙은 모든 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에 권한을 부여하려면, 호스트 프로젝트로 이동하고, Compute Security Admin 역할 또는 compute.firewalls.* 권한이 포함된 커스텀 역할을 서비스 프로젝트의 GKE 서비스 계정에 부여하면 됩니다.

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

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

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

공유 VPC에 있는 비공개 클러스터 수는 25개로 제한됩니다.

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

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

콘솔

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

    GKE 메뉴로 이동

  2. 클러스터 만들기를 클릭합니다.

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

  4. 메뉴 하단에서 고급 옵션을 클릭합니다.

  5. VPC 네이티브에서 VPC 네이티브 사용(별칭 IP 사용) 체크박스를 선택합니다.

  6. 네트워크 드롭다운 메뉴에서 이전에 만든 VPC 네트워크를 선택합니다.

  7. 노드 서브넷 드롭다운 메뉴에서 이전에 만든 공유 서브넷을 선택합니다.

  8. 네트워크 보안에서 비공개 클러스터 체크박스를 선택합니다.

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

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

  11. 원하는 대로 클러스터를 구성합니다. 그런 다음 만들기를 클릭합니다.

보조 범위 참고 사항

지정된 서브넷에서 5개의 보조 범위를 만들 수 있습니다. 각 클러스터에는 포드 및 서비스에 대해 각각 하나씩 2개의 보조 범위가 필요합니다. 즉, 지정된 서브넷을 사용하는 2개의 클러스터만 만들 수 있습니다.

참고: 기본 범위 및 포드 보조 범위는 클러스터 간에 공유될 수 있지만, 권장되는 구성이 아닙니다.

알려진 문제

보조 CIDR 범위가 다른 클러스터에서 사용될 수 있음

Google Cloud Platform Console로 공유 VPC 클러스터를 만들 때 포드 및 서비스에 대해 제안되는 보조 범위가 다른 클러스터에서 이미 사용 중일 수 있습니다. 이러한 CIDR 범위로 클러스터가 생성된 경우, 클러스터 생성 작업이 오류 상태로 실패합니다.

이 문제가 발생하면, 오류 상태의 클러스터를 삭제합니다. 클러스터를 다시 만들기 전에 새 클러스터에서 보조 범위를 사용할 수 있는지 확인합니다.

이 문제는 이후 릴리스에서 수정될 예정입니다.

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

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

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

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

삭제

이 페이지의 연습을 완료한 후에는 다음 단계에 따라 자신의 계정에 원치 않는 비용이 발생하지 않도록 리소스를 삭제합니다.

클러스터 삭제

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

콘솔

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

    Google Kubernetes Engine 메뉴로 이동

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

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

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

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

공유 VPC 사용 중지

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]

콘솔

  1. GCP Console에서 공유 VPC 페이지로 이동합니다.
    공유 VPC 페이지로 이동
  2. 프로젝트 선택기에서 호스트 프로젝트를 선택합니다.
  3. 공유 VPC 사용 중지를 클릭합니다.
  4. 입력란에 [HOST_PROJECT_ID]를 입력하고 사용 안함을 클릭합니다.

방화벽 규칙 삭제

gcloud

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

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

콘솔

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

    방화벽 규칙 페이지로 이동

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

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

  4. 삭제를 클릭합니다.

shared-net 네트워크 삭제

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]

콘솔

  1. GCP Console에서 VPC 네트워크 페이지로 이동합니다.
    VPC 네트워크 페이지로 이동
  2. 프로젝트 선택기에서 호스트 프로젝트를 선택합니다.
  3. 네트워크 목록에서 shared-net을 클릭합니다.
  4. VPC 네트워크 삭제를 클릭합니다.

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

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

콘솔

  1. GCP 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. 삭제를 클릭합니다.ㅇ

다음 단계

이 페이지가 도움이 되었나요? 평가를 부탁드립니다.

다음에 대한 의견 보내기...

Kubernetes Engine