Wymagania wstępne dotyczące wdrażania obciążeń dzierżawy

  • Artykuł

W tym przewodniku opisano wymagania wstępne dotyczące tworzenia:

  • Maszyny wirtualne dla obciążeń funkcji sieci wirtualnej (VNF).
  • Wdrożenia klastra Nexus Kubernetes dla obciążeń funkcji sieci natywnej dla chmury (CNF).

Diagram przepływu wdrażania obciążenia dzierżawcy.

Wymagania wstępne dotyczące sieci

Musisz utworzyć różne sieci w zależności od potrzeb związanych z obciążeniem. Poniższa lista zagadnień nie jest wyczerpująca. Aby uzyskać pomoc, skontaktuj się z odpowiednimi zespołami pomocy technicznej.

  • Określ typy sieci, które mają obsługiwać obciążenia:
    • Sieć warstwy 3 (L3) wymaga przypisania sieci VLAN i podsieci. Podsieć musi być wystarczająco duża, aby obsługiwać przypisywanie adresów IP do każdej z maszyn wirtualnych. Platforma rezerwuje pierwsze trzy użyteczne adresy IP do użytku wewnętrznego. Na przykład w celu obsługi sześciu maszyn wirtualnych minimalna wartość CIDR dla podsieci to /28 (14 adresów do użycia — 3 zarezerwowane = 11 dostępnych adresów).
    • Sieć warstwy 2 (L2) wymaga tylko jednego przypisania sieci VLAN.
    • Sieć magistralna wymaga przypisania wielu sieci VLAN.
  • Określ, ile sieci każdego typu jest potrzebnych.
  • Określ rozmiar jednostki MTU każdej z sieci (maksymalnie 9000).
  • Określ informacje o komunikacji równorzędnej BGP dla każdej sieci i czy sieci muszą komunikować się ze sobą. Należy grupować sieci, które muszą komunikować się ze sobą w tej samej domenie izolacji L3, ponieważ każda domena izolacji L3 może obsługiwać wiele sieci L3.
  • Platforma udostępnia serwer proxy umożliwiający maszynie wirtualnej dotarcie do innych zewnętrznych punktów końcowych. cloudservicesnetwork Utworzenie wystąpienia wymaga, aby punkty końcowe zostały proxied, więc zbierz listę punktów końcowych. Listę punktów końcowych można zmodyfikować po utworzeniu sieci.

Tworzenie domen izolacji

Domeny izolacji umożliwiają komunikację między obciążeniami hostowanymi w tym samym stojaku (komunikacja wewnątrz stojaka) lub różnymi stojakami (komunikacja między stojakami). Więcej szczegółów na temat tworzenia domen izolacji można znaleźć tutaj.

Tworzenie sieci dla obciążeń dzierżawy

W poniższych sekcjach opisano sposób tworzenia tych sieci:

  • Sieć warstwy 2
  • Sieć warstwy 3
  • Sieć magistralna

Tworzenie sieci L2

W razie potrzeby utwórz sieć L2 dla obciążeń. Możesz powtórzyć instrukcje dla każdej wymaganej sieci L2.

Zbierz identyfikator zasobu domeny izolacji L2 utworzonej w celu skonfigurowania sieci VLAN dla tej sieci.

  az networkcloud l2network create --name "<YourL2NetworkName>" \
    --resource-group "<YourResourceGroupName>" \
    --subscription "<YourSubscription>" \
    --extended-location name="<ClusterCustomLocationId>" type="CustomLocation" \
    --location "<ClusterAzureRegion>" \
    --l2-isolation-domain-id "<YourL2IsolationDomainId>"

Tworzenie sieci L3

W razie potrzeby utwórz sieć L3 dla obciążeń. Powtórz instrukcje dla każdej wymaganej sieci L3.

Należy wykonać:

  • resourceID Wartość domeny izolacji L3 utworzonej do skonfigurowania sieci VLAN dla tej sieci.
  • Wartość, która musi być zgodna ipv4-connected-prefix z wartością i-pv4-connected-prefix w domenie izolacji L3.
  • Wartość, która musi być zgodna ipv6-connected-prefix z wartością i-pv6-connected-prefix w domenie izolacji L3.
  • Wartość ip-allocation-type , która może mieć IPv4wartość , IPv6lub DualStack (wartość domyślna).
  • Wartość vlan , która musi być zgodna z tym, co znajduje się w domenie izolacji L3.
  az networkcloud l3network create --name "<YourL3NetworkName>" \
    --resource-group "<YourResourceGroupName>" \
    --subscription "<YourSubscription>" \
    --extended-location name="<ClusterCustomLocationId>" type="CustomLocation" \
    --location "<ClusterAzureRegion>" \
    --ip-allocation-type "<YourNetworkIpAllocation>" \
    --ipv4-connected-prefix "<YourNetworkIpv4Prefix>" \
    --ipv6-connected-prefix "<YourNetworkIpv6Prefix>" \
    --l3-isolation-domain-id "<YourL3IsolationDomainId>" \
    --vlan <YourNetworkVlan>

