이 페이지에서는 AWS에서 AWS용 GKE를 사용하여 서비스 부하 분산기에 대한 서브넷을 선택하고 서비스 부하 분산기를 만들 때 자동 검색을 사용하도록 서브넷에 태그를 지정하는 방법을 설명합니다.
서브넷을 지정해야 하는 이유
부하 분산기를 만들려면 이를 배치할 서브넷을 AWS에 지정해야 합니다. 서브넷은 부하 분산기 가용성 영역, IP 주소 및 엔드포인트를 결정합니다.
일반적으로 부하 분산기는 노드 풀을 포함하는 각 가용성 영역에 대해 하나의 서브넷에 할당됩니다. AWS는 네트워크 부하 분산기(NLB)를 만들기 위해 최소 하나의 사용 가능한 서브넷이 필요합니다. 애플리케이션 부하 분산기(ALB)를 위해서는 최소 2개의 서브넷이 필요합니다.
모든 AWS 서브넷은 공개 IP와 VPC 인터넷 게이트웨이 경로가 포함된 공개 서브넷이거나 이러한 특성이 없는 비공개 서브넷일 수 있습니다. 인터넷 연결 부하 분산기는 공개 서브넷에 있어야 합니다. 내부 부하 분산기는 공개 또는 비공개 서브넷에 있을 수 있습니다.
태그가 지정된 서브넷이 없는 경우
AWS용 GKE가 부하 분산기를 만들어야 하고 사용 가능한 태그 지정된 서브넷이 없거나 용량이 없으면 다른 서브넷에 부하 분산기를 만들 수 있습니다. 이를 방지하고 부하 분산기가 배치되는 서브넷을 제어하기 위해서는 모든 서브넷을 태그 지정해야 합니다.
서브넷 자동 검색
AWS용 GKE는 VPC에 있는 모든 서브넷을 나열하고 각 가용성 영역에서 최대 1개의 서브넷을 선택하여 부하 분산기에 사용할 서브넷을 자동으로 검색합니다.
AWS용 GKE가 서브넷을 자동 검색하기 위해서는 서브넷이 다음 요건을 충족해야 합니다.
kubernetes.io/role/elb로 태그가 지정되어야 합니다(인터넷 연결 부하 분산기).
kubernetes.io/role/internal-elb로 태그가 지정되어야 합니다(내부 부하 분산기).
kubernetes.io/cluster/ 프리픽스를 사용하는 태그를 포함하지 않아야 합니다. 또는 CLUSTER_UID가 현재 클러스터의 UID인 kubernetes.io/cluster/CLUSTER_UID 태그를 포함해야 합니다.
또한 인터넷 연결 부하 분산기에 사용할 서브넷은 VPC의 인터넷 게이트웨이에 대한 경로를 포함해야 합니다.
가용성 영역에서 부하 분산기의 요구사항을 충족하는 여러 서브넷이 있으면 AWS용 GKE가 해당 서브넷 ID의 순서로 서브넷 순위를 지정합니다.
의도된 용도로 서브넷에 태그 지정
AWS용 GKE가 부하 분산기의 서브넷을 자동으로 검색할 수 있게 하려면 해당 가용성을 알리도록 서브넷에 두 태그 중 하나를 적용해야 합니다. 각 필터는 다음과 같습니다.
kubernetes.io/role/elb: 인터넷 연결 부하 분산기에 사용할 수 있도록 하려면 서브넷에 이 태그를 적용합니다. VPC 인터넷 게이트웨이에 대한 경로가 포함된 공개 서브넷이어야 합니다. 이 태그를 1로 설정합니다.
이 태그를 적용하려면 다음 명령어를 실행합니다.
서브넷에 kubernetes.io/role 태그를 지정한 후 하나 이상의 kubernetes.io/cluster/CLUSTER_UID 태그를 지정할 수도 있습니다. 여기서 CLUSTER_UID는 AWS용 GKE 클러스터의 UID입니다.
이렇게 하면 이러한 태그 중 하나에 나열되지 않은 클러스터에서 해당 부하 분산기에 사용할 서브넷이 자동 검색되지 않습니다.
부하 분산기 구성에서 가장 일반적인 문제는 태그가 잘못 지정된 서브넷입니다. 이 경우 자동 검색 알고리즘이 잘못된 서브넷을 선택할 수 있습니다. 이 문제를 진단하고 해결하려면 다음 안내를 따르세요.
인터넷 연결 부하 분산기를 만드는 경우 노드 풀이 있는 각 가용성 영역에 최소 하나 이상의 공개 서브넷이 있고 서브넷이 kubernetes.io/role/elb로 태그 지정되었는지 확인합니다.
내부 부하 분산기를 만드는 경우에는 노드 풀이 있는 각 가용성 영역에서 서브넷이 하나 이상 있고 서브넷이 kubernetes.io/role/internal-elb로 태그 지정되었는지 확인합니다.
자동 검색할 서브넷에 kubernetes.io/cluster/CLUSTER_UID 형태의 태그가 있는지 확인합니다. 서브넷에 클러스터 이름을 지정하는 태그가 있으면 클러스터에 지정된 이름으로만 서브넷을 자동 검색할 수 있습니다. 이 문제를 해결하기 위해서는 모든 클러스터 이름 태그를 삭제(모든 클러스터에서 서브넷이 자동 검색되도록 허용)하거나 AWS용 GKE 클러스터 UID와 shared 값을 사용해서 클러스터 이름 태그를 추가합니다.
다음 명령어로 Kubernetes 이벤트 기록을 확인합니다.
kubectlgetevents-A|grepLoadBalancer
예를 들어 이벤트 메시지 could not find any suitable subnets for
creating the ELB는 서브넷을 자동 검색할 수 없음을 나타냅니다. 이 경고가 표시되면 서브넷 및 해당 태그가 올바르고 완전한지 확인합니다.
인터넷 연결 부하 분산기에 대해 자동 검색할 수 있는 서브넷을 나열하려면 다음 명령어를 실행합니다.
[[["이해하기 쉬움","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-31(UTC)"],[],[],null,["# Load balancer subnets\n\nThis page describes how GKE on AWS works with AWS to\nchoose subnets for Service load balancers, and how to tag subnets to be\nauto-discovered during Service load balancer creation.\n\nWhy you need to specify subnets\n-------------------------------\n\nWhen creating load balancers, AWS needs to know which subnets to\nplace them in. The subnet determines load balancer availability zones, IP\naddresses, and endpoints.\n\nNormally, load balancers are allocated to one subnet for each availability zone\ncontaining a node pool. AWS needs a minimum of one available subnet to create a\nNetwork Load Balancer (NLB), and a minimum of two subnets for an Application\nLoad Balancer (ALB).\n\nAll AWS subnets are either public (with public IPs and a route to the VPC's\ninternet gateway) or private (lacking these features). Internet-facing load\nbalancers must be located in public subnets. Internal load balancers can\nreside in either public or private subnets.\n\n### If there are no tagged subnets available\n\nIf GKE on AWS needs to create a load balancer and no tagged subnets\nare available or have capacity, it might create the load balancer in another\nsubnet. To avoid this and control which subnets your load balancers are placed\nin, you should tag all your subnets.\n\nSubnet auto-discovery\n---------------------\n\nGKE on AWS will auto-discover subnets to use for a load balancer by\nlisting all the subnets in the VPC, and selecting up to one subnet from each\navailability zone.\n\nFor GKE on AWS to auto-discover a subnet, the subnet must:\n\n- Be tagged with `kubernetes.io/role/elb` (for an internet-facing load balancer)\n- Be tagged with `kubernetes.io/role/internal-elb` (for an internal load balancer)\n- Either contain no tags with prefix `kubernetes.io/cluster/`, or contain the tag `kubernetes.io/cluster/`\u003cvar translate=\"no\"\u003eCLUSTER_UID\u003c/var\u003e, where \u003cvar translate=\"no\"\u003eCLUSTER_UID\u003c/var\u003e is the current cluster's UID.\n\nIn addition, a subnet intended for use with an internet-facing load balancer\nmust have a route to the VPC's internet gateway.\n\nIf there are several subnets in an availability zone that satisfy the load\nbalancer's requirements, GKE on AWS ranks subnets in\norder by their subnet ID.\n\nTag your subnets for their intended use\n---------------------------------------\n\nFor GKE on AWS to auto-discover a subnet for a load balancer, you\nmust apply one of two tags to the subnet to signal its availability. They are:\n\n- `kubernetes.io/role/elb`: apply this tag to your subnet to mark it as\n available for an internet-facing load balancer. This must be a public\n subnet with a route to your VPC's internet Gateway. Set the tag to `1`.\n To apply this tag, run the following command:\n\n aws ec2 create-tags \\\n --resources \u003cvar translate=\"no\"\u003eSUBNET_ID\u003c/var\u003e \\\n --tags \"Key=kubernetes.io/role/elb,Value=1\"\n\n- `kubernetes.io/role/internal-elb`: apply this tag to your subnet\n to mark it as available for an internal load balancer. Set the tag's\n value to `1`. To apply this tag, run the following command:\n\n aws ec2 create-tags \\\n --resources \u003cvar translate=\"no\"\u003eSUBNET_ID\u003c/var\u003e \\\n --tags Key=kubernetes.io/role/internal-elb,Value=1\n\nReplace the following:\n\n- \u003cvar translate=\"no\"\u003eSUBNET_ID\u003c/var\u003e: the ID of the subnet you're tagging\n\nAfter giving your subnet a `kubernetes.io/role` tag, you can also tag it with\none or more `kubernetes.io/cluster/`\u003cvar translate=\"no\"\u003eCLUSTER_UID\u003c/var\u003e tags,\nwhere \u003cvar translate=\"no\"\u003eCLUSTER_UID\u003c/var\u003e is the UID of a GKE on AWS cluster.\nThis prevents any cluster not listed in one of these tags from auto-discovering\nthe subnet for use by its load balancers.\n\nSee the Amazon\n[aws ec2 create-tags](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-tags.html#create-tags)\ndocumentation for more information about the `aws ec2 create-tags` command.\n\nTroubleshooting\n---------------\n\nThe most common problem with load balancer configuration is incorrectly tagged\nsubnets. This can cause the auto-discovery algorithm to select the wrong\nsubnets. To diagnose and resolve this problem:\n\n- If you're creating an internet-facing load balancer, make sure there is\n at least one public subnet in each of the availability zones that contain a\n node pool, and that the subnets are tagged with `kubernetes.io/role/elb`.\n\n- If you're creating an internal load balancer, make sure there is\n at least one subnet in each of the availability zones that contain a\n node pool, and that the subnets are tagged with\n `kubernetes.io/role/internal-elb`.\n\n- Check whether the subnets you want auto-discovered have any tags of the form\n `kubernetes.io/cluster/`\u003cvar translate=\"no\"\u003eCLUSTER_UID\u003c/var\u003e. If a subnet has any\n such tags naming a cluster, the subnet can only be auto-discovered\n by the named clusters. To resolve this, either delete all cluster name tags\n (to let the subnet be auto-discovered from any cluster) or add a cluster\n name tag with your GKE on AWS cluster UID and a value of `shared`.\n\n- Check the Kubernetes event history with the following command:\n\n kubectl get events -A | grep LoadBalancer\n\n For example, the event message `could not find any suitable subnets for\n creating the ELB` indicates that no subnets could be auto-discovered. If\n you get this warning, ensure that your subnets and their tags are correct and\n complete.\n- To list the subnets that can be auto-discovered for internet-facing load\n balancers, run the following command:\n\n aws ec2 describe-subnets \\\n --filters \"Name=vpc-id,Values=\u003cvar translate=\"no\"\u003eVPC_ID\u003c/var\u003e\" \"Name=tag:kubernetes.io/role/elb,Values=*\"\n\n Replace \u003cvar translate=\"no\"\u003eVPC_ID\u003c/var\u003e with the ID of your VPC.\n- To list the subnets that can be auto-discovered for internal load balancers,\n run:\n\n aws ec2 describe-subnets \\\n --filters \"Name=vpc-id,Values=\u003cvar translate=\"no\"\u003eVPC_ID\u003c/var\u003e\" \"Name=tag:kubernetes.io/role/internal-elb,Values=*\"\n\nNext steps\n----------\n\n- Learn more about [network load balancing](/kubernetes-engine/multi-cloud/docs/aws/how-to/network-load-balancing)\n\n- [Set up an HTTP Load Balancer](/kubernetes-engine/multi-cloud/docs/aws/how-to/http-load-balancing)."]]
