AKS(Azure Kubernetes Service)에서 퍼블릭 표준 부하 분산 장치 사용

아티클
04/11/2024

Azure Load Balancer는 인바운드 및 아웃바운드 시나리오를 모두 지원하는 OSI(개방형 시스템 간 상호 접속) 모델의 계층 4에서 작동합니다. 부하 분산 장치의 프런트 엔드에 도착하는 인바운드 흐름을 백 엔드 풀 인스턴스에 배포합니다.

AKS와 통합된 퍼블릭 부하 분산 장치는 두 가지 용도로 사용됩니다.

개인 IP 주소를 아웃바운드 풀의 공용 IP 주소 부분으로 변환하여 AKS 가상 네트워크 내부의 클러스터 노드에 대한 아웃바운드 연결을 제공합니다.
LoadBalancer 형식의 Kubernetes Service를 통해 애플리케이션에 대한 액세스를 제공하여 애플리케이션을 쉽게 크기 조정하고 고가용성 서비스를 만들 수 있도록 합니다.

내부(또는 개인) 부하 분산 장치는 개인 IP만 프런트 엔드로 허용되는 경우에 사용됩니다. 내부 부하 분산 장치는 트래픽 부하를 가상 네트워크 내에 분산하는 데 사용됩니다. 하이브리드 시나리오의 온-프레미스 네트워크에서 부하 분산 장치 프런트 엔드에 액세스할 수도 있습니다.

이 문서에서는 AKS의 공용 부하 분산 장치와의 통합에 대해 설명합니다. 내부 부하 분산 장치 통합에 대해서는 AKS에서 내부 부하 분산 장치 사용을 참조하세요.

시작하기 전에

Azure Load Balancer는 기본 및 표준의 두 가지 SKU에서 사용할 수 있습니다. 표준 SKU는 AKS 클러스터를 만들 때 기본적으로 사용됩니다. 표준 SKU는 더 큰 백 엔드 풀, 여러 노드 풀, 가용성 영역과 같이 추가된 기능에 대한 액세스 권한을 제공하며, 기본적으로 안전합니다. 이는 AKS에 권장되는 부하 분산 장치 SKU입니다. 기본 및 표준 SKU에 대한 자세한 정보는 Azure Load Balancer SKU 비교를 참조하세요.
LoadBalancer 형식의 Kubernetes 서비스를 지원하는 주석의 전체 목록은 LoadBalancer 주석을 참조하세요.
이 문서에서는 ‘표준’ SKU Azure Load Balancer를 사용하는 AKS 클러스터가 있다고 가정합니다. AKS 클러스터가 필요한 경우 Azure CLI, Azure PowerShell 또는 Azure Portal을 사용하여 만들 수 있습니다.
AKS는 에이전트 노드의 수명 주기와 작업을 관리합니다. 에이전트 노드와 연결된 IaaS 리소스 수정은 지원되지 않습니다. 지원되지 않는 작업의 예는 부하 분산 장치 리소스 그룹을 수동으로 변경하는 것입니다.

Important

자체 게이트웨이, 방화벽 또는 프록시를 사용하여 아웃바운드 연결을 제공하려는 경우 아웃바운드 형식을 UDR(UserDefinedRouting)로 사용하여 부하 분산 장치 아웃바운드 풀 및 해당 프런트 엔드 IP 만들기를 건너뛸 수 있습니다. . 아웃바운드 유형은 클러스터에 대한 송신 방법을 정의하며 기본값은 LoadBalancer 형식입니다.

공용 표준 부하 분산 장치 사용

아웃바운드 형식이 LoadBalancer(기본값)인 AKS 클러스터를 만들고 나면 클러스터가 부하 분산 장치를 사용하여 서비스를 노출할 준비가 됩니다.

LoadBalancer 형식의 공용 서비스를 만드는 public-svc.yaml이라는 서비스 매니페스트를 만듭니다.

apiVersion: v1
kind: Service
metadata:
  name: public-svc
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: public-app

부하 분산 장치 IP 주소 지정

부하 분산 장치에서 특정 IP 주소를 사용하려는 경우 두 가지 방법이 있습니다.

Important

부하 분산 장치 YAML 매니페스트에 LoadBalancerIP 속성을 추가하는 기능은 업스트림 Kubernetes에 따라 더 이상 사용되지 않습니다. 현재 사용량은 동일하게 유지되고 기존 서비스는 수정 없이 작동할 것으로 예상되지만 대신 서비스 주석을 설정하는 것이 좋습니다.

서비스 주석 설정: IPv4 주소에는 service.beta.kubernetes.io/azure-load-balancer-ipv4를, IPv6 주소에는 service.beta.kubernetes.io/azure-load-balancer-ipv6을 사용합니다.
부하 분산 장치 YAML 매니페스트에 LoadBalancerIP 속성 추가: 부하 분산 장치 YAML 매니페스트에 Service.Spec.LoadBalancerIP 속성을 추가합니다. 이 필드는 업스트림 Kubernetes에 따라 더 이상 사용되지 않으며 이중 스택을 지원할 수 없습니다. 현재 사용량은 동일하게 유지되며 기존 서비스는 수정 없이 작동할 것으로 예상됩니다.

서비스 매니페스트 배포

kubectl apply를 사용하여 공용 서비스 매니페스트를 배포하고 YAML 매니페스트의 이름을 지정합니다.

kubectl apply -f public-svc.yaml

Azure Load Balancer는 새 서비스를 전면에 배치하는 새 공용 IP로 구성됩니다. Azure Load Balancer에는 여러 개의 프런트 엔드 IP가 있을 수 있으므로 배포하는 각각의 새 서비스는 고유하게 액세스할 수 있는 새로운 전용 프런트 엔드 IP를 갖게 됩니다.

다음 명령을 사용하여 서비스가 만들어지고 부하 분산 장치가 구성되었는지 확인합니다.

kubectl get service public-svc

NAMESPACE     NAME          TYPE           CLUSTER-IP     EXTERNAL-IP     PORT(S)         AGE
default       public-svc    LoadBalancer   10.0.39.110    52.156.88.187   80:32068/TCP    52s

서비스 세부 정보에서 볼 수 있듯 부하 분산 장치의 이 서비스에 대해 생성된 공용 IP 주소는 EXTERNAL-IP 열에 표시됩니다. IP 주소가 <보류 중>에서 실제 공용 IP 주소로 변경되는 데 몇 분 정도 걸릴 수 있습니다.

서비스에 대한 자세한 정보를 얻으려면 다음 명령을 사용합니다.

kubectl describe service public-svc

