Łączność sieciowa w Azure Operator Nexus Kubernetes

Instancja Azure Operator Nexus, lub po prostu Operator Nexus, składa się ze sprzętu obliczeniowego i sieciowego zainstalowanego w siedzibie klienta. Wiele warstw urządzeń fizycznych i wirtualnych zapewnia łączność sieciową i usługi routingu do obciążeń uruchomionych na tym sprzęcie obliczeniowym. Ten dokument zawiera szczegółowy opis każdej z tych warstw sieciowych.

Topologia

W tym miejscu opisano topologię sprzętu w wystąpieniu Operatora Nexus.

Klienci posiadają routery brzegowe dostawcy (PE) i zarządzają nimi. Te routery reprezentują krawędź sieci szkieletowej klienta.

Operator Nexus zarządza routerami brzegowymi klienta (CE). Te routery są częścią instancji Operatora Nexus i są zawarte w rachunku materiałów bliskiej krawędzi sprzętu (BOM). Istnieją dwa routery CE w każdym wystąpieniu Operator Nexus z wieloma stojakami. Każdy router CE ma łącze z każdym routerem PE. Routery CE to jedyne urządzenia Operator Nexus, które są fizycznie połączone z siecią klienta.

Każdy stojak serwerów obliczeniowych w wystąpieniu operatora platformy Azure Operator Nexus z wieloma stojakami ma dwa przełączniki top-of-rack (TOR). Każdy przełącznik TOR ma łącze do każdego routera CE. Każdy TOR jest podłączony do każdego serwera obliczeniowego bare-metal w stojaku i jest skonfigurowany jako prosty przełącznik warstwy 2.

Goły sprzęt

Obciążenia najemców uruchomione w tej infrastrukturze obliczeniowej to zazwyczaj funkcje sieciowe, które są wirtualizowane lub konteneryzowane. Funkcje sieci wirtualnej (VNFs) działają jako maszyny wirtualne na sprzęcie serwera obliczeniowego. Konteneryzowane funkcje sieciowe (CNFs) działają wewnątrz kontenerów. Te kontenery działają na maszynach wirtualnych, które są uruchamiane na sprzęcie serwera obliczeniowego.

Funkcje sieciowe, które zapewniają usługi płaszczyzny danych użytkownika końcowego, wymagają interfejsów sieciowych o wysokiej wydajności, które oferują zaawansowane funkcje i wysoką przepustowość I/O.

W przypadku niemal brzegowych wystąpień multi-rack Operator Nexus, każdy serwer obliczeniowy bare metal jest maszyną dwugniazdową z architekturą NUMA (Non-Uniform Memory Access).

Serwer typu bare metal w instancji Azure Operator Nexus w pobliżu brzegu sieci, zawiera jedną kartę sieciową z dwoma portami (pNIC) dla każdej komórki NUMA. Te komputery obsługują wirtualizację we/wy pojedynczego katalogu głównego (SR-IOV) i inne funkcje o wysokiej wydajności. Jedna komórka NUMA jest pamięcią i procesorem zgodnym z jedną pNIC.

Wszystkie interfejsy sieciowe przypisane do obciążeń dzierżawy to urządzenia hosta przekazujące i korzystają z funkcji wirtualnych (VFs) SR-IOV, które są przydzielone z karty pNIC dostosowanej do komórki NUMA, w której znajdują się zasoby CPU i pamięci maszyny wirtualnej obsługującej obciążenie. Takie rozwiązanie zapewnia optymalną wydajność stosu sieciowego wewnątrz maszyn wirtualnych i kontenerów, które są przypisane do tych funkcji wirtualnych (VF).

Stojaki obliczeniowe są wdrażane z parą przełączników TOR (Top-of-Rack). Każda pNIC na każdym serwerze obliczeniowym bare metal jest połączona z obydwoma tymi przełącznikami TOR. Grupa agregacji łączy między obudowami (MLAG) zapewnia wysoką dostępność, a protokół kontroli agregacji łączy (LACP) zapewnia zwiększoną przepustowość zagregowaną łącza.

Każdy serwer obliczeniowy na surowym metalu ma interfejs sieciowy danych, który jest dostarczany przez połączenie agregujące dwie funkcje wirtualne (VF) hosta (w przeciwieństwie do lokalnych VF maszyn wirtualnych) podłączone do obu kart sieciowych. Te dwa wirtualne dyski wirtualne są agregowane w obligacji aktywnej kopii zapasowej, aby upewnić się, że jedna z kart sieciowych ulegnie awarii, łączność z magazynem sieciowym pozostaje dostępna.

