Wdrażanie aplikacji i zarządzanie zasobami sieciowymi na Azure AKS (Azure Kubernetes Service)

Azure Kubernetes Service (AKS) ułatwia wdrażanie zarządzanego klastra Kubernetes na platformie Azure. Jako hostowana usługa Kubernetes platforma Azure obsługuje krytyczne zadania, takie jak monitorowanie kondycji i konserwacja. Ponieważ wzorce kubernetes są zarządzane przez platformę Azure, zarządzamy tylko węzłami agentów.

Klaster Azure AKS można utworzyć przy użyciu interfejsu wiersza polecenia (CLI) platformy Azure, przez portal Azure lub Azure PowerShell. Użytkownicy mogą również tworzyć opcje wdrażania oparte na szablonach za pomocą szablonów usługi Azure Resource Manager.

Dlaczego AKS?

Podstawowymi zaletami AKS są elastyczność, automatyzacja i mniejsze koszty zarządzania dla administratorów i deweloperów. Na przykład AKS automatycznie konfiguruje wszystkie węzły Kubernetes, które kontrolują i zarządzają węzłami roboczymi podczas procesu wdrażania i obsługuje szereg innych zadań, w tym integrację Azure Active Directory (AD), połączenia z usługami monitorowania i konfiguracją zaawansowanych funkcji sieciowych, takich jak jako routing aplikacji HTTP. Użytkownicy mogą bezpośrednio monitorować klaster lub wyświetlać wszystkie klastry za pomocą Azure Monitor.

Dlaczego właśnie warto zarządzać  klastrami za pomocą usługi AKS?

Jeżeli klient chce wdrożyć własny klaster, przyjmuje się, że  powinien posiadać przynajmniej trzy master nody, którymi będzie zarządzał – 3 nody to oczywiście kolejne koszty, z którymi musi mierzyć się deweloper. Z upływem czasu, a co za tym idzie zwiększeniem potrzeb i wielkością takiego klastra, wdrażana lokalnie aplikacja staje się coraz bardziej kosztowną inwestycją.  Dla porównania, jeśli klient zdecyduje się na uruchomienie klastra w AKS na platformie Azure, część zarządzania nim jest za darmo. Azure AKS jest bezpłatną usługą, płaci się tylko za węzły agentów w klastrach, a nie za wzorce. Kolejnym plusem założenia tam klastra jest dostępna dla użytkownika lista metryk, która pomoże deweloperowi zbudować cały zestaw alertów pozwalający na wgląd do wnętrza klastra Kubernetesa. Gwarantuje to możliwość obserwacji i monitoringu nie tylko nody’ów, ale całego systemu usługi.

Architektury AKS, a zapotrzebowanie aplikacji.

Wdrażanie aplikacji na Kubernetesie często ciągnie za sobą szereg zmian i nieplanowanych transformacji. Ważne jest, aby usługa, z której korzystamy, była elastyczna oraz posiadała funkcje, które pozwolą na podporządkowanie jej idealnie do potrzeb. AKS daje taką możliwość, między innymi, dzięki zdolności zaimplementowania klastra z integracją ze środowiskiem on-premise.

AKS - integracja z siecią on-premise.

Istnieje kilka przykładów ilustrujących integrację klastra ze środowiskiem on-premise.

Podczas tworzenia klastra na platformie Azure należy wybrać konfigurację, gdzie domyślnym wyborem jest użycie pluginu Kubenet. Kubenet to bardzo podstawowa, prosta wtyczka sieciowa, używana razem z dostawcą usług w chmurze, który konfiguruje reguły routingu dla komunikacji między węzłami lub w środowiskach z jednym węzłem.

Na poniższym diagramie przedstawiona jest warstwa sieciowa połączona pomiędzy Pod’em, Nod’em i siecią, w której zostały uruchomione Nod’y  w klastrze korzystającym z wtyczki kubenet. W tym przypadku ruch sieciowy między Pod’ami a Nod’ami jest w oparciu o NAT. Oznacza to całkowitą oddzielność adresacji – każda próba kontaktu z Pod’em uruchomionym na Nod’zie kończy się na NAT, za który z kolei odpowiada Host, na którym uruchomiony jest sam Pod.

Korzystając z kubenet, węzły uzyskują adres IP z podsieci sieci wirtualnej platformy Azure. Pod’y otrzymują adres IP z logicznie innej przestrzeni adresowej do podsieci sieci wirtualnej platformy Azure węzłów. Translacja adresów sieciowych (NAT) jest następnie konfigurowana tak, aby pod’y mogły uzyskać dostęp do zasobów w sieci wirtualnej platformy Azure. Źródłowy adres IP ruchu to NAT do podstawowego adresu IP węzła. Takie podejście znacznie zmniejsza liczbę adresów IP, które należy zarezerwować w przestrzeni sieciowej, aby można było z nich korzystać.

