AKS(Azure Kubernetes Service)에서 Azure CNI 오버레이 네트워킹 구성

  • 아티클

기존의 Azure CNI(Container Networking Interface)는 모든 Pod에 VNet IP 주소를 할당합니다. 모든 노드에 미리 예약된 IP 집합 또는 Pod용으로 예약된 별도의 서브넷에서 이 IP 주소를 할당합니다. 이 접근 방식을 사용하려면 IP 주소를 계획해야 하며 주소가 고갈될 수 있습니다. 따라서 애플리케이션 수요가 증가하면 클러스터를 스케일링하는 데 어려움이 있을 수 있습니다.

Azure CNI 오버레이를 사용하면 클러스터 노드가 Azure VNet(Virtual Network) 서브넷에 배포됩니다. Pod에는 노드를 호스트하는 VNet과 논리적으로 다른 프라이빗 CIDR의 IP 주소가 할당됩니다. 클러스터 내의 Pod 및 노드 트래픽은 오버레이 네트워크를 사용합니다. NAT(Network Address Translation)는 노드의 IP 주소를 사용하여 클러스터 외부의 리소스에 연결합니다. 이 솔루션은 상당한 양의 VNet IP 주소를 저장하고 클러스터를 대규모로 크기 조정할 수 있도록 해줍니다. 또한 다양한 AKS 클러스터에서 프라이빗 CIDR을 재사용할 수 있으므로, 이를 통해 AKS(Azure Kubernetes Service)의 컨테이너화된 애플리케이션에 사용할 수 있는 IP 공간을 확장할 수 있습니다.

오버레이 네트워킹 개요

오버레이 네트워킹에서는 Kubernetes 클러스터 노드에만 서브넷의 IP가 할당됩니다. Pod는 클러스터 만들 때 제공된 프라이빗 CIDR로부터 IP를 수신합니다. 각 노드에는 동일한 CIDR에서 얻은 /24 주소 공간이 할당됩니다. 클러스터를 스케일 아웃할 때 만들어진 추가 노드는 동일한 CIDR에서 자동으로 /24 주소 공간을 수신합니다. Azure CNI는 이 /24 공간의 Pod에 IP를 할당합니다.

Pod의 프라이빗 CIDR 공간에 대한 Azure 네트워킹 스택에 별도의 라우팅 도메인이 만들어지며, 이때 Pod 간 직접 통신을 위한 오버레이 네트워크가 만들어집니다. 클러스터 서브넷에서 사용자 지정 경로를 프로비전하거나 캡슐화 방법을 사용하여 Pod 간 트래픽을 터널링할 필요가 없습니다. 이는 VNet의 VM과 동등한 Pod 간 연결 성능을 제공합니다. Pod 내에서 실행되는 워크로드는 네트워크 주소 조작이 발생하고 있다는 사실조차 인식하지 못합니다.

오버레이 네트워크에서 각각 3개의 Pod가 실행되는 두 개의 노드를 보여 주는 다이어그램 클러스터 외부의 엔드포인트에 대한 Pod 트래픽은 NAT를 통해 라우팅됩니다.

온-프레미스 및 피어링된 VNet과 같은 클러스터 외부 엔드포인트와의 통신은 NAT를 통해 노드 IP를 사용하여 발생합니다. Azure CNI는 트래픽의 원본 IP(Pod의 오버레이 IP)를 VM의 기본 IP 주소로 변환하며, 따라서 Azure 네트워킹 스택이 트래픽을 대상으로 라우팅할 수 있게 됩니다. 클러스터 외부의 엔드포인트는 Pod에 직접 연결할 수 없습니다. VNet에서 연결할 수 있도록 Pod의 애플리케이션을 Kubernetes Load Balancer 서비스로 게시해야 합니다.

표준 SKU Load Balancer 또는 관리 NAT Gateway를 사용하여 오버레이 Pod에 인터넷에 대한 아웃바운드(송신) 연결을 제공할 수 있습니다. 클러스터 서브넷에서 사용자 정의 경로를 사용하여 송신 트래픽을 방화벽으로 전달하는 방식으로 송신 트래픽을 제어할 수도 있습니다.

Nginx 또는 HTTP 애플리케이션 라우팅과 같은 수신 컨트롤러를 사용하여 클러스터에 대한 수신 연결을 구성할 수 있습니다. Azure App Gateway를 사용하여 수신 연결을 구성할 수 없습니다. 자세한 내용은 Azure CNI 오버레이 제한 사항을 참조하세요.

