Udostępnij za pośrednictwem

Zagadnienia dotyczące topologii sieci i łączności dla usługi Azure Red Hat OpenShift

  • Artykuł

Zapoznaj się z zagadnieniami i zaleceniami dotyczącymi topologii sieci i łączności podczas korzystania z akceleratora strefy docelowej usługi Azure Red Hat OpenShift.

Uwagi dotyczące projektowania

  • Usługa Azure Red Hat OpenShift wymaga podsieci podstawowej i podsieci pomocniczej.

    • Użyj podsieci podstawowej, aby wdrożyć węzły główne klastra.
    • Użyj podsieci pomocniczej, aby wdrożyć węzły robocze klastra.
    • Podsieć pomocnicza i podsieć podstawowa powinny być trasą minimalną /27 .
    • Nie można zmienić podsieci pomocniczej ani podsieci podstawowej po wdrożeniu klastra.
    • Podsieć podstawowa i podsieć pomocnicza nie mogą mieć skojarzonej sieciowej grupy zabezpieczeń. Klaster Usługi Azure Red Hat OpenShift automatycznie tworzy sieciową grupę zabezpieczeń i zarządza nią.
    • Podsieć pomocnicza i podsieć podstawowa nie mogą nakładać się na sieci lokalne ani z żadną inną siecią na platformie Azure.

  • Starannie zaplanuj adresy IP i rozmiar podsieci sieci wirtualnej w celu obsługi skalowania klastra. Może być konieczne dodanie węzłów.

  • Usługi i trasy usługi Azure Red Hat OpenShift można uwidocznić przy użyciu publicznych lub wewnętrznych modułów równoważenia obciążenia. Skonfiguruj wewnętrzne moduły równoważenia obciążenia w tej samej podsieci co węzły pomocnicze. W klastrze z ograniczeniami ruchu wychodzącego nie można używać publicznych modułów równoważenia obciążenia z powodu routingu asymetrycznego.

  • Usługa Azure Red Hat OpenShift używa sieci CoreDNS do zapewnienia rozpoznawania nazw zasobników uruchomionych w klastrze.

    • Usługa CoreDNS bezpośrednio rozpoznaje domeny wewnętrzne klastra.
    • Usługa Azure Red Hat OpenShift obsługuje również niestandardowe serwery DNS w sieci wirtualnej.
    • Inne domeny są przekazywane do serwerów DNS skonfigurowanych w usłudze Azure Virtual Network. Serwery DNS będą domyślnym modułem rozpoznawania nazw DNS platformy Azure lub niestandardowymi serwerami DNS skonfigurowanymi na poziomie sieci wirtualnej.
    • Przekazywanie DNS można dostosować w usłudze Azure Red Hat OpenShift CoreDNS.
    • Jeśli w sieci wirtualnej nie skonfigurowano niestandardowych serwerów DNS, usługa Azure Red Hat OpenShift używa domyślnego rozpoznawania nazw DNS platformy Azure.

    Aby uzyskać więcej informacji na temat systemu DNS, zobacz Konfiguracja usługi DNS prywatnego punktu końcowego platformy Azure.

  • Ruch sieciowy wychodzący (wychodzący) można wysyłać za pośrednictwem usługi Azure Firewall lub za pośrednictwem klastra wirtualnego urządzenia sieciowego.

  • Domyślnie wszystkie zasobniki w klastrze Usługi Azure Red Hat OpenShift mogą wysyłać i odbierać ruch bez ograniczeń. Wszystkie zasobniki w projekcie są dostępne z innych zasobników i punktów końcowych sieci. Aby odizolować co najmniej jeden zasobnik w projekcie, można utworzyć NetworkPolicy obiekty w projekcie, aby wskazać dozwolone połączenia przychodzące. Sieć zdefiniowana programowo (SDN) w systemie Red Hat OpenShift obsługuje używanie zasad sieciowych w domyślnym trybie izolacji sieciowej.

  • Siatka usług zapewnia funkcje, takie jak zarządzanie ruchem, odporność, zasady, zabezpieczenia, silna tożsamość i możliwość obserwacji. Aby uzyskać więcej informacji na temat usługi Red Hat OpenShift Service Mesh, zobacz Różnice między usługami Service Mesh i Istio.

  • Globalne mechanizmy równoważenia obciążenia, takie jak Usługi Azure Traffic Manager i Azure Front Door , zwiększają odporność, rozsyłając ruch między wieloma klastrami, potencjalnie w różnych regionach świadczenia usługi Azure.

