Przy uruchamianiu klastra Kubernetes dla konkretnej aplikacji należy zrozumieć, jakie wymagania stawia ta aplikacja, biznes i programiści. Posiadając te informacje, można przystąpić do podejmowania decyzji architektonicznych, w szczególności do wyboru konkretnego kontrolera Ingress, których obecnie jest wiele. Aby stworzyć podstawowe pojęcie o dostępnych opcjach bez konieczności przeszukiwania wielu artykułów/dokumentacji itp., przygotowaliśmy ten przegląd, w którym uwzględniliśmy głównych (gotowych do produkcji) kontrolerów Ingress.
Mamy nadzieję, że pomoże on kolegom w wyborze decyzji architektonicznej — przynajmniej będzie punktem wyjścia do uzyskania bardziej szczegółowych informacji i praktycznych eksperymentów. Uprzednio zbadaliśmy inne podobne materiały w sieci i, co ciekawe, nie znaleźliśmy żadnego bardziej w miarę kompletnego, a przede wszystkim — uporządkowanego — przeglądu. Zatem uzupełnijmy tę lukę!
Kryteria
Aby w ogóle przeprowadzić porównanie i uzyskać jakiekolwiek użyteczne wyniki, należy zrozumieć nie tylko obszar tematyczny, ale także mieć konkretną listę kryteriów, które będą wyznaczać kierunek badań. Nie pretendując do analizy wszystkich możliwych przypadków zastosowania Ingress/Kubernetes, staraliśmy się wyróżnić najbardziej ogólne wymagania dotyczące kontrolerów — bądźcie gotowi na to, że wszelkie szczegóły i specyfika będą musiały być badane osobno.
Zacznę jednak od cech, które stały się na tyle powszechne, że są zrealizowane we wszystkich rozwiązaniach i nie są omawiane:
- dynamiczne odkrywanie usług (service discovery);
- terminowanie SSL;
- praca z websocketami.
Teraz — o punktach porównania:
Obsługiwane protokoły
Jeden z podstawowych kryteriów wyboru. Wasze oprogramowanie może nie działać według standardowego protokołu HTTP lub wymagać pracy od razu z wieloma protokołami. Jeśli wasz przypadek jest niestandardowy, koniecznie weźcie pod uwagę ten czynnik, aby nie trzeba było później ponownie konfigurować klastra. Lista obsługiwanych protokołów różni się w zależności od kontrolera.
Oprogramowanie w podstawie
Istnieje kilka rodzajów aplikacji, na których oparty jest kontroler. Popularne to nginx, traefik, haproxy, envoy. W ogólnym przypadku może to nie mieć dużego wpływu na to, jak ruch jest odbierany i przesyłany, jednak zawsze warto znać potencjalne niuanse i szczegóły tego, co „pod maską”.
Trasowanie ruchu
Na podstawie czego można podejmować decyzje o kierowaniu ruchu do konkretnej usługi? Zazwyczaj jest to host i ścieżka, ale istnieją również dodatkowe możliwości.
Przestrzeń nazw w klastrze
Przestrzeń nazw (namespace) – możliwość logicznego podziału zasobów w Kubernetes (na przykład na stage, production itp.). Są kontrolery Ingress, które należy instalować osobno w każdej przestrzeni nazw (i wtedy mogą kierować ruch tylko do podów tej przestrzeni). A są i takie (i jest ich zdecydowana większość), które działają globalnie na cały klaster – w nich ruch kierowany jest do dowolnego poda w klastrze, niezależnie od przestrzeni nazw.
Pingi dla upstreamów
W jaki sposób zapewniane jest kierowanie ruchu do zdrowych instancji aplikacji, usług? Istnieją opcje z aktywnymi i pasywnymi kontrolami, powtórnymi próbami (retries), circuit breakers (więcej na ten temat można znaleźć na przykład w ), własnymi realizacjami kontroli zdrowia (custom health checks) itp. Jest to bardzo ważny parametr, jeśli masz wysokie wymagania dotyczące dostępności i terminowego wyłączenia z obciążenia usług, które uległy awarii.
Algorytmy balansowania
Tutaj jest wiele opcji: od tradycyjnych do egzotycznych, takich jak , a także dodatkowe możliwości, takie jak .
Autoryzacja
Jakie schematy autoryzacji obsługuje kontroler? Basic, digest, oauth, external-auth – myślę, że te opcje powinny być znane. To ważny kryterium, jeśli korzysta się z wielu obwodów dla deweloperów (i/lub po prostu zamkniętych), do których dostęp realizowany jest poprzez Ingress.
Rozdzielanie ruchu
Czy kontroler obsługuje takie powszechnie stosowane mechanizmy rozdzielania ruchu, jak wdrożenia kanarowe (canary), testy A/B, mirroring/shadowing? To naprawdę ważny temat dla aplikacji, które wymagają dokładnego i precyzyjnego zarządzania ruchem do testów produkcyjnych, debugowania błędów produktów nie na żywo (lub przy minimalnych stratach), analizy ruchu itp.
Subskrypcja płatna
Czy istnieje płatna wersja kontrolera z rozszerzonymi funkcjonalnościami i/lub wsparciem technicznym?
Interfejs graficzny (Web UI)
Czy istnieje jakikolwiek graficzny interfejs do zarządzania konfiguracją kontrolera? Głównie dla „wygody” i/lub dla tych, którzy muszą wprowadzać zmiany w konfiguracji Ingress, ale praca z „surowymi” szablonami jest niewygodna. Może być przydatny, gdy programiści chcą przeprowadzać jakieś eksperymenty z ruchem na bieżąco.
Weryfikacja JWT
Obecność wbudowanej weryfikacji tokenów JSON web do autoryzacji i walidacji użytkownika w aplikacji końcowej.
Możliwości dostosowania konfiguracji
Rozszerzalność szablonów w sensie dostępności mechanizmów pozwalających na dodawanie w standardowych szablonach konfiguracji własnych dyrektyw, flag itp.
Podstawowe mechanizmy ochrony przed DDOS
Proste algorytmy limitujące ruch lub bardziej złożone opcje filtrowania ruchu na podstawie adresów, białych list, krajów itp.
Śledzenie zapytań
Możliwości monitorowania, śledzenia i debugowania zapytań od Ingress do konkretne usługi/pod'y, a idealnie — również między usługami/pod'ami.
WAF
Wsparcie .
Kontrolery Ingress
Lista kontrolerów została opracowana na podstawie i . Niektóre z nich zostały wykluczone z przeglądu z powodu specyfiki lub małej popularności (wczesna faza rozwoju). Pozostałe są omówione poniżej. Zacznijmy od ogólnego opisu rozwiązań i kontynuujmy zestawieniem tabeli.
Ingress od Kubernetes
Strona:
Licencja: Apache 2.0
To oficjalny kontroler dla Kubernetes, który jest rozwijany przez społeczność. Jak wskazuje nazwa, oparty jest na nginx i wzbogacony o różny zestaw wtyczek Lua, stosowanych do realizacji dodatkowych możliwości. Dzięki popularności samego nginx i minimalnym modyfikacjom przy użyciu jako kontrolera, ta opcja może być najprostszą i najbardziej zrozumiałą w konfiguracji dla przeciętnego inżyniera (z doświadczeniem w web).
Ingress od NGINX Inc
Strona:
Licencja: Apache 2.0
Oficjalny produkt twórców nginx. Posiada płatną wersję opartą na Główną ideą jest wysoki poziom stabilności, ciągła wsteczna kompatybilność, brak jakichkolwiek zewnętrznych modułów i zadeklarowana zwiększona prędkość (w porównaniu do oficjalnego kontrolera), osiągnięta dzięki rezygnacji z Lua.
Wersja darmowa jest znacznie okrojona, nawet w porównaniu do oficjalnego kontrolera (ze względu na brak tych samych modułów Lua). Wersja płatna oferuje natomiast dość szeroką gamę dodatkowych funkcji: metryki w czasie rzeczywistym, walidację JWT, aktywne health checki i inne. Ważną zaletą w porównaniu do NGINX Ingress jest pełne wsparcie dla ruchu TCP/UDP (również w wersji community!). Minusem jest niedobór funkcji do rozkładania ruchu, co jednak „ma najwyższy priorytet dla programistów”, ale wymaga czasu na realizację.
Kong Ingress
Strona:
Licencja: Apache 2.0
Produkt rozwijany przez firmę Kong Inc. w dwóch wersjach: komercyjnej i darmowej. Opiera się na nginx, którego możliwości zostały rozszerzone o szereg modułów na Lua.
Początkowo był skierowany na obsługę i routowanie żądań API, tj. jako API Gateway, jednak obecnie stał się pełnoprawnym kontrolerem Ingress. Główne zalety: wiele dodatkowych modułów (w tym od zewnętrznych programistów), które można łatwo zainstalować i skonfigurować, a które umożliwiają realizację szerokiego wachlarza dodatkowych możliwości. Niemniej wbudowane funkcje oferują już wiele możliwości. Konfiguracja pracy odbywa się za pomocą zasobów CRD.
Ważną cechą produktu jest działanie w ramach jednego konturu (w przeciwieństwie do cross-namespaced), co jest kontrowersyjnym tematem: dla niektórych może to być wadą (konieczność tworzenia jednostek dla każdego konturu), a dla innych – funkcjonalnością (większy poziom izolacji, ponieważ jeśli jeden kontroler zawiedzie, problem ogranicza się tylko do jednego konturu).większąwiększy poziom izolacji, ponieważ jeśli jeden kontroler ulegnie awarii, problem dotyczy tylko jednego konturu.
Traefik
Strona:
Licencja: MIT
Proxy, który został pierwotnie stworzony do pracy z routowaniem zapytań dla mikrousług i ich dynamicznego środowiska. Stąd też wiele przydatnych funkcji: aktualizacja konfiguracji bez restartów, wsparcie dla wielu metod balansowania, interfejs webowy, przekazywanie metryk, wsparcie dla różnych protokołów, REST API, wersje kanaryjskie i wiele innych. Miłą cechą jest także wsparcie dla certyfikatu Let’s Encrypt od razu po zainstalowaniu. Niedogodnością jest to, że aby zorganizować wysoką dostępność (HA), kontroler będzie musiał mieć zainstalowane i podłączone własne przechowywanie KV.
HAProxy
Strona:
Licencja: Apache 2.0
HAProxy jest od dawna znany jako proxy i równoważnik obciążenia. W ramach klastra Kubernetes oferuje "miękką" aktualizację konfiguracji (bez utraty ruchu), odkrywanie usług na podstawie DNS, dynamiczną konfigurację za pomocą API. Atrakcyjną cechą jest pełna personalizacja szablonu konfiguracji poprzez zamianę CM’a, a także możliwość używania funkcji biblioteki Sprig. Ogólnie rzecz biorąc, główny nacisk tej decyzji kładzie się na dużą szybkość działania, optymalizację i efektywność w zużywanych zasobach. Zaletą kontrolera jest wsparcie rekordowej liczby różnych metod balansowania.
Voyager
Strona:
Licencja: Apache 2.0
Kontroler oparty na HAproxy, który jest pozycjonowany jako uniwersalne rozwiązanie, oferujące szerokie możliwości na dużej liczbie dostawców. Oferuje możliwość równoważenia ruchu na L7 i L4, a równoważenie ruchu TCP L4 można określić jako jedną z kluczowych cech tego rozwiązania.
Contour
Strona:
Licencja: Apache 2.0
Podstawą tego rozwiązania nie tylko jest Envoy: zostało opracowane wspólnie z autorami tego popularnego proxy. Ważną cechą jest możliwość podziału zarządzania zasobami Ingress za pomocą zasobów CRD IngressRoute. Dla organizacji z wieloma zespołami deweloperskimi używającymi jednego klastra, pomaga to maksymalnie zabezpieczyć pracę z ruchem w sąsiednich konturach i chronić je przed błędami podczas zmiany zasobów Ingress.
Oferowany jest również rozszerzony zestaw metod równoważenia obciążenia (obecne są lustrowanie zapytań, automatyczne powtórki, ograniczenia dotyczące liczby zapytań i wiele więcej), szczegółowy monitoring ruchu i awarii. Może dla niektórych istotnym minusem będzie brak wsparcia dla sesji połączonych (choć prace ).
Istio Ingress
Strona:
Licencja: Apache 2.0
Kompleksowe rozwiązanie service mesh, które jest nie tylko kontrolerem Ingress zarządzającym przychodzącym ruchem zewnętrznym, ale także kontroluje cały ruch w ramach klastra. ‘Pod maską’, jako proxy sidecar dla każdej usługi, używany jest Envoy. W istocie to duży kombajn, który ‘może wszystko’, a jego główną ideą jest maksymalna kontrolowalność, rozszerzalność, bezpieczeństwo i przezroczystość. Dzięki niemu możesz szczegółowo konfigurować trasowanie ruchu, autoryzację dostępu między usługami, równoważenie obciążenia, monitoring, releasy kanaryjne i wiele więcej. Szczegóły o Istio znajdziesz w serii artykułów ‘».
Ambassador
Strona:
Licencja: Apache 2.0
Kolejne rozwiązanie oparte na Envoy. Posiada wersje darmowe i komercyjne. Pozycjonuje się jako ‘w pełni natywne dla Kubernetes’, co przynosi odpowiednie korzyści (ścisła integracja z metodami i encjami klastra K8s).
Tabela porównawcza
Zatem kulminacją artykułu jest ta ogromna tabela:
Jest klikalna, aby umożliwić bardziej szczegółowy przegląd, a także dostępna w formacie .
Podsumujmy
Celem artykułu jest dostarczenie pełniejszego zrozumienia (choć zupełnie nie wyczerpującego!) tego, jaki wybór należy dokonać w Twoim konkretnym przypadku. Jak to zwykle bywa, każdy kontroler ma swoje zalety i wady...
Klasyczny Ingress od Kubernetes jest ceniony za swoją dostępność i niezawodność oraz bogate możliwości — ogólnie rzecz biorąc, powinien wystarczyć w większości przypadków. Jeśli jednak Twoje wymagania co do stabilności, funkcji i rozwoju są wyższe, warto zwrócić uwagę na Ingress z NGINX Plus i płatną subskrypcją. Kong oferuje bogaty zestaw wtyczek (i związanych z nimi możliwości), a w wersji płatnej jest ich jeszcze więcej. Posiada szerokie możliwości pracy jako API Gateway oraz dynamicznej konfiguracji na podstawie zasobów CRD, a także podstawowych usług Kubernetes.
Przy zwiększonych wymaganiach dotyczących równoważenia obciążenia i metod autoryzacji warto przyjrzeć się Traefik oraz HAProxy. To projekty Open Source, które zostały sprawdzone przez lata, są bardzo stabilne i aktywnie rozwijane. Contour istnieje od kilku lat, ale nadal wygląda na stosunkowo młody i ma jedynie podstawowe możliwości, dodane na podstawie Envoy. Jeśli masz wymogi dotyczące posiadania/wbudowania WAF przed aplikacją, warto zwrócić uwagę na ten sam Ingress od Kubernetes lub HAProxy.
Najbardziej funkcjonalne są produkty zbudowane na bazie Envoy, szczególnie Istio. Uznawany jest za kompleksowe rozwiązanie, które "może wszystko", co jednak oznacza znacznie wyższy próg wejścia w zakresie konfiguracji/uruchomienia/administrowania w porównaniu do innych rozwiązań.
Jako standardowy kontroler wybraliśmy i nadal używamy Ingress od Kubernetes, który pokrywa 80–90% potrzeb. Jest całkiem niezawodny, łatwy do konfiguracji i rozszerzania. Z reguły, przy braku specyficznych wymagań, powinien pasować do większości klastrów/aplikacji. Z podobnych uniwersalnych i stosunkowo prostych produktów można polecić Traefik i HAProxy.
P.S.
Przeczytaj także na naszym blogu:
- „Powrót do mikroserwisów z Istio”: , , ;
- «»;
- «».
Źródło: habr.com