Zasoby sieci logicznej

Podczas interakcji z interfejsem API chmury sieci Operator Nexus i interfejsami API sieci zarządzanej sieci szkieletowej użytkownicy tworzą i modyfikują zestaw zasobów logicznych.

Zasoby logiczne w interfejsie API sieci zarządzanej sieci szkieletowej odpowiadają sieciom i konfiguracji kontroli dostępu na podstawowym sprzęcie sieciowym (tors i urzędy certyfikacji). Zauważalnie, zasoby ManagedNetworkFabric.L2IsolationDomain i ManagedNetworkFabric.L3IsolationDomain zawierają konfigurację przełącznika i sieci niskiego poziomu. A ManagedNetworkFabric.L2IsolationDomain reprezentuje wirtualny identyfikator sieci lokalnej (VLAN). Element ManagedNetworkFabric.L3IsolationDomain reprezentuje konfigurację routingu wirtualnego i przekazywania (VRF) na routerach CE. Przeczytaj o koncepcji domeny izolacji.

Zasoby logiczne w interfejsie API chmury sieciowej odpowiadają infrastrukturze obliczeniowej. Istnieją zasoby dla stojaków fizycznych i sprzętu typu bare metal. Podobnie istnieją zasoby dla klastrów Kubernetes i maszyn wirtualnych, które działają na tym sprzęcie i sieciach logicznych, które je łączą.

NetworkCloud.L2Network, NetworkCloud.L3Networki NetworkCloud.TrunkedNetwork wszystkie reprezentują sieci obciążeń, co oznacza, że ruch w tych sieciach jest przeznaczony dla obciążeń dzierżawy.

Obiekt NetworkCloud.L2Network reprezentuje sieć warstwy 2 i zawiera niewiele więcej niż link do elementu ManagedNetworkFabric.L2IsolationDomain. Ten L2IsolationDomain zawiera identyfikator sieci VLAN i ustawienie maksymalnej jednostki transmisji (MTU).

Obiekt NetworkCloud.L3Network reprezentuje sieć warstwy 3 i zawiera identyfikator sieci VLAN, informacje o przypisywaniu adresów IP dla punktów końcowych w sieci i link do ManagedNetworkFabric.L3IsolationDomain.

Uwaga

NetworkCloud.L3Network Dlaczego zasób zawiera identyfikator sieci VLAN? Czy sieci VLAN nie są pojęciami warstwy 2?

Tak, tak są! Przyczyną tego jest fakt, że NetworkCloud.L3Network element musi mieć możliwość odwoływania się do określonego ManagedNetworkFabric.InternalNetworkelementu . ManagedNetworkFabric.InternalNetworks są tworzone w ramach określonego ManagedNetworkFabric.L3IsolationDomain i otrzymują identyfikator VLAN. W związku z tym, aby odwołać się do określonego ManagedNetworkFabric.InternalNetworkelementu , NetworkCloud.L3Network musi zawierać zarówno identyfikator L3IsolationDomain, jak i identyfikator sieci VLAN.

Zasoby sieci logicznej w interfejsie API chmury sieciowej, takie jak NetworkCloud.L3Network zasobów logicznych w interfejsie API sieci szkieletowej sieci zarządzanej i w ten sposób zapewniają logiczne połączenie między infrastrukturą obliczeniową fizyczną a infrastrukturą sieci fizycznej.

Podczas tworzenia maszyny wirtualnej Nexus można określić zero lub więcej L2, L3 i Magistraled Networks w maszynie NetworkAttachmentswirtualnej Nexus . Podczas tworzenia klastra Kubernetes Nexus można określić zero lub więcej sieci L2, L3 i Trunked w polu Klastra NetworkConfiguration.AttachedNetworkConfiguration Kubernetes Nexus. Puli agentów to kolekcje podobnych węzłów roboczych kubernetes w klastrze Kubernetes Nexus. W polu AgentPool można skonfigurować dołączone sieci L2, L3 i Magistraled puli agentów AttachedNetworkConfiguration .

Sieci można udostępniać w autonomicznych maszynach wirtualnych Nexus i klastrach Kubernetes Nexus. Dzięki tej kompozycyjności można łączyć CNF i VNF, które współpracują w ramach tych samych sieci logicznych.