다음 예 출력은 kubectl describe service를 실행한 후 출력의 압축된 버전입니다. LoadBalancer 수신은 서비스에서 노출된 외부 IP 주소를 보여 줍니다. IP는 내부 주소를 보여 줍니다.

Name:                        public-svc
Namespace:                   default
Labels:                      <none>
Annotations:                 <none>
Selector:                    app=public-app
...
IP:                          10.0.39.110
...
LoadBalancer Ingress:        52.156.88.187
...
TargetPort:                  80/TCP
NodePort:                    32068/TCP
...
Session Affinity:            None
External Traffic Policy:     Cluster
...

공용 표준 부하 분산 장치 구성

클러스터를 만들 때 또는 클러스터를 업데이트하여 표준 공용 부하 분산 장치에 대한 다양한 설정을 사용자 지정할 수 있습니다. 이러한 사용자 지정 옵션을 사용하면 워크로드 요구 사항을 충족하는 부하 분산 장치를 만들 수 있습니다. 표준 부하 분산 장치를 사용하면 다음을 수행할 수 있습니다.

관리되는 아웃바운드 IP 수 설정 또는 크기를 조정합니다.
사용자 고유 사용자 지정 아웃바운드 IP 또는 아웃바운드 IP 접두사를 가져옵니다.
클러스터의 각 노드에 할당된 아웃바운드 포트 수 사용자 지정
유휴 연결에 대한 시간 제한 설정을 구성합니다.

Important

하나의 아웃바운드 IP 옵션(관리되는 IP, 사용자 고유 IP 또는 IP 접두사)만 지정된 시간에 사용할 수 있습니다.

인바운드 풀 형식 변경

AKS 노드는 해당 IP 구성(Azure Virtual Machine Scale Sets 기반 멤버 자격) 또는 IP 주소만으로 부하 분산 장치 백 엔드 풀에서 참조할 수 있습니다. IP 주소 기반 백 엔드 풀 멤버 자격을 활용하면 특히 노드 수가 많을 때 서비스를 업데이트하고 부하 분산 장치를 프로비전할 때 더 높은 효율성을 제공합니다. IP 기반 백 엔드 풀로 새 클러스터를 프로비전하고 기존 클러스터를 변환하는 것이 이제 지원됩니다. NAT Gateway 또는 사용자 정의 라우팅 송신 형식과 결합하면 새 노드 및 서비스의 프로비전 성능이 향상됩니다.

두 가지 다른 풀 멤버 자격 형식을 사용할 수 있습니다.

nodeIPConfiguration - 레거시 Virtual Machine Scale Sets IP 구성 기반 풀 멤버 자격 유형
nodeIP - IP 기반 멤버 자격 형식

요구 사항

AKS 클러스터는 버전 1.23 이상이어야 합니다.
AKS 클러스터는 표준 Load Balancer 및 가상 머신 확장 집합을 사용해야 합니다.

제한 사항

IP 기반 백 엔드 풀을 사용하는 클러스터는 2,500개 노드로 제한됩니다.

IP 기반 인바운드 풀 멤버 자격으로 새 AKS 클러스터 만들기

az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-backend-pool-type=nodeIP

IP 기반 인바운드 풀 멤버 자격을 사용하도록 기존 AKS 클러스터 업데이트

Warning

이 작업으로 인해 클러스터에서 들어오는 서비스 트래픽이 일시적으로 중단됩니다. 노드가 많은 대형 클러스터일수록 영향을 받는 시간이 증가합니다.

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-backend-pool-type=nodeIP

관리되는 아웃바운드 공용 IP 수 크기 조정

Azure Load Balancer는 가상 네트워크에서 아웃바운드 및 인바운드 연결을 제공합니다. 아웃바운드 규칙을 사용하면 퍼블릭 표준 부하 분산 장치에 대한 네트워크 주소 변환을 간단하게 구성할 수 있습니다.

아웃바운드 규칙은 부하 분산 및 인바운드 NAT 규칙과 동일한 구문을 따릅니다.

프런트 엔드 IP + 매개 변수 + 백 엔드 풀

아웃바운드 규칙은 백 엔드 풀에서 식별된 모든 가상 머신에 대한 아웃바운드 NAT를 프런트 엔드로 변환하도록 구성합니다. 매개 변수는 아웃바운드 NAT 알고리즘에 대한 더 많은 제어를 제공합니다.

단일 공용 IP 주소로 아웃바운드 규칙을 사용할 수 있지만 아웃바운드 규칙은 구성 부담을 덜어주기 때문에 아웃바운드 NAT의 크기를 조정하는 데 좋습니다. 여러 IP 주소를 사용하여 대규모 시나리오 및 아웃바운드 규칙을 계획하여 SNAT 소진 경향이 있는 패턴을 완화할 수 있습니다. 프런트 엔드에서 제공하는 각 IP 주소는 부하 분산 장치가 SNAT 포트로 사용할 64k 임시 포트를 제공합니다.

기본적으로 생성된 관리 아웃바운드 공용 IP를 사용하는 표준 SKU 부하 분산 장치를 사용하는 경우 --load-balancer-managed-outbound-ip-count 매개 변수를 사용하여 관리 아웃바운드 공용 IP 개수를 스케일링할 수 있습니다.

다음 명령을 사용하여 기존 클러스터를 업데이트합니다. 관리되는 아웃바운드 공용 IP가 여러 개 있도록 이 매개 변수를 설정할 수도 있습니다.

Important

Azure Portal을 사용하여 아웃바운드 규칙을 변경하지 않는 것이 좋습니다. 이러한 변경을 수행할 때 Load Balancer 리소스에서 직접이 아니라 AKS 클러스터를 거쳐야 합니다.

Load Balancer 리소스에서 직접 변경된 아웃바운드 규칙은 중지, 시작, 업그레이드 또는 크기 조정과 같이 클러스터가 조정될 때마다 제거됩니다.

예에 표시된 대로 Azure CLI를 사용합니다. az aks CLI 명령을 사용하여 수행한 아웃바운드 규칙 변경 내용은 클러스터 가동 중지 시간 동안 영구적입니다.

자세한 내용은 Azure Load Balancer 아웃바운드 규칙을 참조하세요.

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-managed-outbound-ip-count 2

위의 예제에서는 관리 아웃바운드 공용 IP 개수를 myResourceGroup의 myAKSCluster 클러스터에 대해 2로 설정합니다.

클러스터를 만들 때 --load-balancer-managed-outbound-ip-count 매개 변수를 추가하고 원하는 값으로 설정하여 관리 아웃바운드 공용 IP의 초기 수를 설정할 수도 있습니다. 관리되는 아웃바운드 공용 IP의 기본 개수는 1입니다.

사용자 고유 아웃바운드 공용 IP 또는 접두사 제공

