Notatka
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Azure Red Hat OpenShift z hostowaną płaszczyzną sterowania wdraża węzły robocze do Twojej sieci wirtualnej platformy Azure i używa dedykowanej podsieci do ustanowienia prywatnej łączności między hostowaną płaszczyzną sterowania a węzłami roboczymi. Przed utworzeniem klastra należy zaplanować układ sieci wirtualnej, podsieci i zakresy adresów IP.
Planowanie pojemności obliczeniowej
Pule węzłów zapewniają pojemność obliczeniową. Pula węzłów to grupa węzłów roboczych, które mają ten sam rozmiar maszyny wirtualnej, konfigurację dysku i strefę dostępności. W jednym klastrze można utworzyć wiele pul węzłów, aby uruchamiać różne typy obciążeń na innym sprzęcie. Aby uzyskać informacje o obsługiwanych rozmiarach maszyn wirtualnych węzła roboczego, zobacz Obsługiwane rozmiary maszyn wirtualnych. Kilka decyzji dotyczących puli węzłów bezpośrednio wpływa na układ sieci, dlatego przed rozmiarem sieci należy zaplanować pojemność obliczeniową.
Udzielenie odpowiedzi na następujące pytania pomaga zaplanować podsieci i zakresy adresów IP dla klastra:
- Ile pul węzłów zostanie uruchomionych? Liczba pul węzłów określa, ile podsieci może być potrzebnych. Jeśli wszystkie pule używają domyślnej podsieci węzłów roboczych klastra, wystarczy jedna podsieć. Jeśli przypiszesz oddzielne podsieci do różnych pul, każda z nich zwiększa wymagania dotyczące zakresów CIDR sieci wirtualnej i maszyn.
- Czy wdrożysz w różnych strefach dostępności? Każda pula węzłów jest wdrażana w jednej strefie dostępności. Aby dystrybuować obciążenia między strefy w celu zapewnienia wysokiej dostępności, potrzebna jest oddzielna pula węzłów i potencjalnie oddzielna podsieć dla każdej strefy. Więcej stref oznacza więcej podsieci i większy zakres CIDR maszyn.
- Czy każda pula węzłów będzie używać własnej podsieci? Pule węzłów są wdrażane do domyślnej podsieci węzłów roboczych klastra, chyba że określisz inną podsieć. Oddzielne podsieci zapewniają izolację sieciową między pulami węzłów, ale każda podsieć musi mieścić się w zakresie CIDR przypisanym do maszyn oraz w przestrzeni adresowej sieci wirtualnej.
- Ile węzłów zostanie uruchomionych w szczytowym momencie? Maksymalna liczba węzłów, w tym maksimum skalowania automatycznego, określa, jak duża musi być każda podsieć. Klaster obsługuje łącznie maksymalnie 500 węzłów we wszystkich pulach.
- Czy później dodasz więcej pul węzłów? Nie można zmienić zakresów CIDR klastra po utworzeniu. Jeśli planujesz dodać pule węzłów z nowymi podsieciami w przyszłości, maszyna CIDR i sieć wirtualna muszą mieć wystarczającą przestrzeń adresową, aby je pomieścić.
Wskazówka
Przykład doboru rozmiaru: Klaster z 3 strefami dostępności, maksymalnie 50 węzłami na strefę oraz oddzielną podsiecią dla każdej strefy wymaga trzech podsieci /26 (po 64 adresy każda, co pozwala obsłużyć 50 węzłów oraz adresy zarezerwowane przez platformę Azure) oraz jednej podsieci integracji z siecią wirtualną /29.
Wszystkie cztery podsieci mieszczą się w obrębie zakresu CIDR maszyny /24 (256 adresów).
Jeśli planujesz później dodać więcej pul węzłów, użyj większego zakresu CIDR dla maszyn, takiego jak /22 lub /16, aby pozostawić miejsce na dodatkowe podsieci.
Wymagania dotyczące podsieci
Sieć wirtualna musi zawierać następujące składniki:
- Podsieć węzłów roboczych — domyślna podsieć, w której wdrażane są węzły robocze klastra. Podczas tworzenia puli węzłów zostanie ona wdrożona w tej podsieci, chyba że określisz inną podsieć. Jeśli planujesz wdrożyć pule węzłów w wielu strefach dostępności, możesz utworzyć oddzielną podsieć dla każdej strefy. Wszystkie podsieci puli węzłów muszą znajdować się w tej samej sieci wirtualnej co klaster. Rozmiar każdej podsieci na podstawie liczby węzłów roboczych, które mają być w niej uruchomione.
-
Podsieć integracji z siecią VNet — dedykowana podsieć umożliwiająca prywatną łączność między hostowaną płaszczyzną sterowania (uruchomioną na koncie platformy Azure firmy Red Hat) a węzłami roboczymi w Twojej subskrypcji. Musi spełniać następujące wymagania:
- Minimalny rozmiar
/29 - Znajdująca się w tej samej sieci wirtualnej co podsieć robocza
- Nie jest współdzielone z podsiecią roboczą ani z żadną podsiecią puli węzłów
- Minimalny rozmiar
- Sieciowe grupy zabezpieczeń - jeśli skojarzysz sieciową grupę zabezpieczeń (NSG) z węzłem roboczym, pulą węzłów lub podsiecią integracji z siecią wirtualną (VNet), sprawdź jej reguły pod kątem wymaganego ruchu opisanego w sekcji Wymagany ruch dla sieciowych grup zabezpieczeń. Przypisujesz NSG bezpośrednio do podsieci.
Wymagany ruch w sieciowej grupie zabezpieczeń
Sieciowa grupa zabezpieczeń skojarzona z pulą węzłów i podsieciami integracji sieci wirtualnej musi zezwalać na następujący ruch:
| Skojarzenie z NSG | Kierunek | Źródło | Destination | Porty docelowe |
|---|---|---|---|---|
| Podsieć węzła roboczego lub puli węzłów | Wychodzący | Podsieć węzła roboczego lub puli węzłów | Podsieć klastra nadrzędnego | TCP 443 i 6443 |
| Podsieć integracji z siecią VNet | Inbound | Podsieć węzła roboczego lub puli węzłów | Podsieć integracji z usługą VNet | TCP 443 i 8443 |
Te połączenia umożliwiają węzłom roboczym uzyskanie dostępu do hostowanego kube-apiservera i hostowanej płaszczyzny sterowania. Jeśli reguła typu Odmów w grupie zabezpieczeń sieciowych (NSG) blokuje wymagany ruch sieciowy, nie można utworzyć pul węzłów.
Aby naprawić regułę Odmowy, która blokuje wymagany przepływ, wykonaj jedną z następujących akcji:
- Usuń regułę Odmowy.
- Zawęź regułę Odmów, aby nie była zgodna z wymaganym źródłem, miejscem docelowym i portami.
- Dodaj regułę Zezwalaj zgodną z wymaganym źródłem, miejscem docelowym i portami i ma wyższy priorytet niż reguła Odmowy. W sieciowej grupie zabezpieczeń niższy priorytet liczbowy ma wyższy priorytet.
Azure Red Hat OpenShift z hostowanymi płaszczyznami sterowania ocenia reguły TCP i reguły z symbolami wieloznacznymi, które obejmują wymagane porty. Reguły odmowy dla niepowiązanych portów, ruchu UDP lub niepowiązanych miejsc docelowych nie mają wpływu na tę walidację. Jednak te reguły nadal mogą blokować inny ruch.
Wymagania ciDR
W poniższej tabeli opisano wymagania dotyczące sieci wirtualnej i ciDR:
| Wymaganie dotyczące sieci | Wartość domyślna | Description |
|---|---|---|
| Zakres CIDR dla maszyny | 10.0.0.0/16 |
Zakres adresów IP dla węzłów obliczeniowych. Musi ona obejmować wszystkie zakresy adresów CIDR dla podsieci sieci wirtualnej, w tym wszystkie podsieci, które mają być używane dla dodatkowych pul węzłów. Podsieci muszą być ciągłe. Co najmniej 128 adresów (/25) jest obsługiwanych w przypadku wdrożeń w pojedynczej strefie dostępności. W przypadku wdrożeń w wielu strefach dostępności obsługiwanych jest co najmniej 256 adresów (/24). |
| Zakres CIDR dla usługi | 172.30.0.0/16 |
Zakres adresów IP dla usług Kubernetes. Zakres musi być wystarczająco duży, aby pomieścić obciążenie i nie może pokrywać się z żadną usługą zewnętrzną dostępną z poziomu klastra. |
| Zakres CIDR poda | 10.128.0.0/14 |
Zakres adresów IP dla zasobników. Zakres musi być wystarczająco duży, aby pomieścić obciążenie i nie może pokrywać się z żadną usługą zewnętrzną dostępną z poziomu klastra. |
| Prefiks hosta | 23 |
Długość prefiksu podsieci przydzielona do każdego węzła dla jego podów. Wartość 23 przypisuje podsieć /23 (512 adresów IP) na węzeł z zakresu CIDR podów. |
Użyj wartości domyślnych, chyba że nie spełniają wymagań. Jeśli musisz zmienić dowolną z tych wartości, postępuj zgodnie z następującymi wytycznymi:
- Zakresy CIDR poda, usługi i maszyny nie mogą nakładać się na siebie.
- Zakresy CIDR dla podów i usług nie mogą nakładać się na żadne zakresy adresów używane w sieci ani przez jakiekolwiek usługi zewnętrzne, do których uzyskuje się dostęp z klastra.
- Blok CIDR maszyny musi obejmować wszystkie podsieci sieci wirtualnej używane przez klaster, w tym podsieć węzłów roboczych, wszelkie dodatkowe podsieci puli węzłów oraz podsieć integracji z siecią wirtualną. Jeśli planujesz dodać pule węzłów z oddzielnymi podsieciami w przyszłości, upewnij się, że maszyna CIDR jest wystarczająco duża, aby je uwzględnić. Na przykład jeśli VNet używa
10.0.0.0/16, domyślny CIDR maszyny10.0.0.0/16obejmuje wszystkie podsieci. - Sieć poda używa nieroutowalnych adresów IP i jest używana wyłącznie wewnątrz programowo zdefiniowanej sieci klastra.
Łączność z klastrem prywatnym
Jeśli wybierzesz prywatny serwer interfejsu API, prywatny domyślny ingress lub obie te opcje, przed wdrożeniem klastra musisz ustanowić prywatną łączność sieciową między sieciami użytkowników a siecią wirtualną klastra. Bez tej łączności administratorzy, potoki ciągłej integracji i ciągłego wdrażania oraz użytkownicy końcowi nie mogą uzyskać dostępu do prywatnych punktów końcowych.
Typowe opcje łączności obejmują:
- Komunikacja równorzędna sieci wirtualnych platformy Azure — połącz dwie sieci wirtualne platformy Azure, aby zasoby w każdej z nich mogły się ze sobą komunikować.
- Azure VPN Gateway — połącz sieć lokalną z siecią wirtualną klastra za pośrednictwem tunelu vpn typu lokacja-lokacja.
- Azure ExpressRoute — ustanów prywatne, dedykowane połączenie z sieci lokalnej do Azure za pośrednictwem dostawcy łączności.
Podczas planowania prywatnej łączności sieciowej upewnij się, że zakresy adresów IP sparowanych lub połączonych sieci nie nakładają się z zakresem CIDR maszyn klastra, zakresem CIDR zasobników ani zakresem CIDR usług.