Kubenet과 Azure CNI 오버레이의 차이점

Azure CNI 오버레이와 마찬가지로, Kubenet은 VNet과 논리적으로 다른 주소 공간의 Pod에 IP 주소를 할당하지만 스케일링 및 기타 제한 사항이 있습니다. 아래 표에는 Kubenet과 Azure CNI 오버레이의 차이점이 자세히 비교되어 있습니다. IP 부족으로 인해 VNet IP 주소를 Pod에 할당하지 않으려면 Azure CNI 오버레이를 사용하는 것이 좋습니다.

지역 Azure CNI 오버레이 Kubenet
클러스터 스케일링 노드 5000개 및 Pod/노드 250개 노드 400개 및 Pod/노드 250개
네트워크 구성 단순 - Pod 네트워킹에 추가 구성이 필요 없음 복합 - Pod 네트워킹을 사용하려면 클러스터 서브넷에 경로 테이블과 UDR 필요
Pod 연결 성능 VNet의 VM과 동등한 성능 추가 홉으로 인해 약간의 대기 시간이 추가됨
Kubernetes 네트워크 정책 Azure 네트워크 정책, Calico, Cilium Calico
지원되는 OS 플랫폼 Linux 및 Windows Server 2022, 2019 Linux만

IP 주소 계획

  • 클러스터 노드: AKS 클러스터를 설정할 때 VNet 서브넷에 향후 크기 조정을 위해 성장할 수 있는 충분한 공간이 있는지 확인합니다. 각 노드 풀을 전용 서브넷에 할당할 수 있습니다. 처음 3개의 IP 주소는 관리 작업용으로 예약되어 있으므로 /24서브넷은 최대 251개의 노드를 수용할 수 있습니다.
  • Pod: 오버레이 솔루션은 클러스터를 만드는 동안 지정하는 프라이빗 CIDR의 모든 노드에 있는 Pod에 /24 주소 공간을 할당합니다. 크기가 /24로 고정되어 있으므로 늘리거나 줄일 수 없습니다. 한 노드에서 최대 250개의 Pod를 실행할 수 있습니다. Pod 주소 공간을 계획할 때, 향후 클러스터 확장을 지원할 수 있도록 새 노드의 /24 주소 공간을 제공할 수 있을 만큼 프라이빗 CIDR이 충분히 커야 합니다.
    • Pod의 IP 주소 공간을 계획할 때 다음 요소를 고려합니다.
      • 동일한 Pod CIDR 공간을 동일한 VNet에 있는 여러 독립 AKS 클러스터에서 사용할 수 있습니다.
      • Pod CIDR 공간이 클러스터 서브넷 범위와 겹치면 안 됩니다.
      • Pod CIDR 공간은 직접 연결된 네트워크(예: VNet 피어링, ExpressRoute 또는 VPN)와 겹쳐서는 안 됩니다. 외부 트래픽에 podCIDR 범위의 원본 IP가 있는 경우 클러스터와 통신하려면 SNAT를 통해 겹치지 않는 IP로 변환해야 합니다.
  • Kubernetes 서비스 주소 범위: 서비스 주소 CIDR의 크기는 만들려는 클러스터 서비스 수에 따라 달라집니다. /12보다 작아야 합니다. 이 범위는 피어링된 VNet 및 온-프레미스 네트워크에 사용되는 Pod CIDR 범위, 클러스터 서브넷 범위 및 IP 범위와 겹쳐서는 안 됩니다.
  • Kubernetes DNS 서비스 IP 주소: 이 IP 주소는 클러스터 서비스 검색에 사용되는 Kubernetes Service 주소 범위 내에 있습니다. 주소 범위의 첫 번째 IP 주소는 kubernetes.default.svc.cluster.local 주소가 사용되므로 주소를 사용하지 마세요.

네트워크 보안 그룹

Azure CNI 오버레이를 사용하는 Pod-Pod 트래픽은 캡슐화되지 않으며 서브넷 네트워크 보안 그룹 규칙이 적용됩니다. 서브넷 NSG에 Pod CIDR 트래픽에 영향을 주는 거부 규칙이 포함된 경우 적절한 클러스터 기능(모든 AKS 송신 요구 사항 외에)을 보장하기 위해 다음 규칙이 있는지 확인합니다.

  • 노드 CIDR에서 모든 포트 및 프로토콜의 노드 CIDR로의 트래픽
  • 모든 포트 및 프로토콜에서 노드 CIDR에서 Pod CIDR로의 트래픽(서비스 트래픽 라우팅에 필요)
  • 모든 포트 및 프로토콜에서 포드 CIDR에서 포드 CIDR로의 트래픽(Pod에서 Pod로, Pod에서 서비스로의 트래픽(DNS 포함)에 필요)