Tworzenie sieci magistralnej

W razie potrzeby utwórz sieć magistralową dla maszyny wirtualnej. Powtórz instrukcje dla każdej wymaganej sieci magistrali.

resourceId Zbierz wartości domen izolacji L2 i L3 utworzonych wcześniej w celu skonfigurowania sieci VLAN dla tej sieci. W razie potrzeby można dołączyć dowolną liczbę domen izolacji L2 i L3.

  az networkcloud trunkednetwork create --name "<YourTrunkedNetworkName>" \
    --resource-group "<YourResourceGroupName>" \
    --subscription "<YourSubscription>" \
    --extended-location name="<ClusterCustomLocationId>" type="CustomLocation" \
    --location "<ClusterAzureRegion>" \
    --interface-name "<YourNetworkInterfaceName>" \
    --isolation-domain-ids \
      "<YourL3IsolationDomainId1>" \
      "<YourL3IsolationDomainId2>" \
      "<YourL2IsolationDomainId1>" \
      "<YourL2IsolationDomainId2>" \
      "<YourL3IsolationDomainId3>" \
    --vlans <YourVlanList>

Tworzenie sieci usług w chmurze

Aby utworzyć maszynę wirtualną Operator Nexus (VM) lub klaster Operator Nexus Kubernetes, musisz mieć sieć usług w chmurze. Bez tej sieci nie można utworzyć maszyny wirtualnej ani klastra.

Chociaż sieć usług w chmurze automatycznie umożliwia dostęp do podstawowych punktów końcowych platformy, należy dodać inne, takie jak docker.io, jeśli aplikacja ich wymaga. Skonfigurowanie serwera proxy sieci usług w chmurze jest kluczowym krokiem w zapewnieniu pomyślnego połączenia z żądanymi punktami końcowymi. Aby to osiągnąć, możesz dodać punkty końcowe ruchu wychodzącego do sieci usług w chmurze podczas początkowego tworzenia lub jako aktualizacji przy użyciu parametru --additional-egress-endpoints . Chociaż symbole wieloznaczne punktów końcowych adresu URL mogą wydawać się wygodne, nie jest zalecane ze względów bezpieczeństwa. Jeśli na przykład chcesz skonfigurować serwer proxy, aby zezwolić na ściąganie obrazu z dowolnego repozytorium hostowanego poza docker.io, możesz określić .docker.io jako punkt końcowy.

Punkty końcowe ruchu wychodzącego muszą być zgodne ze specyfikacjami nazw domen i nazwami hostów opisanymi w dokumentach RFC 1034, RFC 1035 i RFC 1123. Prawidłowe nazwy domen zawierają znaki alfanumeryczne, łączniki (nie na początku lub na końcu) i mogą mieć poddomeny oddzielone kropkami. Punkty końcowe mogą być jedną nazwą FQDN lub poddomeną (prefiks domeny z nazwą .). Poniżej przedstawiono kilka przykładów, aby zademonstrować zgodne konwencje nazewnictwa dla domen i nazw hostów.

  • contoso.com: domena podstawowa służąca jako domena drugiego poziomu w domenie najwyższego poziomu .com.
  • sales.contoso.com: poddomena contoso.com, która służy jako domena trzeciego poziomu w .com domenie najwyższego poziomu.
  • web-server-1.contoso.com: nazwa hosta dla określonego serwera internetowego, używając łączników do oddzielania wyrazów i liczb.
  • api.v1.contoso.com: obejmuje dwie poddomeny (v1 i api) powyżej domeny podstawowej contoso.com.
  • .api.contoso.com: symbol wieloznaczny dla dowolnej poddomeny w obszarze api.contoso.com, obejmujący wiele domen trzeciego poziomu.
  az networkcloud cloudservicesnetwork create --name "<YourCloudServicesNetworkName>" \
    --resource-group "<YourResourceGroupName >" \
    --subscription "<YourSubscription>" \
    --extended-location name="<ClusterCustomLocationId >" type="CustomLocation" \
    --location "<ClusterAzureRegion>" \
    --additional-egress-endpoints "[{\"category\":\"<YourCategory >\",\"endpoints\":[{\"<domainName1 >\":\"< endpoint1 >\",\"port\":<portnumber1 >}]}]"

