다음을 통해 공유

AKS(Azure Kubernetes Service)의 NAP(노드 자동 프로비저닝)에 대한 네트워킹 구성 개요

이 문서에서는 NAP(노드 자동 프로비저닝)를 사용하는 AKS(Azure Kubernetes Service) 클러스터에 대한 네트워킹 구성 요구 사항 및 권장 사항에 대한 개요를 제공합니다. 지원되는 구성, 기본 서브넷 동작, RBAC(역할 기반 액세스 제어) 설정 및 CIDR(클래스리스 도메인 간 라우팅) 고려 사항을 다룹니다.

AKS의 노드 자동 프로비저닝에 대한 개요는 AKS(Azure Kubernetes Service)의 NAP(노드 자동 프로비저닝) 개요를 참조하세요.

NAP에 지원되는 네트워킹 구성

NAP는 다음과 같은 네트워킹 구성을 지원합니다.

Cilium과 함께 Azure CNI를 사용하는 것이 좋습니다. Cilium은 고급 네트워킹 기능을 제공하며 NAP를 사용한 성능에 최적화되어 있습니다.

NAP에 대한 지원되지 않는 네트워킹 구성

NAP는 다음 네트워킹 구성을 지원하지 않습니다.

  • Calico 네트워크 정책
  • 동적 IP 할당

NAP에 대한 서브넷 구성

NAP는 AKS 클러스터에서 Karpenter를 자동으로 배포, 구성 및 관리하며 오픈 소스 Karpenter 및 AKS Karpenter 공급자 프로젝트를 기반으로 합니다. 리소스를 사용하여 AKSNodeClass 선택적 vnetSubnetID 필드를 설정하여 노드 풀에서 NAP 노드에 대한 사용자 지정 서브넷 구성을 지정할 수 있으며, Karpenter는 노드 프로비전에 지정한 서브넷을 사용합니다. 서브넷을 지정하지 않으면 Karpenter는 Karpenter 설치 중에 구성된 기본 서브넷을 사용합니다. 이 기본 서브넷은 일반적으로 명령의 매개 변수 --vnet-subnet-id 를 az aks create 사용하여 AKS 클러스터를 만드는 동안 지정된 동일한 서브넷입니다.

이 방법을 사용하면 노드 클래스를 혼합할 수 있으며, 일부는 특정 워크로드에 사용자 지정 서브넷을 사용하고 다른 일부는 클러스터의 기본 서브넷 구성을 사용할 수 있습니다.

서브넷 드리프트 동작

Karpenter는 서브넷 구성 변경을 모니터링하고, AKSNodeClass에서 vnetSubnetID이 수정될 때 드리프트를 감지합니다. 사용자 지정 네트워킹 구성을 관리할 때는 이 동작을 이해하는 것이 중요합니다.

vnetSubnetID 한 유효한 서브넷에서 다른 유효한 서브넷으로 수정하는 작업은 지원되지 않습니다. 다른 유효한 서브넷을 가리키도록 vnetSubnetID을(를) 변경하면 Karpenter는 이를 서브넷 드리프트로 감지하고, vnetSubnetID을(를) 원래 서브넷으로 되돌릴 때까지 노드 프로비저닝을 방지합니다. 이 동작은 노드가 의도한 서브넷에서만 프로비전되어 네트워크 무결성 및 보안을 유지하도록 합니다. 그러나 이 규칙에는 예외가 있습니다. 다음 시나리오에서만 vnetSubnetID 수정할 수 있습니다.

  • 노드 프로비저닝을 방지하는 잘못된 형식의 서브넷 ID 수정
  • 구성 오류를 발생시키는 잘못된 서브넷 참조를 수정합니다.
  • 존재하지 않거나 액세스할 수 없는 서브넷을 가리키는 서브넷 식별자를 업데이트합니다.

AKS 클러스터 CIDR(클래스리스 Inter-Domain 라우팅) 범위 이해

사용자 지정 네트워킹을 vnetSubnetID구성할 때 네트워크 충돌을 방지하기 위해 클러스터의 CIDR 범위를 이해하고 관리해야 합니다. ARM 템플릿을 통해 만든 기존 AKS 노드 풀과 달리 Karpenter는 ARM에서 제공하는 확장된 유효성 검사 없이 노드를 즉시 프로비전하는 CRD(사용자 지정 리소스 정의)를 적용합니다.

사용자 지정 서브넷 구성에 대한 CIDR 고려 사항

vnetSubnetID을(를) 구성할 때 다음을 수행해야 합니다.

  • CIDR 호환성 확인: 사용자 지정 서브넷이 기존 CIDR 범위와 충돌하지 않도록 합니다.
  • IP 용량 계획: 예상 크기 조정에 필요한 IP 주소를 계산합니다.
  • 연결 유효성 검사: 네트워크 경로 및 보안 그룹 규칙을 테스트합니다.
  • 사용량 모니터링: 서브넷 사용률을 추적하고 성장을 계획합니다.
  • 문서 구성: 네트워크 디자인 결정의 레코드를 유지 관리합니다.

일반적인 CIDR 충돌

NAP에서 사용자 지정 서브넷을 사용하는 경우 다음과 같은 일반적인 CIDR 충돌 시나리오에 유의하세요.