Klastry prywatne

Adres IP klastra interfejsu API Usługi Azure Red Hat OpenShift może być publiczny lub prywatny. Klastry prywatne uwidaczniają interfejs API usługi Azure Red Hat OpenShift za pośrednictwem prywatnego adresu IP, ale nie za pośrednictwem publicznego. Interfejs API usługi Azure Red Hat OpenShift nie powinien być dostępny za pośrednictwem jego adresu IP. Zamiast tego uzyskaj dostęp do interfejsu API Usługi Azure Red Hat OpenShift za pośrednictwem w pełni kwalifikowanej nazwy domeny (FQDN). Usługa Azure DNS rozpoznaje nazwę FQDN interfejsu API OpenShift usługi Azure Red Hat na swój adres IP.

Zgodnie ze sprawdzonymi rozwiązaniami sprawdzonymi rozwiązaniami dotyczącymi strefy docelowej platformy Azure rozpoznawanie nazw DNS dla obciążeń platformy Azure jest oferowane przez scentralizowane serwery DNS wdrożone w ramach subskrypcji łączności. Serwery Dns platformy Azure znajdują się w sieci wirtualnej koncentratora lub w sieci wirtualnej usług udostępnionych połączonych z wystąpieniem usługi Azure Virtual WAN. Serwery DNS warunkowo rozpoznają nazwy specyficzne dla platformy Azure i publiczne przy użyciu usługi Azure DNS (adresu 168.63.129.16IP). Serwery rozpoznają nazwy prywatne przy użyciu firmowych serwerów DNS. Ten model łączności jest typowy i ważne jest, aby zezwolić na dostęp prywatny do innych zasobów platformy Azure, jeśli używasz prywatnych punktów końcowych.

Diagram przedstawiający sieć dla klastra prywatnego.

Ruch z użytkowników aplikacji do klastra

Użyj kontrolerów przychodzących (przychodzących), aby uwidocznić aplikacje działające w klastrach usługi Azure Red Hat OpenShift.

  • Kontrolery ruchu przychodzącego zapewniają routing na poziomie aplikacji tylko z niewielkim wzrostem złożoności.
  • Usługa Azure Red Hat OpenShift tworzy ogólny wpis DNS, który upraszcza dostęp do uwidocznionych aplikacji w klastrze. Przykładowy wpis DNS to *.apps.<cluster-ID>.<region>.aroapp.io. Jest to przydatne w przypadku klastra prywatnego do kierowania ruchu dla aplikacji.
  • Usługa Azure Red Hat OpenShift oferuje wbudowany kontroler ruchu przychodzącego i trasy.
  • Możesz użyć ruchu przychodzącego usługi Azure Red Hat OpenShift z usługą Azure Front Door.
  • Dostosuj konfigurację do projektu filtrowania ruchu wychodzącego, aby uniknąć routingu asymetrycznego. Trasy zdefiniowane przez użytkownika mogą potencjalnie powodować routing asymetryczny.
  • Jeśli scenariusz wymaga zakończenia protokołu TLS, rozważ sposób zarządzania certyfikatami TLS.

Ważne