Na diagramie przedstawiono przykład klastra Kubernetes Nexus z dwoma pulami agentów i autonomiczną maszyną wirtualną Nexus połączoną z różnymi sieciami obciążeń. Pula agentów "AP1" nie ma dodatkowej konfiguracji sieci i dlatego dziedziczy informacje o sieci kubernetesCluster. Należy również pamiętać, że wszystkie węzły Kubernetes i wszystkie autonomiczne maszyny wirtualne Nexus są skonfigurowane do łączenia się z tą samą siecią usług w chmurze. Na koniec pula agentów "AP2" i autonomiczna maszyna wirtualna są skonfigurowane do nawiązywania połączenia z "udostępnioną siecią L3".

The CloudServicesNetwork

Nexus Virtual Machines i Nexus Kubernetes Clusters zawsze odwołują się do czegoś o nazwie "Cloud Services Network" (CSN). CSN to specjalna sieć używana do ruchu między środowiskami lokalnymi oraz zestawem zewnętrznych lub hostowanych w Azure punktów końcowych.

Ruch w usłudze CloudServicesNetwork jest kierowany przez serwer proxy, gdzie ruch wychodzący jest kontrolowany za pośrednictwem listy dozwolonych. Użytkownicy mogą dostroić tę listę dozwolonych przy użyciu interfejsu API Chmury Sieciowej.

Sieć CNI

Podczas tworzenia klastra Kubernetes Nexus należy podać identyfikator NetworkCloud.L3Network zasobu w NetworkConfiguration.CniNetworkId polu.

Ta sieć "sieć CNI", czasami nazywana "Siecią DefaultCNI", określa sieć warstwy 3, która udostępnia adresy IP węzłów Kubernetes w klastrze Nexus Kubernetes.

Na diagramie przedstawiono relacje między niektórymi zasobami logicznymi chmury sieciowej, sieci szkieletowej sieci zarządzanej i platformy Kubernetes. Na diagramie NetworkCloud.L3Network to zasób logiczny w interfejsie API chmury sieciowej, który reprezentuje sieć warstwy trzeciej. Zasób NetworkCloud.KubernetesCluster zawiera pole networkConfiguration.cniNetworkId zawierające odwołanie do NetworkCloud.L3Network zasobu.

Zasób NetworkCloud.L3Network jest skojarzony z pojedynczym zasobem ManagedNetworkFabric.InternalNetwork za pośrednictwem pól l3IsolationDomainId i vlanId. Zasób ManagedNetworkFabric.L3IsolationDomain zawiera jeden lub więcej zasobów ManagedNetworkFabric.InternalNetwork, które są przypisane do klucza vlanId. Gdy użytkownik utworzy NetworkCloud.KubernetesCluster zasób, zostanie utworzony co najmniej jeden NetworkCloud.AgentPool zasób.

Każdy z tych NetworkCloud.AgentPool zasobów składa się z co najmniej jednej maszyny wirtualnej. Zasób Kubernetes Node reprezentuje każdą z tych maszyn wirtualnych. Te zasoby kubernetes Node muszą uzyskać adres IP i wtyczki interfejsu sieci kontenera (CNI) na maszynach wirtualnych pobierają adres IP z puli adresów IP skojarzonych z NetworkCloud.L3Network. Zasób NetworkCloud.KubernetesCluster odwołuje się do NetworkCloud.L3Network poprzez swoje pole cniNetworkId. Reguły routingu i dostępu dla tych adresów IP na poziomie węzła znajdują się w pliku ManagedNetworkFabric.L3IsolationDomain. NetworkCloud.L3Network odnosi się do ManagedNetworkFabric.L3IsolationDomain przy użyciu pola l3IsoldationDomainId.

Operator Nexus — sieć Kubernetes

Na platformie Kubernetes istnieją trzy warstwy logiczne sieci:

• Warstwa sieci węzłów
• Warstwa sieci Pod
• Warstwa sieci usługi

Warstwa sieciowa Node zapewnia łączność między płaszczyzną sterowania Kubernetes a agentem węzła roboczego kubelet.

Warstwa sieciowa Pod zapewnia łączność między kontenerami (Podami) działającymi wewnątrz klastra Nexus Kubernetes, a także między Podem a jedną lub kilkoma sieciami zdefiniowanymi przez użytkownika.

Warstwa sieciowa usługi zapewnia równoważenie obciążenia i funkcjonalność ruchu przychodzącego dla zestawów powiązanych Podów.

Sieć węzłów

Klastry Kubernetes Operator Nexus mieszczą jedną lub więcej konteneryzowaną funkcję sieciową (CNF), które działają na maszynie wirtualnej (VM). Węzeł Kubernetes reprezentuje jedną maszynę wirtualną. Węzły platformy Kubernetes mogą być węzłami płaszczyzny sterowania lub węzłami procesu roboczego . Węzły płaszczyzny sterowania zawierają składniki zarządzania klastra Kubernetes. Węzły robocze przechowują obciążenia aplikacji najemcy.