Pod에서 Pod CIDR 블록 외부의 대상으로의 트래픽은 SNAT를 활용하여 원본 IP를 Pod가 실행되는 노드의 IP로 설정합니다.

클러스터의 워크로드 간 트래픽을 제한하려면 네트워크 정책을 사용하는 것이 좋습니다.

노드당 최대 포드

클러스터를 만들 때 또는 새 노드 풀을 추가할 때 노드당 최대 Pod 수를 구성할 수 있습니다. Azure CNI 오버레이의 기본값은 250입니다. Azure CNI 오버레이에서 지정할 수 있는 최댓값은 250이고, 최솟값은 10입니다. 노드 풀을 만드는 동안 구성된 노드당 최대 Pod 수는 해당 노드 풀의 노드에만 적용됩니다.

사용할 네트워크 모델 선택

Azure CNI는 Pod에 두 가지 IP 주소 지정 옵션 제공: 하나는 Pod에 VNet IP를 할당하는 기존 구성이고, 다른 하나는 오버레이 네트워킹입니다. AKS 클러스터에 사용할 옵션을 선택할 때 중요한 것은 유연성과 고급 구성 요구 사항 간의 균형입니다. 다음 고려 사항은 각 네트워크 모델이 가장 적합한 경우를 대략적으로 알려줍니다.

다음과 같은 경우 오버레이 네트워킹 사용:

  • Pod 수를 대량으로 스케일링하고 싶지만 VNet의 IP 주소 공간이 제한되어 있습니다.
  • Pod 통신 대부분이 클러스터 내에 있습니다.
  • 가상 노드와 같은 고급 AKS 기능이 필요하지 않습니다.

다음과 같은 경우 기존 VNet 옵션 사용:

  • 사용 가능한 IP 주소 공간이 있습니다.
  • Pod 통신 대부분이 클러스터 외부의 리소스를 대상으로 진행됩니다.
  • 클러스터 외부의 리소스는 Pod에 직접 연결해야 합니다.
  • 가상 노드와 같은 AKS 고급 기능이 필요합니다.

Azure CNI 오버레이의 제한 사항

Azure CNI 오버레이에는 다음과 같은 제한 사항이 있습니다.

  • Application Gateway를 오버레이 클러스터의 AGIC(수신 컨트롤러)로 사용할 수 없습니다.
  • 오버레이에 대한 VMAS(가상 머신 가용성 집합)는 지원되지 않습니다.
  • 노드 풀에서는 DCsv2 시리즈 가상 머신을 사용할 수 없습니다. 기밀 컴퓨팅 요구 사항을 충족하려면 대신 DCasv5 또는 DCadsv5 시리즈 기밀 VM을 사용하는 것이 좋습니다.
  • 사용자 고유의 서브넷을 사용하여 클러스터를 배포하는 경우 서브넷, VNET 및 VNET을 포함하는 리소스 그룹의 이름은 63자 이하여야 합니다. 이러한 이름은 AKS 작업자 노드에서 레이블로 사용되므로 kubernetes 레이블 구문 규칙에 따라 좌우됩니다.

오버레이 클러스터 설정

참고 항목

--network-plugin-mode 인수를 사용하려면 CLI 버전 2.48.0 이상이 있어야 합니다. Windows의 경우 최신 aks-preview Azure CLI 확장이 설치되어 있어야 하며 아래 지침을 따를 수 있습니다.

az aks create 명령을 사용하여 Azure CNI 오버레이로 클러스터를 만듭니다. 오버레이 클러스터를 지정하려면 인수 --network-plugin-mode를 사용해야 합니다. Pod CIDR이 할당되지 않은 경우 AKS는 기본 공간인 viz. 10.244.0.0/16을 할당합니다.

clusterName="myOverlayCluster"
resourceGroup="myResourceGroup"
location="westcentralus"

az aks create -n $clusterName -g $resourceGroup \
  --location $location \
  --network-plugin azure \
  --network-plugin-mode overlay \
  --pod-cidr 192.168.0.0/16