Jeśli używasz usługi Azure Firewall do ograniczania ruchu wychodzącego i tworzenia trasy zdefiniowanej przez użytkownika w celu wymuszenia całego ruchu wychodzącego, upewnij się, że w usłudze Azure Firewall utworzono odpowiednią regułę tłumaczenia adresów sieciowych (DNAT), aby poprawnie zezwalać na ruch przychodzący. Używanie usługi Azure Firewall z trasą zdefiniowaną przez użytkownika przerywa konfigurację ruchu przychodzącego z powodu routingu asymetrycznego. Problem występuje, gdy podsieć usługi Azure Red Hat OpenShift ma domyślną trasę, która przechodzi do prywatnego adresu IP zapory, ale używasz publicznego modułu równoważenia obciążenia (ruchu przychodzącego lub usługi Kubernetes typu Load Balancer). W takim przypadku przychodzący ruch modułu równoważenia obciążenia jest odbierany za pośrednictwem publicznego adresu IP, ale ścieżka powrotna przechodzi przez prywatny adres IP zapory. Ponieważ zapora jest stanowa, odrzuca zwracany pakiet, ponieważ zapora nie wykrywa ustanowionej sesji. Aby dowiedzieć się, jak zintegrować usługę Azure Firewall z modułem równoważenia obciążenia ruchu przychodzącego lub usługi, zobacz Integrowanie usługi Azure Firewall z usługą Azure usługa Load Balancer w warstwie Standardowa.

W poniższych krokach opisano przepływ, jeśli używasz usługi Azure Front Door z prywatnym klastrem usługi Azure Red Hat OpenShift i kontrolerem ruchu przychodzącego:

  1. Klienci z publicznego Internetu rozpoznają nazwę DNS aplikacji, która wskazuje usługę Azure Front Door.
  2. Usługa Azure Front Door używa usługi Azure Private Link do uzyskiwania dostępu do prywatnego adresu IP wewnętrznego modułu równoważenia obciążenia sieci platformy Azure i uzyskiwania dostępu do aplikacji w kontrolerze ruchu przychodzącego usługi Azure Red Hat OpenShift.

W tych krokach opisano przepływ dla aplikacji spoza sieci Web, która uzyskuje dostęp do klastra prywatnego usługi Azure Red Hat OpenShift:

  1. Klienci z publicznego Internetu rozpoznają nazwę DNS aplikacji, która wskazuje publiczny adres IP usługi Azure Firewall lub wirtualne urządzenie sieciowe.
  2. Usługa Azure Firewall lub wirtualne urządzenie sieciowe przesyła dalej ruch (DNAT) do prywatnego klastra usługi Azure Red Hat OpenShift przy użyciu prywatnego adresu IP modułu równoważenia obciążenia sieci wewnętrznej platformy Azure w celu uzyskania dostępu do aplikacji w kontrolerze ruchu przychodzącego usługi Azure Red Hat OpenShift.

Ruch z zasobników usługi Azure Red Hat OpenShift do usług zaplecza

Zasobniki działające w klastrze Azure Red Hat OpenShift mogą wymagać dostępu do usług zaplecza, takich jak Azure Storage, Azure Key Vault, Azure SQL Database i Azure Cosmos DB. Aby zabezpieczyć łączność z tymi usługami zarządzanymi przez platformę Azure, możesz użyć punktów końcowych usługi sieci wirtualnej i usługi Azure Private Link .

Jeśli używasz prywatnych punktów końcowych platformy Azure na potrzeby ruchu zaplecza, możesz użyć stref usługi Azure Prywatna strefa DNS na potrzeby rozpoznawania nazw DNS dla usług platformy Azure. Ponieważ narzędzia rozpoznawania nazw DNS dla całego środowiska znajdują się w sieci wirtualnej koncentratora (lub w sieci wirtualnej usług udostępnionych, jeśli używasz modelu łączności usługi Virtual WAN), utwórz te strefy prywatne w subskrypcji łączności. Aby utworzyć rekord A, który jest wymagany do rozpoznania nazwy FQDN usługi prywatnej, można skojarzyć prywatną strefę DNS w subskrypcji łączności z prywatnym punktem końcowym w subskrypcji aplikacji. Ta operacja wymaga określonych uprawnień w tych subskrypcjach.