표준 SKU 부하 분산 장치를 사용하는 경우 AKS 클러스터에서 기본적으로 공용 IP를 AKS 관리 인프라 리소스 그룹에 자동으로 만들고 이를 부하 분산 장치 아웃바운드 풀에 할당합니다.

AKS에서 만든 공용 IP는 AKS 관리되는 리소스입니다. 즉, 해당 공용 IP의 수명 주기는 AKS에서 관리하며 사용자가 공용 IP 리소스를 직접 작업할 필요가 없습니다. 또는 클러스터 생성 시점에 고유한 사용자 지정 공용 IP 또는 공용 IP 접두사를 할당할 수 있습니다. 기존 클러스터의 부하 분산 장치 속성에서 사용자 지정 IP를 업데이트할 수도 있습니다.

고유의 공용 IP 또는 접두사를 사용하기 위한 요구 사항은 다음과 같습니다.

사용자는 사용자 지정 공용 IP 주소를 만들고 소유해야 합니다. AKS에서 생성한 관리 공용 IP는 "사용자 고유 사용자 지정 IP"로 재사용할 수 없습니다. 관리 충돌 문제를 일으킬 수 있기 때문입니다.
필수 공용 IP 권한 목록에 따라 아웃바운드 IP에 액세스할 수 있는 권한이 AKS 클러스터 ID(서비스 주체 또는 관리 ID)에 있는지 확인해야 합니다.
아웃바운드 IP 또는 아웃바운드 IP 접두사를 구성하는 데 필요한 필수 조건 및 제약 조건을 충족하는지 확인합니다.

사용자 고유 아웃바운드 공용 IP로 클러스터를 업데이트합니다.

az network public-ip show 명령을 사용하여 공용 IP의 ID를 나열합니다.

az network public-ip show --resource-group myResourceGroup --name myPublicIP --query id -o tsv

위의 명령은 myResourceGroup 리소스 그룹의 myPublicIP 공용 IP에 대한 ID를 표시합니다.

load-balancer-outbound-ips 매개 변수로 az aks update 명령을 사용하여 공용 IP로 클러스터를 업데이트합니다.

다음 예제에서는 이전 명령의 ID와 함께 load-balancer-outbound-ips 매개 변수를 사용합니다.

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-outbound-ips <publicIpId1>,<publicIpId2>

사용자 고유 아웃바운드 공용 IP 접두사로 클러스터 업데이트

‘표준’ SKU 부하 분산 장치를 사용하여 송신하는 데 공용 IP 접두사를 사용할 수도 있습니다. 다음 예제에서는 az network public-ip prefix show 명령을 사용하여 공용 IP 접두사의 ID를 나열합니다.

az network public-ip prefix show --resource-group myResourceGroup --name myPublicIPPrefix --query id -o tsv

위의 명령은 myResourceGroup 리소스 그룹의 myPublicIPPrefix 공용 IP 접두사에 대한 ID를 표시합니다.

다음 예제에서는 이전 명령의 ID를 사용하여 load-balancer-outbound-ip-prefixes 매개 변수를 사용합니다.

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-outbound-ip-prefixes <publicIpPrefixId1>,<publicIpPrefixId2>

사용자 고유 공용 IP 또는 접두사로 클러스터 만들기

클러스터를 만들 때 허용 목록에 송신 엔드포인트를 추가하는 것과 같은 시나리오를 지원하기 위해 송신용 IP 주소 또는 IP 접두사를 가져올 수 있습니다. 클러스터를 만들 때 자체 공용 IP 및 IP 접두사를 정의하려면 이전 명령에 표시된 것과 동일한 매개 변수를 추가합니다.

load-balancer-outbound-ips 매개 변수와 함께 az aks create 명령을 사용하여 고유의 공용 IP로 새 클러스터를 만듭니다.

az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-outbound-ips <publicIpId1>,<publicIpId2>

load-balancer-outbound-ip-prefixes 매개 변수와 함께 az aks create 명령을 사용하여 고유의 공용 IP 접두사가 있는 새 클러스터를 만듭니다.

az aks create \
    --resource-group myResourceGroup \
    --load-balancer-outbound-ip-prefixes <publicIpPrefixId1>,<publicIpPrefixId2>

할당된 아웃바운드 포트 구성

Important

데이터베이스에 연결하는 프런트 엔드 애플리케이션의 많은 인스턴스와 같이 작은 대상 집합에 대한 많은 수의 연결을 설정할 수 있는 클러스터에 애플리케이션이 있는 경우 SNAT 포트 소모가 발생할 가능성이 높은 시나리오가 있을 수 있습니다. SNAT 포트 소모는 애플리케이션이 다른 애플리케이션 또는 호스트에 대한 연결을 설정하는 데 사용할 아웃바운드 포트가 부족할 때 발생합니다. SNAT 포트 소진이 발생할 수 있는 시나리오가 있는 경우 부하 분산 장치에서 할당된 아웃바운드 포트 및 아웃바운드 프런트 엔드 IP를 늘리는 것이 좋습니다.

SNAT에 대한 자세한 내용은 아웃바운드 연결에 SNAT 사용을 참조하세요.

기본값으로 AKS는 부하 분산 장치의 AllocatedOutboundPorts를 클러스터를 만들 때 백 엔드 풀 크기에 따라 자동 아웃바운드 포트 할당 을 사용하도록 0(으)로 설정합니다. 예를 들어 클러스터에 노드가 50개 이하인 경우 각 노드에 1024개의 포트가 할당됩니다. 클러스터의 노드 수가 증가하면 노드당 사용할 수 있는 포트 수가 줄어듭니다.

Important

노드 크기가 50 이하(1~50)일 때 프런트 엔드 IP가 추가되는지 여부에 관계없이 포트의 하드 제한은 1024개입니다.

AKS 클러스터 부하 분산 장치에 대한 AllocatedOutboundPorts 값을 표시하려면 az network lb outbound-rule list을(를) 사용합니다.

NODE_RG=$(az aks show --resource-group myResourceGroup --name myAKSCluster --query nodeResourceGroup -o tsv)
az network lb outbound-rule list --resource-group $NODE_RG --lb-name kubernetes -o table

다음 예제 출력에서는 백 엔드 풀 크기를 기반으로 하는 자동 아웃바운드 포트 할당이 클러스터에 사용하도록 설정되어 있음을 보여 줍니다.

AllocatedOutboundPorts    EnableTcpReset    IdleTimeoutInMinutes    Name             Protocol    ProvisioningState    ResourceGroup
------------------------  ----------------  ----------------------  ---------------  ----------  -------------------  -------------
0                         True              30                      aksOutboundRule  All         Succeeded            MC_myResourceGroup_myAKSCluster_eastus

