AKS(Azure Kubernetes Service)에서 사용자 고유의 IP 주소 범위에 kubenet 네트워킹 사용

아티클
08/05/2024

AKS 클러스터는 kubenet을 사용하고 기본적으로 Azure Virtual Network와 서브넷을 만듭니다. kubenet을 사용하면 노드는 Azure Virtual Network 서브넷의 IP 주소를 얻습니다. Pod는 논리적으로 다른 주소 공간에서 노드의 Azure 가상 네트워크 서브넷으로 IP 주소를 수신합니다. 그런 후에 NAT(Network Address Translation)는 Pod가 Azure Virtual Network의 리소스에 연결할 수 있도록 구성됩니다. 트래픽의 원본 IP 주소는 노드의 기본 IP 주소로 NAT됩니다. 이 방법을 사용하면 네트워크 공간에서 Pod가 사용하도록 예약해야 하는 IP 주소의 수가 크게 줄어듭니다.

Azure CNI(컨테이너 네트워킹 인터페이스)를 사용하면 모든 pod가 서브넷에서 IP 주소를 가져오고 직접 액세스할 수 있습니다. 이러한 IP 주소는 미리 계획되어야 하며 네트워크 공간 전체에서 고유해야 합니다. 각 노드에는 지원하는 최대 Pod 수에 대한 구성 매개 변수가 있습니다. 그러면 노드당 동일한 IP 주소 수가 해당 노드에 대해 미리 예약됩니다. 이 방식을 사용할 경우 더 많은 계획이 필요하며, 애플리케이션 요구가 증가하면서 IP 주소가 고갈되거나 더 큰 서브넷에서 클러스터를 구축해야 할 수 있습니다. 클러스터를 만들 때 또는 새 노드 풀을 만들 때 노드에 배포할 수 있는 최대 Pod 수를 구성할 수 있습니다. 새 노드 풀을 만들 때 maxPods를 지정하지 않으면 kubenet에 대한 기본값인 110을 받게 됩니다.

이 문서에서는 kubenet 네트워킹을 사용하여 AKS 클러스터용 가상 네트워크를 만들고 사용하는 방법에 대해 설명합니다. 네트워킹 옵션 및 고려 사항에 대한 자세한 내용은 Kubernetes 및 AKS에 대한 네트워크 개념을 참조하세요.

필수 조건

AKS 클러스터에 대한 가상 네트워크는 아웃바운드 인터넷 연결을 허용해야 합니다.
동일한 서브넷에 둘 이상의 AKS 클러스터를 만들지 마세요.
AKS 클러스터는 Kubernetes 서비스 주소 범위, Pod 주소 범위 또는 클러스터 가상 네트워크 주소 범위에 대해 169.254.0.0/16, 172.30.0.0/16, 172.31.0.0/16 또는 192.0.2.0/24를 사용할 수 없습니다. 클러스터를 만든 후에는 범위를 업데이트할 수 없습니다.
AKS 클러스터에서 사용하는 클러스터 ID에는 최소한 가상 네트워크 내의 서브넷에 대한 네트워크 기여자 역할이 있어야 합니다. CLI는 역할 할당을 자동으로 설정하는 데 도움이 됩니다. ARM 템플릿이나 다른 클라이언트를 사용하는 경우 역할 할당을 수동으로 설정해야 합니다. 또한 클러스터 ID를 만들고 사용 권한을 할당하려면 구독 소유자와 같은 적절한 사용 권한이 있어야 합니다. 기본 제공 네트워크 기여자 역할을 사용하는 대신 사용자 지정 역할을 정의하려는 경우 다음 권한이 필요합니다.
- Microsoft.Network/virtualNetworks/subnets/join/action
- Microsoft.Network/virtualNetworks/subnets/read

Warning

Windows Server 노드 풀을 사용하려면 Azure CNI를 사용해야 합니다. kubenet 네트워크 모델은 Windows Server 컨테이너에 사용할 수 없습니다.

시작하기 전에

Azure CLI 버전 2.0.65 이상을 설치하고 구성해야 합니다. az --version을 실행하여 버전을 찾습니다. 설치 또는 업그레이드해야 하는 경우 Azure CLI 설치를 참조하세요.

고유한 서브넷을 사용한 Kubenet 네트워킹 개요