Rekordy A można utworzyć ręcznie, ale skojarzenie prywatnej strefy DNS z prywatnym punktem końcowym powoduje, że konfiguracja jest mniej podatna na błędy konfiguracji.

Łączność zaplecza z zasobników Azure Red Hat OpenShift z usługami Platformy jako usługi platformy Azure (PaaS) uwidoczniona za pośrednictwem prywatnych punktów końcowych jest następująca sekwencja:

  1. Zasobniki usługi Azure Red Hat OpenShift rozpoznają nazwę FQDN usługi Azure PaaS przy użyciu centralnych serwerów DNS w subskrypcji łączności, które są zdefiniowane jako niestandardowe serwery DNS w sieci wirtualnej usługi Azure Red Hat OpenShift.
  2. Rozpoznany adres IP to prywatny adres IP prywatnych punktów końcowych, do których uzyskuje się dostęp bezpośrednio z zasobników usługi Azure Red Hat OpenShift.

Ruch między zasobnikami azure Red Hat OpenShift i prywatnymi punktami końcowymi domyślnie nie przechodzi przez wystąpienie usługi Azure Firewall w sieci wirtualnej koncentratora (lub bezpiecznego koncentratora wirtualnego, jeśli używasz wirtualnej sieci WAN), nawet jeśli klaster usługi Azure Red Hat OpenShift jest skonfigurowany do filtrowania ruchu wychodzącego za pomocą usługi Azure Firewall. Prywatny punkt końcowy tworzy trasę w podsieciach sieci wirtualnej aplikacji, w której wdrożono usługę /32 Azure Red Hat OpenShift.

Zalecenia dotyczące projektowania

  • Jeśli zasady zabezpieczeń wymagają użycia prywatnego adresu IP dla interfejsu API usługi Azure Red Hat OpenShift, wdróż prywatny klaster usługi Azure Red Hat OpenShift.
  • Użyj usługi Azure DDoS Protection, aby chronić sieć wirtualną używaną w klastrze Usługi Azure Red Hat OpenShift, chyba że używasz usługi Azure Firewall lub zapory aplikacji internetowej w scentralizowanej subskrypcji.
  • Użyj konfiguracji DNS połączonej z ogólną konfiguracją sieci za pomocą usługi Azure Virtual WAN lub architektury piasty i szprych, stref usługi Azure DNS i własnej infrastruktury DNS.
  • Użyj usługi Azure Private Link, aby zabezpieczyć połączenia sieciowe i korzystać z prywatnej łączności opartej na protokole IP z innymi zarządzanymi usługami platformy Azure, które obsługują usługę Private Link, taką jak Azure Storage, Azure Container Registry, Azure SQL Database i Azure Key Vault.
  • Użyj kontrolera ruchu przychodzącego, aby zapewnić zaawansowane routing i zabezpieczenia HTTP oraz oferować pojedynczy punkt końcowy dla aplikacji.
  • Wszystkie aplikacje internetowe skonfigurowane do korzystania z ruchu przychodzącego powinny używać szyfrowania TLS i nie powinny zezwalać na dostęp za pośrednictwem niezaszyfrowanego protokołu HTTP.
  • Użyj usługi Azure Front Door z zaporą aplikacji internetowej, aby bezpiecznie opublikować aplikacje usługi Azure Red Hat OpenShift w Internecie.
  • Jeśli zasady zabezpieczeń wymagają sprawdzenia całego wychodzącego ruchu internetowego wygenerowanego w klastrze Usługi Azure Red Hat OpenShift, bezpieczny ruch sieciowy wychodzący przy użyciu usługi Azure Firewall lub wirtualnego urządzenia sieciowego innej firmy wdrożonego w sieci wirtualnej koncentratora zarządzanego. Aby uzyskać więcej informacji, zobacz Kontrolowanie ruchu wychodzącego do klastra usługi Azure Red Hat OpenShift.
  • Użyj warstwy Standardowa usługi Azure Load Balancer zamiast warstwy Podstawowa dla aplikacji innych niż internetowe.

Następne kroki