클러스터를 만들거나 업데이트할 때 AllocatedOutboundPorts 및 아웃바운드 IP 주소에 대한 특정 값을 구성하려면 load-balancer-outbound-ports 및 load-balancer-managed-outbound-ip-count, load-balancer-outbound-ips, load-balancer-outbound-ip-prefixes 중 하나를 사용합니다. 아웃바운드 포트 및 아웃바운드 IP 주소에 대해 특정 값을 설정하거나 기존 값을 늘리려면 먼저 적절한 아웃바운드 포트 및 IP 주소 수를 계산해야 합니다. 가장 가까운 정수로 반올림된 이 계산에 수식 64,000 ports per IP / <outbound ports per node> * <number of outbound IPs> = <maximum number of nodes in the cluster>을(를) 사용합니다.

아웃바운드 포트 및 IP 수를 계산하고 값을 설정할 때 다음 정보를 염두에 두세요.

노드당 아웃바운드 포트 수는 설정한 값에 따라 고정됩니다.
아웃바운드 포트의 값은 8의 배수여야 합니다.
더 많은 IP를 추가해도 노드에 더 많은 포트가 추가되지는 않지만 클러스터의 더 많은 노드에 대한 용량을 제공합니다.
maxSurge 값을 통해 지정된 노드 수를 포함하여 업그레이드의 일부로 추가될 수 있는 노드를 고려해야 합니다.

다음 예제에서는 사용자가 설정한 값이 아웃바운드 포트 및 IP 주소의 수에 어떤 영향을 미치는지 보여줍니다.

기본값을 사용하고 클러스터에 48개의 노드가 있는 경우 각 노드의 사용 가능한 포트 수는 1024개입니다.
기본값을 사용하고 클러스터의 노드 수를 48개에서 52개로 스케일링하면 각 노드의 사용 가능한 포트 수가 1024개에서 512개로 업데이트됩니다.
아웃바운드 포트 수가 1,000으로 설정되고 아웃바운드 IP 수가 2개로 설정된 경우 클러스터는 최대 128개의 노드(64,000 ports per IP / 1,000 ports per node * 2 IPs = 128 nodes)를 지원할 수 있습니다.
아웃바운드 포트 수가 1,000으로 설정되고 아웃바운드 IP 수가 7개로 설정된 경우 클러스터는 최대 448개의 노드(64,000 ports per IP / 1,000 ports per node * 7 IPs = 448 nodes)를 지원할 수 있습니다.
아웃바운드 포트 수가 4,000으로 설정되고 아웃바운드 IP 수가 2로 설정된 경우 클러스터는 최대 32개의 노드(64,000 ports per IP / 4,000 ports per node * 2 IPs = 32 nodes)를 지원할 수 있습니다.
아웃바운드 포트 수가 4,000으로 설정되고 아웃바운드 IP 수가 7개로 설정된 경우 클러스터는 최대 112개의 노드(64,000 ports per IP / 4,000 ports per node * 7 IPs = 112 nodes)를 지원할 수 있습니다.

Important

아웃바운드 포트 및 IP 수를 계산한 후 업그레이드 중에 노드 서지를 처리할 수 있는 추가 아웃바운드 포트 용량이 있는지 확인합니다. 업그레이드 및 기타 작업에 필요한 추가 노드에 충분한 포트를 할당하는 것이 중요합니다. AKS는 업그레이드 작업을 위해 기본값으로 하나의 버퍼 노드로 설정됩니다. maxSurge 값을 사용하는 경우 노드당 아웃바운드 포트를 maxSurge 값으로 곱하여 필요한 포트 수를 결정합니다. 예를 들어 다음과 같이 최대 100개의 노드와 최대 2개의 서지가 있는 클러스터에서 7개의 IP 주소가 있는 노드당 4,000개의 포트가 필요하다고 계산한 경우가 있습니다.

2개의 서지 노드 * 노드당 4,000개의 포트 = 업그레이드 중에 노드 서지에 필요한 8,000개의 포트.
노드 100개 * 노드당 4,000개의 포트 = 클러스터에 필요한 포트 400,000개.
7개 IP * IP당 64,000 포트 = 448,000개의 포트를 클러스터에 사용할 수 있습니다.

위의 예제에서는 클러스터의 용량이 48,000개 포트를 초과하어 업그레이드 중에 노드 서지에 필요한 8,000개의 포트를 처리하기에 충분하다는 것을 보여 줍니다.

값이 계산되고 확인되면 클러스터를 만들거나 업데이트할 때 load-balancer-outbound-ports 및 load-balancer-managed-outbound-ip-count, load-balancer-outbound-ips, load-balancer-outbound-ip-prefixes 중 하나를 사용하여 해당 값을 적용할 수 있습니다.

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-managed-outbound-ip-count 7 \
    --load-balancer-outbound-ports 4000

부하 분산 장치 유휴 시간 제한 구성

SNAT 포트 리소스가 고갈되면 기존 흐름에서 SNAT 포트를 릴리스할 때까지 아웃바운드 흐름이 실패합니다. 부하 분산 장치는 흐름이 닫히면 SNAT 포트를 회수하고, AKS 구성 부하 분산 장치는 유휴 흐름에서 SNAT 포트를 회수하기 위해 30분의 유휴 시간 제한을 사용합니다.

또한 전송(예: TCP keepalives 또는 application-layer keepalives)을 사용하여 유휴 흐름을 새로 고치고 필요한 경우 이 유휴 시간 제한을 다시 설정할 수 있습니다. 이 시간 제한은 아래 예제에 따라 구성할 수 있습니다.

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-idle-timeout 4

kubectl proxy 또는 kubectl port-forward를 활용하는 것처럼 오랜 시간 동안 유휴 상태가 될 수 있는 수명이 짧은 연결이 많고 수명이 긴 연결이 없다고 예상되는 경우 4분과 같은 짧은 시간 제한 값을 사용하는 것이 좋습니다. TCP keepalive를 사용하는 경우 연결의 한쪽에서 사용하도록 설정하는 것으로 충분합니다. 예를 들어 흐름의 유휴 타이머를 다시 설정하기 위해서만 서버 쪽에서 사용하도록 설정하는 것으로 충분합니다. 양쪽에서 TCP keepalive를 시작할 필요가 없습니다. 데이터베이스 클라이언트 서버 구성을 포함하여 애플리케이션 계층에 대한 유사한 개념이 있습니다. 서버 쪽에서 사용 가능한 애플리케이션 관련 Keepalive 옵션을 확인합니다.

Important

