Pojęcia dotyczące sieci kontenerów
Dotyczy: usługa AKS w usłudze Azure Stack HCI 22H2, AKS w systemie Windows Server
Składniki aplikacji muszą współpracować, aby przetwarzać swoje zadania w podejściu mikrousług opartym na kontenerach. Platforma Kubernetes udostępnia zasoby, które umożliwiają komunikację aplikacji i umożliwiają łączenie się z aplikacjami i uwidacznianie ich wewnętrznie lub zewnętrznie. Możesz równoważyć obciążenie aplikacji w celu tworzenia aplikacji o wysokiej dostępności.
Bardziej złożone aplikacje mogą wymagać konfiguracji ruchu przychodzącego na potrzeby kończenia żądań SSL/TLS lub routingu wielu składników. Może być również konieczne ograniczenie przepływu ruchu sieciowego do zasobników i węzłów w celu zapewnienia zabezpieczeń.
W tym artykule przedstawiono podstawowe pojęcia, które zapewniają sieć aplikacjom w usłudze AKS włączone przez usługę Arc:
- Usługi Kubernetes
- Kontroler ruchu przychodzącego
- Zasady sieciowe
Usługi Kubernetes
Aby uprościć konfigurację sieci dla obciążeń aplikacji, platforma Kubernetes używa usług do logicznego grupowania zestawu zasobników i zapewnienia łączności sieciowej. Dostępne są następujące typy usług:
Adres IP klastra: tworzy wewnętrzny adres IP do użycia w klastrze Kubernetes. Użyj adresu IP klastra dla aplikacji tylko wewnętrznych, które obsługują inne obciążenia w klastrze.
NodePort: tworzy mapowanie portów w bazowym węźle, który umożliwia aplikacji bezpośredni dostęp do adresu IP węzła i portu.
LoadBalancer: tworzy zasób modułu równoważenia obciążenia platformy Azure, konfiguruje zewnętrzny adres IP i łączy żądane zasobniki z pulą zaplecza modułu równoważenia obciążenia. Aby zezwolić klientom na dostęp do aplikacji, reguły równoważenia obciążenia są tworzone na żądanych portach.
W przypadku innej kontroli i routingu ruchu przychodzącego można użyć kontrolera ruchu przychodzącego.
Uwaga
Podczas wdrażania klastra docelowego, który współudzieli sieć z innym klastrem docelowym, istnieje możliwość konfliktu adresów IP modułu równoważenia obciążenia.
Może się tak zdarzyć, jeśli wdrożysz dwa obciążenia korzystające z różnych portów w klastrach docelowych współużytkujących ten sam AksHciClusterNetwork obiekt. Ze względu na sposób przydzielania adresów IP i mapowań portów wewnątrz serwera proxy wysokiej dostępności może to prowadzić do zduplikowanego przypisania adresu IP. W takim przypadku jedno lub oba obciążenia mogą napotkać losowe problemy z łącznością sieciową do czasu ponownego wdrożenia obciążeń. Podczas ponownego wdrażania obciążeń można użyć tego samego portu, który powoduje, że każde obciążenie odbiera oddzielny adres IP usługi, lub można ponownie wdrożyć obciążenia w klastrach docelowych, które używają różnych AksHciClusterNetwork obiektów.
ExternalName: tworzy określony wpis DNS, aby ułatwić dostęp do aplikacji. Adresy IP modułów równoważenia obciążenia i usług mogą być adresami wewnętrznymi lub zewnętrznymi w zależności od ogólnej konfiguracji sieci i mogą być przypisywane dynamicznie. Możesz też określić istniejący statyczny adres IP do użycia. Istniejący statyczny adres IP jest często powiązany z wpisem DNS. Wewnętrzne moduły równoważenia obciążenia mają przypisany tylko prywatny adres IP, więc nie można uzyskać do nich dostępu z Internetu.
Podstawy sieci platformy Kubernetes w środowisku lokalnym platformy Azure
Aby umożliwić dostęp do aplikacji lub składnikom aplikacji komunikowanie się ze sobą, platforma Kubernetes zapewnia warstwę abstrakcji sieci wirtualnej. Węzły kubernetes są połączone z siecią wirtualną i mogą zapewnić łączność przychodzącą i wychodzącą dla zasobników. Składnik kube-proxy uruchomiony w każdym węźle udostępnia te funkcje sieciowe.
W usłudze Kubernetes logicznie grupuj zasobniki usług, aby umożliwić:
- Bezpośredni dostęp za pośrednictwem pojedynczego adresu IP lub nazwy DNS i określonego portu.
- Dystrybuuj ruch przy użyciu modułu równoważenia obciążenia między wieloma zasobnikami obsługującymi tę samą usługę lub aplikację.
Platforma lokalna platformy Azure pomaga również uprościć sieć wirtualną dla usługi AKS w klastrach lokalnych platformy Azure, zapewniając sieć "nakładki" w sposób wysoce dostępny.
Podczas tworzenia klastra usługi AKS tworzymy i konfigurujemy bazowy HAProxy zasób modułu równoważenia obciążenia. Podczas wdrażania aplikacji w klastrze Kubernetes adresy IP są konfigurowane dla zasobników i usług Kubernetes jako punktów końcowych w tym module równoważenia obciążenia.
Zasoby adresów IP
Aby uprościć konfigurację sieci dla obciążeń aplikacji, usługa AKS Arc przypisuje adresy IP do następujących obiektów we wdrożeniu:
- Serwer interfejsu API klastra Kubernetes: serwer interfejsu API jest składnikiem płaszczyzny sterowania platformy Kubernetes, która uwidacznia interfejs API platformy Kubernetes. Serwer interfejsu API to fronton płaszczyzny sterowania platformy Kubernetes. Statyczne adresy IP są zawsze przydzielane do serwerów interfejsu API niezależnie od bazowego modelu sieci.
- Węzły Kubernetes (maszyny wirtualne):klaster Kubernetes składa się z zestawu maszyn roboczych, nazywanych węzłami, a węzły hostuje konteneryzowane aplikacje. Oprócz węzłów płaszczyzny sterowania każdy klaster ma co najmniej jeden węzeł roboczy. W przypadku klastra usługi AKS węzły Kubernetes są konfigurowane jako maszyny wirtualne. Te maszyny wirtualne są tworzone jako maszyny wirtualne o wysokiej dostępności w środowisku lokalnym platformy Azure, aby uzyskać więcej informacji, zobacz Pojęcia dotyczące sieci węzłów.
- Usługi Kubernetes: w usłudze Kubernetes logicznie grupuj adresy IP zasobników, aby umożliwić bezpośredni dostęp za pośrednictwem jednego adresu IP lub nazwy DNS na określonym porcie. Usługi mogą również dystrybuować ruch przy użyciu modułu równoważenia obciążenia. Statyczne adresy IP są zawsze przydzielane do usług Kubernetes niezależnie od bazowego modelu sieci.
- Moduły równoważenia obciążenia HAProxy: HAProxy to moduł równoważenia obciążenia TCP/HTTP i serwer proxy, który rozkłada żądania przychodzące na wiele punktów końcowych. Każdy klaster obciążeń w usłudze AKS w lokalnym wdrożeniu platformy Azure ma wdrożony i skonfigurowany jako wyspecjalizowana maszyna wirtualna.
- Lokalna usługa w chmurze firmy Microsoft: jest to lokalny dostawca chmury platformy Azure, który umożliwia tworzenie i zarządzanie zwirtualizowanym środowiskiem hostujące platformę Kubernetes w lokalnym klastrze lokalnym platformy Azure lub klastrze systemu Windows Server. Model sieci, po którym następuje klaster usługi Azure Local lub Windows Server, określa metodę alokacji adresów IP używaną przez lokalną usługę w chmurze firmy Microsoft. Aby dowiedzieć się więcej na temat pojęć związanych z siecią wdrożonych przez lokalną usługę w chmurze firmy Microsoft, zobacz Pojęcia dotyczące sieci węzłów.
Sieci Kubernetes
W usłudze AKS w usłudze Azure Local można wdrożyć klaster, który korzysta z jednego z następujących modeli sieciowych:
- Sieć nakładki flannel — zasoby sieciowe są zwykle tworzone i konfigurowane podczas wdrażania klastra.
- Sieć w programie Project Calico — ten model oferuje dodatkowe funkcje sieciowe, takie jak zasady sieci i sterowanie przepływem.
Obie implementacje sieci używają modelu konfiguracji sieci nakładki, który zapewnia przypisanie adresu IP, które jest odłączone od pozostałej części sieci centrum danych.
Aby dowiedzieć się więcej na temat sieci nakładek, zobacz Introducing: Kubernetes Overlay Networking for Windows (Wprowadzenie do sieci nakładek platformy Kubernetes dla systemu Windows).
Aby uzyskać więcej informacji na temat wtyczki i zasad calico network, zapoznaj się z wprowadzeniem do zasad sieci Calico.
Porównywanie modeli sieciowych
Flanela
Uwaga
Flannel CNI został wycofany w grudniu 2023 roku.
Flannel to warstwa sieci wirtualnej przeznaczona specjalnie dla kontenerów. Platforma Flannel tworzy sieć płaską, która nakłada sieć hosta. Wszystkie kontenery/zasobniki mają przypisany jeden adres IP w tej sieci nakładki i komunikują się bezpośrednio, łącząc się ze sobą adresem IP.
Perkal
Calico to rozwiązanie sieci typu open source i zabezpieczeń sieci dla kontenerów, maszyn wirtualnych i natywnych obciążeń opartych na hoście. Calico obsługuje wiele płaszczyzn danych, w tym: płaszczyznę danych eBPF systemu Linux, płaszczyznę danych sieci systemu Linux i płaszczyznę danych HNS systemu Windows.
Możliwości
| Możliwość | Flanela | Perkal |
|---|---|---|
| Zasady sieciowe | Nie. | Tak |
| Protokół IPv6 | Nie. | Tak |
| Używane warstwy | L2 (VxLAN) | L2 (VxLAN) |
| Wdrażanie klastra w istniejącej lub nowej sieci wirtualnej | Tak | Tak |
| Obsługa systemu Windows | Tak | Tak |
| Połączenie zasobnika | Tak | Tak |
| Połączenie zasobnika, maszyna wirtualna w tej samej sieci | Nie. | Tak |
| Połączenie zasobnika, maszyna wirtualna w innej sieci | Tak | Tak |
| Usługi Kubernetes | Tak | Tak |
| Uwidaczniaj za pośrednictwem modułu równoważenia obciążenia | Tak | Tak |
| Sieci | Wiele sieci w tym samym klastrze z demonem z wieloma demonami | Wiele sieci w tym samym klastrze |
| Wdrożenie | Linux: DaemonSet | Linux: DaemonSet |
| Windows: usługa | Windows: usługa | |
| Wiersz polecenia | Brak | calicoctl |
Ważne
Obecnie domyślnym wyborem jest użycie Calico w trybie sieci nakładki. Aby włączyć usługę Flannel, użyj -primaryNetworkPlugin parametru New-AksHciCluster polecenia programu PowerShell i określ flannel jako wartość. Tej wartości nie można zmienić po wdrożeniu klastra i dotyczy zarówno węzłów klastra systemu Windows, jak i Linux.
Na przykład:
New-AksHciCluster -name MyCluster -primaryNetworkPlugin 'flannel'
Następne kroki
W tym artykule opisano pojęcia dotyczące sieci dla kontenerów w węzłach usługi AKS w usłudze Azure Local. Aby uzyskać więcej informacji na temat usługi AKS na temat pojęć lokalnych platformy Azure, zobacz następujące artykuły: