Wymagania dotyczące planowania adresów IP
Dotyczy: Azure Local, wersja 23H2
Planowanie adresów IP dla usługi AKS włączonej przez usługę Azure Arc obejmuje projektowanie sieci obsługującej aplikacje, pule węzłów, sieci zasobników, komunikację usług i dostęp zewnętrzny. W tym artykule przedstawiono niektóre kluczowe zagadnienia dotyczące efektywnego planowania adresów IP oraz minimalną liczbę adresów IP wymaganych do wdrożenia usługi AKS w środowisku produkcyjnym. Zapoznaj się z pojęciami i wymaganiami dotyczącymi sieci usługi AKS przed przeczytaniem tego artykułu.
Proste planowanie adresów IP dla klastrów i aplikacji Kubernetes
W poniższym scenariuszu przedstawiono rezerwowanie adresów IP z jednej sieci dla klastrów i usług Kubernetes. Ten przykład jest najprostszym i prostym scenariuszem przypisywania adresów IP.
| Wymaganie dotyczące adresu IP | Minimalna liczba adresów IP | Jak i gdzie dokonać tej rezerwacji |
|---|---|---|
| Adresy IP maszyn wirtualnych usługi AKS Arc | Zarezerwuj jeden adres IP dla każdego węzła roboczego w klastrze Kubernetes. Jeśli na przykład chcesz utworzyć 3 pule węzłów z 3 węzłami w każdej puli węzłów, potrzebujesz 9 adresów IP w puli adresów IP. | Zarezerwuj adresy IP za pośrednictwem pul adresów IP w sieci logicznej maszyny wirtualnej usługi Arc. |
| Adresy IP uaktualnienia wersji usługi AKS Arc K8s | Ponieważ usługa AKS Arc wykonuje uaktualnienia stopniowe, zarezerwuj jeden adres IP dla każdego klastra usługi AKS Arc dla operacji uaktualniania wersji platformy Kubernetes. | Zarezerwuj adresy IP za pośrednictwem pul adresów IP w sieci logicznej maszyny wirtualnej usługi Arc. |
| Adres IP płaszczyzny sterowania | Zarezerwuj jeden adres IP dla każdego klastra Kubernetes w środowisku. Jeśli na przykład chcesz utworzyć 5 klastrów w sumie, zarezerwuj 5 adresów IP, po jednym dla każdego klastra Kubernetes. | Zarezerwuj adresy IP za pośrednictwem pul adresów IP w sieci logicznej maszyny wirtualnej usługi Arc. |
| Adresy IP modułu równoważenia obciążenia | Liczba zarezerwowanych adresów IP zależy od modelu wdrażania aplikacji. Jako punkt początkowy można zarezerwować jeden adres IP dla każdej usługi Kubernetes. | Zarezerwuj adresy IP w tej samej podsieci co sieć logiczna maszyny wirtualnej usługi Arc, ale poza pulą adresów IP. |
Przykładowy przewodnik dotyczący rezerwacji adresów IP dla klastrów i aplikacji Kubernetes
Jane jest administratorem IT, który dopiero zaczyna się od usługi AKS włączonej przez usługę Azure Arc. Jane chce wdrożyć dwa klastry Kubernetes: klaster Kubernetes A i klaster Kubernetes B w klastrze lokalnym platformy Azure. Jane chce również uruchomić aplikację do głosowania na szczycie klastra A. Ta aplikacja ma trzy wystąpienia interfejsu użytkownika frontonu uruchomionego w dwóch klastrach i jedno wystąpienie bazy danych zaplecza. Wszystkie klastry i usługi AKS działają w jednej sieci z jedną podsiecią.
- Klaster Kubernetes A ma 3 węzły płaszczyzny sterowania i 5 węzłów roboczych.
- Klaster Kubernetes B ma 1 węzeł płaszczyzny sterowania i 3 węzły robocze.
- 3 wystąpienia interfejsu użytkownika frontonu (port 443).
- 1 wystąpienie bazy danych zaplecza (port 80).
Na podstawie poprzedniej tabeli Jane musi zarezerwować łącznie 19 adresów IP w podsieci Jane:
- 8 adresów IP maszyn wirtualnych węzła usługi A usługi A w węźle usługi A (jeden adres IP na maszynę wirtualną węzła K8s).
- 4 adresy IP maszyn wirtualnych węzła usługi AKS Arc w klastrze B (jeden adres IP na maszynę wirtualną węzła K8s).
- 2 adresy IP do uruchamiania operacji uaktualniania usługi AKS Arc (jeden adres IP na klaster usługi AKS Arc).
- 2 adresy IP płaszczyzny sterowania usługi AKS Arc (jeden adres IP dla klastra usługi AKS Arc)
- 3 adresy IP usługi Kubernetes (jeden adres IP na wystąpienie interfejsu użytkownika frontonu, ponieważ wszystkie używają tego samego portu. Baza danych zaplecza może używać dowolnego z trzech adresów IP, o ile używa innego portu).
Kontynuując ten przykład i dodając go do poniższej tabeli, uzyskasz następujące informacje:
| Parametr | Liczba adresów IP | Jak i gdzie dokonać tej rezerwacji |
|---|---|---|
| Maszyny wirtualne usługi AKS Arc, uaktualnienie wersji K8s i adres IP płaszczyzny sterowania | Zarezerwuj 16 adresów IP | Utwórz tę rezerwację za pośrednictwem pul adresów IP w lokalnej sieci logicznej platformy Azure. |
| Adresy IP modułu równoważenia obciążenia | 3 Adres IP dla usług Kubernetes dla aplikacji do głosowania Jane. | Te adresy IP są używane podczas instalowania modułu równoważenia obciążenia w klastrze A. Możesz użyć rozszerzenia MetalLB Arc lub użyć własnego modułu równoważenia obciążenia innej firmy. Upewnij się, że ten adres IP znajduje się w tej samej podsieci co sieć logiczna usługi Arc, ale poza pulą adresów IP zdefiniowaną w sieci logicznej maszyny wirtualnej arc. |
Przykładowe polecenia interfejsu wiersza polecenia dla rezerwacji adresów IP dla klastrów i aplikacji Kubernetes
W tej sekcji opisano zestaw poleceń, które jane uruchamia dla swojego scenariusza. Najpierw utwórz sieć logiczną z pulą adresów IP, która ma co najmniej 16 adresów IP. Utworzyliśmy pulę adresów IP z 20 adresami IP, aby zapewnić możliwość skalowania w dniu N. Aby uzyskać szczegółowe informacje o opcjach parametrów w sieciach logicznych, zobacz az stack-hci-vm network lnet create:
$ipPoolStart = "10.220.32.18"
$ipPoolEnd = "10.220.32.37"
az stack-hci-vm network lnet create --subscription $subscription --resource-group $resource_group --custom-location $customLocationID --name $lnetName --vm-switch-name $vmSwitchName --ip-allocation-method "Static" --address-prefixes $addressPrefixes --gateway $gateway --dns-servers $dnsServers --ip-pool-start $ipPoolStart --ip-pool-end $ipPoolEnd
Następnie utwórz klaster usługi AKS Arc z poprzednią siecią logiczną:
az aksarc create -n $aksclustername -g $resource_group --custom-location $customlocationID --vnet-ids $lnetName --aad-admin-group-object-ids $aadgroupID --generate-ssh-keys
Teraz możesz włączyć moduł równoważenia obciążenia usługi MetalLB z pulą adresów IP z 3 adresami IP w tej samej podsieci co sieć logiczna maszyny wirtualnej arc. Możesz dodać więcej pul adresów IP później, jeśli aplikacja wymaga zwiększenia. Aby uzyskać szczegółowe wymagania, zobacz Omówienie rozszerzenia MetalLB Arc.
az k8s-runtime load-balancer create --load-balancer-name $lbName --resource-uri subscriptions/$subscription/resourceGroups/$resource_group/providers/Microsoft.Kubernetes/connectedClusters/metallb-demo --addresses 10.220.32.47-10.220.32.49 --advertise-mode ARP
Zagadnienia dotyczące sieciowych dla klastrów usługi AKS i maszyn wirtualnych usługi Arc
Sieci logiczne w usłudze Azure Local są używane zarówno przez klastry usługi AKS, jak i maszyny wirtualne usługi Arc. Sieci logiczne można skonfigurować na jeden z następujących 2 sposobów:
- Współużytkuj sieć logiczną między maszynami wirtualnymi usługi AKS i arc.
- Zdefiniuj oddzielne sieci logiczne dla klastrów usługi AKS i maszyn wirtualnych usługi Arc.
Udostępnianie sieci logicznej między maszynami wirtualnymi AKS i Arc na platformie Azure Local zapewnia korzyści z usprawnionej komunikacji, oszczędności kosztów i uproszczonego zarządzania siecią. Jednak takie podejście wprowadza również potencjalne wyzwania, takie jak rywalizacja o zasoby, zagrożenia bezpieczeństwa i złożoność rozwiązywania problemów.
| Kryteria | Udostępnianie sieci logicznej | Definiowanie oddzielnych sieci logicznych |
|---|---|---|
| Złożoność konfiguracji | Prostsza konfiguracja z jedną siecią, co zmniejsza złożoność konfiguracji. | Bardziej złożona konfiguracja, ponieważ należy skonfigurować wiele sieci logicznych dla maszyn wirtualnych i klastrów usługi AKS. |
| Skalowalność | Potencjalne ograniczenia skalowalności, ponieważ maszyny wirtualne usługi Arc i klastry usługi AKS współdzielą zasoby sieciowe. | Bardziej skalowalne, ponieważ zasoby sieciowe są oddzielone i mogą być skalowane niezależnie. |
| Zarządzanie zasadami sieciowymi | Łatwiejsze zarządzanie jednym zestawem zasad sieciowych, ale trudniejsze do izolowania obciążeń. | Łatwiejsze do izolowania obciążeń, ponieważ można stosować oddzielne zasady dla sieci logicznej. |
| Zagadnienia związane z zabezpieczeniami | Zwiększone ryzyko luk w zabezpieczeniach komunikacji krzyżowej, jeśli nie zostały prawidłowo podzielone na segmenty. | Lepsze zabezpieczenia, ponieważ każda sieć może być segmentowana i izolowana bardziej ściśle. |
| Wpływ awarii sieci | Awaria w sieci udostępnionej może mieć wpływ zarówno na maszyny wirtualne usługi AKS, jak i Arc. | Awaria w jednej sieci wpływa tylko na obciążenia w tej sieci, co zmniejsza ogólne ryzyko. |
Alokacja zakresu adresów IP dla zasobnika CIDR i ciDR usługi
W tej sekcji opisano zakresy adresów IP używane przez platformę Kubernetes do komunikacji zasobnika i usługi w klastrze. Te zakresy adresów IP są definiowane podczas procesu tworzenia klastra usługi AKS i służą do przypisywania unikatowych adresów IP do zasobników i usług w klastrze.
CiDR sieci zasobnika
CiDR sieci zasobnika to zakres adresów IP używanych przez platformę Kubernetes do przypisywania unikatowych adresów IP do poszczególnych zasobników uruchomionych w klastrze Kubernetes. Każdy zasobnik pobiera własny adres IP w tym zakresie, umożliwiając zasobnikom komunikowanie się ze sobą i z usługami w klastrze. W usłudze AKS adresy IP zasobników są przypisywane za pośrednictwem calico CNI w trybie VXLAN. Calico VXLAN pomaga tworzyć sieci nakładki, gdzie adresy IP zasobników (z sieci zasobników CIDR) są zwirtualizowane i tunelowane za pośrednictwem sieci fizycznej. W tym trybie każdy zasobnik ma przypisany adres IP z sieci zasobnika CIDR, ale ten adres IP nie jest bezpośrednio routingiem w sieci fizycznej. Zamiast tego jest hermetyzowany w pakietach sieciowych i wysyłany za pośrednictwem bazowej sieci fizycznej w celu dotarcia do zasobnika docelowego w innym węźle.
Usługa AKS udostępnia wartość domyślną 10.244.0.0/16 dla sieci zasobnika CIDR. Usługa AKS obsługuje dostosowania dla sieci zasobnika CIDR. Możesz ustawić własną wartość przy użyciu parametru --pod-cidr podczas tworzenia klastra usługi AKS. Upewnij się, że zakres adresów IP CIDR jest wystarczająco duży, aby pomieścić maksymalną liczbę zasobników na węzeł i w klastrze Kubernetes.
CiDR sieci usługi
CiDR sieci usługi to zakres adresów IP zarezerwowanych dla usług Kubernetes, takich jak LoadBalancers, ClusterIP i NodePort w klastrze. Platforma Kubernetes obsługuje następujące typy usług:
- ClusterIP: domyślny typ usługi, który uwidacznia usługę w klastrze. Adres IP przypisany z sieci usługi CIDR jest dostępny tylko w klastrze Kubernetes.
- NodePort: uwidacznia usługę na określonym porcie pod adresem IP każdego węzła. KlasterIP jest nadal używany wewnętrznie, ale dostęp zewnętrzny odbywa się za pośrednictwem adresów IP węzła i określonego portu.
- LoadBalancer: ten typ tworzy zarządzany przez dostawcę chmury moduł równoważenia obciążenia i uwidacznia usługę zewnętrznie. Dostawca usług w chmurze zwykle zarządza zewnętrznym przypisaniem adresu IP, podczas gdy wewnętrzny klasterIP pozostaje w sieci usługi CIDR.
Usługa AKS udostępnia wartość domyślną 10.96.0.0/12 dla sieci usługi CIDR. Usługa AKS nie obsługuje obecnie dostosowań ciDR sieci usługi.