AKS는 기본적으로 유휴 상태에서 TCP 다시 설정을 사용하도록 설정합니다. 시나리오에서 더 예측 가능한 애플리케이션 동작을 위해 이 구성을 유지하고 활용하는 것이 좋습니다.

TCP RST는 ESTABLISHED 상태에서 TCP 연결 중에만 전송됩니다. 자세한 내용은 여기서 확인할 수 있습니다.

IdleTimeoutInMinutes를 기본값 30분이 아닌 다른 값으로 설정할 때는 워크로드에 아웃바운드 연결이 필요한 기간을 고려합니다. 또한 AKS 외부에서 사용되는 표준 SKU 부하 분산 장치의 기본 시간 제한 값은 4분입니다. 특정 AKS 워크로드를 더 정확하게 반영하는 IdleTimeoutInMinutes 값을 지정하면 더 이상 사용되지 않는 연결로 인한 SNAT 고갈을 줄이는 데 도움이 될 수 있습니다.

Warning

AllocatedOutboundPorts 및 IdleTimeoutInMinutes 값을 변경하면 부하 분산 장치에 대한 아웃바운드 규칙의 동작이 크게 변경될 수 있으므로 신중하게 수행해야 합니다. 이러한 값을 업데이트하기 전에 SNAT 문제 해결 섹션을 확인하고 Load Balancer 아웃바운드 규칙 및 Azure에서 아웃바운드 연결을 검토하여 변경의 영향을 완전히 이해하세요.

인바운드 트래픽을 특정 IP 범위로 제한

다음 매니페스트는 loadBalancerSourceRanges를 사용하여 인바운드 외부 트래픽에 대한 새 IP 범위를 지정합니다.

apiVersion: v1
kind: Service
metadata:
  name: azure-vote-front
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: azure-vote-front
  loadBalancerSourceRanges:
  - MY_EXTERNAL_IP_RANGE

이 예에서는 MY_EXTERNAL_IP_RANGE 범위에서 인바운드 외부 트래픽만 허용하도록 규칙을 업데이트합니다. MY_EXTERNAL_IP_RANGE을(를) 내부 서브넷 IP 주소로 바꾸면 트래픽은 클러스터 내부 IP로만 제한됩니다. 트래픽이 클러스터 내부 IP로 제한된 경우 Kubernetes 클러스터 외부의 클라이언트는 부하 분산 장치에 액세스할 수 없습니다.

참고 항목

인바운드, 외부 트래픽은 부하 분산 장치에서 AKS 클러스터의 가상 네트워크로 흐릅니다. 가상 네트워크에는 부하 분산 장치의 모든 인바운드 트래픽을 허용하는 NSG(네트워크 보안 그룹)가 있습니다. 이 NSG는 LoadBalancer 형식의 서비스 태그를 사용하여 부하 분산 장치의 트래픽을 허용합니다.
v1.25 이상 버전 클러스터에 대한 서비스의 LoadBalancer IP에 액세스해야 하는 Pod가 있는 경우 loadBalancerSourceRanges에 Pod CIDR을 추가해야 합니다.

인바운드 연결에서 클라이언트의 IP 유지 관리

기본적으로 Kubernetes 및 AKS의 LoadBalancer 서비스 형식은 Pod에 연결된 클라이언트의 IP 주소를 유지하지 않습니다. Pod에 전달되는 패킷의 원본 IP는 노드의 개인 IP가 됩니다. 클라이언트의 IP 주소를 유지하려면 서비스 정의에서 service.spec.externalTrafficPolicy를 local로 설정해야 합니다. 다음 매니페스트는 예를 보여 줍니다.

apiVersion: v1
kind: Service
metadata:
  name: azure-vote-front
spec:
  type: LoadBalancer
  externalTrafficPolicy: Local
  ports:
  - port: 80
  selector:
    app: azure-vote-front

Kubernetes 주석을 통한 사용자 지정

다음 주석은 LoadBalancer 형식의 Kubernetes 서비스에 지원되며 인바운드 흐름에만 적용됩니다.

주석	값	설명
`service.beta.kubernetes.io/azure-load-balancer-internal`	`true` 또는 `false`	부하 분산 장치가 내부여야 하는지 여부를 지정합니다. 설정하지 않으면 기본적으로 공용으로 설정됩니다.
`service.beta.kubernetes.io/azure-load-balancer-internal-subnet`	서브넷 이름	내부 부하 분산 장치가 바인딩되어야 하는 서브넷을 지정합니다. 설정하지 않으면 기본적으로 클라우드 구성 파일에 구성된 서브넷이 사용됩니다.
`service.beta.kubernetes.io/azure-dns-label-name`	공용 IP의 DNS 레이블 이름	공용 서비스에 대한 DNS 레이블 이름을 지정합니다. 빈 문자열로 설정하면 공용 IP의 DNS 항목이 사용되지 않습니다.
`service.beta.kubernetes.io/azure-shared-securityrule`	`true` 또는 `false`	네트워크 보안 그룹의 Azure 보강된 보안 규칙을 활용하여 잠재적 공유 Azure 보안 규칙을 통해 서비스를 노출하도록 지정하여 서비스 노출을 높입니다.
`service.beta.kubernetes.io/azure-load-balancer-resource-group`	리소스 그룹의 이름	클러스터 인프라와 동일한 리소스 그룹에 있지 않은 부하 분산 장치 공용 IP의 리소스 그룹(노드 리소스 그룹)을 지정합니다.
`service.beta.kubernetes.io/azure-allowed-service-tags`	허용되는 서비스 태그 목록	허용되는 서비스 태그를 쉼표로 구분한 목록을 지정합니다.
`service.beta.kubernetes.io/azure-load-balancer-tcp-idle-timeout`	TCP 유휴 시간 제한(분)	부하 분산 장치에서 TCP 연결 유휴 시간 제한이 발생하는 시간을 분 단위로 지정합니다. 기본값 및 최솟값은 4입니다. 최댓값은 30입니다. 값은 정수여야 합니다.
`service.beta.kubernetes.io/azure-load-balancer-disable-tcp-reset`	`true` 또는 `false`	부하 분산 장치에서 유휴 상태의 TCP 재설정 시간 제한을 사용하지 않도록 설정할지 여부를 지정합니다.
`service.beta.kubernetes.io/azure-load-balancer-ipv4`	IPV4 주소	부하 분산 장치에 할당할 IPv4 주소를 지정합니다.
`service.beta.kubernetes.io/azure-load-balancer-ipv6`	IPv6 주소	부하 분산 장치에 할당할 IPv6 주소를 지정합니다.

부하 분산 장치 상태 프로브 사용자 지정

