프로덕션을 위한 Google Kubernetes Engine 환경 준비

이 솔루션은 Google Kubernetes Engine에 더욱 안전하고 안정적이며 비용 효율적으로 작업 부하를 온보딩하기 위한 청사진 및 방법론을 제공합니다. 클러스터에 대한 관리 및 네트워크 액세스를 구성하기 위한 지침을 제공합니다. 이 문서는 Kubernetes 리소스 및 클러스터 관리에 대한 올바른 이해와 Google Cloud Platform(GCP) 네트워킹 기능에 익숙해지는 것을 목표로 합니다.

프로젝트, 가상 사설 클라우드(VPC) 네트워크, 클러스터 구성

다음 다이어그램은 프로젝트, VPC 네트워크, 지역, 하위 네트워크, 영역, 클러스터에 대한 최상의 구조를 보여줍니다.

프로젝트, 네트워크, 클러스터 구조

프로젝트

GCP는 프로젝트 항목 내에 모든 리소스를 생성합니다. 프로젝트는 결제 단위이며 관리자가 Cloud Identity and Access Management(Cloud IAM) 역할을 사용자와 연결하도록 합니다. 역할이 프로젝트 수준에서 적용되면, 역할은 프로젝트 내에서 캡슐화된 모든 리소스에 적용됩니다.

프로젝트를 사용하여 다양한 운영 환경을 캡슐화해야 합니다. 예를 들어 운영팀용 productionstaging 프로젝트와 개발자용 test-dev 프로젝트가 있다고 가정해 봅니다. 가장 중요하고 민감한 데이터 및 작업 부하를 보유하는 프로젝트에는 상세하고 엄격한 정책을 적용하는 반면, 실험을 위한 test-dev 환경에 있는 개발자에게는 관대하고 유연한 정책을 적용할 수 있습니다.

클러스터

프로젝트에 여러 클러스터가 포함될 수 있습니다. 배포할 작업 부하가 여러 개인 경우 이 작업 부하에 대해 단일 공유 클러스터 또는 별도의 클러스터를 사용하도록 선택할 수 있습니다. 결정에 도움이 필요한 경우 GKE 클러스터의 크기 및 범위 선택에 관한 권장사항을 참고하세요.

네트워크 및 하위 네트워크

각 프로젝트 내에서 실제 네트워크의 가상 버전인 1개 이상의 VPC 네트워크를 가질 수 있습니다. 각 VPC 네트워크는 하위 네트워크, 외부 IP 주소, 방화벽 규칙, 경로, VPN, Cloud Router와 같은 기타 네트워킹 관련 리소스를 포함하는 글로벌 리소스입니다. VPC 네트워크 내에서 지역 리소스인 하위 네트워크를 사용하여 GKE 클러스터 간의 각 지역 안팎으로 트래픽을 격리하고 제어할 수 있습니다.

각 프로젝트에는 단일 기본 네트워크가 있습니다. 기존 IP 주소 관리(IPAM) 규칙에 매핑할 추가 네트워크를 만들고 구성할 수 있습니다. 이 네트워크에 방화벽 규칙을 적용하여 GKE 노드와의 트래픽을 필터링할 수 있습니다. 기본적으로 GKE 노드에 대한 모든 인터넷 트래픽은 거부됩니다.

하위 네트워크 간의 통신을 제어하려면 트래픽이 하위 네트워크 사이를 오갈 수 있도록 방화벽 규칙을 만들어야 합니다. 클러스터 또는 노드 풀 생성 중 --tags 플래그를 사용하여 GKE 노드에 태그를 적절히 지정하여 방화벽 규칙을 적용합니다. 필요한 경우 태그를 사용하여 하위 네트워크 간 경로를 만들 수도 있습니다.

다중 영역 및 지역 클러스터

기본적으로 클러스터는 개발자가 생성 시 지정하는 단일 영역에 클러스터 마스터와 해당 노드를 만듭니다. 다중 영역 또는 지역 클러스터를 만들어서 클러스터의 가용성 및 복구성을 향상시킬 수 있습니다. 다중 영역 및 지역 클러스터는 지역 내 여러 영역에 Kubernetes 리소스를 배포합니다.

다중 영역 클러스터:

  • 하나의 영역에 단일 클러스터 마스터를 만듭니다.
  • 다중 영역에 노드를 만듭니다.

