이 문서에서는 Envoy 프록시에 대해 설명하지만, Cloud Service Mesh에 모든 공개 표준 API(xDS) 프록시를 사용할 수 있습니다. 그러나 Google은 Envoy 프록시로만 Cloud Service Mesh를 테스트했습니다.
모든 알려진 보안 취약점을 해결하기 위해서는 최신 Envoy 버전을 사용하는 것이 좋습니다. Envoy 보안 자문에 대한 자세한 내용은 Envoy 보안 자문을 참조하세요.
Google Cloud 콘솔은 하이브리드 연결 네트워크 엔드포인트 그룹(NEG)을 지원하지 않습니다. 하이브리드 연결 NEG를 만들거나 삭제하려면 Google Cloud CLI를 사용합니다.
데이터 영역에서 상태 점검을 처리하므로 Google Cloud 콘솔, API 또는 gcloud CLI를 사용하여 상태 점검 상태를 가져올 수 없습니다.
iptables를 확인하고 올바르게 설정되었는지 확인합니다. iptables를 구성하는 방법에 대한 자세한 내용은 HTTP 필터링 구성에 대한 Envoy의 참고사항을 참조하세요.
Google Cloud 콘솔을 사용하여 가상 머신(VM) 인스턴스를 만드는 경우 다시 시작하기 전에는 일부 ipv6 관련 모듈이 설치 및 제공되지 않습니다. 따라서 누락된 종속 항목으로 인해 iptables.sh가 실패합니다. 이러한 경우에는 VM을 다시 시작하고 run.sh 스크립트를 다시 실행합니다.
gcloud CLI를 사용하여 Compute Engine VM을 만들면 이러한 문제가 발생하지 않습니다.
고급 트래픽 관리 제한사항
고급 트래픽 관리 제한사항은 다음과 같습니다.
BackendService.sessionAffinity 값이 NONE이 아니며 BackendService.localityLbPolicy가 MAGLEV 또는 RING_HASH가 아닌 부하 분산 정책으로 설정된 경우 세션 어피니티 설정이 적용되지 않습니다.
gcloud import 명령어는 백엔드 서비스 및 URL 맵과 같은 리소스의 최상위 레벨 필드를 삭제하지 않습니다. 예를 들어 백엔드 서비스가 circuitBreakers 설정으로 생성된 경우 후속 gcloud import 명령어를 사용해서 해당 설정을 업데이트할 수 있습니다.
하지만 백엔드 서비스에서 이러한 설정을 삭제할 수 없습니다.
circuitBreakers 설정 없이 리소스 자체를 삭제하고 다시 만들 수 있습니다.
서비스 디렉터리 제한사항
서비스 디렉터리 및 Cloud Service Mesh는 클라이언트의 네트워크 도달성을 보장하지 않습니다.
백엔드 서비스는 다음 중 하나만 참조할 수 있습니다.
관리형 인스턴스 그룹 또는 비관리형 인스턴스 그룹
네트워크 엔드포인트 그룹
서비스 결합
서비스 디렉터리 서비스는 load-balancing-scheme=INTERNAL_SELF_MANAGED가 있는 전역 백엔드 서비스에서만 사용할 수 있습니다.
서비스 결합에서 참조되는 서비스 디렉터리 서비스는 삭제할 수 있습니다. 백엔드 서비스가 연결된 기본 서비스 디렉터리 서비스가 삭제되면 Cloud Service Mesh를 사용하는 애플리케이션이 이 서비스에 트래픽을 전송할 수 없으므로, 요청이 실패합니다. 권장사항은 관측 가능성 및 디버깅을 참조하세요.
서비스 디렉터리 서비스를 백엔드 서비스에 바인딩할 때 백엔드 서비스에 상태 점검을 구성할 수 없습니다.
다음 단계
프록시리스 gRPC 애플리케이션을 사용하는 Cloud Service Mesh에 적용되는 제한사항을 알아보려면 프록시리스 gRPC 제한사항을 참조하세요.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-04-23(UTC)"],[],[],null,["# Cloud Service Mesh limitations with Envoy\n=========================================\n\nThis document describes limitations that apply to Cloud Service Mesh with the\nGoogle Cloud APIs, including\nadvanced traffic management limitations. It does not apply to Cloud Service Mesh\nwith the Istio APIs.\n\nFor information about *limits* , see [Quotas and limits](/service-mesh/quotas).\n\nGeneral limitations\n-------------------\n\nThe limitations of Cloud Service Mesh include the following:\n\n- Cloud Service Mesh with the service routing APIs only supports Google Cloud APIs.\n- You can use Cloud Service Mesh to configure the following request protocols: HTTP (HTTP/1.1 or HTTP/2), HTTPS, TCP, and gRPC.\n- When you use Envoy as the dataplane proxy, the [`stream_idle_timeout` value](https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/filters/network/http_connection_manager/v3/http_connection_manager.proto) defaults to 5 minutes. This is not configurable through Cloud Service Mesh.\n- When you use the `TCPRoute` resource to configure the TCP request protocol, you cannot use the [advanced traffic management features](/service-mesh/docs/service-routing/advanced-traffic-management). Advanced traffic management is only available when you configure the data plane to handle HTTP or gRPC requests.\n- Cloud Service Mesh supports [VPC Network Peering](/vpc/docs/vpc-peering) with the [service routing APIs](/service-mesh/docs/service-routing/service-routing-overview).\n- Cloud Service Mesh does not support server-first protocols.\n- You cannot use Cloud Service Mesh with services running in [Knative](/knative) or [Google Cloud Serverless Computing](/serverless).\n- This document discusses Envoy proxies, but you can use any [open standard API (xDS) proxy](https://www.envoyproxy.io/docs/envoy/latest/api/api) with Cloud Service Mesh. However, Google has tested Cloud Service Mesh only with the Envoy proxy.\n- To ensure that all known security vulnerabilities are mitigated, we recommend that you use the most recent Envoy version. For information about Envoy security advisories, see [Envoy Security Advisories](https://github.com/envoyproxy/envoy/security/advisories).\n- The Google Cloud console does not support hybrid connectivity network endpoint groups (NEGs). To create or delete hybrid connectivity NEGs, use the Google Cloud CLI.\n- Because your data plane handles health checks, you cannot use the Google Cloud console, API, or gcloud CLI to retrieve health check status.\n- Check `iptables` and ensure that it is set up correctly. For more information\n about how to configure `iptables`, see Envoy's notes about configuring\n [HTTP filtering](https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_filters/original_src_filter#extra-setup).\n\n - If you use the Google Cloud console to create virtual machine (VM) instances, some `ipv6`-related modules are not installed and available before a restart. As a result, `iptables.sh` fails due to missing dependencies. In such a case, restart the VM and rerun the `run.sh` script.\n - If you use the gcloud CLI to create Compute Engine VMs, you are not expected to have this problem.\n\nAdvanced traffic management limitations\n---------------------------------------\n\nThe limitations of advanced traffic management include the following:\n\n- If the value of `BackendService.sessionAffinity` is not NONE, and `BackendService.localityLbPolicy` is set to a load-balancing policy other than `MAGLEV` or `RING_HASH`, the session affinity settings don't take effect.\n- The `gcloud import` command doesn't delete top-level fields of the resource, such as the backend service and the URL map. For example, if a backend service is created with settings for `circuitBreakers`, you can use a subsequent `gcloud import` command to update those settings. However, you cannot delete those settings from the backend service. You can delete and recreate the resource itself without the `circuitBreakers` settings.\n\nLimitations with Service Directory\n----------------------------------\n\n- Service Directory and Cloud Service Mesh don't guarantee network reachability for clients.\n- A backend service can only reference one of the following:\n\n - Managed instance group or unmanaged instance group\n - Network endpoint group\n - Service bindings\n- Service Directory services can only be used with global\n backend services with `load-balancing-scheme=INTERNAL_SELF_MANAGED`.\n\n- A Service Directory service that is referenced by a service\n binding can be deleted. If the underlying Service Directory\n service to which the backend service is attached is deleted, applications\n that use Cloud Service Mesh cannot send traffic to this service, therefore,\n requests fail. See [Observability and debugging](/traffic-director/docs/service-directory-observability) for best practices.\n\n- When you bind a Service Directory service to a backend\n service, you cannot configure a health check on that backend service.\n\nWhat's next\n-----------\n\n- To learn about limitations that apply to Cloud Service Mesh with proxyless gRPC applications, see [Proxyless gRPC limitations](/service-mesh/docs/service-routing/limitations-proxyless)."]]