주석	값	설명
`service.beta.kubernetes.io/azure-load-balancer-health-probe-interval`	상태 프로브 간격
`service.beta.kubernetes.io/azure-load-balancer-health-probe-num-of-probe`	상태 프로브의 최소 비정상 응답 수
`service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path`	상태 프로브의 요청 경로
`service.beta.kubernetes.io/port_{port}_no_lb_rule`	true/false	{port}는 서비스 포트 번호입니다. true로 설정하면 이 포트에 대한 lb 규칙 또는 상태 프로브 규칙이 생성되지 않습니다. 상태 검사 서비스는 공용 인터넷(예: istio/envoy 상태 확인 서비스)에 노출되면 안 됩니다.
`service.beta.kubernetes.io/port_{port}_no_probe_rule`	true/false	{port}는 서비스 포트 번호입니다. true로 설정하면 이 포트에 대한 상태 프로브 규칙이 생성되지 않습니다.
`service.beta.kubernetes.io/port_{port}_health-probe_protocol`	상태 프로브 프로토콜	{port}는 서비스 포트 번호입니다. 서비스 포트 {port}의 상태 프로브에 대한 명시적 프로토콜이며, 설정하면 port.appProtocol을 재정의합니다.
`service.beta.kubernetes.io/port_{port}_health-probe_port`	서비스 매니페스트의 포트 번호 또는 포트 이름	{port}는 서비스 포트 번호입니다. 서비스 포트 {port}의 상태 프로브에 대한 명시적 프로토콜이며, 기본값을 재정의합니다.
`service.beta.kubernetes.io/port_{port}_health-probe_interval`	상태 프로브 간격	{port}는 서비스 포트 번호입니다.
`service.beta.kubernetes.io/port_{port}_health-probe_num-of-probe`	상태 프로브의 최소 비정상 응답 수	{port}는 서비스 포트 번호입니다.
`service.beta.kubernetes.io/port_{port}_health-probe_request-path`	상태 프로브의 요청 경로	{port}는 서비스 포트 번호입니다.

여기에 설명된 것처럼 Tcp, Http 및 Https는 부하 분산 장치 서비스에서 지원하는 세 가지 프로토콜입니다.

현재 상태 프로브의 기본 프로토콜은 서로 다른 전송 프로토콜, 앱 프로토콜, 주석 및 외부 트래픽 정책을 사용하는 서비스마다 다릅니다.

로컬 서비스의 경우 HTTP 및 /healthz가 사용됩니다. 상태 프로브는 실제 백 엔드 서비스가 아닌 NodeHealthPort를 쿼리합니다.
클러스터 TCP 서비스의 경우 TCP가 사용됩니다.
클러스터 UDP 서비스의 경우 상태 프로브가 없습니다.

참고 항목

PLS 통합 및 PLS 프록시 프로토콜을 사용하는 로컬 서비스의 경우 기본 HTTP+/healthz 상태 프로브가 작동하지 않습니다. 따라서 클러스터 서비스와 동일한 방식으로 이 시나리오를 지원하도록 상태 프로브를 사용자 지정할 수 있습니다.

v1.20부터 상태 프로브 동작을 확인하기 위해 service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path 서비스 주석이 도입되었습니다.

클러스터 버전 <=1.23인 경우 service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path도 설정된 경우에만 spec.ports.appProtocol이 프로브 프로토콜로 사용됩니다.
클러스터 버전 >1.24인 경우 spec.ports.appProtocol은 프로브 프로토콜로 사용되고 /는 기본 프로브 요청 경로로 사용됩니다(service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path는 다른 요청 경로로 변경하는 데 사용할 수 있음).

TCP를 사용하거나 spec.ports.appProtocol이 비어 있으면 요청 경로가 무시됩니다. 즉,

loadbalancer sku	`externalTrafficPolicy`	spec.ports.Protocol	spec.ports.AppProtocol	`service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path`	LB 프로브 프로토콜	LB 프로브 요청 경로
표준	로컬	any	any	any	http	`/healthz`
표준	cluster	udp	any	any	null	null
표준	cluster	tcp		(무시됨)	tcp	null
표준	cluster	tcp	tcp	(무시됨)	tcp	null
표준	cluster	tcp	http/https		TCP(<=1.23) 또는 http/https(>=1.24)	null(<=1.23) 또는 `/`(>=1.24)
표준	cluster	tcp	http/https	`/custom-path`	http/https	`/custom-path`
표준	cluster	tcp	지원되지 않는 프로토콜	`/custom-path`	tcp	null
basic	로컬	any	any	any	http	`/healthz`
basic	cluster	tcp		(무시됨)	tcp	null
basic	cluster	tcp	tcp	(무시됨)	tcp	null
basic	cluster	tcp	http		TCP(<=1.23) 또는 http/https(>=1.24)	null(<=1.23) 또는 `/`(>=1.24)
basic	cluster	tcp	http	`/custom-path`	http	`/custom-path`
basic	cluster	tcp	지원되지 않는 프로토콜	`/custom-path`	tcp	null

v1.21부터 상태 프로브의 구성을 사용자 지정하는 service.beta.kubernetes.io/azure-load-balancer-health-probe-interval 및 load-balancer-health-probe-num-of-probe 서비스 주석이 도입되었습니다. service.beta.kubernetes.io/azure-load-balancer-health-probe-interval을 설정하지 않으면 기본값인 5가 적용됩니다. load-balancer-health-probe-num-of-probe를 설정하지 않으면 기본값인 2가 적용됩니다. 총 프로브는 120초 미만이어야 합니다.

포트의 Load Balancer 상태 프로브 사용자 지정

서비스의 여러 포트에는 서로 다른 상태 프로브 구성이 필요할 수 있습니다. 이는 서비스 디자인(예: 상태 엔드포인트 하나로 여러 포트를 제어) 또는 MixedProtocolLBService 같은 Kubernetes 기능 때문일 수 있습니다.

다음 주석을 사용하여 서비스 포트별로 프로브 구성을 사용자 지정할 수 있습니다.

포트별 주석	전체 프로브 주석	사용
service.beta.kubernetes.io/port_{port}_no_lb_rule	해당 없음(전역적으로 동일하지 않음)	true로 설정하면 lb 규칙 및 프로브 규칙이 생성되지 않음
service.beta.kubernetes.io/port_{port}_no_probe_rule	해당 없음(전역적으로 동일하지 않음)	true로 설정하면 프로브 규칙이 생성되지 않음
service.beta.kubernetes.io/port_{port}_health-probe_protocol	해당 없음(전역적으로 동일하지 않음)	이 서비스 포트의 상태 프로브 프로토콜을 설정(예: Http, Https, Tcp)
service.beta.kubernetes.io/port_{port}_health-probe_port	해당 없음(전역적으로 동일하지 않음)	이 서비스 포트의 상태 프로브 포트를 설정(예: 15021)
service.beta.kubernetes.io/port_{port}_health-probe_request-path	service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path	Http 또는 Https의 경우 상태 프로브 요청 경로를 설정. 기본값은 /
service.beta.kubernetes.io/port_{port}_health-probe_num-of-probe	service.beta.kubernetes.io/azure-load-balancer-health-probe-num-of-probe	이 횟수만큼 프로브가 연속으로 실패하면 포트를 비정상으로 간주
service.beta.kubernetes.io/port_{port}_health-probe_interval	service.beta.kubernetes.io/azure-load-balancer-health-probe-interval	프로브 시도 간격