지역 클러스터:

  • 3개의 영역에 걸쳐 3개의 클러스터 마스터를 만듭니다.
  • 기본적으로 3개의 영역 또는 원하는 수만큼 여러 영역에 노드를 만듭니다.

지역 클러스터와 다중 영역 클러스터의 주요 차이점은 지역 클러스터는 3개의 마스터를 만들고 다중 영역 클러스터는 1개만 만든다는 점입니다. 두 경우 모두 영역 사이의 노드 간 트래픽 비용이 청구됩니다.

클러스터를 생성할 때 다중 영역 또는 지역 클러스터를 만들도록 선택할 수 있습니다. 기존 클러스터에 새 영역을 추가하여 다중 영역으로 만들 수 있습니다. 그러나 기존 클러스터를 수정하여 지역 클러스터로 만들 수는 없습니다. 또한 지역 클러스터를 지역이 아닌 것으로 만들 수 없습니다.

다중 영역 및 지역 클러스터에 대한 자세한 내용은 GKE 문서를 참조하세요.

ID 및 액세스 관리

프로젝트 수준 액세스

이전 섹션에서는 IAM 역할을 프로젝트 수준의 사용자에게 결합할 수 있다고 언급했습니다. 개별 사용자에게 역할을 부여하는 것 외에도 그룹을 사용하여 역할 적용을 단순화할 수 있습니다.

다음은 곧 출시될 기능 및 버그 수정과 프로덕션 트래픽을 위한 prod 프로젝트를 개발하고 테스트하도록 설정된 개발자용 dev 프로젝트에 최소 권한 원칙을 제공하는 IAM 정책 레이아웃을 보여주는 그림입니다.

ID 및 액세스 관리

다음 표는 2가지 프로젝트 사이에서 IAM 역할을 통해 부여되는 다양한 수준의 권한을 가진 4가지 유형의 조직 내 사용자 그룹을 보여줍니다.

IAM 역할 프로젝트 권한
개발자 container.developer dev 프로젝트 내의 기존 클러스터에 대해 Kubernetes 리소스를 만들 수 있으며, 클러스터를 만들거나 삭제할 수 없습니다.
운영 container.admin prod 프로젝트 내에서 실행되는 클러스터 및 Kubernetes 리소스에 대한 전체 관리 액세스 권한입니다.
보안 container.viewer
security.admin
prod 방화벽 규칙 및 SSL 인증서를 생성, 수정, 삭제할 뿐만 아니라 실행 중인 포드의 로그를 포함하여 각 클러스터 내에서 생성된 리소스를 확인합니다.
네트워크 network.admin prod 방화벽 규칙과 SSL 인증서를 제외한 네트워킹 리소스를 생성, 수정, 삭제합니다.

prod 프로젝트에 대한 액세스 권한이 있는 3개 팀 외에도 추가 서비스 계정prod를 위한 container.developer 역할이 부여되어 클러스터 내의 리소스를 생성, 나열, 삭제할 수 있습니다. 서비스 계정은 자동화 스크립트 또는 배포 프레임워크에 사용자를 대신할 수 있는 기능을 제공합니다. 프로덕션 프로젝트 및 클러스터 배포는 자동화된 파이프라인을 거쳐야 합니다.

dev 프로젝트에는 동일한 클러스터 내의 동일한 애플리케이션에서 작업하는 여러 명의 개발자가 있습니다. 이는 클러스터 사용자가 작성할 수 있는 네임스페이스의 도움을 받습니다. 각 개발자는 자체 네임스페이스 내에서 리소스를 만들 수 있으므로 이름 충돌을 피할 수 있습니다. 개발자는 동일한 YAML 구성 파일을 배포를 위해 다시 사용할 수 있으므로 개발 반복 중에 구성이 가능한 한 비슷하게 유지됩니다. 또한 네임스페이스를 사용하면 클러스터 내에서 CPU, 메모리, 저장소 사용량에 대한 할당량을 만들 수 있어서 1명의 개발자가 클러스터 내에서 너무 많은 리소스를 사용하지 않도록 할 수 있습니다. 다음 섹션에서는 사용자를 특정 네임스페이스 내에서만 작동하도록 제한하는 방법에 대해 설명합니다.

RBAC 승인