Rozlokowanie usługi AKS przy wykorzystaniu Kubenet’a gwarantuje powstanie nowej sieci – z automatu korzysta z całej klasy adresów na potrzeby nowej usługi. Ta konfiguracja będzie zawsze identyczna, co niesie za sobą pewne konsekwencje.  Jeśli użytkownik uruchomi usługę AKS na platformie Azure, gdzie sieć tworzy się automatycznie (np. z adresacją 10.0.0.0), a pod koniec projektu okaże się, że klient potrzebował integrować się z  on-premisem, niestety, będzie to niemożliwe. Przy korzystaniu z ustawień domyślnych z Kubenet’a, trzeba mieć na uwadze, że zwykłe ustawienia mogą nie sprostać oczekiwaniom projektu.

Azure CNI

Należy jednak zaznaczyć, że Kubenet to nie jedyna opcja wyboru konfiguracji sieciowej, którą proponuje AKS. Od domyślnych ustawień, usługa Azure Container Network Interface różni się tym, że, każdy pod otrzymuje adres IP z podsieci i można uzyskać do niego bezpośredni dostęp. Te adresy IP muszą być unikalne w całej przestrzeni sieciowej i należy je zaplanować z wyprzedzeniem. Każdy węzeł ma parametr konfiguracyjny dla maksymalnej liczby obsługiwanych przez niego pod’ów. Równoważna liczba adresów IP na węzeł jest następnie rezerwowana z góry dla tego węzła. Takie podejście wymaga więcej planowania i często prowadzi do wyczerpania adresów IP lub konieczności przebudowy klastrów w większe podsieci w miarę wzrostu wymagań aplikacji.

Użytkownik, tworząc klaster, tworzy nową sieć lub wybiera istniejącą oraz może zdefiniować podsieć, która będzie wykorzystywana dla adresacji nod’ów i pod’ów, ale również zakres adresów, wykorzystywanych do usług, które będą uruchamiane w klastrze Kubernetesa.

Należy pamiętać, że w przypadku serwisów, użytkownik jedynie podaje i deklaruje jakie adresy mają być wykorzystane, ale ich nie rezerwuje. Klient nie tworzy żadnej sieci lub podsieci, którą później przypisze do serwisów w usłudze AKS.

Przy wdrożeniu usługi, warto też pamiętać, że istnieją takie adresy, które są już zarezerwowane i których zaimplementowanie nie jest możliwe. Jednym z takich adresów jest, np.: 172.30.0.0/16.

Kolejnym aspektem związanym z różnicą między wtyczką Azure CNI a kubenet jest limit – domyślna wartość Pod’ów, jaką uruchamiamy w klastrze Kubernetesa na pojedynczym Nodzi’e. W przypadku Kuberneta domyślna wartość wynosi 110, czyli posiadając pojedynczego Nod’a w usłudze AKS, można uruchomić na nim 110 Pod’ów. Dla Azure CNI ta liczba wynosi 30.

Procesy komunikacji

AKS tworzy sieć główną [vnet-main], do której klient może wdrożyć swoje projekty, bądź zostawić sieć pustą. W tej sieci możemy stworzyć VPN- gateway, który będzie miał połączenie z infrastrukturą on-premise. AKS dla każdego produktu tworzy nową osobną sieć na platformie Azure, na przykład, żeby rozróżnić środowisko produkcyjne i deweloperskie. Osobne sieci tworzą pewnego rodzaju izolację logiczną, a poprzez łączenie z siecią główną, klient może zezwolić, na to, aby to, co zostało uruchomione wewnątrz klastra Kubernetesa, miało dostęp do innych zasobów, które użytkownik uruchomi na platformie Azure i umieści je w vnet-main. Jest również możliwość przekierowania ruchu, tak, aby zdobyć dostęp do zasobów znajdujących się lokalnie. Nawet w sytuacji, gdy klient tworzy kolejne produkty (również oparte o AKS), usługa pozwala na tworzenie kolejnych sieci, kolejnych węzłów, które umożliwiają dostęp do zasobów lokalnych.

Podsumowanie

Do celów produkcyjnych obie opcje są prawidłowe i obsługiwane przez firmę Microsoft. Należy pamiętać, że kubenet, ponieważ używa NAT w Azure, oznacza, że jest to dodatkowa warstwa w pakietach enkapsulowanych VXLAN, co może spowodować dodatkowe opóźnienia. Ponadto korzystanie z usługi Azure CNI oznacza, że musisz zaplanować zakresy adresów IP. Jeśli planujesz na przykład używać usługi Azure CNI w połączeniu z Azure NetApp Files, musisz również zaplanować liczbę żądanych/wymaganych adresów IP, ponieważ pliki NetApp obsługują tylko 1000 adresów IP w ramach tej samej sieci wirtualnej (i równorzędnej sieci wirtualnej).