Udostępnij przez

Wymagania wstępne dotyczące wdrażania zadań dzierżawcy

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

  • Maszyny wirtualne dla obciążeń funkcji sieci wirtualnej (VNF).
  • Wdrożenia klastra Kubernetes Nexus dla obciążeń chmurowo-natywnych funkcji sieciowych (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 VLAN.
    • Sieć trunkowa wymaga przypisania wielu VLANów.
  • 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. Utworzenie wystąpienia cloudservicesnetwork wymaga, aby punkty końcowe zostały zproxyfikowane, dlatego należy zebrać 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ń najemców

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

  • Sieć warstwy 2
  • Sieć warstwy 3
  • Sieć trunkingowa

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 swoich obciążeń. Powtórz instrukcje dla każdej wymaganej sieci L3.

Potrzebujesz:

  • resourceID Wartość domeny izolacji L3 utworzonej do skonfigurowania sieci VLAN dla tej sieci.
  • Wartość ipv4-connected-prefix, która musi być zgodna z wartością i-pv4-connected-prefix w domenie izolacji L3.
  • Wartość ipv6-connected-prefix, która musi być zgodna z wartością i-pv6-connected-prefix w domenie izolacji L3.
  • Wartość ip-allocation-type, która może być IPv4, IPv6 lub 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 aktualizacja, używając parametru --additional-egress-endpoints. Chociaż symbole wieloznaczne w końcowych adresach URL mogą wydawać się wygodne, nie są 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ć pojedynczym FQDN (pełna nazwa domeny) lub poddomeną (prefiks domeny z oznaczeniem .). 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.

Wdrożenia z wieloma urządzeniami magazynowymi obsługują wybieranie urządzenia magazynowego do użycia w celu udostępnienia współdzielonej pamięci systemu plików dla obciążeń konteneryzowanych. CSN zarządza usługą magazynu udostępnionego, która umożliwia udostępnianie magazynu systemu plików. Urządzenie magazynujące można wybrać tylko podczas tworzenia CSN. Wszystkie kolejne próby zmiany konfiguracji nie będą miały wpływu. Nazwa urządzenia magazynu musi być zgodna z nazwą usługi Azure Resource Manager urządzenia magazynu zarządzanego przez klaster Nexus. Jeśli nie podano nazwy urządzenia pamięci masowej lub jeśli konfiguracja nie jest zgodna z urządzeniem pamięci masowej w wystąpieniu Azure Operator Nexus, domyślnie używane jest pierwsze urządzenie pamięci masowej.

  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 >}]}]"
    --tags "storageApplianceName": "<YourStorageApplianceName>""

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 / Notatka

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

Ponadto, jeśli ACR ma włączone dedykowane punkty końcowe dla danych, należy dodać wszystkie nowe punkty końcowe danych do listy dozwolonej dla 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 maszyny wirtualnej Operatora Nexus lub klastra Kubernetes operatora Nexus z tą siecią usług w chmurze, należy dodatkowo ustawić odpowiednie zmienne środowiskowe na maszynie wirtualnej, aby skorzystać z serwera proxy dzierżawy oraz aby umożliwić komunikację z elementami 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 uzyska dostęp do skonfigurowanych punktów końcowych dla ruchu wychodzącego.

Uwaga / Notatka

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łę antykoligacji, aby rozłożyć maszynę wirtualną między stojaki i węzły bare metalowe, co nie jest zagwarantowane. 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
  • Last updated on