전용 서브넷에 새 노드 풀 추가

Azure CNI 오버레이를 사용하여 클러스터를 만든 후에는 다른 노드 풀을 만들고 동일한 VNet의 새 서브넷에 노드를 할당할 수 있습니다. 이 방식은 동일한 VNet 또는 피어링된 VNet의 대상에서 호스트의 수신 IP 또는 송신 IP를 제어하려는 경우 유용할 수 있습니다.

clusterName="myOverlayCluster"
resourceGroup="myResourceGroup"
location="westcentralus"
nodepoolName="newpool1"
subscriptionId=$(az account show --query id -o tsv)
vnetName="yourVnetName"
subnetName="yourNewSubnetName"
subnetResourceId="/subscriptions/$subscriptionId/resourceGroups/$resourceGroup/providers/Microsoft.Network/virtualNetworks/$vnetName/subnets/$subnetName"
az aks nodepool add  -g $resourceGroup --cluster-name $clusterName \
  --name $nodepoolName --node-count 1 \
  --mode system --vnet-subnet-id $subnetResourceId

기존 클러스터를 CNI 오버레이로 업그레이드

참고 항목

클러스터가 다음 기준을 충족하는 경우 기존 Azure CNI 클러스터를 오버레이로 업데이트할 수 있습니다.

  • 클러스터는 Kubernetes 버전 1.22 이상에 있습니다.
  • 동적 Pod IP 할당 기능을 사용하지 않습니다.
  • 네트워크 정책이 사용하도록 설정되어 있지 않습니다. 업그레이드 전에 네트워크 정책 엔진을 제거할 수 있습니다. Azure 네트워크 정책 관리자 또는 Calico 제거를 참조하세요.
  • Docker를 컨테이너 런타임으로 사용하는 Windows 노드 풀을 사용하지 않습니다.

참고 항목

ARM에서는 라우팅 도메인이 아직 지원되지 않기 때문에 CNI 오버레이는 아직 ARM 기반(ARM64) 프로세서 노드에서 지원되지 않습니다.

참고 항목

기존 클러스터를 CNI 오버레이로 업그레이드하는 것은 되돌릴 수 없는 프로세스입니다.

Warning

Windows OS 빌드 20348.1668 이전에는 Windows 오버레이 Pod가 호스트 네트워크 Pod에서 패킷을 잘못 SNATing하는 것과 관련된 제한 사항이 있었으며, 이는 오버레이로 업그레이드하는 클러스터에 더 나쁜 영향을 미칩니다. 이 문제를 방지하려면 20348.1668 이상의 Windows OS 빌드를 사용합니다.

Warning

사용자 지정 azure-ip-masq-agent 구성을 사용하여 Pod에서 SNAT 패킷을 보내서는 안 되는 추가 IP 범위를 포함하는 경우 Azure CNI 오버레이로 업그레이드하면 해당 범위에 대한 연결이 끊어질 수 있습니다. 오버레이 공간의 Pod IP는 클러스터 노드 외부의 어떤 것에서도 연결할 수 없습니다. 또한 충분히 오래된 클러스터의 경우 이전 버전의 azure-ip-masq-agent에 남아 있는 ConfigMap이 있을 수 있습니다. azure-ip-masq-agent-config라는 이 ConfigMap이 존재하며 의도적으로 현재 위치가 아닌 경우 업데이트 명령을 실행하기 전에 삭제해야 합니다. 사용자 지정 ip-masq-agent 구성을 사용하지 않는 경우 Azure ip-masq-agent ConfigMap과 관련하여 azure-ip-masq-agent-config-reconciled ConfigMap만 존재해야 하며 이는 업그레이드 프로세스 중에 자동으로 업데이트됩니다.

업그레이드 프로세스는 각 노드 풀을 동시에 이미지로 다시 생성하도록 트리거합니다. 각 노드 풀을 개별적으로 오버레이로 업그레이드하는 것은 지원되지 않습니다. 클러스터 네트워킹 중단은 노드 풀의 각 노드가 다시 이미지화되는 노드 이미지 업그레이드 또는 Kubernetes 버전 업그레이드와 유사합니다.

Azure CNI 클러스터 업그레이드

az aks update 명령을 사용하여 오버레이를 사용하도록 기존 Azure CNI 클러스터를 업데이트합니다.

clusterName="myOverlayCluster"
resourceGroup="myResourceGroup"
location="westcentralus"