Kubernetes 1.6 이상을 실행하는 GKE 클러스터는 사용자가 개별 클러스터에서 수행할 수 있는 권한에 대한 추가 제한 사항을 활용할 수 있습니다. Cloud IAM은 사용자에게 전체 클러스터 및 그 안에 있는 리소스에 대한 액세스를 제공할 수 있지만, Kubernetes 역할 기반 액세스 제어(RBAC)를 사용하면 Kubernetes API를 사용하여 사용자가 클러스터 내에서 수행할 수 있는 작업을 더욱 제한할 수 있습니다.

RBAC를 사용하면 클러스터 관리자는 클러스터 내의 개별 네임스페이스 또는 클러스터 전체에 세밀한 정책을 적용합니다. Kubernetes 명령줄 인터페이스인 kubectl은 gcloud 도구의 활성 사용자 인증 정보를 사용하여 클러스터 관리자가 역할을 GCP ID(사용자 및 서비스 계정)에 RoleBindings의 주체로 매핑하게 합니다.

예를 들어 아래 그림에서 2명의 사용자 user-auser-bapp-a 네임스페이스에서 config-readerpod-reader 역할을 부여받았습니다.

RBAC 승인

또 다른 예로, 특정 사용자가 프로젝트의 모든 클러스터에 액세스할 수 있게 해주는 GCP 프로젝트 수준 IAM 역할이 있습니다. 또한 개별 네임스페이스 및 클러스터 수준 역할 바인딩이 RBAC를 통해 추가되어 특정 클러스터 또는 네임스페이스 내의 리소스에 대한 세밀한 액세스를 제공합니다.

IAM 역할 바인딩

Kubernetes에는 몇 가지 기본 역할이 포함되어 있지만, 클러스터 관리자는 조직의 요구사항에 보다 근접하게 매핑되는 역할을 만들 수 있습니다. 다음은 delete 동사가 포함되어 있지 않으므로 사용자가 ConfigMaps를 보고, 편집하고, 업데이트만 할 수 있도록 허용하는 역할 예입니다.

kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  namespace: default
  name: config-editor
rules:
- apiGroups: [""]
  resources: ["configmaps"]
  verbs: ["get", "list", "watch", "create", "update", "patch"]

역할을 정의한 후에는 해당 역할을 바인딩을 통해 클러스터 또는 네임스페이스에 적용할 수 있습니다. 바인딩은 사용자, 그룹 또는 서비스 계정에 역할을 연결합니다. 아래는 이전에 생성된 역할(config-editor)을 bob@example.org 사용자와 development 네임스페이스에 바인딩하는 예입니다.

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: config-editors
  namespace: development
subjects:
- kind: User
  name: bob@example.org
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: config-editor
  apiGroup: rbac.authorization.k8s.io

RBAC에 대한 자세한 내용은 GKE 문서를 참조하세요.

이미지 액세스 및 공유

Container Registry의 이미지는 Cloud Storage에 저장됩니다. 이 섹션에서는 이미지를 공유하는 2가지 방법에 대해 설명합니다. 1가지 방법은 이미지를 공개로 만드는 것이고 다른 하나는 프로젝트 간에 이미지를 공유하는 것입니다.

공개 이미지 만들기

객체와 버킷을 공개하여 이미지를 공개할 수 있습니다. 자세한 내용은 Container Registry 액세스 제어 문서를 참조하세요.

프로젝트 간 이미지 액세스

Kubernetes 노드가 서비스 계정을 사용하게 해서 프로젝트 간의 컨테이너 이미지를 공유할 수 있습니다. 프로젝트에 연결된 기본 서비스 계정은 양식 [PROJECT_ID]-compute@developer.gserviceaccount.com에 있습니다. 이 식별자를 가진 후에는 storage.viewer로서 Container Registry를 사용하려는 프로젝트에 액세스 권한을 부여할 수 있습니다. 그러나 기본 권한에는 전체 프로젝트에 대한 액세스 수정 권한이 있으므로 권한이 제한된 커스텀 서비스 계정을 사용하세요.

클러스터에 다른 서비스 계정을 사용하려면 --service-account 플래그를 사용하여 클러스터 또는 노드 풀 생성 시 서비스 계정을 제공합니다. 예를 들어, 프로젝트 my-project에서 gke-sa 서비스 계정을 사용하려면 다음을 수행하세요.

gcloud container clusters create west --service-account \
  gke-sa@my-project.google.com.iam.gserviceaccount.com

네트워킹 구성

Kubernetes는 클러스터 외부에서 실행되는 기존 시스템뿐만 아니라 클러스터 내의 포드 집합 전반에 걸쳐 부하 분산 및 서비스 검색을 제공하는 서비스 추상화 기능을 제공합니다. 아래 섹션에서는 Kubernetes 포드와 다른 Kubernetes 클러스터를 포함한 다른 시스템 간의 통신에 대한 권장사항을 설명합니다.