Grupy węzłów roboczych platformy Kubernetes są nazywane pulami agentów. Pule agentów to konstrukcja Operatora Nexus, a nie konstrukcja Kubernetes.

Każdy serwer obliczeniowy bez systemu operacyjnego w wystąpieniu Operatora Nexus ma przełącznik , który jest koligowany z pojedynczą komórką NUMA na serwerze bez systemu operacyjnego. Switchdev zawiera zestaw portów reprezentantów SR-IOV VF, które zapewniają łączność z zestawem urządzeń mostkowych używanych do przechowywania tabel routingu w różnych sieciach.

Oprócz interfejsu defaultcni Operator Nexus ustanawia cloudservices interfejs sieciowy na każdym węźle. Interfejs cloudservices sieciowy jest odpowiedzialny za routing ruchu przeznaczonego dla punktów końcowych znajdujących się poza siedzibą klienta. Interfejs cloudservices sieciowy odpowiada zasobowi interfejsu API zdefiniowanemu NetworkCloud.CloudServicesNetwork przez użytkownika przed utworzeniem klastra Kubernetes Nexus. Adres IP przypisany do interfejsu cloudservices sieciowego jest adresem lokalnym linku, dzięki czemu ruch sieciowy zewnętrzny zawsze przechodzi przez ten konkretny interfejs.

Oprócz interfejsów sieciowych defaultcni i cloudservices, operator Nexus tworzy jeden lub więcej interfejsów sieciowych w każdym węźle Kubernetes, które odpowiadają skojarzeniom z NetworkCloud.L2Network, NetworkCloud.L3Network i NetworkCloud.TrunkedNetwork z klastrem Nexus Kubernetes lub AgentPool.

Tylko maszyny wirtualne puli agentów mają te dodatkowe interfejsy sieciowe. Maszyny wirtualne płaszczyzny sterowania mają tylko interfejsy sieciowe defaultcni i cloudservices.

Zarządzanie adresami IP węzłów (IPAM)

Węzły w puli agentów otrzymują adres IP z puli adresów IP skojarzonych z zasobem NetworkCloud.L3Network, określonym w polu networkConfiguration.cniNetworkId zasobu NetworkCloud.KubernetesCluster. Ta defaultcni sieć jest bramą domyślną dla wszystkich Podów, które działają na tym węźle, i służy jako domyślna sieć dla komunikacji między Podami na kierunku wschód-zachód w klastrze Nexus Kubernetes.

Sieć podów

Zasobniki Kubernetes to zbiory jednego lub więcej obrazów kontenerów, które działają w przestrzeni nazw systemu Linux. Ta przestrzeń nazw systemu Linux izoluje procesy i zasoby kontenera od innych kontenerów i procesów na hoście. W przypadku klastrów Nexus Kubernetes ten "host" to maszyna wirtualna reprezentowana jako węzeł roboczy Kubernetes.

Przed utworzeniem klastra Kubernetes Operatora Nexus, użytkownicy najpierw tworzą zestaw zasobów reprezentujących sieci wirtualne, z których przypisywane są adresy dla obciążeń dzierżawców. Te sieci wirtualne są następnie przywołyne w cniNetworkIdpolach , cloudServicesNetworkId, agentPoolL2Networks, agentPoolL3Networksi agentPoolTrunkedNetworks podczas tworzenia klastra Kubernetes Operatora Nexus.

Pody mogą być uruchamiane na dowolnym serwerze obliczeniowym w dowolnej szafie w przykładzie Operator Nexus. Domyślnie wszystkie pody w klastrze Nexus Kubernetes mogą komunikować się ze sobą za pośrednictwem sieci podów. Kilka pluginów Container Networking Interface (CNI), które są instalowane w każdym węźle roboczym Nexus Kubernetes, zarządzają siecią Podów.

Dodatkowe sieci

Podczas tworzenia zasobnika w klastrze Kubernetes Nexus należy zadeklarować wszelkie dodatkowe sieci, do których zasobnik powinien zostać dołączony, określając adnotację k8s.v1.cni.cnf.io/networks . Wartość adnotacji to lista nazw sieci oddzielona przecinkami. Te nazwy sieci odpowiadają nazwam dowolnych sieci magistrali, L3 lub L2 skojarzonych z klastrem Kubernetes Nexus lub pulą agentów.

Operator Nexus konfiguruje maszynę wirtualną puli agentów przy użyciu plików NetworkAttachmentDefinition (NAD), które zawierają konfigurację sieci dla pojedynczej dodatkowej sieci.

