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.
- 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 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.
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 element
/subnets/<nameofyoursubnect>
. Ta wartość będzie używana jako wartość klucza w modelu interfejsuvnetSubnetId
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
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ń.
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/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ć 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-sn
10.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-sn
172.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