동일한 클러스터 내에서 통신

서비스 검색

Kubernetes를 사용하면 라벨 집합을 기반으로 클러스터에서 실행 중인 포드를 그룹화하는 서비스를 정의할 수 있습니다. 이 포드 그룹은 DNS를 사용하여 클러스터 내에서 검색할 수 있습니다. Kubernetes의 서비스 검색에 대한 자세한 내용은 서비스로 애플리케이션 연결 문서를 참조하세요.

DNS

클러스터 로컬 DNS 서버인 kube-dns는 정상적인 포드 IP에 서비스 이름을 매핑하는 것을 처리하는 각 GKE 클러스터에 배포됩니다. 기본적으로 Kubernetes DNS 서버는 서비스의 클러스터 IP 주소를 반환합니다. 이 IP 주소는 서비스 수명 주기 동안 고정입니다. 이 IP로 트래픽을 전송할 때 노드의 iptable은 서비스의 선택기와 일치하는 준비된 포드 사이에서 패킷을 부하 분산합니다. 이 iptable은 각 노드에서 실행 중인 kube-proxy 서비스에 의해 자동으로 프로그래밍됩니다.

서비스 검색 및 상태 모니터링을 원하지만 DNS 서비스가 가상 IP가 아닌 포드 IP를 반환하도록 하려면, ClusterIP 필드를 '없음'으로 설정한 서비스를 프로비저닝하여 헤드리스 서비스로 만듭니다. 이 경우 DNS 서버는 서비스의 DNS 이름이 서비스에서 정의한 라벨 선택기와 일치하는 준비된 포드의 A 레코드에 매핑하는 A 레코드 목록을 반환합니다. 응답의 레코드는 순환을 하면서 여러 포드에 걸쳐 부하 분산을 촉진합니다. 일부 클라이언트 측 DNS 리졸버는 DNS 응답을 캐시하여 A 레코드 순환을 비효율적으로 만듭니다. ClusterIP 사용의 장점은 Kubernetes 문서에 나열되어 있습니다.

헤드리스 서비스의 일반적인 사용 사례 중 하나는 StatefulSets입니다. StatefulSet은 복제본 간에 안정적인 저장소 및 네트워킹이 필요한 상태 저장 애플리케이션을 실행하는 데 적합합니다. 이러한 유형의 배포는 안정적인 네트워크 ID를 갖는 포드를 제공합니다. 즉, 클러스터에서 호스트 이름을 인식할 수 있습니다. 포드의 IP 주소가 변경될 수 있지만 호스트 이름 DNS 항목은 최신 상태로 유지되고 인식이 가능합니다.

패킷 흐름: ClusterIP

다음 다이어그램은 표준 Kubernetes 서비스의 DNS 응답 및 패킷 흐름을 보여줍니다. 포드 IP 주소는 클러스터 외부에서 라우팅할 수 있지만 서비스의 클러스터 IP 주소는 클러스터 내에서만 액세스할 수 있습니다. 이러한 가상 IP 주소는 각 Kubernetes 노드에서 대상 네트워크 주소 변환(DNAT)을 수행하여 구현됩니다. 각 노드에서 실행 중인 kube-proxy 서비스는 클러스터 IP 주소를 클러스터에서 정상적인 포드의 IP 주소로 매핑하는 각 노드에서 전달 규칙을 최신 상태로 유지합니다. 로컬 노드에서 실행 중인 서비스 포드가 있는 경우 해당 포드가 사용되며 그렇지 않으면 클러스터의 임의 포드가 선택됩니다.

클러스터 IP 서비스

서비스 IP가 구현되는 방법에 대한 자세한 내용은 Kubernetes 문서를 참조하세요. GKE 네트워킹에 대해 자세히 알아보려면 YouTube에서 Next 2017 talk를 확인하세요.

헤드리스 서비스

아래는 헤드리스 서비스에 대한 DNS 응답 및 트래픽 패턴의 예입니다. 포드 IP 주소는 기본 GCP 하위 네트워크 경로 테이블을 통해 라우팅할 수 있으며 애플리케이션에서 직접 액세스할 수 있습니다.

헤드리스 서비스에 대한 DNS 응답 및 트래픽 패턴의 예

네트워크 정책