다음 매니페스트의 경우 포트 httpsserver에 대한 주석이 지정되므로 httpsserver 포트의 프로브 규칙이 httpserver의 프로브 규칙과 다릅니다.

apiVersion: v1
kind: Service
metadata:
  name: appservice
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-health-probe-num-of-probe: "5"
    service.beta.kubernetes.io/port_443_health-probe_num-of-probe: "4"
spec:
  type: LoadBalancer
  selector:
    app: server
  ports:
    - name: httpserver
      protocol: TCP
      port: 80
      targetPort: 30102
    - name: httpsserver
      protocol: TCP
      appProtocol: HTTPS
      port: 443
      targetPort: 30104

이 매니페스트에서 https 포트는 /healthz(kube-proxy의 healthz 엔드포인트)의 포트 10256에서 다른 노드 포트(HTTP 준비 검사)를 사용합니다.

apiVersion: v1
kind: Service
metadata:
  name: istio
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-internal: "true"
    service.beta.kubernetes.io/port_443_health-probe_protocol: "http"
    service.beta.kubernetes.io/port_443_health-probe_port: "10256"
    service.beta.kubernetes.io/port_443_health-probe_request-path: "/healthz"
spec:
  ports:
    - name: https
      protocol: TCP
      port: 443
      targetPort: 8443
      nodePort: 30104
      appProtocol: https
  selector:
    app: istio-ingressgateway
    gateway: istio-ingressgateway
    istio: ingressgateway
  type: LoadBalancer
  sessionAffinity: None
  externalTrafficPolicy: Local
  ipFamilies:
    - IPv4
  ipFamilyPolicy: SingleStack
  allocateLoadBalancerNodePorts: true
  internalTrafficPolicy: Cluster

이 매니페스트에서 https 포트는 /healthz/ready의 포트 30000에서 다른 상태 프로브 엔드포인트(HTTP 준비 검사)를 사용합니다.

apiVersion: v1
kind: Service
metadata:
  name: istio
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-internal: "true"
    service.beta.kubernetes.io/port_443_health-probe_protocol: "http"
    service.beta.kubernetes.io/port_443_health-probe_port: "30000"
    service.beta.kubernetes.io/port_443_health-probe_request-path: "/healthz/ready"
spec:
  ports:
    - name: https
      protocol: TCP
      port: 443
      targetPort: 8443
      appProtocol: https
  selector:
    app: istio-ingressgateway
    gateway: istio-ingressgateway
    istio: ingressgateway
  type: LoadBalancer
  sessionAffinity: None
  externalTrafficPolicy: Local
  ipFamilies:
    - IPv4
  ipFamilyPolicy: SingleStack
  allocateLoadBalancerNodePorts: true
  internalTrafficPolicy: Cluster

SNAT 문제 해결

동일한 대상 IP 주소 및 포트에 대해 많은 아웃바운드 TCP 또는 UDP 연결을 시작할 것임을 알고 있으며, 실패하는 아웃바운드 연결을 확인하거나 지원 서비스에서 SNAT 포트(PAT에서 사용하는 미리 할당된 삭제 포트)가 소진하고 있다고 알리는 경우 일반적인 완화 옵션 몇 가지를 사용할 수 있습니다. 이러한 옵션을 검토하고 시나리오에 가장 적합한 옵션을 결정합니다. 하나 이상이 시나리오 관리에 도움이 될 수 있습니다. 자세한 내용은 아웃바운드 연결 문제 해결 가이드를 검토하세요.

SNAT 소모의 근본 원인은 아웃바운드 연결의 설정, 관리 또는 구성 가능한 타이머가 기본값에서 변경되는 방식에 대한 앤티 패턴인 경우가 많습니다. 이 섹션을 주의 깊게 검토하세요.

단계

연결이 오랫동안 유휴 상태를 유지하고, 해당 포트를 해제하는 데 기본 유휴 시간 제한을 사용하는지 확인합니다. 이 경우 시나리오에 맞게 기본 시간 제한인 30분을 줄여야 할 수 있습니다.
애플리케이션이 아웃바운드 연결을 만드는 방법을 조사합니다(예: 코드 검토 또는 패킷 캡처).
이 활동이 예상되는 동작인지, 아니면 애플리케이션이 잘못 작동하는지를 확인합니다. Azure Monitor에서 메트릭 및 로그를 사용하여 검색 결과를 구체화합니다. 예를 들어 "실패" 범주를 SNAT 연결 메트릭에 사용합니다.
적절한 패턴을 따르는지 여부를 평가합니다.
더 많은 아웃바운드 IP 주소 + 더 많은 할당된 아웃바운드 포트로 SNAT 포트 소진을 완화해야 하는지 평가합니다.

디자인 패턴

가능한 경우 연결 다시 사용 및 연결 풀링을 활용합니다. 이러한 패턴은 리소스 소진 문제를 방지하고 예측 가능한 동작을 생성하는 데 도움이 됩니다. 이러한 패턴의 기본 형식은 다양한 개발 라이브러리 및 프레임워크에서 찾을 수 있습니다.

