1. 소개
Cloud Load Balancing은 온프레미스 데이터 센터, 하이브리드 연결을 사용하여 연결할 수 있는 기타 퍼블릭 클라우드 등 Google Cloud 이상으로 확장되는 엔드포인트에 대한 부하 분산 트래픽을 지원합니다.
하이브리드 전략은 변화하는 시장 수요에 적응하고 애플리케이션을 점진적으로 현대화할 수 있는 실용적인 솔루션입니다. 최신 클라우드 기반 솔루션으로의 마이그레이션을 위한 임시 하이브리드 배포 또는 조직의 IT 인프라의 영구적 설비일 수 있습니다.
또한 하이브리드 부하 분산을 설정하면 Google Cloud 외부의 기존 인프라에서 실행되는 서비스에서 Cloud Load Balancing의 네트워킹 기능의 이점을 누릴 수 있습니다.
다른 VPC 네트워크에서 하이브리드 서비스를 사용할 수 있도록 하려면 Private Service Connect를 사용하여 서비스를 게시하면 됩니다. 내부 리전 HTTP(S) 부하 분산기 앞에 서비스 연결을 배치하면 다른 VPC 네트워크의 클라이언트가 온프레미스 또는 다른 클라우드 환경에서 실행되는 하이브리드 서비스에 도달할 수 있습니다.
빌드할 항목
이 Codelab에서는 네트워크 엔드포인트 그룹을 사용하여 온프레미스 서비스에 대한 하이브리드 연결이 포함된 내부 HTTP(S) 부하 분산기를 빌드합니다. 소비자 VPC는 포트 80을 사용하여 온프레미스 서비스와 통신할 수 있습니다. 포트 443은 Codelab 범위에 속하지 않습니다.
학습할 내용
- 하이브리드 NEG 백엔드로 내부 HTTP(S) 부하 분산기를 만드는 방법
- Private Service Connect 프로듀서(서비스 연결) 및 소비자(전달 규칙)를 설정하는 방법
필요한 항목
- 기존 하이브리드 네트워킹(예: HA VPN, 상호 연결, SW-WAN)
- Google Cloud 프로젝트
하이브리드 연결 설정
Google Cloud와 온프레미스 또는 기타 클라우드 환경은 Cloud Interconnect VLAN 연결이나 Cloud Router가 포함된 Cloud VPN 터널을 사용해 하이브리드 연결을 통해 연결되어야 합니다. 고가용성 연결을 사용하는 것이 좋습니다.
전역 동적 라우팅이 사용 설정된 Cloud Router는 BGP를 통해 특정 엔드포인트를 학습하여 Google Cloud VPC 네트워크에 프로그래밍합니다. 리전별 동적 라우팅은 지원되지 않습니다. 정적 경로도 지원되지 않습니다.
Cloud Interconnect 또는 Cloud VPN을 구성하는 데 사용하는 Google Cloud VPC 네트워크는 하이브리드 부하 분산 배포를 구성하는 데 사용하는 네트워크와 동일합니다. VPC 네트워크의 서브넷 CIDR 범위가 원격 CIDR 범위와 충돌하지 않는지 확인합니다. 서브넷 경로는 IP 주소가 겹칠 때 원격 연결보다 우선 적용됩니다.
자세한 안내는 다음을 참조하세요.
커스텀 경로 공지
아래의 서브넷에는 Cloud Router에서 온프레미스 네트워크로의 커스텀 공지가 필요하여 온프레미스 방화벽 규칙이 업데이트됩니다.
서브넷 | 설명 |
172.16.0.0/23 | 온프레미스 서비스와 직접 통신하는 데 사용되는 프록시 서브넷 |
130.211.0.0/22, 35.191.0.0/16 |
2. 시작하기 전에
Codelab을 지원하도록 프로젝트 업데이트
이 Codelab에서는 $variables를 사용하여 Cloud Shell에서 gcloud 구성을 구현합니다.
Cloud Shell 내에서 다음을 수행합니다.
gcloud config list project
gcloud config set project [YOUR-PROJECT-NAME]
psclab=YOUR-PROJECT-NAME
echo $psclab
3. 프로듀서 설정
프로듀서 VPC 만들기
Cloud Shell 내에서 다음을 수행합니다.
gcloud compute networks create producer-vpc --project=$psclab --subnet-mode=custom
생성자 서브넷 만들기
Cloud Shell 내에서 다음을 수행합니다.
gcloud compute networks subnets create subnet-201 --project=$psclab --range=10.10.1.0/24 --network=producer-vpc --region=us-central1
gcloud compute networks subnets create subnet-202 --project=$psclab --range=10.20.1.0/24 --network=producer-vpc --region=us-central1
내부 부하 분산기의 IP 주소 예약
Cloud Shell 내에서 다음을 수행합니다. SHARED_VIP 사용은 Private Service Connect에서 지원되지 않습니다. 대신 GCE_ENDPOINT를 사용하세요.
gcloud compute addresses create lb-ip \
--region=us-central1 \
--subnet=subnet-202 \
--purpose=GCE_ENDPOINT
compute addresses describe 명령어를 사용하여 할당된 IP 주소를 확인합니다.
gcloud compute addresses describe lb-ip --region=us-central1 | grep address:
리전 프록시 서브넷 만들기
프록시 할당은 부하 분산기 수준이 아닌 VPC 수준에서 이루어집니다. Envoy 기반 부하 분산기를 사용하는 가상 네트워크(VPC)의 리전마다 프록시 전용 서브넷 하나를 만들어야 합니다. 동일한 리전 및 동일한 VPC 네트워크에 여러 부하 분산기를 배포하는 경우 부하 분산을 위해 동일한 프록시 전용 서브넷을 공유합니다.
- 클라이언트는 부하 분산기 전달 규칙의 IP 주소와 포트에 연결됩니다.
- 각 프록시는 해당 부하 분산기의 전달 규칙에서 지정한 IP 주소와 포트를 리슨합니다. 프록시 중 하나에서 클라이언트의 네트워크 연결을 수신하고 종료합니다.
- 프록시는 부하 분산기의 URL 맵과 백엔드 서비스에서 지정한 대로 NEG의 적절한 백엔드 VM 또는 엔드포인트에 대한 연결을 설정합니다.
네트워크가 자동 모드인지 또는 커스텀 모드인지 여부에 관계없이 프록시 전용 서브넷을 만들어야 합니다. 프록시 전용 서브넷에서 IP 주소를 64개 이상 제공해야 합니다. 이는 /26 이하의 프리픽스 길이에 해당합니다. 권장 서브넷 크기는 /23 (512개의 프록시 전용 주소)입니다.
Cloud Shell에서 다음을 실행합니다.
gcloud compute networks subnets create proxy-subnet-us-central \
--purpose=REGIONAL_MANAGED_PROXY \
--role=ACTIVE \
--region=us-central1 \
--network=producer-vpc \
--range=172.16.0.0/23
Private Service Connect NAT 서브넷 만들기
Private Service Connect에서 사용할 전용 서브넷을 하나 이상 만듭니다. Google Cloud 콘솔을 사용하여 서비스를 게시하는 경우 해당 절차 중에 서브넷을 만들 수 있습니다. 서비스의 부하 분산기와 동일한 리전에 서브넷을 만듭니다. 일반 서브넷은 Private Service Connect 서브넷으로 변환할 수 없습니다.
Cloud Shell 내에서 다음을 수행합니다.
gcloud compute networks subnets create psc-nat-subnet --network=producer-vpc --region=us-central1 --range=100.100.10.0/24 --purpose=private-service-connect
프로듀서 방화벽 규칙 만들기
Private Service Connect 엔드포인트와 서비스 연결 간의 트래픽을 허용하도록 방화벽 규칙을 구성합니다. Codelab에서 NAT 서브넷 100.100.10.0/24가 Private Service Connect 서비스 연결(내부 부하 분산기)에 액세스하도록 허용하는 인그레스 방화벽 규칙을 만들었습니다.
Cloud Shell에서 다음을 실행합니다.
gcloud compute --project=$psclab firewall-rules create allow-to-ingress-nat-subnet --direction=INGRESS --priority=1000 --network=producer-vpc --action=ALLOW --rules=all --source-ranges=100.100.10.0/24
Cloud Shell 내부에서 Google Cloud 상태 점검이 TCP 포트 80에서 온프레미스 서비스 (백엔드 서비스)에 도달할 수 있도록 fw-allow-health-check 규칙을 만듭니다.
gcloud compute firewall-rules create fw-allow-health-check \
--network=producer-vpc \
--action=allow \
--direction=ingress \
--source-ranges=130.211.0.0/22,35.191.0.0/16 \
--rules=tcp:80
프록시 전용 서브넷에 대한 인그레스 허용 방화벽 규칙을 만들어 부하 분산기가 TCP 포트 80에서 백엔드 인스턴스와 통신할 수 있도록 합니다.
gcloud compute firewall-rules create fw-allow-proxy-only-subnet \
--network=producer-vpc \
--action=allow \
--direction=ingress \
--source-ranges=172.16.0.0/23 \
--rules=tcp:80
하이브리드 연결 NEG 설정
NEG를 만들 때 Google Cloud와 온프레미스 또는 다른 클라우드 환경 간의 지리적 거리를 최소화하는 ZONE을 사용합니다. 예를 들어 독일 프랑크푸르트의 온프레미스 환경에서 서비스를 호스팅하는 경우 NEG를 만들 때 europe-west3-a Google Cloud 영역을 지정할 수 있습니다.
또한 Cloud Interconnect를 사용하는 경우 NEG를 만드는 데 사용된 ZONE이 Cloud Interconnect 연결이 구성된 리전과 동일해야 합니다.
사용 가능한 리전 및 영역은 Compute Engine 문서: 사용 가능한 리전 및 영역을 참고하세요.
Cloud Shell 내에서 gcloud compute network-endpoint-groups create 명령어를 사용하여 하이브리드 연결 NEG를 만듭니다.
gcloud compute network-endpoint-groups create on-prem-service-neg \
--network-endpoint-type=NON_GCP_PRIVATE_IP_PORT \
--zone=us-central1-a \
--network=producer-vpc
Cloud Shell 내에서 온프레미스 IP:포트 엔드포인트를 하이브리드 NEG에 추가합니다.
gcloud compute network-endpoint-groups update on-prem-service-neg \
--zone=us-central1-a \
--add-endpoint="ip=192.168.1.5,port=80"
부하 분산기 구성
다음 단계에서는 부하 분산기 (전달 규칙) 및 네트워크 엔드포인트 그룹과
Cloud Shell 내에서 온프레미스 서비스에 전달된 리전별 상태 점검을 만듭니다.
gcloud compute health-checks create http http-health-check \
--region=us-central1 \
--use-serving-port
Cloud Shell 내에서 하이브리드 NEG를 사용하여 온프레미스 백엔드를 활용할 수 있는 백엔드 서비스 만들기
gcloud compute backend-services create on-premise-service-backend \
--load-balancing-scheme=INTERNAL_MANAGED \
--protocol=HTTP \
--health-checks=http-health-check \
--health-checks-region=us-central1 \
--region=us-central1
Cloud Shell에서 백엔드 서비스에 하이브리드 NEG 백엔드를 추가합니다. RATE에는 백엔드가 처리해야 하는 최대 RATE를 입력합니다.
gcloud compute backend-services add-backend on-premise-service-backend \
--region=us-central1 \
--balancing-mode=RATE \
--max-rate-per-endpoint=100 \
--network-endpoint-group=on-prem-service-neg \
--network-endpoint-group-zone=us-central1-a
Cloud Shell 내에서 수신되는 요청을 백엔드 서비스로 라우팅하는 URL 맵을 만듭니다.
gcloud compute url-maps create on-prem-svc-url-map \
--default-service on-premise-service-backend \
--region=us-central1
HTTP 대상 프록시 만들기
gcloud compute target-http-proxies create proxy-subnet-us-central\
--url-map=on-prem-svc-url-map \
--url-map-region=us-central1 \
--region=us-central1
수신되는 요청을 프록시로 라우팅하는 전달 규칙을 만듭니다. 전달 규칙을 만들 때 프록시 전용 서브넷을 사용하지 마세요.
gcloud compute forwarding-rules create http-hybrid-neg-fwd-rule \
--load-balancing-scheme=INTERNAL_MANAGED \
--network=producer-vpc \
--subnet=subnet-202 \
--address=lb-ip \
--ports=80 \
--region=us-central1 \
--target-http-proxy=proxy-subnet-us-central \
--target-http-proxy-region=us-central1
4. 부하 분산기 유효성 검사
Cloud 콘솔에서 네트워크 서비스 → 부하 분산 → 부하 분산기로 이동합니다. NEG 1개가 '녹색'으로 표시되어 온프레미스 서비스의 상태 점검에 성공했음을 나타냅니다.
‘on-premise-svc-url-map'을 선택하면 프런트엔드 IP 주소가 생성되고 백엔드 서비스가 식별됩니다.
5. 온프레미스에서 학습된 경로 보기
VPC 네트워크 → 경로로 이동합니다. 학습된 온프레미스 서비스 서브넷 192.168.1.0/27
6. 온프레미스 서비스에 대한 연결 검증
프로듀서 VPC에서 VM을 만들어 온프레미스 서비스에 대한 연결을 테스트하겠습니다. 그 다음 서비스 연결이 다음 구성이 됩니다.
Cloud Shell 내에서 프로듀서 VPC에 테스트 인스턴스 만들기
gcloud compute instances create test-box-us-central1 \
--zone=us-central1-a \
--image-family=debian-10 \
--image-project=debian-cloud \
--subnet=subnet-201 \
--no-address
IAP가 VM 인스턴스에 연결하도록 하려면 다음과 같은 방화벽 규칙을 만드세요.
- IAP를 사용하여 액세스할 수 있도록 하려는 모든 VM 인스턴스에 적용됩니다.
- IP 범위 35.235.240.0/20에서 들어오는 인그레스 트래픽을 허용합니다. 이 범위에는 IAP가 TCP 전달에 사용하는 모든 IP 주소가 포함됩니다.
Cloud Shell 내에서 제작자 VPC에 테스트 인스턴스를 만듭니다.
gcloud compute firewall-rules create ssh-iap \
--network producer-vpc \
--allow tcp:22 \
--source-ranges=35.235.240.0/20
Cloud Shell에서 IAP를 사용하여 test-box-us-central1에 로그인하여 부하 분산 IP 주소에 대해 curl을 실행하여 온프레미스 서비스에 대한 연결을 확인합니다. 시간 초과가 발생하면 다시 시도하세요.
gcloud compute ssh test-box-us-central1 --project=$psclab --zone=us-central1-a --tunnel-through-iap
온프레미스 서비스에 대한 연결을 확인하는 curl을 실행합니다. 검증이 완료되면 VM을 종료하여 Cloud Shell 프롬프트로 돌아갑니다. 4단계에서 식별된 출력에 따라 내부 부하 분산기 IP를 바꿉니다.
user@test-box-us-central1:~$ curl -v 10.20.1.2
* Expire in 0 ms for 6 (transfer 0x55b7725c10f0)
* Trying 10.20.1.2...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x55b7725c10f0)
* Connected to 10.20.1.2 (10.20.1.2) port 80 (#0)
> GET / HTTP/1.1
> Host: 10.20.1.2
> User-Agent: curl/7.64.0
> Accept: */*
>
< HTTP/1.1 200 OK
< content-type: text/html; charset=utf-8
< accept-ranges: bytes
< etag: "3380914763"
< last-modified: Mon, 05 Dec 2022 15:10:56 GMT
< expires: Mon, 12 Dec 2022 03:17:20 GMT
< cache-control: max-age=0
< content-length: 37
< date: Mon, 12 Dec 2022 03:17:20 GMT
< server: lighttpd/1.4.53
< via: 1.1 google
<
Welcome to my on-premise service!!
7. Private Service Connect 서비스 연결 만들기
다음 단계에서는 서비스 연결을 만듭니다. 소비자 엔드포인트와 페어링되면 VPC 피어링 없이도 온프레미스 서비스에 대한 액세스가 가능합니다.
서비스 연결 만들기
Cloud Shell 내부에서 서비스 연결 만들기
gcloud compute service-attachments create service-1 --region=us-central1 --producer-forwarding-rule=http-hybrid-neg-fwd-rule --connection-preference=ACCEPT_AUTOMATIC --nat-subnets=psc-nat-subnet
선택사항: 공유 VPC를 사용하는 경우 서비스 프로젝트에 서비스 연결을 만듭니다.
gcloud compute service-attachments create service-1 --region=us-central1 --producer-forwarding-rule=http-hybrid-neg-fwd-rule --connection-preference=ACCEPT_AUTOMATIC --nat-subnets=projects/<hostproject>/regions/<region>/subnetworks/<natsubnet>
TCP 서비스 연결 확인
gcloud compute service-attachments describe service-1 --region us-central1
선택사항: Network Services(네트워크 서비스) → Private Service Connect로 이동하여 새로 설정된 서비스 연결을 확인합니다.
Service-1을 선택하면 소비자가 비공개 서비스 연결을 설정하는 데 사용하는 서비스 연결 URI를 비롯한 자세한 정보가 제공됩니다. URI는 이후 단계에서 사용되므로 기록해 둡니다.
서비스 연결 세부정보: projects/<projectname>/regions/us-central1/serviceAttachments/service-1
8. 소비자 설정
소비자 VPC 만들기
Cloud Shell 내에서 다음을 수행합니다.
gcloud compute networks create consumer-vpc --project=$psclab --subnet-mode=custom
소비자 서브넷 만들기
Cloud Shell에서 GCE 서브넷 만들기
gcloud compute networks subnets create subnet-101 --project=$psclab --range=10.100.1.0/24 --network=consumer-vpc --region=us-central1
Cloud Shell에서 소비자 엔드포인트 서브넷 만들기
gcloud compute networks subnets create subnet-102 --project=$psclab --range=10.100.2.0/24 --network=consumer-vpc --region=us-central1
소비자 엔드포인트(전달 규칙) 만들기
Cloud Shell 내에서 소비자 엔드포인트로 사용될 고정 IP 주소를 만듭니다.
gcloud compute addresses create psc-consumer-ip-1 --region=us-central1 --subnet=subnet-102 --addresses 10.100.2.10
이전에 생성된 서비스 연결 URI를 사용하여 소비자 엔드포인트를 만들 수 있습니다.
Cloud Shell 내부에서 소비자 엔드포인트 만들기
gcloud compute forwarding-rules create psc-consumer-1 --region=us-central1 --network=consumer-vpc --address=psc-consumer-ip-1 --target-service-attachment=projects/$psclab/regions/us-central1/serviceAttachments/service-1
9. Consumer Private Service Connect 검증 - 소비자 VPC
소비자 VPC에서 네트워크 서비스 → Private Service Connect → 연결된 엔드포인트로 이동하여 비공개 서비스 연결이 성공적으로 이루어졌는지 확인합니다. 설정된 psc-consumer-1 연결과 이전에 만든 해당 IP 주소를 확인합니다.
psc-consumer-1을 선택하면 서비스 연결 URI를 비롯한 세부정보가 제공됩니다.
10. Consumer Private Service Connect 검증 - 프로듀서 VPC
제작자 VPC에서 네트워크 서비스 → Private Service Connect→게시된 서비스로 이동하여 비공개 서비스 연결이 성공적으로 이루어졌는지 확인합니다. 게시된 service-1 연결에 전달 규칙 1개(연결 엔드포인트)가 표시됩니다.
11. 비공개 DNS 영역 생성 및 A 레코드
PSC 연결 엔드포인트에 매핑된 비공개 DNS 영역을 만들어 VPC 내의 모든 호스트에서 생산자에 원활하게 액세스할 수 있습니다.
Cloud Shell 사용
gcloud dns --project=$psclab managed-zones create codelab-zone --description="" --dns-name="codelab.net." --visibility="private" --networks="consumer-vpc"
gcloud dns --project=$psclab record-sets create service1.codelab.net. --zone="codelab-zone" --type="A" --ttl="300" --rrdatas="10.100.2.10"
12. VM을 사용하여 소비자가 제작자 서비스에 액세스할 수 있는지 확인
소비자 VPC에서 소비자 엔드포인트 service1.codelabs.net에 액세스하여 온프레미스 서비스에 대한 연결을 테스트하는 VM을 만듭니다.
Cloud Shell 내에서 소비자 VPC에 테스트 인스턴스 만들기
gcloud compute instances create consumer-vm \
--zone=us-central1-a \
--image-family=debian-10 \
--image-project=debian-cloud \
--subnet=subnet-101 \
--no-address
IAP가 VM 인스턴스에 연결하도록 하려면 다음과 같은 방화벽 규칙을 만드세요.
- IAP를 사용하여 액세스할 수 있도록 하려는 모든 VM 인스턴스에 적용됩니다.
- IP 범위 35.235.240.0/20에서 들어오는 인그레스 트래픽을 허용합니다. 이 범위에는 IAP가 TCP 전달에 사용하는 모든 IP 주소가 포함됩니다.
Cloud Shell 내에서 소비자 VPC에 테스트 인스턴스 만들기
gcloud compute firewall-rules create ssh-iap-consumer \
--network consumer-vpc \
--allow tcp:22 \
--source-ranges=35.235.240.0/20
Cloud Shell에서 IAP를 사용하여 consumer-vm에 로그인하고 DNS FQDN service1.codelab.net에 대해 curl을 실행하여 온프레미스 서비스에 대한 연결을 확인합니다. 시간 초과가 발생하면 다시 시도하세요.
gcloud compute ssh consumer-vm --project=$psclab --zone=us-central1-a --tunnel-through-iap
온프레미스 서비스에 대한 연결을 확인하는 curl을 실행합니다. 검증이 완료되면 VM을 종료하여 Cloud Shell 프롬프트로 돌아갑니다.
Cloud Shell 내에서 curl 수행
$ curl -v service1.codelab.net
* Trying 10.100.2.10...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x5650fc3390f0)
* Connected to service1.codelab.net (10.100.2.10) port 80 (#0)
> GET / HTTP/1.1
> Host: service1.codelab.net
> User-Agent: curl/7.64.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Content-Type: text/html; charset=utf-8
< Accept-Ranges: bytes
< ETag: "3380914763"
< Last-Modified: Mon, 05 Dec 2022 15:10:56 GMT
< Expires: Mon, 05 Dec 2022 15:15:41 GMT
< Cache-Control: max-age=0
< Content-Length: 37
< Date: Mon, 05 Dec 2022 15:15:41 GMT
< Server: lighttpd/1.4.53
<
Welcome to my on-premise service!!
아래는 온프레미스 서비스의 캡처 예시입니다. 소스 IP 주소 172.16.0.13은 프록시 서브넷 범위 172.16.0.0/23에 속합니다.
13. Producer 정리
Producer 구성요소 삭제
Cloud Shell 내에서 생산자 VPC의 테스트 인스턴스를 삭제합니다.
gcloud compute instances delete test-box-us-central1 --zone=us-central1-a --quiet
gcloud compute service-attachments delete service-1 --region=us-central1 --quiet
gcloud compute forwarding-rules delete http-hybrid-neg-fwd-rule --region=us-central1 --quiet
gcloud compute target-http-proxies delete proxy-subnet-us-central --region=us-central1 --quiet
gcloud compute url-maps delete on-prem-svc-url-map --region=us-central1 --quiet
gcloud compute backend-services delete on-premise-service-backend --region=us-central1 --quiet
gcloud compute network-endpoint-groups delete on-prem-service-neg --zone=us-central1-a --quiet
gcloud compute addresses delete lb-ip --region=us-central1 --quiet
gcloud compute networks subnets delete psc-nat-subnet subnet-201 subnet-202 proxy-subnet-us-central --region=us-central1 --quiet
gcloud compute firewall-rules delete ssh-iap fw-allow-proxy-only-subnet allow-to-ingress-nat-subnet fw-allow-health-check --quiet
gcloud compute health-checks delete http-health-check --region=us-central1 --quiet
gcloud compute networks delete producer-vpc --quiet
14. 소비자 정리
소비자 구성요소 삭제
Cloud Shell 내에서 소비자 VPC의 테스트 인스턴스를 삭제합니다.
gcloud compute instances delete consumer-vm --zone=us-central1-a --quiet
gcloud compute forwarding-rules delete psc-consumer-1 --region=us-central1 --quiet
gcloud compute addresses delete psc-consumer-ip-1 --region=us-central1 --quiet
gcloud compute networks subnets delete subnet-101 subnet-102 --region=us-central1 --quiet
gcloud compute firewall-rules delete ssh-iap-consumer --quiet
gcloud dns record-sets delete service1.codelab.net --type=A --zone=codelab-zone --quiet
gcloud dns managed-zones delete codelab-zone --quiet
gcloud compute networks delete consumer-vpc --quiet
15. 축하합니다
축하합니다. 내부 HTTP(S) 부하 분산기를 사용하여 Private Service Connect를 구성하고 유효성을 검사했습니다.
프로듀서 인프라를 만들고 프로듀서 VPC에 온프레미스 서비스를 가리키는 서비스 연결을 추가했습니다. 온프레미스 서비스에 연결할 수 있는 소비자 VPC에서 소비자 엔드포인트를 만드는 방법을 알아봤습니다.
다음 단계
다음 Codelab을 확인하세요.
- 비공개 서비스를 사용하여 GKE로 서비스 게시 및 사용
- Private Service Connect를 소비한 서비스 게시 및 사용
- Private Service Connect 및 내부 TCP 프록시 부하 분산기를 사용하여 하이브리드 네트워킹을 통해 온프레미스 서비스에 연결