Udostępnij przez

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)

NAP obsługuje następujące konfiguracje sieciowe:

Zalecamy używanie Azure CNI z Cilium. Cilium zapewnia zaawansowane możliwości sieciowe i jest zoptymalizowany pod kątem wydajności z NAP.

Nieobsługiwane konfiguracje sieciowe dla NAP

NAP (Ochrona dostępu do sieci) nie obsługuje następujących konfiguracji sieci:

  • Zasady sieci Calico
  • Dynamiczna alokacja adresów IP

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

NAP automatycznie wdraża, konfiguruje i zarządza Karpenterem na klastrach AKS i opiera się na projektach open source Karpenter oraz dostawcy AKS Karpenter. Za pomocą zasobów AKSNodeClass można określić niestandardowe konfiguracje podsieci dla węzłów NAP w pulach węzłów, ustawiając opcjonalne pole vnetSubnetID, a Karpenter używa podanej podsieci do tworzenia węzłów. Jeśli nie określisz podsieci, Firma Karpenter używa domyślnej podsieci skonfigurowanej podczas instalacji Karpenter. Ta domyślna podsieć jest zazwyczaj tą samą podsiecią, która została określona podczas tworzenia klastra AKS za pomocą parametru --vnet-subnet-id w poleceniu az aks create.

Takie podejście umożliwia łączenie różnych klas węzłów; niektóre korzystają z niestandardowych podsieci dla określonych obciążeń, a inne z 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.

Modyfikowanie vnetSubnetID z jednej prawidłowej podsieci do innej prawidłowej podsieci nie jest obsługiwaną operacją. Jeśli zmienisz vnetSubnetID tak, aby wskazywało na inną prawidłową podsieć, Karpenter wykryje to jako dryf podsieci i zablokuje aprowizowanie węzłów, dopóki problem nie zostanie rozwiązany poprzez przywrócenie vnetSubnetID do oryginalnej podsieci. Takie zachowanie zapewnia, że węzły są przydzielane tylko w zamierzonych podsieciach, zachowując integralność i bezpieczeństwo sieci. Istnieją jednak wyjątki od tej reguły. Można modyfikować vnetSubnetID tylko w następujących scenariuszach:

  • Poprawianie źle sformułowanego identyfikatora podsieci, który uniemożliwia udostępnianie węzłów.
  • Naprawianie nieprawidłowego odwołania do podsieci, które powoduje błędy konfiguracji.
  • Aktualizowanie identyfikatora podsieci wskazującego na nieistniejącą lub niedostępną podsieć.

Zrozumienie zakresów CIDR (Classless Inter-Domain Routing) klastra AKS

Podczas konfigurowania sieci niestandardowej za pomocą vnetSubnetID, odpowiadasz za zrozumienie zakresów CIDR klastra i zarządzanie nimi, aby uniknąć konfliktów sieci. W przeciwieństwie do tradycyjnych pul węzłów usługi AKS utworzonych za pomocą szablonów usługi ARM, Firma Karpenter stosuje niestandardowe definicje zasobów (CRD), które umożliwiają natychmiastowe aprowizowanie węzłów bez rozszerzonej weryfikacji zapewnianej przez usługę ARM.

Zagadnienia dotyczące CIDR w niestandardowych konfiguracjach podsieci

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:

# 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.

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.

To podejście jest najbardziej liberalne i przyznaje tożsamości klastra uprawnienia do odczytu i połączenia się z dowolną podsiecią w głównej sieci wirtualnej, i zapewnia dostęp jako współautor sieci.

Ważne

Przed zastosowaniem tego podejścia do klastra produkcyjnego zbadaj rolę "Współautor sieci".

Korzyści i zagadnienia

W poniższej tabeli przedstawiono korzyści i zagadnienia dotyczące przypisywania szerokich uprawnień sieci wirtualnej:

Korzyści Rozważania
• Upraszcza zarządzanie uprawnieniami.
• Eliminuje konieczność aktualizowania uprawnień podczas dodawania nowych podsieci.
• Dobrze sprawdza się w środowiskach jednolokatorskich.
• Funkcje, gdy subskrypcja osiągnie maksymalną liczbę ról niestandardowych.		 • Zapewnia szersze uprawnienia niż ściśle wymagane.
• Może nie spełniać rygorystycznych wymagań dotyczących zabezpieczeń.

Wymagane uprawnienia

Aby przypisać szerokie uprawnienia sieci wirtualnej, przyznaj tożsamości zarządzanej klastra następujące uprawnienia w sieci wirtualnej:

# 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

Pełny przykład konfigurowania sieci niestandardowej i przypisywania szerokich uprawnień dla sieci wirtualnej można znaleźć w przykładowym skrypcie ustalania niestandardowej sieci wirtualnej – najbardziej liberalne uprawnienia RBAC.

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.

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"

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/$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"

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

Platforma Karpenter dla platformy Azure umożliwia korzystanie z własnych konfiguracji interfejsu sieciowego kontenera (BYO CNI), zgodnie z tymi samymi zasadami pomocy technicznej co usługa AKS. Oznacza to, że w przypadku korzystania z niestandardowej sieci CNI rozwiązywanie problemów związanych z siecią jest poza zakresem wszelkich 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:

  • Last updated on