Udostępnij za pośrednictwem


Wdrażanie klastra Kubernetes w niestandardowej sieci wirtualnej w usłudze Azure Stack Hub

Klaster Kubernetes można wdrożyć przy użyciu aparatu usługi Azure Kubernetes Service (AKS) w niestandardowej sieci wirtualnej. W tym artykule omówiono znajdowanie potrzebnych informacji 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.

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 Uzyskiwanie 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 .
  • Przestrzeń adresowa 169.254.0.0/16 może nie być używana dla niestandardowych sieci wirtualnych dla klastrów Kubernetes.

Tworzenie niestandardowej sieci wirtualnej

Musisz mieć niestandardową sieć wirtualną w wystąpieniu usługi Azure Stack Hub. Aby uzyskać więcej informacji, zobacz Szybki start: tworzenie sieci wirtualnej przy użyciu witryny 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.

  1. Otwórz portal użytkowników usługi Azure Stack Hub w wystąpieniu usługi Azure Stack Hub.

  2. Wybierz pozycję Wszystkie zasoby.

  3. Wprowadź nazwę sieci wirtualnej w polu wyszukiwania.

  4. Wybierz pozycję Podsieci+ Podsieci, aby dodać podsieć>.

  5. Dodaj nazwę i zakres adresów przy użyciu notacji CIDR. Wybierz przycisk OK.

  6. Wybierz pozycję Właściwości w bloku Sieci wirtualne. Skopiuj identyfikator zasobu, a następnie dodaj element /subnets/<nameofyoursubnect>. Ta wartość będzie używana jako wartość klucza w modelu interfejsu vnetSubnetId API dla klastra. Identyfikator zasobu podsieci używa następującego formatu:
    /subscriptions/SUB_ID/resourceGroups/RG_NAME/providers/Microsoft.Network/virtualNetworks/VNET_NAME/subnets/SUBNET_NAME

    identyfikator zasobu sieci wirtualnej

  7. Wybierz pozycję Podsieci w bloku Sieci wirtualne. Wybierz nazwę podsieci, na przykład control-plane-sn.

    Nie należy kojarzyć podsieci z sieciową grupą zabezpieczeń.

    blok CIDR sieci wirtualnej

  8. W bloku podsieci zanotuj zakres adresów (BLOK CIDR) 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/8zakresach , 172.16/12i 192.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ć twoją zdolność do włączania komunikacji równorzędnej.

Pobieranie bloków adresów IP

Aparat AKS obsługuje wdrażanie w istniejącej sieci wirtualnej. Po wdrożeniu 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 jest co najmniej trzy bloki adresów:

  • Blok adresów węzłów: jest to blok adresów 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 (podsieciami) 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 należy wziąć pod uwagę liczbę kontenerów, które mają zostać wdrożone w klastrze podczas wybierania zakresu adresów podczas korzystania z usługi Azure CNI.
  • Blok adresów usług: jest to blok adresowy, 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 adresowy, 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 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ć kolejnego 10 adresu IP po ostatnim węźle płaszczyzny sterowania dla rezerwacji adresów IP nad głową. 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 umieszczenia 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 pozostać 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 pod koniec 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 adresami 256, 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 dla podsieci /24 Liczba Uwaga
172.100.0.0 - 172.100.0.3 100 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ącami adresów, możesz nie być praktyczne, aby ustawić statyczne przypisania adresów IP na końcu przestrzeni sieciowej. Ustaw zakres statycznych adresów IP klastra z dala od pierwszych 24 adresów w przestrzeni adresów 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 dla 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 adresowy (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 zarezerwowanych = 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 dla 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

Jeśli w twoim środowisku zakres publicznych adresów IP znajduje się w ciągu CIDR10.0.0.0/8, użyj rozwiązania kubenet jako wtyczki sieciowej.

Blok adresowy (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 agentów i blok klastra 172.24.128.0/17 172.24.128.0 - 172.24.255.255 32 768 – 5 zarezerwowanych = 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 identyfikator ścieżki usługi Azure Resource Manager podsieci. Ta wartość mapuje blok adresowy węzłów płaszczyzny sterowania powyżej.
firstConsecutiveStaticIP 10.100.0.239 Przypisz do właściwości konfiguracji adres IP zbliżony do firstConsecutiveStaticIP końca dostępnej przestrzeni adresowej IP w żądanej podsieci. firstConsecutiveStaticIP dotyczy tylko puli węzłów płaszczyzny sterowania.

W obszarze 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 identyfikator ścieżki usługi Azure Resource Manager podsieci. Ta wartość mapuje blok adresu węzłów agenta powyżej.

W pliku orchestratorProfile znajdź polecenie 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 mapowania 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 mapowa 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ą sieciową10.100.0.0/16, w której znajduje się podsieć control-plane-sn i jest 10.100.0.0/24 agents-sn10.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ą sieciową172.24.0.0/16, w której znajduje się podsieć control-plane-sn i jest 172.24.0.0/24 k8s-sn172.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.

  1. Otwórz portal użytkowników usługi Azure Stack Hub w wystąpieniu usługi Azure Stack Hub.

  2. Wybierz pozycję Wszystkie zasoby.

  3. Wprowadź nazwę sieci wirtualnej w polu wyszukiwania.

  4. Wybierz pozycję Podsieci, a następnie wybierz nazwę podsieci zawierającej klaster.

    tabela tras i sieciowa grupa zabezpieczeń

  5. Wybierz pozycję Tabela tras, a następnie wybierz tabelę tras dla klastra.

  6. Upewnij się, że jest to wykonywane dla każdej podsieci określonej w modelu interfejsu API, w tym podsieci masterProfile .

Następne kroki