많은 환경에서 IP 주소 범위가 할당된 가상 네트워크와 서브넷을 정의했으며 이러한 리소스를 사용하여 여러 서비스와 애플리케이션을 지원합니다. AKS 클러스터 네트워크 연결을 제공하기 위해 AKS 클러스터는 kubenet(기본 네트워킹) 또는 Azure CNI(고급 네트워킹)을 사용할 수 있습니다.

kubenet을 사용하는 경우 해당 노드만 가상 네트워크 서브넷의 IP 주소를 수신합니다. Pod는 서로 직접 통신할 수 없습니다. 대신 UDR(사용자 정의 라우팅) 및 IP 전달이 노드 전체의 Pod 간 연결을 처리합니다. UDR 및 IP 전달 구성은 기본적으로 AKS 서비스에 의해 만들어지고 유지 관리되지만 원하는 경우 사용자 지정 경로 관리를 위해 자체 경로 테이블을 가져올 수 있습니다. 애플리케이션에 대해 할당된 IP 및 부하 분산 트래픽을 수신하는 서비스 뒤에 pod를 배포할 수도 있습니다. 다음 다이어그램은 AKS 노드가 pod가 아닌 가상 네트워크 서브넷의 IP 주소를 수신하는 방법을 보여 줍니다.

AKS 클러스터를 사용하는 Kubenet 네트워크 모델

Azure는 UDR에서 최대 400개의 경로를 지원하므로 400개 노드보다 큰 AKS 클러스터를 사용할 수 없습니다. AKS 가상 노드 및 Azure 네트워크 정책은 kubenet에서 지원되지 않습니다. Calico 네트워크 정책이 지원됩니다.

Azure CNI를 사용하면 각 Pod는 IP 서브넷에서 IP 주소를 수신하고 다른 Pod 및 서비스와 직접 통신할 수 있습니다. 클러스터는 사용자가 지정하는 IP 주소 범위만큼 클 수 있습니다. 그러나 IP 주소 범위를 미리 계획해야 하며 모든 IP 주소는 지원할 수 있는 최대 Pod 수에 따라 AKS 노드에서 사용됩니다. 가상 노드 또는 네트워크 정책과 같은 고급 네트워크 기능 및 시나리오는 Azure CNI에서 지원됩니다.

Kubenet의 제한 사항 및 고려 사항

Kubenet 디자인에는 추가 홉이 필요하며 이는 Pod 통신에 약간의 대기 시간을 추가합니다.
kubenet을 사용하려면 경로 테이블 및 사용자 정의 경로가 필요하며 이는 작업에 복잡성을 더합니다.
- 자세한 내용은 AKS에서 사용자 지정 라우팅 테이블을 사용하여 클러스터 송신 사용자 지정 및 AKS에서 아웃바운드 형식으로 클러스터 송신 사용자 지정을 참조하세요.
Kubenet 디자인으로 인해 kubenet에 직접 Pod 주소 지정은 지원되지 않습니다.
Azure CNI 클러스터와 달리 여러 kubenet 클러스터는 서브넷을 공유할 수 없습니다.
AKS는 서브넷에 NSG(네트워크 보안 그룹)를 적용하지 않으며 해당 서브넷과 연결된 NSG를 수정하지 않습니다. 고유한 서브넷을 제공하고 해당 서브넷과 연결된 NSG를 추가하는 경우 NSG의 보안 규칙이 노드와 Pod CIDR 간의 트래픽을 허용하는지 확인해야 합니다. 자세한 내용은 네트워크 보안 그룹을 참조하세요.
kubenet에서 지원되지 않는 기능은 다음과 같습니다.

참고 항목

클러스터 내 konnectivity와 같은 일부 시스템 Pod에서는 오버레이 주소 공간의 IP가 아닌 호스트 노드 IP 주소를 사용합니다. 시스템 Pod는 가상 네트워크의 IP 주소가 아닌 노드 IP만 사용합니다.

IP 주소 가용성 및 고갈

Azure CNI의 일반적인 문제는 할당된 IP 주소 범위가 너무 작아서 클러스터의 크기를 조정하거나 업그레이드할 때 노드를 추가할 수 없다는 것입니다. 또한 네트워크 팀은 예상되는 애플리케이션 요구 사항을 지원하기에 충분히 큰 IP 주소 범위를 발급하지 못할 수도 있습니다.

