이 배포에서는 Cloud Service Mesh와 Cloud Load Balancing을 결합하여 서비스 메시의 애플리케이션을 인터넷 클라이언트에 노출하는 방법을 보여줍니다.
클라이언트 위치에 따라 여러 가지 방법으로 클라이언트에 애플리케이션을 노출할 수 있습니다. 이 배포에서는 부하 분산기를 서비스 메시에 통합하기 위해 Cloud Load Balancing을 Cloud Service Mesh와 결합하여 클라이언트에 애플리케이션을 노출하는 방법을 보여줍니다. 이 배포는 Cloud Service Mesh를 실행하는 고급 실무자를 대상으로 하지만 Google Kubernetes Engine의 Istio에도 적용됩니다.
아키텍처
다음 다이어그램은 메시 인그레스 게이트웨이를 사용하여 부하 분산기를 서비스 메시와 통합하는 방법을 보여줍니다.
앞의 다이어그램의 토폴로지에서 GKE 게이트웨이를 통해 프로그래밍된 클라우드 인그레스 레이어는 서비스 메시 외부에서 유입되는 트래픽을 수집하고 이 트래픽을 메시 인그레스 레이어로 전달합니다. 그러면 메시 인그레스 레이어가 메시에서 호스팅된 애플리케이션 백엔드로 트래픽을 전달합니다.
위 토폴로지에서는 다음을 고려해야 합니다.
- 클라우드 인그레스: 이 참조 아키텍처에서는 노출된 상태 확인 포트에서 메시 인그레스 프록시의 상태를 확인하도록 GKE 게이트웨이를 통해 Google Cloud 부하 분산기를 구성합니다.
- 메시 인그레스: 메시 애플리케이션에서는 로컬로 부하 분산 및 트래픽 관리를 실행할 수 있도록 백엔드에서 직접 상태 검사를 수행합니다.
앞의 다이어그램은 클라이언트에서 Google Cloud 부하 분산기, 부하 분산기에서 메시 인그레스 프록시, 인그레스 프록시에서 사이드카 프록시로 HTTPS 암호화를 보여줍니다.
목표
- Google Cloud에 Google Kubernetes Engine(GKE) 클러스터를 배포합니다.
- GKE 클러스터에 Istio 기반 Cloud Service Mesh를 배포합니다.
- 공개 HTTPS 트래픽을 종료한 후 이 트래픽이 서비스 메시에서 호스팅되는 애플리케이션으로 전달되도록 GKE 게이트웨이를 구성합니다.
- 인터넷에서 클라이언트에 노출되는 GKE 클러스터에 Online Boutique 애플리케이션을 배포합니다.
비용 최적화
이 문서에서는 비용이 청구될 수 있는 다음과 같은 Google Cloud 구성요소를 사용합니다.
- Google Kubernetes Engine
- Compute Engine
- Cloud Load Balancing
- Certificate Manager
- Cloud Service Mesh
- Google Cloud Armor
- Cloud Endpoints
프로젝트 사용량을 기준으로 예상 비용을 산출하려면 가격 계산기를 사용하세요.
이 문서에 설명된 태스크를 완료했으면 만든 리소스를 삭제하여 청구가 계속되는 것을 방지할 수 있습니다. 자세한 내용은 삭제를 참조하세요.
시작하기 전에
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Make sure that billing is enabled for your Google Cloud project.
-
In the Google Cloud console, activate Cloud Shell.
이 배포의 모든 터미널 명령어는 Cloud Shell에서 실행됩니다.
Google Cloud CLI를 최신 버전으로 업그레이드합니다.
gcloud components update기본 Google Cloud 프로젝트를 설정합니다.
export PROJECT=PROJECT export PROJECT_NUMBER=$(gcloud projects describe ${PROJECT} --format="value(projectNumber)") gcloud config set project ${PROJECT}PROJECT를 이 배포에 사용할 프로젝트 ID로 바꿉니다.작업 디렉터리를 만듭니다.
mkdir -p ${HOME}/edge-to-mesh cd ${HOME}/edge-to-mesh export WORKDIR=`pwd`이 배포를 마치면 작업 디렉터리를 삭제할 수 있습니다.
GKE 클러스터 만들기
이 배포에서 설명하는 기능에는 GKE 클러스터 버전 1.16 이상이 필요합니다.
Cloud Shell에서 새
kubeconfig파일을 만듭니다. 이 단계를 수행하면 기존의 기본kubeconfig파일과 충돌이 발생하지 않습니다.touch edge2mesh_kubeconfig export KUBECONFIG=${WORKDIR}/edge2mesh_kubeconfigGKE 클러스터의 환경 변수를 정의합니다.
export CLUSTER_NAME=edge-to-mesh export CLUSTER_LOCATION=us-central1Google Kubernetes Engine API를 사용 설정합니다.
gcloud services enable container.googleapis.comGKE Autopilot 클러스터를 만듭니다.
gcloud container --project ${PROJECT} clusters create-auto \ ${CLUSTER_NAME} --region ${CLUSTER_LOCATION} --release-channel rapid클러스터가 실행 중인지 확인합니다.
gcloud container clusters list출력은 다음과 비슷합니다.
NAME LOCATION MASTER_VERSION MASTER_IP MACHINE_TYPE NODE_VERSION NUM_NODES STATUS edge-to-mesh us-central1 1.27.3-gke.1700 34.122.84.52 e2-medium 1.27.3-gke.1700 3 RUNNING
서비스 메시 설치
이 섹션에서는 Fleet API로 관리형 Cloud Service Mesh를 구성합니다.
Cloud Shell에서 필요한 API를 사용 설정합니다.
gcloud services enable mesh.googleapis.comFleet에서 Cloud Service Mesh를 사용 설정합니다.
gcloud container fleet mesh enableFleet에 클러스터를 등록합니다.
gcloud container fleet memberships register ${CLUSTER_NAME} \ --gke-cluster ${CLUSTER_LOCATION}/${CLUSTER_NAME}edge-to-mesh클러스터에mesh_id라벨을 적용합니다.gcloud container clusters update ${CLUSTER_NAME} --project ${PROJECT} --region ${CLUSTER_LOCATION} --update-labels mesh_id=proj-${PROJECT_NUMBER}자동 제어 영역 관리 및 관리형 데이터 영역을 사용 설정합니다.
gcloud container fleet mesh update \ --management automatic \ --memberships ${CLUSTER_NAME}몇 분 후 제어 영역 상태가
ACTIVE인지 확인합니다.gcloud container fleet mesh describe출력은 다음과 비슷합니다.
... membershipSpecs: projects/892585880385/locations/us-central1/memberships/edge-to-mesh: mesh: management: MANAGEMENT_AUTOMATIC membershipStates: projects/892585880385/locations/us-central1/memberships/edge-to-mesh: servicemesh: controlPlaneManagement: details: - code: REVISION_READY details: 'Ready: asm-managed-rapid' state: ACTIVE dataPlaneManagement: details: - code: OK details: Service is running. state: ACTIVE state: code: OK description: 'Revision(s) ready for use: asm-managed-rapid.' updateTime: '2023-08-04T02:54:39.495937877Z' name: projects/e2m-doc-01/locations/global/features/servicemesh resourceState: state: ACTIVE ...
GKE 게이트웨이 배포
다음 단계에서는 GKE Gateway Controller를 통해 외부 애플리케이션 부하 분산기를 배포합니다. GKE 게이트웨이 리소스는 부하 분산기 및 백엔드 상태 점검의 프로비저닝을 자동화합니다. 또한 인증서 관리자를 사용하여 TLS 인증서를 프로비저닝 및 관리하고 Endpoints를 사용하여 애플리케이션의 공개 DNS 이름을 자동으로 프로비저닝합니다.
서비스 메시 인그레스 게이트웨이 설치
보안 권장사항으로 제어 영역과 다른 네임스페이스에 인그레스 게이트웨이를 배포하는 것이 좋습니다.
Cloud Shell에서 전용
asm-ingress네임스페이스를 만듭니다.kubectl create namespace asm-ingress네임스페이스 라벨을
asm-ingress네임스페이스에 추가합니다.kubectl label namespace asm-ingress istio-injection=enabled출력은 다음과 비슷합니다.
namespace/asm-ingress labeled
asm-ingress네임스페이스에istio-injection=enabled라벨을 지정하면 애플리케이션이 배포될 때 Cloud Service Mesh가 Envoy 사이드카 프록시를 자동으로 삽입합니다.Google Cloud 부하 분산기(나중에 GKE Gateway Controller를 통해 구성됨)와 인그레스 게이트웨이 간의 TLS 연결을 종료하기 위해 인그레스 게이트웨이에서 사용되는 자체 서명 인증서를 만들고 이 자체 서명 인증서를 Kubernetes 보안 비밀로 저장합니다.
openssl req -new -newkey rsa:4096 -days 365 -nodes -x509 \ -subj "/CN=frontend.endpoints.${PROJECT}.cloud.goog/O=Edge2Mesh Inc" \ -keyout frontend.endpoints.${PROJECT}.cloud.goog.key \ -out frontend.endpoints.${PROJECT}.cloud.goog.crt kubectl -n asm-ingress create secret tls edge2mesh-credential \ --key=frontend.endpoints.${PROJECT}.cloud.goog.key \ --cert=frontend.endpoints.${PROJECT}.cloud.goog.crt인그레스 게이트웨이 인증서 요구사항에 대한 자세한 내용은 보안 백엔드 프로토콜 고려사항 가이드를 참조하세요.
다음 명령어를 실행하여 인그레스 게이트웨이 리소스 YAML을 만듭니다.
mkdir -p ${WORKDIR}/asm-ig/base cat <<EOF > ${WORKDIR}/asm-ig/base/kustomization.yaml resources: - github.com/GoogleCloudPlatform/anthos-service-mesh-samples/docs/ingress-gateway-asm-manifests/base EOF mkdir ${WORKDIR}/asm-ig/variant cat <<EOF > ${WORKDIR}/asm-ig/variant/role.yaml apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: asm-ingressgateway namespace: asm-ingress rules: - apiGroups: [""] resources: ["secrets"] verbs: ["get", "watch", "list"] EOF cat <<EOF > ${WORKDIR}/asm-ig/variant/rolebinding.yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: asm-ingressgateway namespace: asm-ingress roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: asm-ingressgateway subjects: - kind: ServiceAccount name: asm-ingressgateway EOF cat <<EOF > ${WORKDIR}/asm-ig/variant/service-proto-type.yaml apiVersion: v1 kind: Service metadata: name: asm-ingressgateway spec: ports: - name: status-port port: 15021 protocol: TCP targetPort: 15021 - name: http port: 80 targetPort: 8080 - name: https port: 443 targetPort: 8443 appProtocol: HTTP2 type: ClusterIP EOF cat <<EOF > ${WORKDIR}/asm-ig/variant/gateway.yaml apiVersion: networking.istio.io/v1beta1 kind: Gateway metadata: name: asm-ingressgateway spec: servers: - port: number: 443 name: https protocol: HTTPS hosts: - "*" # IMPORTANT: Must use wildcard here when using SSL, see note below tls: mode: SIMPLE credentialName: edge2mesh-credential EOF cat <<EOF > ${WORKDIR}/asm-ig/variant/kustomization.yaml namespace: asm-ingress resources: - ../base - role.yaml - rolebinding.yaml patches: - path: service-proto-type.yaml target: kind: Service - path: gateway.yaml target: kind: Gateway EOF인그레스 게이트웨이 CRD를 적용합니다.
kubectl apply -k ${WORKDIR}/asm-ig/variant모든 배포가 실행 중인지 확인합니다.
kubectl wait --for=condition=available --timeout=600s deployment --all -n asm-ingress출력은 다음과 비슷합니다.
deployment.apps/asm-ingressgateway condition met
서비스 메시 인그레스 게이트웨이 상태 점검 적용
서비스 메시 인그레스 게이트웨이를 Google Cloud 애플리케이션 부하 분산기에 통합할 때는 인그레스 게이트웨이 포드에 대한 상태 점검을 수행하도록 애플리케이션 부하 분산기를 구성해야 합니다. HealthCheckPolicy CRD는 상태 점검을 구성하는 API를 제공합니다.
Cloud Shell에서
HealthCheckPolicy.yaml파일을 만듭니다.cat <<EOF >${WORKDIR}/ingress-gateway-healthcheck.yaml apiVersion: networking.gke.io/v1 kind: HealthCheckPolicy metadata: name: ingress-gateway-healthcheck namespace: asm-ingress spec: default: checkIntervalSec: 20 timeoutSec: 5 #healthyThreshold: HEALTHY_THRESHOLD #unhealthyThreshold: UNHEALTHY_THRESHOLD logConfig: enabled: True config: type: HTTP httpHealthCheck: #portSpecification: USE_NAMED_PORT port: 15021 portName: status-port #host: HOST requestPath: /healthz/ready #response: RESPONSE #proxyHeader: PROXY_HEADER #requestPath: /healthz/ready #port: 15021 targetRef: group: "" kind: Service name: asm-ingressgateway EOFHealthCheckPolicy:를 적용합니다.kubectl apply -f ${WORKDIR}/ingress-gateway-healthcheck.yaml
보안 정책 정의
Google Cloud Armor는 인그레스 리소스를 통해 부하 분산기에 연결할 수 있는 DDoS 방어 및 맞춤설정 가능한 보안 정책을 제공합니다. 다음 단계에서는 사전 구성된 규칙을 사용하여 교차 사이트 스크립팅(XSS) 공격을 차단하는 보안 정책을 만듭니다. 이 규칙은 알려진 공격 서명과 일치하지만 다른 모든 트래픽을 허용하는 트래픽을 차단합니다. 환경에 적용되는 규칙은 워크로드에 따라 달라질 수 있습니다.
Cloud Shell에서
edge-fw-policy라는 보안 정책을 만듭니다.gcloud compute security-policies create edge-fw-policy \ --description "Block XSS attacks"사전 구성된 XSS 필터를 사용하는 보안 정책 규칙을 만듭니다.
gcloud compute security-policies rules create 1000 \ --security-policy edge-fw-policy \ --expression "evaluatePreconfiguredExpr('xss-stable')" \ --action "deny-403" \ --description "XSS attack filtering"인그레스 게이트웨이 서비스에 연결할
GCPBackendPolicy.yaml파일을 만듭니다.cat <<EOF > ${WORKDIR}/cloud-armor-backendpolicy.yaml apiVersion: networking.gke.io/v1 kind: GCPBackendPolicy metadata: name: cloud-armor-backendpolicy namespace: asm-ingress spec: default: securityPolicy: edge-fw-policy targetRef: group: "" kind: Service name: asm-ingressgateway EOFGCPBackendPolicy.yaml파일을 적용합니다.kubectl apply -f ${WORKDIR}/cloud-armor-backendpolicy.yaml
IP 주소 지정 및 DNS 구성
Cloud Shell에서 Google Cloud 부하 분산기의 전역 고정 IP 주소를 만듭니다.
gcloud compute addresses create e2m-gclb-ip --global이 고정 IP 주소는 GKE 게이트웨이 리소스에서 사용되며 외부 부하 분산기가 변경되더라도 IP 주소가 동일하게 유지됩니다.
고정 IP 주소를 가져옵니다.
export GCLB_IP=$(gcloud compute addresses describe e2m-gclb-ip \ --global --format "value(address)") echo ${GCLB_IP}애플리케이션 부하 분산기의 고정 IP 주소에 대해 사용자 친화적이고 안정적인 매핑을 만들려면 공개 DNS 레코드가 있어야 합니다. 원하는 DNS 제공업체 및 자동화를 사용할 수 있습니다. 이 배포에서는 관리형 DNS 영역을 만드는 대신 Endpoints를 사용합니다. Endpoints는 공개 IP 주소에 무료 Google 관리 DNS 레코드를 제공합니다.
다음 명령어를 실행하여
dns-spec.yaml이라는 YAML 사양 파일을 만듭니다.cat <<EOF > ${WORKDIR}/dns-spec.yaml swagger: "2.0" info: description: "Cloud Endpoints DNS" title: "Cloud Endpoints DNS" version: "1.0.0" paths: {} host: "frontend.endpoints.${PROJECT}.cloud.goog" x-google-endpoints: - name: "frontend.endpoints.${PROJECT}.cloud.goog" target: "${GCLB_IP}" EOFYAML 사양은 공개 DNS 레코드를
frontend.endpoints.${PROJECT}.cloud.goog형식으로 정의합니다. 여기서${PROJECT}는 고유한 프로젝트 식별자입니다.Google Cloud 프로젝트에
dns-spec.yaml파일을 배포합니다.gcloud endpoints services deploy ${WORKDIR}/dns-spec.yaml출력은 다음과 비슷합니다.
project [e2m-doc-01]... Operation "operations/acat.p2-892585880385-fb4a01ad-821d-4e22-bfa1-a0df6e0bf589" finished successfully. Service Configuration [2023-08-04r0] uploaded for service [frontend.endpoints.e2m-doc-01.cloud.goog]
이제 IP 주소와 DNS가 구성되었으므로 공개 인증서를 생성하여 프런트엔드를 보호할 수 있습니다. GKE 게이트웨이와 통합하려면 인증서 관리자 TLS 인증서를 사용합니다.
TLS 인증서 프로비저닝
이 섹션에서는 인증서 관리자를 사용하여 TLS 인증서를 만들고 인증서 맵 항목을 통해 인증서 맵과 연결합니다. GKE 게이트웨이를 통해 구성된 애플리케이션 부하 분산기는 인증서를 사용하여 클라이언트와 Google Cloud 간의 보안 통신을 제공합니다. 생성된 인증서 맵 항목은 GKE 게이트웨이 리소스에서 참조됩니다.
Cloud Shell에서 Certificate Manager API를 사용 설정합니다.
gcloud services enable certificatemanager.googleapis.com --project=${PROJECT}TLS 인증서를 만듭니다.
gcloud --project=${PROJECT} certificate-manager certificates create edge2mesh-cert \ --domains="frontend.endpoints.${PROJECT}.cloud.goog"인증서 맵을 만듭니다.
gcloud --project=${PROJECT} certificate-manager maps create edge2mesh-cert-map인증서 맵 항목을 사용하여 인증서 맵에 인증서를 연결합니다.
gcloud --project=${PROJECT} certificate-manager maps entries create edge2mesh-cert-map-entry \ --map="edge2mesh-cert-map" \ --certificates="edge2mesh-cert" \ --hostname="frontend.endpoints.${PROJECT}.cloud.goog"
GKE 게이트웨이 및 HTTPRoute 리소스 배포
이 섹션에서는 gke-l7-global-external-managed
gatewayClass를 사용하여 Google Cloud 애플리케이션 부하 분산기를 프로비저닝하는 GKE 게이트웨이 리소스를 구성합니다.
또한 요청을 애플리케이션으로 라우팅하고 HTTP에서 HTTP(S)로 리디렉션을 수행하는 HTTPRoute 리소스를 구성합니다.
Cloud Shell에서 다음 명령어를 실행하여
Gateway매니페스트를gke-gateway.yaml로 만듭니다.cat <<EOF > ${WORKDIR}/gke-gateway.yaml kind: Gateway apiVersion: gateway.networking.k8s.io/v1 metadata: name: external-http namespace: asm-ingress annotations: networking.gke.io/certmap: edge2mesh-cert-map spec: gatewayClassName: gke-l7-global-external-managed # gke-l7-gxlb listeners: - name: http # list the port only so we can redirect any incoming http requests to https protocol: HTTP port: 80 - name: https protocol: HTTPS port: 443 addresses: - type: NamedAddress value: e2m-gclb-ip # reference the static IP created earlier EOFGateway매니페스트를 적용하여external-http라는Gateway를 만듭니다.kubectl apply -f ${WORKDIR}/gke-gateway.yaml기본
HTTPRoute.yaml파일을 만듭니다.cat << EOF > ${WORKDIR}/default-httproute.yaml apiVersion: gateway.networking.k8s.io/v1 kind: HTTPRoute metadata: name: default-httproute namespace: asm-ingress spec: parentRefs: - name: external-http namespace: asm-ingress sectionName: https rules: - matches: - path: value: / backendRefs: - name: asm-ingressgateway port: 443 EOF기본
HTTPRoute를 적용합니다.kubectl apply -f ${WORKDIR}/default-httproute.yaml추가
HTTPRoute.yaml파일을 만들어 HTTP를 HTTP(S)로 리디렉션합니다.cat << EOF > ${WORKDIR}/default-httproute-redirect.yaml kind: HTTPRoute apiVersion: gateway.networking.k8s.io/v1 metadata: name: http-to-https-redirect-httproute namespace: asm-ingress spec: parentRefs: - name: external-http namespace: asm-ingress sectionName: http rules: - filters: - type: RequestRedirect requestRedirect: scheme: https statusCode: 301 EOF리디렉션
HTTPRoute를 적용합니다.kubectl apply -f ${WORKDIR}/default-httproute-redirect.yaml조정에는 시간이 걸립니다.
programmed=true까지 다음 명령어를 사용합니다.kubectl get gateway external-http -n asm-ingress -w
Online Boutique 샘플 앱 설치
Cloud Shell에서 전용
onlineboutique네임스페이스를 만듭니다.kubectl create namespace onlineboutiqueonlineboutique네임스페이스에 라벨을 추가합니다.kubectl label namespace onlineboutique istio-injection=enabledonlineboutique네임스페이스에istio-injection=enabled라벨을 지정하면 애플리케이션이 배포될 때 Cloud Service Mesh가 Envoy 사이드카 프록시를 자동으로 삽입합니다.Online Boutique 샘플 앱의 Kubernetes YAML 파일을 다운로드합니다.
curl -LO \ https://raw.githubusercontent.com/GoogleCloudPlatform/microservices-demo/main/release/kubernetes-manifests.yamlOnline Boutique 앱을 배포합니다.
kubectl apply -f kubernetes-manifests.yaml -n onlineboutique출력은 다음과 비슷합니다(GKE Autopilot 기본 리소스 요청 및 한도 설정에 대한 경고 포함).
Warning: autopilot-default-resources-mutator:Autopilot updated Deployment onlineboutique/emailservice: adjusted resources to meet requirements for containers [server] (see http://g.co/gke/autopilot-resources) deployment.apps/emailservice created service/emailservice created Warning: autopilot-default-resources-mutator:Autopilot updated Deployment onlineboutique/checkoutservice: adjusted resources to meet requirements for containers [server] (see http://g.co/gke/autopilot-resources) deployment.apps/checkoutservice created service/checkoutservice created Warning: autopilot-default-resources-mutator:Autopilot updated Deployment onlineboutique/recommendationservice: adjusted resources to meet requirements for containers [server] (see http://g.co/gke/autopilot-resources) deployment.apps/recommendationservice created service/recommendationservice created ...모든 배포가 실행 중인지 확인합니다.
kubectl get pods -n onlineboutique출력은 다음과 비슷합니다.
NAME READY STATUS RESTARTS AGE adservice-64d8dbcf59-krrj9 2/2 Running 0 2m59s cartservice-6b77b89c9b-9qptn 2/2 Running 0 2m59s checkoutservice-7668b7fc99-5bnd9 2/2 Running 0 2m58s ...GKE Autopilot 클러스터가 애플리케이션을 지원하는 데 필요한 컴퓨팅 인프라를 프로비저닝할 때까지 몇 분 정도 기다립니다.
다음 명령어를 실행하여
VirtualService매니페스트를frontend-virtualservice.yaml로 만듭니다.cat <<EOF > frontend-virtualservice.yaml apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: frontend-ingress namespace: onlineboutique spec: hosts: - "frontend.endpoints.${PROJECT}.cloud.goog" gateways: - asm-ingress/asm-ingressgateway http: - route: - destination: host: frontend port: number: 80 EOFVirtualService는 애플리케이션 네임스페이스(onlineboutique)에 생성됩니다. 일반적으로 애플리케이션 소유자는 앱 소유자가VirtualService를 배포하도록 트래픽이frontend애플리케이션으로 라우팅되는 양과 방법을 결정하고 구성합니다.클러스터에
frontend-virtualservice.yaml을 배포합니다.kubectl apply -f frontend-virtualservice.yaml다음 링크에 액세스합니다.
echo "https://frontend.endpoints.${PROJECT}.cloud.goog"Online Boutique 프런트엔드가 표시됩니다.
인증서의 세부정보를 표시하려면 브라우저의 주소 표시줄에서 사이트 정보 보기를 클릭하고 인증서(유효)를 클릭합니다.
인증서 뷰어에 유효 기간과 인증서 발급자를 포함한 관리형 인증서의 세부정보가 표시됩니다.
이제 서비스 메시에서 호스팅된 애플리케이션의 프런트엔드 역할을 하는 전역 HTTPS 부하 분산기가 준비되었습니다.
삭제
배포를 완료한 후에는 이후에 요금이 청구되지 않도록 Google Cloud에서 만든 리소스를 삭제할 수 있습니다. 프로젝트를 완전히 삭제하거나 클러스터 리소스를 삭제한 다음 클러스터를 삭제할 수 있습니다.
프로젝트 삭제
- In the Google Cloud console, go to the Manage resources page.
- In the project list, select the project that you want to delete, and then click Delete.
- In the dialog, type the project ID, and then click Shut down to delete the project.
개별 리소스 삭제
이 배포에서 사용된 Google Cloud 프로젝트를 유지하려면 개별 리소스를 삭제합니다.
Cloud Shell에서
HTTPRoute리소스를 삭제합니다.kubectl delete -f ${WORKDIR}/default-httproute-redirect.yaml kubectl delete -f ${WORKDIR}/default-httproute.yamlGKE 게이트웨이 리소스를 삭제합니다.
kubectl delete -f ${WORKDIR}/gke-gateway.yamlTLS 인증서 리소스(인증서 맵 항목 및 상위 인증서 맵 포함)를 삭제합니다.
gcloud --project=${PROJECT} certificate-manager maps entries delete edge2mesh-cert-map-entry --map="edge2mesh-cert-map" --quiet gcloud --project=${PROJECT} certificate-manager maps delete edge2mesh-cert-map --quiet gcloud --project=${PROJECT} certificate-manager certificates delete edge2mesh-cert --quietEndpoints DNS 항목을 삭제합니다.
gcloud endpoints services delete "frontend.endpoints.${PROJECT}.cloud.goog"출력은 다음과 비슷합니다.
Are you sure? This will set the service configuration to be deleted, along with all of the associated consumer information. Note: This does not immediately delete the service configuration or data and can be undone using the undelete command for 30 days. Only after 30 days will the service be purged from the system.
계속할지 묻는 메시지가 표시되면 Y를 입력합니다.
출력은 다음과 비슷합니다.
Waiting for async operation operations/services.frontend.endpoints.edge2mesh.cloud.goog-5 to complete... Operation finished successfully. The following command can describe the Operation details: gcloud endpoints operations describe operations/services.frontend.endpoints.edge2mesh.cloud.goog-5
고정 IP 주소를 삭제합니다.
gcloud compute addresses delete ingress-ip --global출력은 다음과 비슷합니다.
The following global addresses will be deleted: - [ingress-ip]
계속할지 묻는 메시지가 표시되면 Y를 입력합니다.
출력은 다음과 비슷합니다.
Deleted [https://www.googleapis.com/compute/v1/projects/edge2mesh/global/addresses/ingress-ip].
GKE 클러스터를 삭제합니다.
gcloud container clusters delete $CLUSTER_NAME --zone $CLUSTER_LOCATION출력은 다음과 비슷합니다.
The following clusters will be deleted. - [edge-to-mesh] in [us-central1]계속할지 묻는 메시지가 표시되면 Y를 입력합니다.
몇 분이 지나면 출력은 다음과 비슷합니다.
Deleting cluster edge-to-mesh...done. Deleted [https://container.googleapis.com/v1/projects/e2m-doc-01/zones/us-central1/clusters/edge-to-mesh].
다음 단계
- 서비스 메시에서 사용할 수 있는 GKE 인그레스에서 제공하는 다른 기능 알아보기
- GKE에 사용할 수 있는 다양한 유형의 클라우드 부하 분산 알아보기
- Cloud Service Mesh에서 제공하는 기능 알아보기
- 멀티 리전 부하 분산을 위해 여러 GKE 클러스터에 인그레스를 배포하는 방법 알아보기
- 그 밖의 참조 아키텍처, 다이어그램, 튜토리얼, 권장사항을 알아보려면 클라우드 아키텍처 센터를 확인하세요.