az aks update --name $clusterName \
--resource-group $resourceGroup \
--network-plugin-mode overlay \
--pod-cidr 192.168.0.0/16

Pod는 레거시 노드 서브넷과 겹치지 않는 새 오버레이 공간에서 IP를 가져와야 하기 때문에 레거시 CNI에서 업그레이드할 때 --pod-cidr 매개 변수가 필요합니다. 또한 Pod CIDR은 노드 풀의 VNet 주소와 겹칠 수 없습니다. 예를 들어, VNet 주소가 10.0.0.0/8이고 노드가 서브넷 10.240.0.0/16에 있는 경우 --pod-cidr은 10.0.0.0/8 또는 클러스터의 기존 서비스 CIDR과 겹칠 수 없습니다.

Kubenet 클러스터 업그레이드

az aks update 명령을 사용하여 Azure CNI 오버레이를 사용하도록 기존 Kubenet 클러스터를 업데이트합니다.

clusterName="myOverlayCluster"
resourceGroup="myResourceGroup"
location="westcentralus"

az aks update --name $clusterName \
--resource-group $resourceGroup \
--network-plugin azure \
--network-plugin-mode overlay

클러스터는 이미 VNet IP 공간과 겹치지 않는 Pod용 프라이빗 CIDR을 사용하고 있으므로 --pod-cidr 매개 변수를 지정할 필요가 없으며 Pod CIDR은 동일하게 유지됩니다.

참고 항목

Kubenet에서 CNI Overlay로 업그레이드하면 Pod 라우팅에 경로 테이블이 더 이상 필요하지 않습니다. 클러스터가 고객 제공 경로 테이블을 사용하는 경우 Pod 트래픽을 올바른 노드로 전달하는 데 사용되었던 경로는 마이그레이션 작업 중에 자동으로 삭제됩니다. 클러스터가 관리 경로 테이블을 사용하는 경우(경로 테이블은 AKS에서 만들어졌으며 노드 리소스 그룹에 있음) 마이그레이션 중에 해당 경로 테이블이 삭제됩니다.

이중 스택 네트워킹

오버레이 네트워킹 및 이중 스택 Azure Virtual Network를 사용하는 경우 이중 스택 모드에서 AKS 클러스터를 배포할 수 있습니다. 이 구성에서 노드는 Azure 가상 네트워크 서브넷에서 IPv4 및 IPv6 주소를 모두 받습니다. Pod는 IPv4 및 IPv6 주소를 모두 논리적으로 다른 주소 공간에서 노드의 Azure 가상 네트워크 서브넷으로 받습니다. 그러면 Pod가 Azure 가상 네트워크의 리소스에 연결할 수 있도록 NAT(Network Address Translation)가 구성됩니다. 트래픽의 원본 IP 주소는 동일한 패밀리(IPv4-IPv4 및 IPv6-IPv6)의 노드 기본 IP 주소로 변환(NAT)됩니다.

필수 조건

  • Azure CLI 2.48.0 이상이 설치되어 있어야 합니다.
  • Kubernetes 버전 1.26.3 이상.

제한 사항

이중 스택 네트워킹에서는 다음 기능이 지원되지 않습니다.

  • Windows 노드 풀
  • Azure 네트워크 정책
  • Calico 네트워크 정책
  • NAT Gateway
  • 가상 노드 추가 기능

이중 스택 AKS 클러스터 배포

이중 스택 클러스터를 지원하기 위해 다음 특성이 제공됩니다.

  • --ip-families: 클러스터에서 사용하도록 설정할 쉼표로 구분된 IP 패밀리 목록을 사용합니다.
    • ipv4 또는 ipv4,ipv6만 지원됩니다.
  • --pod-cidrs: Pod IP를 할당할 CIDR 표기법 IP 범위의 쉼표로 구분된 목록을 사용합니다.
    • 이 목록의 범위 수와 순서는 --ip-families에 제공된 값과 일치해야 합니다.
    • 값이 제공되지 않으면 기본값 10.244.0.0/16,fd12:3456:789a::/64이 사용됩니다.
  • --service-cidrs: 서비스 IP를 할당할 CIDR 표기법 IP 범위의 쉼표로 구분된 목록을 사용합니다.
    • 이 목록의 범위 수와 순서는 --ip-families에 제공된 값과 일치해야 합니다.
    • 값이 제공되지 않으면 기본값 10.0.0.0/16,fd12:3456:789a:1::/108이 사용됩니다.
    • --service-cidrs에 할당된 IPv6 서브넷은 /108보다 클 수 없습니다.