절충안으로, kubenet을 사용하는 AKS 클러스터를 만들고 기존 가상 네트워크 서브넷에 연결할 수 있습니다. 이 방법을 사용하면 클러스터에서 실행될 수 있는 모든 잠재적 pod를 위해 많은 수의 IP 주소를 미리 예약할 필요가 없이, 노드가 정의된 IP 주소를 수신할 수 있습니다. kubenet을 사용하면 훨씬 더 작은 IP 주소 범위를 사용하고 대규모 클러스터 및 애플리케이션 요구를 지원할 수 있습니다. 예를 들어, 서브넷의 IP 주소 범위가 /27인 경우 크기 조정 또는 업그레이드할 공간이 충분한 20~25 노드 클러스터를 실행할 수 있습니다. 이 클러스터 크기는 최대 2,200~2,750개의 Pod(기본적으로 노드당 최대 110개의 Pod)를 지원할 수 있습니다. AKS에서 kubenet을 사용하여 구성할 수 있는 노드당 최대 Pod 수는 250입니다.

다음 기본 계산은 네트워크 모델의 차이를 비교합니다.

kubenet: 간단한 /24 IP 주소 범위는 클러스터에서 최대 251개의 노드를 지원할 수 있습니다. 각 Azure Virtual Network 서브넷은 관리 작업을 위해 처음 3개의 IP 주소를 예약합니다. 이 노드 수는 최대 27,610개의 Pod를 지원할 수 있으며 기본적으로 노드당 최대 Pod 수는 110개입니다.
Azure CNI: 동일한 기본 /24 서브넷 범위는 클러스터에서 최대 8개 노드만 지원할 수 있습니다. 이 노드 수는 최대 240개의 Pod만 지원할 수 있으며 기본적으로 노드당 최대 Pod는 30개입니다.

참고 항목

이러한 최대값에는 업그레이드 또는 크기 조정 작업이 고려되지 않습니다. 실제로 서브넷 IP 주소 범위가 지원하는 최대 노드 수를 실행할 수는 없습니다. 크기 조정 또는 업그레이드 작업에 사용할 수 있는 일부 IP 주소를 남겨 두어야 합니다.

가상 네트워크 피어링 및 ExpressRoute 연결

온-프레미스에 연결하려면 kubenet 및 Azure-CNI 네트워크 접근 방식에서 모두 Azure 가상 네트워크 피어링 또는 ExpressRoute 연결을 사용하면 됩니다. 중복되거나 잘못된 트래픽 라우팅를 방지하도록 IP 주소 범위를 신중하게 계획합니다. 예를 들어, 여러 온-프레미스 네트워크는 ExpressRoute 연결을 통해 보급되는 10.0.0.0/8 주소 범위를 사용합니다. 172.16.0.0/16과 같이 이 주소 범위 외부의 Azure Virtual Network 서브넷에 AKS 클러스터를 만드는 것이 좋습니다.

사용할 네트워크 모델 선택

다음 고려 사항은 각 네트워크 모델이 가장 적합한 경우를 대략적으로 알려줍니다.

다음 경우에 kubenet을 사용합니다.

IP 주소 공간이 제한되어 있습니다.
Pod 통신 대부분이 클러스터 내에 있습니다.
가상 노드 또는 Azure 네트워크 정책과 같은 고급 AKS 기능이 필요하지 않습니다.

다음 경우에 Azure CNI를 사용합니다.

사용 가능한 IP 주소 공간이 있습니다.
Pod 통신 대부분이 클러스터 외부의 리소스를 대상으로 진행됩니다.
Pod 연결에 대한 사용자 정의 경로를 관리하지 않으려고 합니다.
가상 노드 또는 Azure 네트워크 정책과 같은 고급 AKS 기능이 필요합니다.

사용할 네트워크 모델을 결정하는 데 도움이 되는 자세한 내용은 네트워크 모델 및 해당 지원 범위 비교를 참조하세요.

가상 네트워크 및 서브넷 만들기

az group create 명령을 사용하여 리소스 그룹을 만듭니다.
```
az group create --name myResourceGroup --location eastus
```
사용할 기존 가상 네트워크와 서브넷이 없다면 az network vnet create 명령을 사용하여 이러한 네트워크 리소스를 만듭니다. 다음 명령 예는 주소 접두사가 192.168.0.0/16인 myAKSVnet이라는 가상 네트워크와 주소 접두사가 192.168.1.0/24인 myAKSSubnet이라는 서브넷을 만듭니다.
```
az network vnet create \
    --resource-group myResourceGroup \
    --name myAKSVnet \
    --address-prefixes 192.168.0.0/16 \
    --subnet-name myAKSSubnet \
    --subnet-prefix 192.168.1.0/24 \
    --location eastus
```
az network vnet subnet show 명령을 사용하여 서브넷 리소스 ID를 가져오고 나중에 사용할 수 있도록 SUBNET_ID라는 변수로 저장합니다.
```
SUBNET_ID=$(az network vnet subnet show --resource-group myResourceGroup --vnet-name myAKSVnet --name myAKSSubnet --query id -o tsv)
```

