GKE 클러스터에 Knative serving이 설치되어 있어야 합니다. GKE 클러스터 기본 요건과 Knative serving 설치 방법에 대한 자세한 내용은 설치 가이드를 참조하세요.
GKE용 워크로드 아이덴티티 제휴로 인증 설정
GKE용 워크로드 아이덴티티 제휴를 사용하여 Knative serving 서비스를 Google Cloud API 및 서비스에 인증할 수 있습니다. 서비스를 클러스터에 배포하기 전에 GKE용 워크로드 아이덴티티 제휴를 설정해야 합니다. 그렇지 않으면 GKE용 워크로드 아이덴티티 제휴를 사용 설정하기 전 클러스터에 존재하는 각 서비스를 마이그레이션해야 합니다.
GKE용 워크로드 아이덴티티 제휴 사용에 대해 자세히 알아보기
GKE용 워크로드 아이덴티티 제휴로 측정항목 사용 설정
요청 수 또는 요청 지연 시간 같은 측정항목을 Google Cloud Observability에 사용 설정하려면 Cloud Monitoring에 대한 쓰기 권한을 수동으로 설정해야 합니다. 자세한 내용은 GKE용 워크로드 아이덴티티 제휴로 측정항목 사용 설정을 참조하세요.
내부 네트워크에 서비스를 배포하는 것은 내부 앱을 직원에게 제공하는 기업과 Knative serving 클러스터 외부에서 실행되는 클라이언트가 사용하는 서비스에 유용합니다. 이 구성을 사용하면 네트워크의 다른 리소스가 공개적으로 액세스할 수 없는 비공개 내부(RFC 1918) IP 주소를 사용하여 서비스와 통신할 수 있습니다.
내부 네트워크를 만들려면 공개 외부 네트워크 부하 분산기 대신 내부 TCP/UDP 부하 분산을 사용하도록 Cloud Service Mesh를 구성합니다. 그런 다음 VPC 네트워크의 내부 IP 주소에 Knative serving 서비스를 배포할 수 있습니다.
시작하기 전에
클러스터에 대한 admin 권한이 있어야 합니다.
커스텀 도메인을 구성한 경우 현재 내부 부하 분산기에서 Knative serving의 관리형 TLS가 지원되지 않으므로 관리형 TLS 기능을 중지해야 합니다.
Google Cloud CLI 버전 310.0 이상만 지원됩니다.
명령줄 도구 설정에 대한 자세한 내용은 다음을 참조하세요.
--option internal-load-balancer 옵션을 지정하면 스크립트가 GitHub에서 내부 부하 분산기 사용 설정 커스텀 리소스를 자동으로 가져옵니다. 커스텀 리소스를 수정해야 하는 경우 --custom_overlay 옵션을 사용하기 위한 안내를 따릅니다.
[[["이해하기 쉬움","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-07-16(UTC)"],[],[],null,["# Setting up Knative serving\n\nLearn how to setup and configure your installation of Knative serving.\n\nBefore you begin\n----------------\n\nYou must have Knative serving installed on your GKE cluster. See the\n[installation guide](/kubernetes-engine/enterprise/knative-serving/docs/install) for details about\nGKE cluster prerequisites and how to install Knative serving.\n\nSetting up authentication with Workload Identity Federation for GKE\n-------------------------------------------------------------------\n\nYou can use Workload Identity Federation for GKE to authenticate your Knative serving services\nto Google Cloud APIs and services. You must set up Workload Identity Federation for GKE\nbefore you deploy services to your cluster, otherwise each service that exists on\nyour cluster prior to enabling Workload Identity Federation for GKE needs to be migrated.\n[Learn more about using Workload Identity Federation for GKE](/kubernetes-engine/enterprise/knative-serving/docs/securing/workload-identity).\n\n### Enabling metrics with Workload Identity Federation for GKE\n\nTo enable metrics, like reporting request count or request latency to\nGoogle Cloud Observability, you need to manually set write permissions for\nCloud Monitoring. For details, see\n[Enabling metrics with Workload Identity Federation for GKE](/kubernetes-engine/enterprise/knative-serving/docs/securing/workload-identity#enabling_all_metrics_with_workload_identity).\n\nConfiguring HTTPS and custom domains\n------------------------------------\n\nTo enable HTTPS and set a custom domain, see the following pages:\n\n- [Using managed TLS certificates and HTTPS](/kubernetes-engine/enterprise/knative-serving/docs/managed-tls)\n- [Mapping custom domains](/kubernetes-engine/enterprise/knative-serving/docs/mapping-custom-domains)\n\nSetting up Cloud Service Mesh\n-----------------------------\n\nTo configure Cloud Service Mesh options for Knative serving, see the\n[In-cluster control plane options](/service-mesh/v1.18/docs/unified-install/options/all-install-options),\nincluding how to\n[set up a private, internal network](/service-mesh/v1.18/docs/unified-install/options/enable-optional-features#enable_an_internal_load_balancer).\n| **Note:** The [Google-managed control plane](/service-mesh/docs/supported-features-mcp) is currently not fully supported by Knative serving.\n\n### Setting up a private, internal network\n\nDeploying services on an internal network is useful for enterprises\nthat provide internal apps to their staff, and for services that are used by\nclients that run outside the Knative serving cluster. This configuration\nallows other resources in your network to communicate with the service using a\nprivate, internal\n([RFC 1918](https://tools.ietf.org/html/rfc1918))\nIP address that can't be accessed by the public.\n\nTo create your internal network, you configure Cloud Service Mesh to use\n[Internal TCP/UDP Load Balancing](/kubernetes-engine/docs/how-to/internal-load-balancing)\ninstead of a public, external network load balancer. You can then deploy your\nKnative serving services on an internal IP address within your\n[VPC network](/vpc/docs/vpc).\n\n**Before you begin**\n\n- You must have `admin` permissions on your cluster.\n- If you configured a custom domain, you must [disable the managed TLS feature](/kubernetes-engine/enterprise/knative-serving/docs/managed-tls#disable-for-domain) because Managed TLS on Knative serving is currently unsupported by the internal load balancer.\n- Only Google Cloud CLI versions 310.0 or above are supported. For details about setting up your command-line tools, see\n - [GKE clusters on Google Cloud](/kubernetes-engine/enterprise/knative-serving/docs/install/on-gcp/command-line-tools)\n - [GKE clusters outside Google Cloud](/kubernetes-engine/enterprise/knative-serving/docs/install/outside-gcp/command-line-tools)\n\nTo set up the internal load balancer:\n\n1. Enable the internal load balancer feature in Cloud Service Mesh.\n\n The internal load balancer is an optional feature that you can configure\n during the installation of Cloud Service Mesh, or by updating your existing\n installation.\n\n Follow the steps in\n [Enabling optional features on the in-cluster control plane](/service-mesh/v1.18/docs/unified-install/options/enable-optional-features)\n and make sure to include the `--option internal-load-balancer` script option.\n\n When you specify the `--option internal-load-balancer` option, the script\n automatically fetches the\n [Enable an internal load balancer](/service-mesh/v1.18/docs/unified-install/options/enable-optional-features#enable_an_internal_load_balancer)\n custom resource from GitHub. If you need to modify the custom resource,\n follow the instructions for using the `--custom_overlay` option instead.\n2. Run the following command to watch updates to your GKE\n cluster:\n\n ```bash\n kubectl -n INGRESS_NAMESPACE get svc istio-ingressgateway --watch\n ```\n\n Replace \u003cvar translate=\"no\"\u003eINGRESS_NAMESPACE\u003c/var\u003e with the namespace of your\n Cloud Service Mesh ingress service. Specify `istio-system` if you installed\n Cloud Service Mesh using its default configuration.\n 1. Note the annotation `cloud.google.com/load-balancer-type: Internal`.\n 2. Look for the value of `IP` in the Ingress load balancer to change to a [private IP address](/vpc/docs/ip-addresses).\n 3. Press `Ctrl+C` to stop the updates once you see a private IP address in the `IP` field.\n3. For [private clusters](/kubernetes-engine/docs/concepts/private-cluster-concept)\n on Google Cloud, you must open ports. For details, see\n [opening ports on your private cluster](/service-mesh/v1.18/docs/private-cluster-open-port)\n in the Cloud Service Mesh documentation.\n\nTo verify internal connectivity after your changes:\n\n1. Deploy a service called `sample` to Knative serving in the\n `default` namespace:\n\n gcloud run deploy sample \\\n --image gcr.io/knative-samples/helloworld \\\n --namespace default\n --platform gke\n\n2. Create a Compute Engine virtual machine\n (VM) in the same zone as the GKE cluster:\n\n VM=cloudrun-gke-ilb-tutorial-vm\n\n gcloud compute instances create $VM\n\n3. Store the private IP address of the Istio Ingress Gateway in an environment\n variable called `EXTERNAL_IP` and a file called `external-ip.txt`:\n\n ```bash\n export EXTERNAL_IP=$(kubectl -n INGRESS_NAMESPACE get svc istio-ingressgateway \\\n -o jsonpath='{.status.loadBalancer.ingress[0].ip}' | tee external-ip.txt)\n ```\n\n Replace \u003cvar translate=\"no\"\u003eINGRESS_NAMESPACE\u003c/var\u003e with the namespace of your\n Cloud Service Mesh ingress service. Specify `istio-system` if you installed\n Cloud Service Mesh using its default configuration.\n4. Copy the file containing the IP address to the VM:\n\n gcloud compute scp external-ip.txt $VM:~\n\n5. Connect to the VM using SSH:\n\n gcloud compute ssh $VM\n\n6. While in the SSH session, test the sample service:\n\n curl -s -w'\\n' -H Host:sample.default.nip.io $(cat external-ip.txt)\n\n The output is as follows: \n\n ```\n Hello World!\n ```\n7. Leave the SSH session:\n\n exit\n\nSetting up a multi-tenant environment\n-------------------------------------\n\nIn multi-tenant use cases, you'll need to manage and deploy\nKnative serving services to a Google Kubernetes Engine cluster that is\noutside your current project. For more information about GKE\nmulti-tenancy, see\n[Cluster multi-tenancy](/kubernetes-engine/docs/concepts/multitenancy-overview).\n\nTo learn how to configure multi-tenancy for Knative serving, see\n[Cross-project multi-tenancy](/kubernetes-engine/enterprise/knative-serving/docs/multi-tenancy).\n\nWhat's next\n-----------\n\n- [Building containers](/kubernetes-engine/enterprise/knative-serving/docs/building/containers)\n- [Deploying containers](/kubernetes-engine/enterprise/knative-serving/docs/deploying)\n- [Troubleshooting](/kubernetes-engine/enterprise/knative-serving/docs/troubleshooting)"]]
