Wdrażanie klastra Kubernetes w niestandardowej sieci wirtualnej w usłudze Azure Stack Hub
Klaster Kubernetes można wdrożyć przy użyciu aparatu Azure Kubernetes Service (AKS) w niestandardowej sieci wirtualnej. Ten artykuł zawiera informacje potrzebne w sieci wirtualnej. Kroki obliczania adresów IP używanych przez klaster można znaleźć, ustawiając wartości w modelu interfejsu API oraz ustawiając tabelę tras i sieciową grupę zabezpieczeń.
Klaster Kubernetes w usłudze Azure Stack Hub przy użyciu aparatu AKS używa wtyczki sieciowej kubenet. Aparat AKS w usłudze Azure Stack Hub obsługuje również wtyczkę sieciową usługi Azure CNI.
- Aby zapoznać się z omówieniem wtyczki sieci kubenet na platformie Azure, zobacz Używanie sieci kubenet z własnymi zakresami adresów IP w usłudze Azure Kubernetes Service (AKS).
- Aby zapoznać się z omówieniem wtyczki sieci azure CNI na platformie Azure, zobacz Konfigurowanie sieci CNI platformy Azure w usłudze Azure Kubernetes Service (AKS).
Ograniczenia podczas tworzenia niestandardowej sieci wirtualnej
- Niestandardowa sieć wirtualna musi znajdować się w tej samej subskrypcji co wszystkie inne składniki klastra Kubernetes.
- Pula węzłów płaszczyzny sterowania i pula węzłów agenta muszą znajdować się w tej samej sieci wirtualnej. Węzły można wdrożyć w różnych podsieciach w tej samej sieci wirtualnej.
- Podsieć klastra Kubernetes musi używać zakresu adresów IP w przestrzeni niestandardowego zakresu adresów IP sieci wirtualnej, zobacz Pobieranie bloku adresów IP.
- Należy wziąć pod uwagę, że zalecany rozmiar podsieci węzłów zależy od typu używanej wtyczki sieciowej. Ogólnie rzecz biorąc, usługa Azure CNI wymaga większej liczby adresów IP dla podsieci obsługującej pule węzłów agenta niż kubenet. Zapoznaj się z poniższymi przykładami kubenet i Azure CNI .
-
169.254.0.0/16
Przestrzeń adresowa może nie być używana dla niestandardowych sieci wirtualnych dla klastrów Kubernetes.
Tworzenie niestandardowej sieci wirtualnej
W wystąpieniu usługi Azure Stack Hub musisz mieć niestandardową sieć wirtualną. Aby uzyskać więcej informacji, zobacz Szybki start: tworzenie sieci wirtualnej przy użyciu Azure Portal.
Utwórz nową podsieć w sieci wirtualnej. Musisz uzyskać identyfikator zasobu podsieci i zakres adresów IP. Podczas wdrażania klastra użyjesz identyfikatora zasobu i zakresu w modelu interfejsu API.
Otwórz portal użytkowników usługi Azure Stack Hub w wystąpieniu usługi Azure Stack Hub.
Wybierz pozycję Wszystkie zasoby.
Wprowadź nazwę sieci wirtualnej w polu wyszukiwania.
Wybierz pozycję Podsieci+ Podsieci, aby dodać podsieć>.
Dodaj nazwę i zakres adresów przy użyciu notacji CIDR. Wybierz przycisk OK.
Wybierz pozycję Właściwości w bloku Sieci wirtualne . Skopiuj identyfikator zasobu, a następnie dodaj polecenie
/subnets/<nameofyoursubnect>
. Ta wartość będzie używana jako wartośćvnetSubnetId
klucza w modelu interfejsu API dla klastra. Identyfikator zasobu dla podsieci używa następującego formatu:/subscriptions/SUB_ID/resourceGroups/RG_NAME/providers/Microsoft.Network/virtualNetworks/VNET_NAME/subnets/SUBNET_NAME
Wybierz pozycję Podsieci w bloku Sieci wirtualne . Wybierz nazwę podsieci, na przykład
control-plane-sn
.Nie kojarzyj podsieci z sieciową grupą zabezpieczeń.
W bloku podsieci zanotuj zakres adresów (CIDR Block) każdej podsieci.
Zagadnienia dotyczące wybierania przestrzeni adresowej
Podczas tworzenia niestandardowej sieci wirtualnej należy określić przestrzeń adresów IP sieci i zakres adresów IP dla każdej podsieci. Podczas wybierania przestrzeni adresowych i zakresów do użycia w klastrze Kubernetes należy wziąć pod uwagę następujące czynniki:
- Nakładające się przestrzenie adresowe mogą powodować konflikty adresów IP lub błędy komunikacji. Aby zmniejszyć ryzyko nakładania się adresów IP, wybierz unikatową przestrzeń adresową dla nowej sieci wirtualnej.
- Przestrzenie adresowe w
10/8
zakresach ,172.16/12
i192.168/16
często są używane dla sieci prywatnych i mogą być używane przez istniejącą infrastrukturę centrum danych. Jeśli aplikacje Kubernetes używają zasobów w centrum danych, zmniejsz ryzyko starć, wybierając przestrzeń adresową dla niestandardowej sieci wirtualnej, która różni się od przestrzeni adresowej centrum danych. - Zalecamy użycie dedykowanej podsieci dla klastra Kubernetes.
- Jeśli używasz wielu istniejących sieci wirtualnych, rozważ użycie różnych przestrzeni adresowych w każdej sieci, jeśli zamierzasz używać komunikacji równorzędnej sieci wirtualnych. Nakładające się przestrzenie adresowe mogą osłabić zdolność komunikacji równorzędnej.
Pobieranie bloków adresów IP
Aparat usługi AKS obsługuje wdrażanie w istniejącej sieci wirtualnej. Podczas wdrażania w istniejącej sieci wirtualnej klaster używa bloków kolejnych adresów dla węzłów agenta, węzłów płaszczyzny sterowania, usług klastra i kontenerów (zasobników). Każdy blok adresów można przetłumaczyć na podsieć w sieci wirtualnej. Wszystkie bloki adresów we wdrożeniu klastra muszą być częścią ogólnej przestrzeni adresowej sieci wirtualnej. Wybranie bloków adresów spoza przestrzeni adresowej sieci wirtualnej może spowodować problemy z łącznością.
Podczas konfigurowania klastra Kubernetes wymagane są co najmniej trzy bloki adresów:
- Blok adresów węzłów: jest to blok adresu używany do przypisywania adresów do węzłów klastra. Może to być pojedynczy blok adresowy dla wszystkich węzłów klastra lub może być oddzielnymi blokami (podsieci) dla płaszczyzny sterowania i pul agentów. Podczas wybierania zakresu adresów dla tego bloku należy wziąć pod uwagę liczbę węzłów w klastrze. W przypadku węzłów i kontenerów usługi Azure CNI pobierają swoje adresy z tego samego bloku adresów, dlatego uwzględniają liczbę kontenerów, które chcesz wdrożyć w klastrze podczas wybierania zakresu adresów podczas korzystania z usługi Azure CNI.
- Blok adresów usług: jest to blok adresu, z którego usługi wdrożone w klastrze Kubernetes otrzymają adres klastra. Podczas wybierania zakresu adresów dla tego bloku należy wziąć pod uwagę maksymalną liczbę usług, które mają być uruchamiane w klastrze.
- Blok adresów klastra: jest to blok adresu, z którego zasobniki otrzymają adres klastra. Podczas wybierania zakresu adresów dla tego bloku należy wziąć pod uwagę maksymalną liczbę zasobników, które mają być uruchamiane w klastrze. Jak wspomniano wcześniej, w przypadku usługi Azure CNI bloki adresów klastra i węzłów są takie same.
Oprócz bloków adresów w przypadku węzłów płaszczyzny sterowania należy ustawić dwie kolejne wartości. Musisz znać liczbę adresów IP, które należy zarezerwować dla klastra, oraz pierwszy kolejny statyczny adres IP w przestrzeni IP podsieci. Aparat usługi AKS wymaga zakresu do 16 nieużywanych adresów IP w przypadku korzystania z wielu węzłów płaszczyzny sterowania. Klaster będzie używać jednego adresu IP dla każdej płaszczyzny sterowania do pięciu węzłów płaszczyzny sterowania. Aparat usługi AKS będzie również wymagać następnego 10 adresu IP po ostatnim węźle płaszczyzny sterowania dla rezerwacji adresów IP pomieszczenia głównego. Na koniec inny adres IP będzie używany przez moduł równoważenia obciążenia po węzłach płaszczyzny sterowania i rezerwacji przestrzeni głównej w sumie 16. Podczas umieszczania bloku adresów IP podsieć wymaga następujących alokacji istniejących adresów IP:
- Pierwsze cztery adresy IP i ostatni adres IP są zarezerwowane i nie można ich używać w żadnej podsieci platformy Azure.
- Bufor 16 adresów IP powinien zostać otwarty.
- Wartość pierwszego adresu IP klastra powinna znajdować się na końcu przestrzeni adresowej, aby uniknąć konfliktów adresów IP. Jeśli to możliwe, przypisz
firstConsecutiveStaticIP
właściwość do adresu IP w pobliżu końca dostępnej przestrzeni adresowej IP w podsieci.
Na przykład w przypadku klastra z trzema węzłami płaszczyzny sterowania. Jeśli używasz podsieci z 256 adresami, na przykład 10.100.0.0/24, musisz ustawić pierwszy kolejny statyczny adres IP przed 239. W poniższej tabeli przedstawiono adresy i zagadnienia:
Zakres podsieci /24 | Liczba | Uwaga |
---|---|---|
172.100.0.0 - 172.100.0.3 | 4 | Zarezerwowane w podsieci platformy Azure. |
172.100.0.224-172.100.0.238 | 14 | Liczba adresów IP dla klastra zdefiniowanego przez aparat usługi AKS. 3 adresy IP dla 3 węzłów płaszczyzny sterowania 10 adresów IP dla miejsca pracy 1 adres IP modułu równoważenia obciążenia |
172.100.0.238 - 172.100.0.254 | 16 | 16 Bufor adresów IP. |
172.100.0.255 | 1 | Zarezerwowane w podsieci platformy Azure. |
W tym przykładzie firstConsecutiveStaticIP
właściwość to 172.100.0.224
.
W przypadku większych podsieci, na przykład /16 z ponad 60 tysięcy adresów, nie można znaleźć praktycznego ustawienia statycznych przypisań adresów IP na końcu przestrzeni sieciowej. Ustaw zakres statycznych adresów IP klastra z dala od pierwszych 24 adresów w przestrzeni ip, aby klaster mógł być odporny podczas oświadczeń adresów.
Przykład bloków adresów kubenet
W poniższym przykładzie można zobaczyć, jak te różne zagadnienia wypełniają przestrzeń adresową w sieci wirtualnej klastra przy użyciu wtyczki sieci kubenet z dedykowanymi podsieciami dla węzła płaszczyzny sterowania i pul węzłów agenta z trzema węzłami na pulę.
Przestrzeń adresowa sieci wirtualnej: 10.100.0.0/16.
Blok adresu (podsieć) | CIDR | Zakres adresów IP | Liczba adresów IP (dostępna) |
---|---|---|---|
Blok węzłów płaszczyzny sterowania | 10.100.0.0/24 | 10.100.0.0 - 10.100.0.255 | 255 – 4 zarezerwowane = 251 |
Blok węzłów agenta | 10.100.1.0/24 | 10.100.1.0 - 10.100.1.255 | 255 – 4 zarezerwowane = 251 |
Blok usług | 10.100.16.0/20 | 10.100.16.0 - 10.100.31.255 | 4096 - 5 zarezerwowane = 4091 |
Blok klastra | 10.100.128.0/17 | 10.100.128.0 - 10.100.255.255 | 32 768 - 5 zarezerwowane = 32 763 |
W tym przykładzie firstConsecutiveStaticIP
właściwość to 10.100.0.239
.
Przykład bloków adresów CNI platformy Azure
W poniższym przykładzie można zobaczyć, jak te różne zagadnienia wypełniają przestrzeń adresową w sieci wirtualnej klastra przy użyciu wtyczki sieci azure CNI z dedykowanymi podsieciami dla płaszczyzny sterowania i pul węzłów agenta z trzema węzłami na pulę.
Przestrzeń adresowa sieci wirtualnej: 172.24.0.0/16.
Uwaga
W twoim środowisku, jeśli publiczny zakres adresów IP znajduje się w obrębie ciDR10.0.0.0/8, użyj rozwiązania kubenet jako wtyczki sieciowej.
Blok adresu (podsieć) | CIDR | Zakres adresów IP | Liczba adresów IP (dostępna) |
---|---|---|---|
Blok węzłów płaszczyzny sterowania | 172.24.0.0/24 | 172.24.0.0 - 172.24.0.255 | 255 – 4 zarezerwowane = 251 |
Węzły agenta & bloku klastra | 172.24.128.0/17 | 172.24.128.0 - 172.24.255.255 | 32 768 - 5 zarezerwowane = 32 763 |
Blok usług | 172.24.16.0/20 | 172.24.16.0 - 172.24.31.255 | 4096 - 5 zarezerwowane = 4091 |
W tym przykładzie firstConsecutiveStaticIP
właściwość to 172.24.0.239
.
Aktualizowanie modelu interfejsu API
Zaktualizuj model interfejsu API używany do wdrażania klastra z aparatu AKS w niestandardowej sieci wirtualnej.
W pliku masterProfile ustaw następujące wartości:
Pole | Przykład | Opis |
---|---|---|
vnetSubnetId | /subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MDBN-K8S/providers/Microsoft.Network/virtualNetworks/MDBN-K8S/subnets/control-plane-sn |
Określ ścieżkę usługi Azure Resource Manager o identyfikatorze podsieci. Ta wartość mapuje blok adresowy węzłów płaszczyzny sterowania powyżej. |
firstConsecutiveStaticIP | 10.100.0.239 | Przypisz do firstConsecutiveStaticIP właściwości konfiguracji adres IP, który znajduje się blisko końca dostępnej przestrzeni adresowej IP w żądanej podsieci.
firstConsecutiveStaticIP dotyczy tylko puli węzłów płaszczyzny sterowania. |
W pliku agentPoolProfile ustaw następujące wartości:
Pole | Przykład | Opis |
---|---|---|
vnetSubnetId | /subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MDBN-K8S/providers/Microsoft.Network/virtualNetworks/MDBN-K8S/subnets/agents-sn |
Określ ścieżkę usługi Azure Resource Manager o identyfikatorze podsieci. Ta wartość jest mapowania na blok adresów węzłów agenta powyżej. |
W pliku orchestratorProfile znajdź plik kubernetesConfig i ustaw następującą wartość:
Pole | Przykład | Opis |
---|---|---|
clusterSubnet | 10.100.128.0/17 |
Podsieć IP używana do przydzielania adresów IP dla interfejsów sieciowych zasobnika. Ta wartość jest mapowa na blok adresów klastra powyżej. Podsieć musi znajdować się w przestrzeni adresowej sieci wirtualnej. Po włączeniu usługi Azure CNI wartość domyślna to 10.240.0.0/12. Bez usługi Azure CNI wartość domyślna to 10.244.0.0/16. Użyj /16 zamiast /24 podsieci. Jeśli używasz /24, ta podsieć zostanie przypisana tylko do jednego węzła. Inny węzeł nie otrzyma przypisanej sieci ZASOBnika, ponieważ zabraknie miejsca na adres IP, więc nie będą gotowe w klastrze. |
serviceCidr | 10.100.16.0/20 |
Podsieć IP używana do przydzielania adresów IP dla usług wdrożonych w klastrze. Ta wartość jest mapowania na blok usług klastra powyżej. |
dnsServiceIP | 10.100.16.10 |
Adres IP, który ma zostać przypisany do usługi DNS klastra. Adres musi pochodzić z podsieci serviceCidr. Tę wartość należy ustawić podczas określania wartości serviceCidr. Wartość domyślna to adres 10 podsieci serviceCidr. |
Jeśli na przykład używasz rozwiązania kubenet:
Z przestrzenią adresową sieci, w 10.100.0.0/16
której znajduje 10.100.0.0/24
się podsieć i control-plane-sn
agents-sn
jest10.100.1.0/24
"masterProfile": {
...
"vnetSubnetId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MDBN-K8S/providers/Microsoft.Network/virtualNetworks/MDBN-K8S/subnets/control-plane-sn",
"firstConsecutiveStaticIP": "10.100.0.239",
...
},
...
"agentPoolProfiles": [
{
...
"vnetSubnetId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MDBN-K8S/providers/Microsoft.Network/virtualNetworks/MDBN-K8S/subnets/agents-sn",
...
},
...
"kubernetesConfig": [
{
...
"clusterSubnet": "10.100.128.0/17",
"serviceCidr": "10.100.16.0/20",
"dnsServiceIP" : "10.100.16.10",
...
},
Jeśli na przykład używasz usługi Azure CNI:
Z przestrzenią adresową sieci, w 172.24.0.0/16
której znajduje 172.24.0.0/24
się podsieć i control-plane-sn
k8s-sn
jest172.24.128.0/17
"masterProfile": {
...
"vnetSubnetId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MDBN-K8S/providers/Microsoft.Network/virtualNetworks/MDBN-K8S/subnets/control-plane-sn",
"firstConsecutiveStaticIP": "172.24.0.239",
...
},
...
"agentPoolProfiles": [
{
...
"vnetSubnetId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MDBN-K8S/providers/Microsoft.Network/virtualNetworks/MDBN-K8S/subnets/k8s-sn",
...
},
...
"kubernetesConfig": [
{
...
"clusterSubnet": "172.24.128.0/17",
"serviceCidr": "172.24.16.0/20",
"dnsServiceIP" : "172.24.16.10",
...
},
Wdrażanie klastra
Po dodaniu wartości do modelu interfejsu API można wdrożyć klaster z maszyny klienckiej przy użyciu deploy
polecenia w aks engine. Aby uzyskać instrukcje, zobacz Wdrażanie klastra Kubernetes.
Ustawianie tabeli tras
Jeśli używasz rozwiązania kubenet, na przykład : networkPlugin
kubenet
w obiekcie konfiguracji modelu interfejsu kubernetesConfig
API. Po wdrożeniu klastra wróć do sieci wirtualnej w portalu użytkowników usługi Azure Stack. Ustaw zarówno tabelę tras, jak i sieciową grupę zabezpieczeń w bloku podsieci. Po pomyślnym wdrożeniu klastra w niestandardowej sieci wirtualnej pobierz identyfikator zasobu Tabela tras z bloku Sieć w grupie zasobów klastra.
Otwórz portal użytkowników usługi Azure Stack Hub w wystąpieniu usługi Azure Stack Hub.
Wybierz pozycję Wszystkie zasoby.
Wprowadź nazwę sieci wirtualnej w polu wyszukiwania.
Wybierz pozycję Podsieci , a następnie wybierz nazwę podsieci zawierającej klaster.
Wybierz pozycję Tabela tras , a następnie wybierz tabelę tras dla klastra.
Upewnij się, że jest to wykonywane dla każdej podsieci określonej w modelu interfejsu API, w tym podsieci
masterProfile
.
Uwaga
Niestandardowa sieć wirtualna dla klastra Kubernetes systemu Windows ma znany problem.
Następne kroki
- Przeczytaj o aks engine w usłudze Azure Stack Hub
- Przeczytaj o usłudze Azure Monitor dla kontenerów — omówienie