Kubernetes Engine의 네트워크 정책 적용을 사용해서 클러스터 포드와 서비스 사이의 통신을 제어할 수 있습니다. Kubernetes Engine에서 네트워크 정책을 정의하려면 Kubernetes 네트워크 정책 API를 사용하여 포드 수준의 방화벽 규칙을 만들 수 있습니다. 이러한 방화벽 규칙은 클러스터 내에서 서로 액세스할 수 있는 포드 및 서비스를 결정합니다.

네트워크 정책은 일종의 심층 방어로 클러스터에서 실행되는 작업 부하의 보안을 강화합니다. 예를 들어 애플리케이션에서 손상된 프런트엔드 서비스가 여러 수준 아래의 청구 또는 회계 서비스와 직접 통신할 수 없도록 네트워크 정책을 만들 수 있습니다.

또한 네트워크 정책을 사용하여 다른 테넌트에 속한 작업 부하를 격리할 수 있습니다. 예를 들어 네임스페이스당 테넌트 모델을 정의해서 보안 다중 임대를 제공할 수 있습니다. 이러한 모델에서 네트워크 정책 규칙은 특정 네임스페이스의 포드 및 서비스가 다른 네임스페이스의 포드 또는 서비스에 액세스할 수 없도록 보장할 수 있습니다.

네트워크 정책에 대한 자세한 내용은 GKE 문서를 참조하세요.

Google Cloud Platform 내부에서 GKE 클러스터에 연결

클러스터 외부이지만 GCP 네트워크의 비공개 IP 공간 내에서 서비스에 연결하려면 내부 부하 분산을 사용합니다. type: Load Balancer 및 Kubernetes의 cloud.google.com/load-balancer-type: Internal 주석을 사용하여 서비스를 만들 때, GCP 프로젝트에서 내부 네트워크 부하 분산기가 만들어지고 구성되어 포드 사이에 TCP 및 UDP 트래픽을 분산합니다.

클러스터 내부에서 외부 서비스로 연결

대부분의 경우 Kubernetes 내부에서 실행 중인 애플리케이션을 클러스터 외부에 있는 서비스, 데이터베이스 또는 애플리케이션과 연결해야 합니다. 아래에 설명된 대로 3가지 옵션이 있습니다.

스텁 도메인

Kubernetes 1.6 이상에서는 특정 도메인에 대한 DNS 쿼리를 외부 DNS 서버로 전달하도록 클러스터 내부 DNS 서비스(kube-dns)를 구성할 수 있습니다. 이는 Kubernetes 포드가 활용해야 하는 도메인에 대해 쿼리를 받아야 하는 권한 DNS 서버가 있는 경우에 유용합니다.

외부 이름 서비스

외부 이름 서비스를 사용하면 DNS 레코드를 클러스터 내의 서비스 이름에 매핑할 수 있습니다. 이 경우 클러스터 내 서비스에 대한 DNS 조회는 선택한 CNAME 레코드를 반환합니다. 기존 DNS 서비스로 다시 매핑하려는 레코드가 몇 개밖에 없는 경우 이 옵션을 사용해야 합니다.

선택기가 없는 서비스

선택기 없이 서비스를 만든 다음 수동으로 엔드포인트를 추가하여 올바른 값으로 서비스 검색을 입력할 수 있습니다. 이렇게 하면 DNS를 통한 서비스 검색 기능이 없는 시스템에 계속 도달할 수 있도록 하면서 클러스터 내 서비스에 동일한 서비스 검색 메커니즘을 사용할 수 있습니다. 이 접근 방식이 가장 융통성이 있지만 장기적으로 보면 가장 많은 구성 및 유지관리가 필요합니다.

DNS에 대한 자세한 내용은 Kubernetes DNS 포드 및 서비스 문서 페이지를 참조하세요.

인터넷에서 클러스터로 트래픽 수신

인터넷의 트래픽은 네트워크 또는 HTTP(S) 부하 분산이라는 두 가지 방법을 사용해 Kubernetes에서 실행 중인 서비스로 전달할 수 있습니다.

Kubernetes 서비스는 외부 TCP/UDP 부하 분산을 위해 LoadBalancer 유형으로 만들어야 합니다. Kubernetes는 GCP 프로젝트에 네트워크 부하 분산기를 만들고 이를 Kubernetes Engine 클러스터의 노드에 매핑합니다. 이렇게하면 최소한의 구성으로 TCP 및 UDP 작업 부하에 대한 부하 분산을 쉽게 얻을 수 있습니다. 네트워크 부하 분산기는 지역적으로 범위가 지정되므로 동일한 지역 내에서 실행되는 포드에 대한 트래픽만 조정할 수 있습니다.