가상 네트워크에서 AKS 클러스터 만들기

시스템 할당 관리 ID로 AKS 클러스터 만들기

참고 항목

시스템 할당 ID를 사용하는 경우 Azure CLI는 클러스터가 만들어진 후 시스템 할당 ID에 네트워크 기여자 역할을 부여합니다. ARM 템플릿이나 다른 클라이언트를 사용하는 경우 대신 사용자 할당 관리 ID를 사용해야 합니다.

az aks create 명령을 사용하여 시스템 할당 관리 ID로 AKS 클러스터를 만듭니다.
```
az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --network-plugin kubenet \
    --service-cidr 10.0.0.0/16 \
    --dns-service-ip 10.0.0.10 \
    --pod-cidr 10.244.0.0/16 \
    --vnet-subnet-id $SUBNET_ID \
    --generate-ssh-keys 
```
배포 매개 변수:
- --service-cidr은 선택 사항입니다. 이 주소는 AKS 클러스터의 내부 서비스에 IP 주소를 할당하는 데 사용됩니다. 이 IP 주소 범위는 Express 경로 또는 사이트 간 VPN 연결을 사용하여 Azure 가상 네트워크에 연결하거나 연결하려는 경우, 모든 온-프레미스 네트워크 범위를 포함하여 네트워크 환경의 다른 곳에서 사용하지 않는 주소 공간이어야 합니다. 기본값은 10.0.0.0/16입니다.
- --dns-service-ip는 선택 사항입니다. 주소는 서비스 IP 주소 범위의 .10 주소여야 합니다. 기본값은 10.0.0.10입니다.
- --pod-cidr은 선택 사항입니다. 이 주소는 네트워크 환경의 다른 곳에서 사용하지 않는 큰 주소 공간이어야 합니다. 여기에는 Express 경로 또는 사이트 간 VPN 연결을 사용하여 Azure 가상 네트워크에 연결하거나 연결하려는 경우, 모든 온-프레미스 네트워크 범위가 포함됩니다. 기본값은 10.244.0.0/16입니다.
  - 이 주소 범위는 확장할 예정인 노드 수를 수용할만큼 충분히 커야 합니다. 클러스터가 배포된 후에는 이 주소 범위를 변경할 수 없습니다.
  - Pod IP 주소 범위를 사용하여 /24 주소 공간을 클러스터의 각 노드에 할당합니다. 다음 예에서 10.244.0.0/16의 -pod-cidr은 첫 번째 노드 10.244.0.0/24, 두 번째 노드 10.244.1.0/24, 세 번째 노드 10.244.2.0/24를 할당합니다.
  - 클러스터가 확장 또는 업그레이드되면 Azure 플랫폼은 새로운 각 노드에 pod IP 주소 범위를 계속 할당합니다.

사용자 할당 관리 ID로 AKS 클러스터 만들기

관리 ID 만들기

az identity 명령을 사용하여 관리 ID를 만듭니다. 기존 관리 ID가 있는 경우 대신 az identity show --ids <identity-resource-id> 명령을 사용하여 주체 ID를 찾습니다.

az identity create --name myIdentity --resource-group myResourceGroup

다음 예와 유사하게 출력됩니다.

{                                  
  "clientId": "<client-id>",
  "clientSecretUrl": "<clientSecretUrl>",
  "id": "/subscriptions/<subscriptionid>/resourcegroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myIdentity", 
  "location": "westus2",
  "name": "myIdentity",
  "principalId": "<principal-id>",
  "resourceGroup": "myResourceGroup",                       
  "tags": {},
  "tenantId": "<tenant-id>",
  "type": "Microsoft.ManagedIdentity/userAssignedIdentities"
}

관리 ID에 대한 역할 할당 추가

Azure CLI를 사용하는 경우 역할이 자동으로 추가되며 이 단계를 건너뛸 수 있습니다. ARM 템플릿 또는 다른 클라이언트를 사용하는 경우 클러스터 관리 ID의 보안 주체 ID를 사용하여 역할 할당을 수행해야 합니다.

