이 주제에서는 Apigee Hybrid에 사용할 수 있도록 SNI 이외의 클라이언트를 사용 설정하는 방법을 설명합니다.
SNI 이외의 클라이언트 구성 방법
이 섹션에서는 Apigee Hybrid에서 SNI(서버 이름 표시) 이외의 클라이언트의 지원을 사용 설정하는 방법을 설명합니다. SNI 이외의 클라이언트는 포트 443을 사용하며 하이브리드 런타임 인스턴스를 Google Cloud Load Balancing과 통합하려는 경우나 SNI를 지원하지 않는 클라이언트에 필요합니다.
인그레스가 지정된 포트(443)에 대해 클러스터 수준에 있고, ApigeeRoute CRD에 대해 하나의 키/인증서 쌍만 가능하므로, 모든 조직이 동일한 키/인증서 쌍을 공유해야 합니다.
클러스터에 환경 그룹이 2개 이상 포함되면 어떻게 되나요? 가상 호스트가 동일한 키/인증서 쌍을 공유할 경우 작동하나요?
모든 환경 그룹 간의 모든 호스트 이름이 동일한 키/인증서 쌍을 사용해야 합니다.
게이트웨이 대신 ApigeeRoute를 만드는 이유가 무엇인가요?
ApigeeRoutes는 Apigee로 검증할 수 있지만 게이트웨이(Istio CRD)는 그렇지 않습니다.
기술적으로 게이트웨이도 작동 가능하지만, 잠재적인 구성 실수를 방지할 수 있습니다(검증 웹훅 사용).
Apigee용으로 SNI 이외의 클라이언트를 구성하려면 어떻게 해야 하나요?
Apigee 인스턴스가 Google 부하 분산기를 통해 노출되면 부하 분산기는 부하 분산 문서의 설명대로 SNI 이외의 클라이언트를 지원합니다.
그렇지 않고 내부 PSC 엔드포인트나 VPC를 통해 Apigee 인스턴스를 노출한 경우 기본적으로 Apigee 인스턴스는 SNI 이외의 클라이언트를 지원합니다.
[[["이해하기 쉬움","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-09-10(UTC)"],[],[],null,["# Enable non-SNI clients\n\nThis topic explains how to enable non-SNI clients\nfor use with Apigee hybrid.\n\nHow to configure a non-SNI client\n---------------------------------\n\nThis section explains how to enable support for non-SNI ([Server Name Indication](https://en.wikipedia.org/wiki/Server_Name_Indication)) clients in Apigee hybrid. A non-SNI client uses port 443 and is required if you want to integrate hybrid runtime instances with Google [Cloud Load Balancing](https://cloud.google.com/load-balancing/docs) or for clients that do not support SNI.\n\n1. Create an ApigeeRoute custom resource definition (CRD). Be sure that `enableNonSniClient` is set to `true`: \n\n ```actionscript-3\n apiVersion: apigee.cloud.google.com/v1alpha1\n kind: ApigeeRoute\n metadata:\n name: ROUTE_NAME\n namespace: APIGEE_NAMESPACE\n spec:\n hostnames:\n - \"*\"\n ports:\n - number: 443\n protocol: HTTPS\n tls:\n credentialName: CREDENTIAL_NAME\n mode: SIMPLE\n #optional\n minProtocolVersion: TLS_AUTO\n selector:\n app: apigee-ingressgateway\n enableNonSniClient: true\n ```\n\n\n Where:\n - \u003cvar translate=\"no\"\u003eROUTE_NAME\u003c/var\u003e is the name you give to the custom resource (CR).\n - \u003cvar translate=\"no\"\u003eCREDENTIAL_NAME\u003c/var\u003e is the name of a Kubernetes Secret deployed to the cluster that contains TLS credentials for your virtualhost. You can find the credential name with the following `kubectl` Command: \n\n ```\n kubectl -n APIGEE_NAMESPACE get ApigeeRoutes -o=yaml | grep credentialName\n ```\n - `hostnames` must be set to the wildcard \"\\*\". **Note:**Do not create two ApigeeRoute objects with a wildcard \"\\*\" hostname.\n2. Open your overrides file and make the change described in the next step.\n3. For each environment group, add the ApigeeRoute name to the `additionalGateways` property. For example: \n\n ```scdoc\n virtualhosts:\n - name: default\n sslCertPath: ./certs/fullchain.pem\n sslKeyPath: ./certs/privkey.pem\n additionalGateways: [\"ROUTE_NAME\"]\n ```\n4. Save the CRD file. For example: `ApigeeRoute.yaml`\n5. Apply the CRD to the cluster: \n\n ```\n kubectl apply -f ApigeeRoute.yaml -n APIGEE_NAMESPACE\n ```\n6. Apply the change to `virtualhosts`. If you have set the \u003cvar translate=\"no\"\u003e$ENV_GROUP\u003c/var\u003e environment variable in your shell, you can use that in the following commands: \n\n ```\n helm upgrade $ENV_GROUP apigee-virtualhost/ \\\n --namespace APIGEE_NAMESPACE \\\n --atomic \\\n --set envgroup=$ENV_GROUP \\\n -f OVERRIDES_FILE.yaml\n ```\n | **Note:** If you see an error saying `Error: UPGRADE FAILED: \"`*ENV_GROUP*`\" has no deployed releases`, replace `upgrade` with `install` and try the command again.\n\nUsage notes\n-----------\n\n- **What happens if the cluster has more than one org?**\n\n\n Since the ingress is at the cluster level for a given port (443), and there can only\n be one key/cert pair for the ApigeeRoute CRD, all orgs must share the same key/cert pair.\n- **What happens if the cluster has more than one environment group? Will it work\n if the virtual hosts share the same key/cert pair?**\n\n\n All hostnames across all environment groups must use the same key/cert pair.\n- **Why are we creating an ApigeeRoute instead of Gateway?**\n\n\n ApigeeRoutes can be validated by Apigee; however,\n [Gateway](https://istio.io/latest/docs/reference/config/networking/gateway/) (the Istio CRD) cannot be.\n Technically, even Gateway can work, but we can prevent potential configuration mistakes\n (through a validation webhook).\n- **How can I configure non-SNI clients for Apigee?**\n\n\n If your Apigee instance is exposed through a Google Load Balancer, then the Load Balancer supports non-SNI clients\n as explained\n [in the Load Balancing documentation.](https://cloud.google.com/load-balancing/docs/ssl-certificates#multiplessl-selection)\n Otherwise, if you have exposed an Apigee instance through an internal PSC endpoint or VPC, by default the Apigee instance supports non-SNI clients."]]