원자성 요청(연결당 하나의 요청)은 일반적으로 좋은 디자인 선택이 아닙니다. 이러한 안티패턴은 규모를 제한하고 성능을 저하시키며 안정성을 떨어뜨립니다. 그 대신, HTTP/S 연결을 다시 사용하여 연결 수와 연결된 SNAT 포트 수를 줄입니다. TLS를 사용하면 핸드셰이크, 오버헤드 및 암호화 작업 비용이 감소하므로 애플리케이션 규모가 증가하고 성능이 향상됩니다.
클러스터/사용자 지정 DNS 또는 coreDNS의 사용자 지정 업스트림 서버를 사용하는 경우 클라이언트에서 DNS 확인자 결과를 캐시하지 않으면 DNS가 볼륨에서 많은 개별 흐름을 도입할 수 있다는 점에 유의해야 합니다. 사용자 지정 DNS 서버를 사용하는 대신 coreDNS를 먼저 사용자 지정하고 적절한 캐싱 값을 정의해야 합니다.
UDP 흐름(예: DNS 조회)은 유휴 제한 시간 동안 SNAT 포트를 할당합니다. 유휴 시간 제한이 길수록 SNAT 포트가 받는 압력이 높아집니다. 유휴 시간 제한을 짧게(예: 4분) 설정하세요.
연결 풀을 사용하여 연결 볼륨을 셰이핑하세요.
절대로 TCP 흐름을 자동으로 중단하고 TCP 타이머를 사용하여 흐름을 정리하지 마세요. TCP에서 연결을 명시적으로 닫지 않는 경우 상태는 중간 시스템 및 엔드포인트에서 할당된 상태를 유지하고 다른 연결에서 SNAT 포트를 사용할 수 없게 만듭니다. 이 패턴은 애플리케이션 오류 및 SNAT 고갈이 트리거할 수 있습니다.
영향에 대한 전문 지식이 없으면 OS 수준 TCP 닫기 관련 타이머 값을 변경하지 마세요. TCP 스택이 복구되는 동안 연결의 엔드포인트에 예상과 다른 부분이 있으면 애플리케이션 성능에 부정적인 영향을 미칠 수 있습니다. 타이머를 변경하고 싶다는 생각이 들면 일반적으로 디자인에 근본적인 문제가 있다는 신호입니다. 다음 권장 사항을 검토하세요.

기본 SKU 부하 분산 장치에서 표준 SKU로 이동

기본 SKU 부하 분산 장치가 있는 기존 클러스터가 있는 경우 표준 SKU 부하 분산 장치로 마이그레이션할 때 유의해야 할 중요한 동작 차이점이 있습니다.

예를 들어 클러스터를 마이그레이션하기 위해 파란색/녹색 배포를 만드는 것은 클러스터의 load-balancer-sku 유형을 고려할 때 일반적이며 클러스터 생성 시에만 정의할 수 있습니다. 그러나 기본 SKU 부하 분산 장치는 표준 SKU 부하 분산 장치와 호환되지 않는 기본 SKU IP 주소를 사용합니다. 표준 SKU 부하 분산 장치에는 표준 SKU IP 주소가 필요합니다. 부하 분산 장치 SKU를 업그레이드하기 위해 클러스터를 마이그레이션할 때 호환되는 IP 주소 SKU가 있는 새 IP 주소가 필요합니다.

클러스터 마이그레이션 방법에 대한 추가 고려 사항은 마이그레이션 고려 사항에 대한 설명서를 참조하세요.

제한 사항

‘표준’ SKU를 포함한 부하 분산 장치를 지원하는 AKS 클러스터를 만들고 관리하는 경우 다음과 같은 제한 사항이 적용됩니다.

AKS 클러스터에서 송신 트래픽을 허용하려면 하나 이상의 공용 IP 또는 IP 접두사가 필요합니다. 공용 IP 또는 IP 접두사는 컨트롤 플레인과 에이전트 노드 간의 연결을 유지하는 것뿐만 아니라 AKS의 이전 버전과의 호환성을 유지하는 데 필요합니다. ‘표준’ SKU 부하 분산 장치를 사용하여 공용 IP 또는 IP 접두사를 지정하는 다음과 같은 옵션이 있습니다.
- 사용자 고유의 공용 IP를 제공합니다.
- 사용자 고유의 공용 IP 접두사를 제공합니다.
- AKS 클러스터가 AKS 클러스터와 동일한 리소스 그룹에 많은 표준 SKU 공용 IP를 만들 수 있도록 최대 100까지 숫자를 지정합니다. 이 리소스 그룹은 일반적으로 처음에 MC_로 이름이 지정됩니다. AKS는 ‘표준’ SKU 부하 분산 장치에 공용 IP를 할당합니다. 공용 IP, 공용 IP 접두사 또는 IP 수가 지정되지 않은 경우 기본적으로 하나의 공용 IP가 AKS 클러스터와 동일한 리소스 그룹에 자동으로 만들어집니다. 또한 공용 주소를 허용하고 IP 생성을 금지하는 Azure Policy를 만들지 않도록 해야 합니다.
AKS에서 만든 공용 IP는 사용자 지정 공용 IP 주소 가져오기로 재사용할 수 없습니다. 사용자는 모든 사용자 지정 IP 주소를 만들고 관리해야 합니다.
부하 분산 장치 SKU를 정의하는 것은 AKS 클러스터를 만들 때만 수행할 수 있습니다. AKS 클러스터를 만든 후에는 부하 분산 장치 SKU를 변경할 수 없습니다.
단일 클러스터에서는 한 가지 유형의 부하 분산 장치 SKU(기본 또는 표준)만 사용할 수 있습니다.
표준 SKU 부하 분산 장치는 표준 SKU IP 주소만 지원합니다.

다음 단계

Kubernetes 서비스에 대한 자세한 내용은 Kubernetes 서비스 설명서를 참조하세요.

인바운드 트래픽에 대한 내부 부하 분산기 사용에 대한 자세한 내용은 AKS 내부 부하 분산 장치 설명서를 참조하세요.

AKS(Azure Kubernetes Service)에서 퍼블릭 표준 부하 분산 장치 사용

시작하기 전에

공용 표준 부하 분산 장치 사용

부하 분산 장치 IP 주소 지정

서비스 매니페스트 배포

공용 표준 부하 분산 장치 구성

인바운드 풀 형식 변경

요구 사항

제한 사항

IP 기반 인바운드 풀 멤버 자격으로 새 AKS 클러스터 만들기

IP 기반 인바운드 풀 멤버 자격을 사용하도록 기존 AKS 클러스터 업데이트

관리되는 아웃바운드 공용 IP 수 크기 조정

사용자 고유 아웃바운드 공용 IP 또는 접두사 제공

사용자 고유 아웃바운드 공용 IP로 클러스터를 업데이트합니다.

사용자 고유 아웃바운드 공용 IP 접두사로 클러스터 업데이트

사용자 고유 공용 IP 또는 접두사로 클러스터 만들기

할당된 아웃바운드 포트 구성

부하 분산 장치 유휴 시간 제한 구성

인바운드 트래픽을 특정 IP 범위로 제한

인바운드 연결에서 클라이언트의 IP 유지 관리

Kubernetes 주석을 통한 사용자 지정

부하 분산 장치 상태 프로브 사용자 지정

포트의 Load Balancer 상태 프로브 사용자 지정

SNAT 문제 해결

단계

디자인 패턴

기본 SKU 부하 분산 장치에서 표준 SKU로 이동

제한 사항

다음 단계

추가 리소스