이중 스택 AKS 클러스터 만들기

  1. [az group create][az-group-create] 명령을 사용하여 클러스터에 대한 Azure 리소스 그룹을 만듭니다.

    az group create -l <region> -n <resourceGroupName>

  2. --ip-families 매개 변수가 ipv4,ipv6으로 설정된 az aks create 명령을 사용하여 이중 스택 AKS 클러스터를 만듭니다.

    az aks create -l <region> -g <resourceGroupName> -n <clusterName> \
  --network-plugin azure \
  --network-plugin-mode overlay \
  --ip-families ipv4,ipv6

예제 워크로드 만들기

클러스터가 만들어지면 워크로드를 배포할 수 있습니다. 이 문서에서는 NGINX 웹 서버의 워크로드 배포 예제를 안내합니다.

NGINX 웹 서버 배포

애플리케이션 라우팅 추가 기능은 AKS 클러스터에서 수신하는 데 권장되는 방법입니다. 애플리케이션 라우팅 추가 기능 및 추가 기능을 사용하여 애플리케이션을 배포하는 방법의 예에 대한 자세한 내용은 애플리케이션 라우팅 추가 기능을 사용하는 관리형 NGINX 수신을 참조하세요.

LoadBalancer 형식 서비스를 통해 워크로드 공개

Important

현재 AKS에는 IPv6 서비스와 관련된 두 가지 제한 사항이 있습니다.

  • Azure Load Balancer는 상태 프로브를 링크 로컬 주소에서 IPv6 대상으로 보냅니다. Azure Linux 노드 풀에서는 이 트래픽을 Pod로 라우팅할 수 없으므로 externalTrafficPolicy: Cluster를 사용하여 배포된 IPv6 서비스로 흐르는 트래픽은 실패합니다. IPv6 서비스는 externalTrafficPolicy: Local을 사용하여 배포되어야 하며, 그러면 kube-proxy가 노드의 프로브에 응답하게 됩니다.
  • Kubernetes 버전 1.27 이전에는 서비스의 첫 번째 IP 주소만 부하 분산 장치에 프로비전되므로 이중 스택 서비스는 첫 번째로 나열된 IP 제품군에 대한 공용 IP만 받습니다. 단일 배포에 대한 이중 스택 서비스를 제공하려면 동일한 선택기를 대상으로 하는 두 개의 서비스를 만듭니다. 하나는 IPv4용이고 다른 하나는 IPv6용입니다. 이는 kubernetes 1.27 이상에서는 더 이상 제한 사항이 아닙니다.

  1. kubectl expose deployment nginx 명령을 사용하여 NGINX 배포를 노출합니다.

    kubectl expose deployment nginx --name=nginx-ipv4 --port=80 --type=LoadBalancer'
kubectl expose deployment nginx --name=nginx-ipv6 --port=80 --type=LoadBalancer --overrides='{"spec":{"ipFamilies": ["IPv6"]}}'

    서비스가 공개되었음을 보여 주는 출력이 표시됩니다.

    service/nginx-ipv4 exposed
service/nginx-ipv6 exposed

  2. 배포가 공개되고 LoadBalancer 서비스가 완전히 프로비전되면 kubectl get services 명령을 사용하여 서비스의 IP 주소를 가져옵니다.

    kubectl get services

    NAME         TYPE           CLUSTER-IP               EXTERNAL-IP         PORT(S)        AGE
nginx-ipv4   LoadBalancer   10.0.88.78               20.46.24.24         80:30652/TCP   97s
nginx-ipv6   LoadBalancer   fd12:3456:789a:1::981a   2603:1030:8:5::2d   80:32002/TCP   63s

  3. IPv6 지원 호스트에서 명령줄 웹 요청을 통해 기능을 확인합니다. Azure Cloud Shell은 IPv6을 지원하지 않습니다.

    SERVICE_IP=$(kubectl get services nginx-ipv6 -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
curl -s "http://[${SERVICE_IP}]" | head -n5

    <!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>

다음 단계

고유한 CNI(Container Network Interface) 플러그 인과 함께 AKS를 활용하는 방법을 알아보려면 사용자 고유의 CNI(Container Network Interface) 플러그 인 가져오기를 참조하세요.