Dla każdej sieci magistrali wymienionej w skojarzonych sieciach zasobnika zasobnik pobiera jeden interfejs sieciowy. Obciążenie jest odpowiedzialne za wysyłanie nieprzetworzonego ruchu oznakowanego za pośrednictwem tego interfejsu lub konstruowanie oznakowanych interfejsów na podstawie interfejsu sieciowego.

Dla każdej sieci L2 wymienionej w skojarzonych sieciach zasobnika zasobnik pobiera jeden interfejs sieciowy. Obciążenie jest odpowiedzialne za własne statyczne adresowanie MAC.

Zarządzanie adresami IP zasobnika

Podczas tworzenia klastra Kubernetes Nexus należy określić zakresy adresów IP dla sieci zasobników w polu podCidrs. Po uruchomieniu zasobników wtyczka CNI ustanawia eth0@ifXX interfejs w zasobniku i przypisuje adres IP z zakresu adresów IP w tym podCidrs polu.

Dla sieci L3, jeśli sieć została skonfigurowana do korzystania z Nexus IPAM, interfejs sieciowy Poda skojarzony z siecią L3 otrzymuje adres IP z zakresu adresów IP (CIDR) skonfigurowanego dla tej sieci. Jeśli sieć L3 nie jest skonfigurowana do korzystania z usługi Nexus IPAM, obciążenie jest odpowiedzialne za statyczne przypisywanie adresu IP do interfejsu sieciowego zasobnika.

Trasowanie

Wewnątrz każdego zasobnika ruch interfejsu eth0 przechodzi przez wirtualne urządzenie Ethernet (veth), które łączy się z urządzeniem switchdev na hoście (maszynie wirtualnej), który zawiera interfejsy poziomu węzła, takie jak defaultcni, cloudservices i inne.

Interfejs eth0 w zasobniku zawiera prostą tabelę tras, która efektywnie używa tabeli tras maszyny wirtualnej węzła roboczego dla dowolnego z następujących rodzajów ruchu.

• pl-PL: Ruch zasobnika do zasobnika: ruch przeznaczony na adres IP w zakresach adresów podCidrs przepływa do switchdev na hostującej maszynie wirtualnej oraz za pośrednictwem interfejsu na poziomie węzła defaultcni, gdzie jest kierowany do odpowiedniego adresu IP maszyny wirtualnej w puli agentów docelowych.
• L3 Ruch sieciowy OSDevice: Ruch przeznaczony dla adresu IP w skojarzonej sieci L3 z pluginem typu OSDevice przepływa do switchdev na maszynie wirtualnej hosta i za pośrednictwem interfejsu na poziomie węzła skojarzonego z tą siecią L3.
• Cały inny ruch przechodzi do domyślnej bramy w Podzie, która kieruje go do interfejsu cloudservices na poziomie węzła. Reguły ruchu wychodzącego skonfigurowane w usłudze CloudServicesNetwork skojarzone z klastrem Nexus Kubernetes określają następnie sposób kierowania ruchu.

Dodatkowe interfejsy sieciowe wewnątrz Pod będą używać jego tabeli tras do kierowania ruchu do dodatkowych sieci L3, które korzystają z typów wtyczek SRIOV i DPDK.

Konfiguracja protokołu CNI BFD i BGP

Domyślna konfiguracja BFD

Parametry wykrywania przekazywania dwukierunkowego (BFD) można skonfigurować dla każdej sesji BGP. Czasomierze BFD są negocjowane między klastrami Kubernetes Operator Nexus a routerem równorzędnym. Wybrano wyższą wartość czasomierza między dwoma routerami, co jest standardowym zachowaniem BFD. Klastry Nexus Kubernetes używają następujących wartości

• Interwał: 300 ms
• Mnożnik: 3
  Jeśli usługa BFD nie jest włączona na routerze równorzędnym, sesja nie zostanie ustanowiona.

Domyślne konfiguracje protokołu BGP

Czasomierze protokołu BGP (Border Gateway Protocol) są negocjowane między klastrami Operator Nexus Kubernetes i routerem równorzędnym. Wybrana jest najniższa wartość czasomierza blokady między dwoma routerami, która jest standardowym zachowaniem protokołu BGP. Klastry Nexus Kubernetes używają następujących wartości

• czas wstrzymania: 240 sekund hold-time
• interwał utrzymania aktywności: 1/3 czasu wstrzymania (80s) Jeśli istnieje również sesja BFD, protokół BGP będzie korzystać z BFD do wykrywania nieudanych elementów równorzędnych.