Po skonfigurowaniu sieci usług w chmurze można jej użyć do utworzenia maszyny wirtualnej lub klastra, który może łączyć się z określonymi punktami końcowymi ruchu wychodzącego. Pamiętaj, że serwer proxy działa tylko z protokołem HTTPS.

Uwaga

Aby upewnić się, że obraz systemu plików VNF można ściągnąć poprawnie, upewnij się, że adres URL usługi ACR znajduje się na liście dozwolonych sieci usług w chmurze, która będzie używana z maszyną wirtualną Operator Nexus.

Ponadto jeśli usługa ACR ma włączone dedykowane punkty końcowe danych, należy dodać wszystkie nowe punkty końcowe danych do listy dozwolonych ruchu wychodzącego. Aby znaleźć wszystkie możliwe punkty końcowe dla usługi ACR, postępuj zgodnie z instrukcjami podanymi tutaj.

Użyj serwera proxy, aby uzyskać dostęp poza maszyną wirtualną

Po utworzeniu klastra Kubernetes operatora Nexus lub maszyny wirtualnej Operatora Nexus z tą siecią usług w chmurze należy dodatkowo ustawić odpowiednie zmienne środowiskowe na maszynie wirtualnej, aby korzystać z serwera proxy dzierżawy i dotrzeć poza maszynę wirtualną. Ten serwer proxy dzierżawy jest przydatny, jeśli musisz uzyskać dostęp do zasobów spoza maszyny wirtualnej, takich jak zarządzanie pakietami lub instalowanie oprogramowania.

Aby użyć serwera proxy, należy ustawić następujące zmienne środowiskowe:

export HTTPS_PROXY=http://169.254.0.11:3128
export https_proxy=http://169.254.0.11:3128

Po ustawieniu zmiennych środowiskowych serwera proxy maszyna wirtualna będzie mogła uzyskać dostęp do skonfigurowanych punktów końcowych ruchu wychodzącego.

Uwaga

Protokół HTTP nie jest obsługiwany ze względu na przyczyny zabezpieczeń podczas używania serwera proxy do uzyskiwania dostępu do zasobów spoza maszyny wirtualnej. Wymagane jest użycie protokołu HTTPS do bezpiecznej komunikacji podczas zarządzania pakietami lub instalowania oprogramowania na maszynie wirtualnej Operator Nexus lub w klastrze Kubernetes Operatora Nexus z tą siecią usług w chmurze.

Ważne

W przypadku korzystania z serwera proxy ważne jest również prawidłowe ustawienie zmiennej środowiskowej no_proxy . Ta zmienna może służyć do określania domen lub adresów IP, do których nie należy uzyskiwać dostępu za pośrednictwem serwera proxy. Jeśli nie zostanie prawidłowo ustawiona, może to spowodować problemy podczas uzyskiwania dostępu do usług, takich jak serwer interfejsu API Platformy Kubernetes lub adres IP klastra. Pamiętaj, aby uwzględnić adres IP lub nazwę domeny serwera interfejsu API Kubernetes i wszystkie adresy IP klastra w zmiennej no_proxy .

Strefa dostępności klastra Nexus Kubernetes

Podczas tworzenia klastra Nexus Kubernetes można zaplanować klaster na określonych stojakach lub rozłożyć go na wiele stojaków. Ta technika może poprawić wykorzystanie zasobów i odporność na uszkodzenia.

Jeśli nie określisz strefy podczas tworzenia klastra Nexus Kubernetes, platforma Azure Operator Nexus automatycznie implementuje domyślną regułę koligacji, aby rozłożyć maszynę wirtualną na stojaki i węzły bez systemu operacyjnego i nie jest gwarantowana. Ta reguła ma również na celu zapobieganie planowania maszyny wirtualnej klastra w węźle, który ma już maszynę wirtualną z tego samego klastra, ale jest to najlepsze podejście i nie może zagwarantować.

Aby uzyskać listę dostępnych stref w wystąpieniu narzędzia Azure Operator Nexus, możesz użyć następującego polecenia:

    az networkcloud cluster show \
      --resource-group <Azure Operator Nexus on-premises cluster resource group> \
      --name <Azure Operator Nexus on-premises cluster name> \
      --query computeRackDefinitions[*].availabilityZone