이 페이지에서는 내부 애플리케이션 부하 분산기용 인그레스가 Google Kubernetes Engine(GKE)에서 작동하는 방식을 설명합니다. 내부 애플리케이션 부하 분산기용 인그레스를 설정 및 사용하는 방법도 알아볼 수 있습니다.
GKE에서 내부 애플리케이션 부하 분산기는 프록시 기반의 리전별 레이어 7 부하 분산기로 내부 부하 분산 IP 주소를 기반으로 서비스를 실행하고 확장할 수 있습니다. GKE 인그레스 객체는 GKE 클러스터에서 인그레스 객체를 생성하여 기본적으로 내부 애플리케이션 부하 분산기를 지원합니다.
내부 애플리케이션 부하 분산기는 네트워크의 프록시 풀을 제공합니다.
프록시는 URL 맵, BackendService의 세션 어피니티, 각 백엔드 NEG의 분산 모드 등 기타 요인을 기반으로 이동하는 각 HTTP(S) 요청의 위치를 평가합니다.
리전의 내부 애플리케이션 부하 분산기는 VPC 네트워크의 해당 리전에 프록시 전용 서브넷을 사용하여 Google Cloud에 의해 생성된 각 프록시에 내부 IP 주소를 할당합니다.
기본적으로 부하 분산기의 전달 규칙에 할당되는 IP 주소는 프록시 전용 서브넷 대신 GKE에서 할당한 노드의 서브넷 범위에서 가져옵니다. 또한 규칙을 만들 때 모든 서브넷에서 전달 규칙의 IP 주소를 수동으로 지정할 수 있습니다.
다음 다이어그램은 이전 단락에서 설명한 대로 내부 애플리케이션 부하 분산기의 트래픽 흐름을 간략하게 보여줍니다.
내부 애플리케이션 부하 분산기 작동 방식은 다음과 같습니다.
클라이언트는 부하 분산기 전달 규칙의 IP 주소와 포트에 연결됩니다.
프록시는 클라이언트의 네트워크 연결을 수신하고 종료합니다.
프록시는 부하 분산기의 URL 맵과 백엔드 서비스에서 지정한 대로 NEG의 적절한 엔드포인트(Pod)에 대한 연결을 설정합니다.
각 프록시는 해당 부하 분산기의 전달 규칙에서 지정한 IP 주소와 포트를 리슨합니다. 프록시에서 엔드포인트로 전송되는 각 패킷의 소스 IP 주소는 프록시 전용 서브넷에서 프록시에 할당된 내부 IP 주소입니다.
부하 분산기와 애플리케이션 간 HTTPS(TLS)
내부 애플리케이션 부하 분산기는 클라이언트와 애플리케이션 사이의 프록시 역할을 합니다. 클라이언트는 HTTP 또는 HTTPS를 사용하여 부하 분산기 프록시와 통신할 수 있습니다. 부하 분산기 프록시와 애플리케이션 간의 연결에는 기본적으로 HTTP가 사용됩니다. 하지만 애플리케이션이 GKE Pod에서 실행되고 HTTPS 요청을 수신할 수 있으면 애플리케이션으로 요청을 전달할 때 HTTPS를 사용하도록 부하 분산기를 구성할 수 있습니다.
부하 분산기와 애플리케이션 사이에서 사용되는 프로토콜을 구성하려면 서비스 매니페스트에서 cloud.google.com/app-protocols 주석을 사용합니다.
다음 서비스 매니페스트는 두 포트를 지정합니다. 주석은 내부 애플리케이션 부하 분산기가 서비스의 포트 80을 타겟팅할 때 HTTP를 사용하도록 지정하고 서비스의 포트 443을 타겟팅할 때 HTTPS를 사용하도록 지정합니다.
주석에 포트의 name 필드를 사용해야 합니다. targetPort와 같은 다른 필드를 사용하지 마세요.
[[["이해하기 쉬움","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-08-08(UTC)"],[],[],null,["# Ingress for internal Application Load Balancers\n\n[Autopilot](/kubernetes-engine/docs/concepts/autopilot-overview) [Standard](/kubernetes-engine/docs/concepts/choose-cluster-mode)\n\n*** ** * ** ***\n\nThis page explains how Ingress for internal Application Load Balancers works in\nGoogle Kubernetes Engine (GKE). You can also learn how to [set up and use Ingress for\ninternal Application Load Balancers](/kubernetes-engine/docs/how-to/internal-load-balance-ingress).\n\nIn GKE, the internal Application Load Balancer is a proxy-based,\nregional, Layer 7 load balancer that enables you to run and scale your services\nbehind an internal load balancing IP address. GKE\n[Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/)\nobjects support the internal Application Load Balancer natively through the creation of\nIngress objects on GKE clusters.\n\nFor general information about using Ingress for load balancing in\nGKE, see\n[HTTP(S) load balancing with Ingress](/kubernetes-engine/docs/concepts/ingress).\n\nBenefits of using Ingress for internal Application Load Balancers\n-----------------------------------------------------------------\n\nUsing GKE Ingress for internal Application Load Balancers provides the\nfollowing benefits:\n\n- A highly available, GKE-managed Ingress controller.\n- Load balancing for internal, service-to-service communication.\n- Container-native load balancing with [Network Endpoint Groups (NEG)](/load-balancing/docs/negs).\n- Application routing with HTTP and HTTPS support.\n- High-fidelity Compute Engine health checks for resilient services.\n- Envoy-based proxies that are deployed on-demand to meet traffic capacity needs.\n\nSupport for Google Cloud features\n---------------------------------\n\nIngress for internal Application Load Balancers supports a variety of additional features.\n\n- [Self-managed SSL Certificates](/load-balancing/docs/ssl-certificates) using Google Cloud. Only regional certificates are supported for this feature.\n- Self-managed SSL Certificates using Kubernetes [Secrets](https://kubernetes.io/docs/concepts/configuration/secret/).\n- The [Session Affinity](/load-balancing/docs/backend-service#session_affinity) and [Connection Timeout](/load-balancing/docs/backend-service#timeout-setting) [BackendService](/load-balancing/docs/backend-service) features. You can configure these features using [BackendConfig](/kubernetes-engine/docs/concepts/backendconfig).\n\nRequired networking environment for internal Application Load Balancers\n-----------------------------------------------------------------------\n\n| **Important:** Ingress for internal Application Load Balancers requires you to use [NEGs](/load-balancing/docs/negs) as backends. It does not support Instance Groups as backends.\n\nThe internal Application Load Balancer provides a pool of proxies for your network.\nThe proxies evaluate where each HTTP(S) request should go based on factors such as\nthe URL map, the BackendService's session affinity, and the balancing mode of\neach backend NEG.\n\nA region's internal Application Load Balancer uses the [proxy-only subnet](/load-balancing/docs/proxy-only-subnets)\nfor that region in your VPC network to assign internal IP\naddresses to each proxy created by Google Cloud.\n\nBy default, the IP address assigned to a load balancer's forwarding rule comes\nfrom the node's subnet range assigned by GKE instead of from the\nproxy-only subnet. You can also [manually specify an IP address](/load-balancing/docs/using-forwarding-rules#adding-fr)\nfor the forwarding rule from any subnet when you create the rule.\n\nThe following diagram provides an overview of the traffic flow for an\ninternal Application Load Balancer, as described in the preceding paragraph.\n\nHere's how the internal Application Load Balancer works:\n\n1. A client makes a connection to the IP address and port of the load balancer's forwarding rule.\n2. A proxy receives and terminates the client's network connection.\n3. The proxy establishes a connection to the appropriate endpoint (Pod) in a NEG, as determined by the load balancer's URL map, and backend services.\n\nEach proxy listens on the IP address and port specified by the corresponding\nload balancer's forwarding rule. The source IP address of each packet sent from a proxy to an endpoint\nis the internal IP address assigned to that proxy from the proxy-only subnet.\n\nHTTPS (TLS) between load balancer and your application\n------------------------------------------------------\n\nAn internal Application Load Balancer acts as a proxy between your clients and your\napplication. Clients can use HTTP or HTTPS to communicate with the load\nbalancer proxy. The connection from the load balancer proxy to\nyour application uses HTTP by default. However, if your application runs in a\nGKE Pod and can receive HTTPS requests, you can\nconfigure the load balancer to use HTTPS when it forwards requests to your\napplication.\n\nTo configure the protocol used between the load balancer and your application,\nuse the `cloud.google.com/app-protocols` annotation in your Service manifest.\n\nThe following Service manifest specifies two ports. The annotation specifies that\nan internal Application Load Balancer should use HTTP when it targets port 80 of the Service,\nAnd use HTTPS when it targets port 443 of the Service.\n\nYou must use the port's `name` field in the annotation. Do not use a different field such as `targetPort`.\n**Caution:** To limit potential downtime, do not edit the Service's port name when you enable this feature. If your Service's port doesn't have a name, use the empty port name as the key in the annotation, similar to `cloud.google.com/app-protocols: '{\"\": \"HTTPS\"}'`. Editing the port name or annotation after the initial setup might cause downtime for your applications \n\n apiVersion: v1\n kind: Service\n metadata:\n name: my-service\n annotations:\n cloud.google.com/app-protocols: '{\"my-https-port\":\"HTTPS\",\"my-http-port\":\"HTTP\"}'\n spec:\n type: NodePort\n selector:\n app: metrics\n department: sales\n ports:\n - name: my-https-port\n port: 443\n targetPort: 8443\n - name: my-http-port\n port: 80\n targetPort: 50001\n\nWhat's next\n-----------\n\n- [Learn how to deploy a proxy-only subnet](/load-balancing/docs/l7-internal/setting-up-l7-internal#configure-a-network).\n- [Learn about Ingress for external Application Load Balancers](/kubernetes-engine/docs/concepts/ingress-xlb).\n- [Learn how to configure Ingress for internal Application Load Balancers](/kubernetes-engine/docs/how-to/internal-load-balance-ingress).\n- [Read an overview of networking in GKE](/kubernetes-engine/docs/concepts/network-overview)."]]