# Example conflict scenarios:
# Cluster Pod CIDR: 10.244.0.0/16  
# Custom Subnet:   10.244.1.0/24  ❌ CONFLICT

# Service CIDR:    10.0.0.0/16
# Custom Subnet:   10.0.10.0/24   ❌ CONFLICT

# Safe configuration:
# Cluster Pod CIDR: 10.244.0.0/16
# Service CIDR:     10.0.0.0/16  
# Custom Subnet:    10.1.0.0/24   ✅ NO CONFLICT

사용자 지정 서브넷 구성에 대한 RBAC 설정

NAP에서 사용자 지정 서브넷 구성을 사용하는 경우 Karpenter가 서브넷 정보를 읽고 노드를 지정된 서브넷에 조인하는 데 필요한 권한이 있는지 확인해야 합니다. 이렇게 하려면 클러스터의 관리 ID에 대한 적절한 RBAC 권한을 설정해야 합니다.

이러한 권한을 설정하는 두 가지 주요 방법은 VNet(광범위한 가상 네트워크) 권한 할당 또는 범위가 지정된 서브넷 사용 권한 할당입니다.

이 방법은 가장 관대하며 기본 VNet 내에서 서브넷을 읽고 조인할 수 있는 클러스터 ID 권한을 부여하고 네트워크 기여자 액세스를 제공합니다.

중요합니다

프로덕션 클러스터에 이 방법을 적용하기 전에 "네트워크 기여자" 역할을 조사합니다.

이점 및 고려 사항

다음 표에서는 광범위한 VNet 권한을 할당할 때의 이점과 고려 사항을 간략하게 설명합니다.

혜택 고려 사항
• 권한 관리를 간소화합니다.
• 새 서브넷을 추가할 때 사용 권한을 업데이트할 필요가 없습니다.
• 단일 테넌트 환경에 적합합니다.
• 구독이 최대 사용자 지정 역할 수에 도달하면 작동합니다.		 • 엄격하게 필요한 것보다 더 광범위한 권한을 제공합니다.
• 엄격한 보안 요구 사항을 충족하지 못할 수 있습니다.

필요한 권한

광범위한 VNet 권한을 할당하려면 클러스터의 관리 ID에 VNet에 대해 다음 권한을 부여합니다.

# Get your cluster's managed identity
CLUSTER_IDENTITY=$(az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --query identity.principalId -o tsv)

# Get your VNet resource ID
VNET_ID="/subscriptions/$SUBSCRIPTION_ID/resourceGroups/$VNET_RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/$VNET_NAME"

# Assign Network Contributor role for subnet read/join operations
az role assignment create \
  --assignee $CLUSTER_IDENTITY \
  --role "Network Contributor" \
  --scope $VNET_ID

사용자 지정 네트워킹을 설정하고 광범위한 VNet 권한을 할당하는 전체 예제는 사용자 지정 VNET 설정 - 가장 허용되는 RBAC 샘플 스크립트를 참조하세요.

사용자 지정 서브넷 구성 예제

다음 예제에서는 vnetSubnetID 필드를 리소스의 AKSNodeClass에 사용하여 NAP 노드에 대한 사용자 지정 서브넷을 구성하는 방법을 보여줍니다.

apiVersion: karpenter.azure.com/v1beta1
kind: AKSNodeClass
metadata:
  name: custom-networking
spec:
  vnetSubnetID: "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/$RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/$VNET_NAME/subnets/$SUBNET_NAME"

다음 예제에서는 여러 서브넷 구성에서 여러 노드 클래스를 사용하는 방법을 보여 줍니다.

apiVersion: karpenter.azure.com/v1beta1
kind: AKSNodeClass
metadata:
  name: frontend-nodes
spec:
  vnetSubnetID: "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/$RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/$VNET_NAME/subnets/$FRONTEND_SUBNET_NAME"
---
apiVersion: karpenter.azure.com/v1beta1
kind: AKSNodeClass
metadata:
  name: backend-nodes
spec:
  vnetSubnetID: "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/$RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/$VNET_NAME/subnets/$BACKEND_SUBNET_NAME"

자체 CNI(BYO CNI) 지원 정책

Azure용 Karpenter를 사용하면 AKS와 동일한 지원 정책에 따라 BYO CNI(컨테이너 네트워크 인터페이스) 구성을 가져올 수 있습니다. 즉, 사용자 지정 CNI를 사용하는 경우 네트워킹과 관련된 문제 해결 지원은 서비스 수준 계약 또는 보증의 범위를 벗어집니다.

지원 범위 세부 정보

다음은 Karpenter와 함께 BYO CNI를 사용할 때 지원되는 내용과 지원되지 않는 사항을 간략하게 설명합니다.

  • 지원됨: BYO(Bring-your-own) CNI 구성을 사용하는 경우 Karpenter 관련 기능 및 통합 문제
  • 지원되지 않음: 타사 CNI 플러그 인을 사용하는 경우 CNI 관련 네트워킹 문제, 구성 문제 또는 문제 해결.

다음 단계

AKS의 노드 자동 프로비저닝에 대한 자세한 내용은 다음 문서를 참조하세요.

  • Last updated on