유연성을 향상하기 위해 독립적인 NEG를 만들 수도 있습니다. 이 경우 부하 분산기의 모든 측면을 만들고 관리해야 합니다.
컨테이너 기반 부하 분산의 이점
컨테이너 기반 부하 분산의 이점은 다음과 같습니다.
포드는 부하 분산에 사용되는 핵심 객체입니다.
kube-proxy는 노드의 iptables 규칙을 구성하여 트래픽을 포드에 분산합니다. 컨테이너 기반 부하 분산이 없으면 부하 분산기 트래픽은 노드 인스턴스 그룹으로 이동하여 iptables 규칙을 통해 같은 노드에 있거나 없을 수 있는 포드로 라우팅됩니다. 컨테이너 기반 부하 분산을 사용하면 트래픽을 수신해야 하는 포드에 부하 분산기 트래픽이 직접 분산되어 추가 네트워크 홉이 제거됩니다. 컨테이너 기본 부하 분산은 포드를 직접 대상 지정하기 때문에 상태 점검 개선에도 도움이 됩니다.
기본 동작(왼쪽)과 컨테이너 기반 부하 분산기 동작 비교
네트워크 성능 향상
컨테이너 기반 부하 분산기가 포드와 직접 통신하고 연결에서 네트워크 홉이 줄어들기 때문에 지연 시간과 처리량이 모두 향상됩니다.
가시성 향상
컨테이너 기반 부하 분산을 통해 애플리케이션 부하 분산기에서 포드로의 지연 시간에 대한 가시성을 얻을 수 있습니다. 애플리케이션 부하 분산기에서 각 포드로의 지연 시간이 표시되고, 노드 IP 기반 컨테이너 기반 부하 분산으로 집계됩니다. 이를 통해 NEG 수준에서 서비스 문제를 쉽게 해결할 수 있습니다.
NEG 데이터 모델은 서비스 메시를 위한Google Cloud의 완전 관리형 트래픽 컨트롤 플레인인 Cloud Service Mesh를 사용하는 데 필요합니다.
포드 준비
관련 포드의 경우 해당 인그레스 컨트롤러는 cloud.google.com/load-balancer-neg-ready 유형의 준비 게이트를 관리합니다. 인그레스 컨트롤러는 NEG에 있는 모든 엔드포인트 상태를 포함하여 부하 분산기의 상태 점검 상태를 폴링합니다. 부하 분산기의 상태 점검 상태가 특정 포드에 해당하는 엔드포인트가 정상임을 나타내면 인그레스 컨트롤러는 포드의 준비 게이트 값을 True로 설정합니다.
이 준비 게이트의 값과 포드의 준비 프로브(정의된 경우)를 고려하여 각 노드에서 실행되는 kubelet이 포드의 유효 준비를 계산합니다.
포드 준비 게이트는 인그레스를 통해 컨테이너 기반 부하 분산을 사용할 때 자동으로 사용 설정됩니다.
준비 게이트는 순차적 업데이트 속도를 관리합니다. 순차적 업데이트를 시작하면 GKE에서 새 포드를 만들 때 각 새 포드의 엔드포인트가 NEG에 추가됩니다. 엔드포인트가 부하 분산기의 관점에서 정상이면 인그레스 컨트롤러는 준비 게이트를 True로 설정합니다. 따라서 새로 만든 포드는 GKE에서 이전 포드를 제거하기 전에 최소한 준비 게이트를 통과해야 합니다. 이렇게 하면 포드의 해당 엔드포인트가 이미 부하 분산기의 상태 점검을 통과하고 백엔드 용량이 유지되도록 할 수 있습니다.
컨테이너 이미지가 잘못되었거나 부하 분산기 상태 점검이 잘못 구성되어 포드의 준비 게이트가 포드가 준비되었음을 나타내지 않으면 부하 분산기가 트래픽을 새 포드로 전송하지 않습니다. 업데이트된 배포를 롤아웃하는 동안 이러한 오류가 발생하면 포드의 준비 게이트가 True가 아니므로 새 포드를 만들려고 시도할 때 롤아웃이 중지됩니다. 이 상황을 감지하고 해결하는 방법은 문제 해결 섹션을 참조하세요.
컨테이너 기반 부하 분산 및 준비 게이트가 없으면 GKE는 포드를 준비 상태로 표시하기 전에 부하 분산기의 엔드포인트가 정상인지 감지할 수 없습니다. 이전 Kubernetes 버전에서는 지연 기간(배포 사양에서 minReadySeconds)을 지정하여 포드가 삭제되고 대체되는 속도를 관리합니다.
GKE는 다음 조건 중 하나가 충족되면 포드의 cloud.google.com/load-balancer-neg-ready 값을 True로 설정합니다.
[[["이해하기 쉬움","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-06-19(UTC)"],[],[],null,["# Container-native load balancing\n\n[Autopilot](/kubernetes-engine/docs/concepts/autopilot-overview) [Standard](/kubernetes-engine/docs/concepts/choose-cluster-mode)\n\n*** ** * ** ***\n\nThis page explains container-native load balancing in\nGoogle Kubernetes Engine (GKE).\n\nThis page assumes that you know about\n[Cloud Load Balancing](/load-balancing/docs/load-balancing-overview#load-balancer-types)\nand\n[zonal network endpoint groups (NEGs)](/load-balancing/docs/negs/zonal-neg-concepts).\nWith container-native load balancing, these load balancers can directly and\nand evenly distribute traffic to Pods.\n\nContainer-native load balancing architecture\n--------------------------------------------\n\nContainer-native load balancing uses\n[`GCE_VM_IP_PORT` network endpoint groups (NEGs)](/load-balancing/docs/negs/zonal-neg-concepts#gce-vm-ip-port).\nThe endpoints of the NEG are Pod IP addresses.\n\nContainer-native load balancing is always used for internal GKE\nIngress and is optional for external Ingress. The Ingress controller creates the\nload balancer, including the virtual IP address, forwarding rules, health\nchecks, and firewall rules.\n\nTo learn how to use container-native load balancing with Ingress, see\n[Container-native load balancing through Ingress](/kubernetes-engine/docs/how-to/container-native-load-balancing).\n\nFor more flexibility, you can also\n[create standalone NEGs](/kubernetes-engine/docs/how-to/standalone-neg). In this\ncase, you are responsible for creating and managing all aspects of the load\nbalancer.\n\nBenefits of container-native load balancing\n-------------------------------------------\n\nContainer-native load balancing offers the following benefits:\n\nPods are core objects for load balancing\n: [kube-proxy](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-proxy/)\n configures nodes' `iptables` rules to distribute traffic to Pods. Without\n container-native load balancing, load balancer\n traffic travels to the node instance groups and gets routed using `iptables`\n rules to Pods which might or might not be in the same node. With\n container-native load balancing, load balancer traffic is distributed directly\n to the Pods which should receive the traffic, eliminating the extra network\n hop. Container-native load balancing also helps with improved health checking\n since it targets Pods directly. \n\n\n Comparison of default behavior (left) with container-native load balancer behavior.\n\nImproved network performance\n: Because the container-native load balancer talks directly with the Pods, and\n connections have fewer network hops, both latency and throughput are improved.\n\nIncreased visibility\n: With container-native load balancing, you have visibility into the latency\n from the Application Load Balancer to Pods. The latency from the\n Application Load Balancer to each Pod is visible, which were aggregated with\n node IP-base container-native load balancing. This makes troubleshooting your\n Services at the NEG-level easier.\n\nSupport for advanced load balancing features\n: Container-native load balancing in GKE supports several\n features of external Application Load Balancers, such as integration with Google Cloud services\n like\n [Google Cloud Armor](/kubernetes-engine/docs/how-to/cloud-armor-backendconfig),\n [Cloud CDN](/kubernetes-engine/docs/how-to/cdn-backendconfig), and\n [Identity-Aware Proxy](/iap/docs/enabling-kubernetes-howto). It also features load\n balancing algorithms for accurate traffic distribution.\n\nSupport for Cloud Service Mesh\n: The NEG data model is required to use [Cloud Service Mesh](/traffic-director/docs),\n Google Cloud's fully managed traffic control plane for service mesh.\n\nPod readiness\n-------------\n\nFor relevant Pods, the corresponding Ingress controller manages a\n[readiness gate](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#pod-readiness-gate)\nof type `cloud.google.com/load-balancer-neg-ready`. The Ingress controller polls\nthe load balancer's\n[health check status](/load-balancing/docs/health-check-concepts), which\nincludes the health of all endpoints in the NEG. When the load balancer's health\ncheck status indicates that the endpoint corresponding to a particular Pod is\nhealthy, the Ingress controller sets the Pod's readiness gate value to `True`.\nThe kubelet running on each Node then computes the Pod's effective readiness,\nconsidering both the value of this readiness gate and, if defined, the Pod's\n[readiness probe](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#define-readiness-probes).\n\nPod readiness gates are automatically enabled when using container-native\nload balancing through Ingress.\n\nReadiness gates control the rate of a rolling update. When you initiate a\nrolling update, as GKE creates new Pods, an endpoint for each new\nPod is added to a NEG. When the endpoint is healthy from the perspective of the\nload balancer, the Ingress controller sets the readiness gate to `True`. A\nnewly created Pod must at least pass its readiness gate *before*\nGKE removes an old Pod. This ensures that the corresponding\nendpoint for the Pod has already passed the load balancer's health check and\nthat the backend capacity is maintained.\n\nIf a Pod's readiness gate never indicates that the Pod is ready, due to a bad\ncontainer image or a misconfigured load balancer health check, the load balancer\nwon't direct traffic to the new Pod. If such a failure occurs while rolling out\nan updated Deployment, the rollout stalls after attempting to create one new\nPod because that Pod's readiness gate is never True. See the\n[troubleshooting section](/kubernetes-engine/docs/how-to/container-native-load-balancing#stalled_rollout)\nfor information on how to detect and fix this situation.\n\nWithout container-native load balancing and readiness gates, GKE\ncan't detect if a load balancer's endpoints are healthy before marking Pods as\nready. In previous Kubernetes versions, you control the\nrate that Pods are removed and replaced by specifying a delay period\n(`minReadySeconds` in the Deployment specification).\n\nGKE sets the value of\n`cloud.google.com/load-balancer-neg-ready` for a Pod to `True` if any of the\nfollowing conditions are met:\n\n- None of the Pod's IP addresses are endpoints in a [`GCE_VM_IP_PORT` NEG](/load-balancing/docs/negs) managed by the GKE control plane.\n- One or more of the Pod's IP addresses are endpoints in a `GCE_VM_IP_PORT` NEG managed by the GKE control plane. The NEG is attached to a [backend service](/load-balancing/docs/backend-service). The backend service has a successful load balancer health check.\n- One or more of the Pod's IP addresses are endpoints in a `GCE_VM_IP_PORT` NEG managed by the GKE control plane. The NEG is attached to a backend service. The load balancer health check for the backend service [times out](/load-balancing/docs/health-check-concepts#method).\n- One or more of the Pod's IP addresses are endpoints in one or more `GCE_VM_IP_PORT` NEGs. None of the NEGs are attached to a backend service. No load balancer health check data is available.\n\nSession affinity\n----------------\n\nContainer-native load balancing supports\nPod-based\n[session affinity](/load-balancing/docs/backend-service#session_affinity).\n\nRequirements for using container-native load balancing\n------------------------------------------------------\n\nContainer-native load balancers through Ingress on GKE have the\nfollowing requirements:\n\n- The cluster must be VPC-native.\n- The cluster must have the `HttpLoadBalancing` add-on enabled. GKE clusters have the `HttpLoadBalancing` add-on enabled by default; you must not disable it.\n\nLimitations for container-native load balancers\n-----------------------------------------------\n\nContainer-native load balancers through Ingress on GKE have the\nfollowing limitations:\n\n- Don't support external passthrough Network Load Balancers.\n- You must not manually change or update the configuration of the Application Load Balancer that GKE creates. Any changes that you make are overwritten by GKE.\n\nPricing for container-native load balancers\n-------------------------------------------\n\nYou are charged for the Application Load Balancer provisioned by the Ingress that\nyou create in this guide. For load balancer pricing information, refer to\n[Load balancing and forwarding rules](/vpc/network-pricing#lb) on the\nVPC pricing page.\n\nWhat's next\n-----------\n\n- Learn more about [NEGs](/load-balancing/docs/negs).\n- Learn more about [VPC-native clusters](/kubernetes-engine/docs/how-to/alias-ips).\n- Learn more about [external Application Load Balancers](/load-balancing/docs).\n- Watch a [KubeCon talk about Pod readiness gates](https://www.youtube.com/watch?v=Vw9GmSeomFg)."]]
