Omówienie konfiguracji sieci na potrzeby automatycznej aprowizacji węzłów (NAP) w usłudze Azure Kubernetes Service (AKS)

Ten artykuł zawiera omówienie wymagań dotyczących konfiguracji sieci i zaleceń dotyczących klastrów usługi Azure Kubernetes Service (AKS) przy użyciu automatycznej aprowizacji węzłów (NAP). Obejmuje ona obsługiwane konfiguracje, domyślne zachowanie podsieci, konfigurację kontroli dostępu opartej na rolach (RBAC) oraz zagadnienia dotyczące routingu międzydomenowego bezklasowego (CIDR).

Aby zapoznać się z omówieniem automatycznej aprowizacji węzłów w usłudze AKS, zobacz Omówienie automatycznej aprowizacji węzłów (NAP) w usłudze Azure Kubernetes Service (AKS).

Obsługiwane konfiguracje sieci dla Network Access Protection (NAP)

Oceniając obsługę sieciową dla NAP, należy wziąć pod uwagę tryb zarządzania adresami IP (IPAM), wtyczkę sieciową, płaszczyznę danych sieci oraz zasady sieciowe. W poniższej tabeli opisano opcje obsługiwane przez NAP:

Użyj nakładki Azure CNI z płaszczyzną danych Azure CNI Powered by Cilium. Cilium zapewnia zaawansowane możliwości sieciowe i jest zoptymalizowany pod kątem wydajności z NAP.

Konfiguracje podsieci dla Ochrony Dostępu do Sieci (NAP)

Ustaw opcjonalne pole vnetSubnetID w zasobie AKSNodeClass, aby skonfigurować niestandardową podsieć używaną przez Karpenter do tworzenia węzłów NAP. Jeśli nie określisz parametru vnetSubnetID, Karpenter użyje domyślnej podsieci skonfigurowanej podczas instalacji, która zazwyczaj jest podsiecią określoną przez parametr --vnet-subnet-id podczas tworzenia klastra AKS.

NAP automatycznie wdraża, konfiguruje i zarządza rozwiązaniem Karpenter w klastrze AKS oraz bazuje na projektach open source Karpenter i AKS Karpenter provider.

Zasoby AKSNodeClass w klastrze AKS mogą określać różne vnetSubnetID, co umożliwia stosowanie mieszanych konfiguracji podsieci w pulach węzłów. Klasy węzłów, które nie określają vnetSubnetID , używają domyślnej konfiguracji podsieci klastra.

Zachowanie dryfu podsieci

Karpenter monitoruje zmiany konfiguracji podsieci i wykrywa dryf, gdy vnetSubnetID w AKSNodeClass jest zmodyfikowany. Zrozumienie tego zachowania ma kluczowe znaczenie podczas zarządzania niestandardowymi konfiguracjami sieci.

W przypadku klastrów korzystających z niestandardowej sieci wirtualnej zmiana vnetSubnetID z jednej prawidłowej podsieci na inną powoduje, że istniejące węzły skojarzone z parametrem AKSNodeClass dryfują. Karpenter tworzy węzły zastępcze w nowej podsieci i w kontrolowany sposób wycofuje węzły, które uległy dryfowi, zgodnie z NodePool budżetami zakłóceń.

Przed zmianą vnetSubnetIDupewnij się, że tożsamość klastra ma wymagane uprawnienia w nowej podsieci i że podsieć ma wystarczające dostępne adresy IP dla węzłów zastępczych. Budżety zakłóceń podów i adnotacje karpenter.sh/do-not-disrupt mogą opóźnić dobrowolną wymianę spowodowaną dryfem.

Zakresy CIDR klastra AKS dla NAP

Podczas konfigurowania niestandardowej konfiguracji sieci za pomocą vnetSubnetID musisz rozumieć zakresy CIDR klastra i nimi zarządzać, aby uniknąć konfliktów sieciowych. W przeciwieństwie do tradycyjnych pul węzłów usługi AKS, które tworzy się za pomocą szablonów Azure Resource Manager (ARM), Karpenter używa niestandardowych definicji zasobów (CRD), które natychmiast aprowizują węzły bez rozszerzonej weryfikacji, którą zapewnia ARM.

Zagadnienia dotyczące protokołu CIDR w niestandardowych konfiguracjach podsieci NAP

Podczas konfigurowania vnetSubnetIDprogramu należy wykonać następujące czynności:

• Sprawdź zgodność ciDR: upewnij się, że podsieci niestandardowe nie powodują konfliktu z istniejącymi zakresami CIDR.
• Planowanie pojemności adresów IP: oblicz wymagane adresy IP na potrzeby oczekiwanego skalowania.
• Weryfikowanie łączności: Testowanie tras sieciowych i reguł grupy zabezpieczeń.
• Monitorowanie użycia: śledzenie wykorzystania podsieci i planowanie wzrostu.
• Konfiguracja dokumentacji: utrzymanie zapisów decyzji projektowych sieci.

Typowe konflikty CIDR

Podczas korzystania z niestandardowych podsieci z NAP, należy pamiętać o następujących typowych scenariuszach konfliktów CIDR:

Poniższe przykłady pokazują zakresy CIDR podsieci, które kolidują z zakresami CIDR podów i usług w klastrze, oraz konfigurację, która pozwala uniknąć tych konfliktów. Użyj tych wzorców, aby sprawdzić zakresy podsieci przed skonfigurowaniem vnetSubnetID.