az network vnet show 명령을 사용하여 가상 네트워크 리소스 ID를 가져와서 VNET_ID라는 변수로 저장합니다.
```
VNET_ID=$(az network vnet show --resource-group myResourceGroup --name myAKSVnet --query id -o tsv)
```

az role assignment create 명령을 사용하여 가상 네트워크에 대한 AKS 클러스터 네트워크 기여자 권한에 대한 관리 ID를 할당하고 <principalId>를 제공합니다.

az role assignment create --assignee <control-plane-identity-principal-id> --scope $VNET_ID --role "Network Contributor"

# Example command
az role assignment create --assignee 22222222-2222-2222-2222-222222222222 --scope "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/myResourceGroup/providers/Microsoft.Network/virtualNetworks/myAKSVnet" --role "Network Contributor"

참고 항목

Azure에서 사용하는 클러스터의 관리 ID에 부여된 권한을 채우는 데 최대 60분이 걸릴 수 있습니다.

AKS 클러스터 만들기

az aks create 명령을 사용하여 AKS 클러스터를 만들고 assign-identity 인수에 컨트롤 플레인의 관리 ID 리소스 ID를 제공하여 사용자 할당 관리 ID를 할당합니다.

az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --node-count 3 \
    --network-plugin kubenet \
    --vnet-subnet-id $SUBNET_ID \
    --assign-identity <identity-resource-id> \
    --generate-ssh-keys

AKS 클러스터를 만들면 네트워크 보안 그룹 및 경로 테이블이 자동으로 만들어집니다. 이러한 네트워크 리소스는 AKS 컨트롤 플레인이 관리합니다. 네트워크 보안 그룹은 노드의 가상 NIC와 자동으로 연결됩니다. 경로 테이블은 가상 네트워크 서브넷과 자동으로 연결됩니다. 네트워크 보안 그룹 규칙 및 경로 테이블은 서비스를 만들고 노출할 때 자동으로 업데이트됩니다.

kubenet을 사용하여 고유 서브넷 및 경로 테이블 가져오기

kubenet을 사용하는 경우에는 클러스터 서브넷에 경로 테이블이 있어야 합니다. AKS는 사용자 고유의 기존 서브넷 및 경로 테이블을 가져오는 것을 지원합니다. 사용자 지정 서브넷에 경로 테이블이 포함되어 있지 않은 경우 AKS는 사용자를 위해 경로 테이블을 만들고 클러스터 수명 주기에 걸쳐 규칙을 추가합니다. 클러스터를 만들 때 사용자 지정 서브넷에 경로 테이블을 포함하는 경우, AKS는 클러스터 작업 중에 기존 경로 테이블을 승인하고 클라우드 공급자 작업에 적절하게 규칙을 추가/업데이트합니다.

Warning

사용자 지정 경로 테이블에 사용자 지정 규칙을 추가/업데이트할 수 있습니다. 그러나 규칙은 업데이트하거나 제거할 수 없는 Kubernetes 클라우드 공급자에 의해 추가됩니다. 0.0.0.0/0과 같은 규칙은 항상 지정된 경로 테이블에 존재해야 하며 NVA 또는 다른 송신 게이트웨이와 같은 인터넷 게이트웨이의 대상에 매핑되어야 합니다. 규칙을 업데이트할 때는 주의해야 합니다.

사용자 지정 경로 테이블 설정에 대해 자세히 알아보세요.

kubenet 네트워킹에서는 요청을 성공적으로 라우팅하기 위해 구성된 경로 테이블 규칙이 필요합니다. 이러한 디자인으로 인해 경로 테이블은 이를 사용하는 각 클러스터에 대해 신중하게 유지 관리되어야 합니다. 서로 다른 클러스터의 Pod CIDR이 겹쳐 예기치 못한 라우팅 시나리오가 발생할 수 있으므로 여러 클러스터는 경로 테이블을 공유할 수 없습니다. 동일한 가상 네트워크에서 여러 클러스터를 구성하거나 각 클러스터에 가상 네트워크를 전용으로 할당하는 경우 다음 제한 사항을 고려합니다.