지역 us-west1의 네트워크 부하 분산기

HTTP(S) 부하 분산의 경우, 단일 Anycast IP 주소를 사용하여 여러 지역에 걸친 트래픽을 부하 분산할 수 있는 Google의 글로벌 HTTP(S) 부하 분산기를 활용해야 합니다. Kubernetes에서는 호스트 이름과 경로를 클러스터 내의 서비스에 매핑할 수 있는 수신 리소스를 만들 수 있습니다. 수신이 제대로 작동하려면 type: NodePort를 사용하여 서비스를 만들어야 합니다.

여러 지역에 걸친 부하 분산

방화벽

GKE 노드는 Compute Engine에서 인스턴스로 프로비저닝됩니다. 따라서 GKE 노드는 다른 인스턴스처럼 상태 저장 방화벽 메커니즘을 준수합니다. 이러한 방화벽 규칙은 태그를 사용하여 네트워크 내에서 인스턴스에 적용됩니다. 각 노드 풀은 규칙에서 사용할 수 있는 자체 태그 집합을 수신합니다. 기본적으로 노드 풀에 속하는 각 인스턴스는 이 노드 풀이 포함된 특정 Kubernetes Engine 클러스터를 식별하는 태그를 수신합니다. 이 태그는 Kubernetes Engine이 자동으로 생성하는 방화벽 규칙에 사용됩니다. gcloud 명령줄에서 --tags 태그를 사용하여 클러스터 또는 노드 풀 생성 시간에 커스텀 태그를 추가할 수 있습니다.

예를 들어 내부 부하 분산기를 사용하여 모든 노드의 포트 8080에 액세스하려면 다음 명령어를 사용합니다.

gcloud compute firewall-rules create \
  allow-8080-fwr --target-tags allow-8080 --allow tcp:8080 \
  --network gke --source-range 130.211.0.0/22
gcloud container clusters create my-cluster --tags allow-8080

다음 예는 다른 클러스터가 VPN의 트래픽을 포트 40000으로 허용하는 태그가 지정되어 있을 때, 인터넷 트래픽이 포트 30000의 노드에 액세스할 수 있도록 태그를 지정하는 방법을 보여줍니다. 이는 VPN과 같은 권한을 가진 네트워크를 사용하여 기업 데이터 센터로 다시 액세스하거나 프로젝트의 다른 클러스터에서만 액세스할 수 있는 NodePort를 통해 서비스를 노출할 때 유용합니다.

두 클러스터에 다른 태그 지정

온프레미스 데이터 센터에 연결

온프레미스 데이터 센터에 연결하기 위한 몇 가지의 Cloud Interconnect 옵션이 있습니다. 이러한 옵션은 상호 배타적이지 않으므로 작업 부하 및 요구사항에 따라 다음과 같은 조합을 사용할 수 있습니다.

  1. 데이터 집약적이거나 지연 시간에 민감하지 않은 작업 부하용 인터넷. Google은 전 세계 서비스 제공업체와 100개 이상의 접속 지점(POP)을 연결합니다.
  2. 전용 대역폭을 요구하는 작업 부하에 대한 직접 피어링은 지연 시간에 민감하며 GCP 제품의 전체 제품군을 비롯한 모든 Google 서비스에 대한 액세스를 요구합니다. 직접 피어링은 BGP 경로를 교환하여 이루어진 Layer 3 연결이므로 등록된 ASN이 필요합니다.
  3. 이동통신사 피어링은 직접 피어링과 동일하지만 서비스 제공업체를 통해 이루어집니다. 등록된 ASN이 없거나 기본 서비스 제공업체를 이용했던 경우 이 옵션이 가장 좋습니다.
  4. 클라우드 VPN은 IPsec 암호화가 필요한 경우 또는 사설 네트워크를 비공개 Compute Engine 네트워크로 확장하려는 경우 Layer 3 Interconnect 및 인터넷 옵션(1, 2, 3)을 통해 구성됩니다.

다음 단계

  • 다른 Google Cloud Platform 기능을 직접 사용해 보세요. 가이드를 살펴보세요.
이 페이지가 도움이 되었나요? 평가를 부탁드립니다.

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