# 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

Konfiguracja RBAC dla niestandardowych ustawień podsieci

W przypadku korzystania z niestandardowych konfiguracji podsieci z NAP należy upewnić się, że Karpenter ma niezbędne uprawnienia do odczytywania informacji o podsieciach i przyłączania węzłów do tych podsieci. Wymaga to skonfigurowania odpowiednich uprawnień RBAC dla tożsamości zarządzanej klastra.

Osoba uruchamiająca następujące polecenia musi mieć uprawnienia do tworzenia wymaganych definicji ról i przypisań ról, takich jak rola Administrator kontroli dostępu opartej na rolach. Nie przyznawaj tożsamości klastra uprawnień do zapisu przypisań ról, chyba że jest to konieczne do tworzenia przypisań ról w innym scenariuszu.

Pobierz identyfikator podmiotu zabezpieczeń tożsamości zarządzanej klastra. Użyj polecenia odpowiadającego typowi tożsamości klastra:

CLUSTER_IDENTITY=$(az aks show \
  --resource-group $RESOURCE_GROUP \
  --name $CLUSTER_NAME \
  --query identity.principalId \
  --output tsv)

CLUSTER_IDENTITY=$(az identity show \
  --resource-group $IDENTITY_RESOURCE_GROUP \
  --name $IDENTITY_NAME \
  --query principalId \
  --output tsv)

Istnieją dwa główne podejścia do konfigurowania tych uprawnień: Przypisywanie uprawnień do szerokiej sieci wirtualnej (VNet) lub Przypisywanie uprawnień podsieci o określonym zakresie.

# 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-object-id $CLUSTER_IDENTITY \
  --assignee-principal-type ServicePrincipal \
  --role "Network Contributor" \
  --scope $VNET_ID

# For each subnet, assign specific subnet permissions
SUBNET_ID="/subscriptions/$SUBSCRIPTION_ID/resourceGroups/$VNET_RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/$VNET_NAME/subnets/$SUBNET_NAME"

# Create custom role definition for subnet access
cat > subnet-access-role.json << EOF
{
  "Name": "Karpenter Subnet Access",
  "IsCustom": true,
  "Description": "Allows reading subnet information and joining VMs to subnets",
  "Actions": [
    "Microsoft.Network/virtualNetworks/subnets/read",
    "Microsoft.Network/virtualNetworks/subnets/join/action"
  ],
  "NotActions": [],
  "DataActions": [],
  "NotDataActions": [],
  "AssignableScopes": [
    "/subscriptions/<subscription-id>"
  ]
}
EOF

# Create the custom role (only needed once per subscription)
az role definition create --role-definition subnet-access-role.json

# Assign the custom role to each subnet
az role assignment create \
  --assignee-object-id $CLUSTER_IDENTITY \
  --assignee-principal-type ServicePrincipal \
  --role "Karpenter Subnet Access" \
  --scope $SUBNET_ID

Przykładowe niestandardowe konfiguracje podsieci

W poniższym przykładzie pokazano, jak skonfigurować niestandardową podsieć dla węzłów NAP przy użyciu pola vnetSubnetID w zasobie AKSNodeClass.

Ustaw w polu spec.vnetSubnetID pełny identyfikator zasobu platformy Azure podsieci docelowej, używając formatu /subscriptions/{subscriptionId}/resourceGroups/{resourceGroup}/providers/Microsoft.Network/virtualNetworks/{vnetName}/subnets/{subnetName}.

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

W poniższym przykładzie pokazano, jak używać wielu klas węzłów z różnymi konfiguracjami podsieci:

apiVersion: karpenter.azure.com/v1beta1
kind: AKSNodeClass
metadata:
  name: frontend-nodes
spec:
  vnetSubnetID: "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/$VNET_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/$VNET_RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/$VNET_NAME/subnets/$BACKEND_SUBNET_NAME"

Polityka wsparcia "przynieś własne CNI" (BYO CNI)

Karpenter dla Azure umożliwia stosowanie własnych konfiguracji interfejsu sieci kontenerów (BYO CNI) i podlega takiej samej polityce wsparcia jak AKS. BYO CNI nie sprawia, że konfiguracja, którą NAP wymienia jako nieobsługiwaną, na przykład kubenet lub Calico, staje się obsługiwana. W przypadku korzystania z niestandardowej sieci CNI rozwiązywanie problemów związanych z siecią jest poza zakresem umów dotyczących poziomu usług lub gwarancji.

Szczegóły zakresu pomocy technicznej

Poniżej opisano, co jest, a co nie jest obsługiwane w przypadku korzystania z BYO CNI z Karpenter:

• Obsługiwane: Problemy z funkcjonalnością i integracją specyficzne dla platformy Karpenter podczas korzystania z konfiguracji CNI bring-your own (BYO).
• Nieobsługiwane: problemy z siecią specyficzną dla sieci CNI, problemy z konfiguracją lub rozwiązywanie problemów podczas korzystania z wtyczek CNI innych firm.

Dalsze kroki

Aby uzyskać więcej informacji o automatycznym aprowizowaniu węzłów w AKS, zobacz następujące artykuły:

• Używanie automatycznej aprowizacji węzłów w niestandardowej sieci wirtualnej
• Konfigurowanie pul węzłów na potrzeby automatycznej aprowizacji węzłów w usłudze AKS
• Konfigurowanie zasad zakłóceń na potrzeby automatycznej aprowizacji węzłów w usłudze AKS