AKS 클러스터를 만들기 전에 사용자 지정 경로 테이블을 서브넷에 연결해야 합니다.
클러스터를 만든 후에는 연결된 경로 테이블 리소스를 업데이트할 수 없습니다. 그러나 경로 테이블에서 사용자 지정 규칙을 수정할 수 있습니다.
각 AKS 클러스터는 클러스터와 연결된 모든 서브넷에 대해 고유한 하나의 경로 테이블을 사용해야 합니다. 겹치는 Pod CIDR 및 충돌하는 회람 규칙이 있을 수 있으므로 여러 클러스터에서 경로 테이블을 다시 사용할 수 없습니다.
시스템 할당 관리 ID의 경우 Azure CLI가 자동으로 역할 할당을 추가하므로 Azure CLI를 통해 자체 서브넷 및 경로 테이블을 제공하는 것만 지원됩니다. ARM 템플릿 또는 다른 클라이언트를 사용하는 경우 사용자 할당 관리 ID를 사용하고, 클러스터를 만들기 전에 권한을 할당하며, 사용자 할당 ID에 사용자 지정 서브넷 및 사용자 지정 경로 테이블에 대한 쓰기 권한이 있는지 확인해야 합니다.
여러 AKS 클러스터에서 동일한 경로 테이블을 사용하는 것은 지원되지 않습니다.

참고 항목

kubenet 네트워크 플러그 인을 사용하여 사용자 자체 VNet과 경로 테이블을 만들고 사용하는 경우 클러스터에 대한 사용자가 할당한 관리 ID를 구성해야 합니다. 시스템이 할당한 관리 ID를 사용하면 클러스터를 만들기 전에 ID를 검색할 수 없으므로 역할 할당 중에 지연이 발생합니다.

Azure 네트워크 플러그 인을 사용하여 자체 VNet 및 경로 테이블을 만들고 사용할 때 시스템 할당 및 사용자 할당 관리 ID가 모두 지원됩니다. BYO 시나리오에는 사용자가 할당한 관리 ID를 사용하는 것이 좋습니다.

사용자가 할당한 관리 ID가 있는 경로 테이블을 AKS 클러스터에 추가합니다.

사용자 지정 경로 테이블을 만들고 가상 네트워크의 서브넷과 연결한 후 사용자 지정 관리 ID로 경로 테이블을 할당하는 새 AKS 클러스터를 만들 수 있습니다. AKS 클러스터를 배포하려는 경우에는 서브넷 ID를 사용해야 합니다. 이 서브넷은 사용자 지정 경로 테이블에도 연결되어야 합니다.

az network vnet subnet list 명령을 사용하여 서브넷 ID를 가져옵니다.

az network vnet subnet list --resource-group myResourceGroup --vnet-name myAKSVnet [--subscription]

az aks create 명령을 사용하고 --vnet-subnet-id 및 --assign-identity 매개 변수에 대한 값을 제공하여 경로 테이블로 사전 구성된 사용자 지정 서브넷이 있는 AKS 클러스터를 만듭니다.
```
az aks create \
    --resource-group myResourceGroup \
    --name myManagedCluster \
    --vnet-subnet-id mySubnetIDResourceID \
    --assign-identity controlPlaneIdentityResourceID \
    --generate-ssh-keys
```

다음 단계

이 문서에서는 AKS 클러스터를 기존 가상 네트워크 서브넷에 배포하는 방법을 보여 줍니다. 이제 Helm을 사용하여 새 앱을 만들거나 Helm을 사용하여 기존 앱 배포를 시작할 수 있습니다.

다음을 통해 공유

AKS(Azure Kubernetes Service)에서 사용자 고유의 IP 주소 범위에 kubenet 네트워킹 사용

필수 조건

시작하기 전에

고유한 서브넷을 사용한 Kubenet 네트워킹 개요

Kubenet의 제한 사항 및 고려 사항

IP 주소 가용성 및 고갈

가상 네트워크 피어링 및 ExpressRoute 연결

사용할 네트워크 모델 선택

가상 네트워크 및 서브넷 만들기

가상 네트워크에서 AKS 클러스터 만들기

시스템 할당 관리 ID로 AKS 클러스터 만들기

사용자 할당 관리 ID로 AKS 클러스터 만들기

관리 ID 만들기

관리 ID에 대한 역할 할당 추가

AKS 클러스터 만들기

kubenet을 사용하여 고유 서브넷 및 경로 테이블 가져오기

사용자가 할당한 관리 ID가 있는 경로 테이블을 AKS 클러스터에 추가합니다.

다음 단계

추가 리소스