Uruchamiając klaster Kubernetes dla określonej aplikacji, musisz zrozumieć, co sama aplikacja, biznes i programiści stanowią dla tego zasobu. Dzięki tym informacjom możesz rozpocząć podejmowanie decyzji architektonicznej, aw szczególności wybór konkretnego kontrolera Ingress, których jest już dziś bardzo dużo. Aby uzyskać podstawowe pojęcie o dostępnych opcjach bez konieczności przeglądania wielu artykułów/dokumentacji itp., przygotowaliśmy ten przegląd, w tym główne (gotowe do produkcji) kontrolery Ingress.
Mamy nadzieję, że pomoże kolegom w wyborze rozwiązania architektonicznego - przynajmniej stanie się punktem wyjścia do uzyskania bardziej szczegółowych informacji i praktycznych eksperymentów. Wcześniej studiowaliśmy inne podobne materiały w sieci i, co dziwne, nie znaleźliśmy ani jednej mniej lub bardziej kompletnej, a co najważniejsze - ustrukturyzowanej - recenzji. Wypełnijmy więc tę lukę!
kryteria
Zasadniczo, aby dokonać porównania i uzyskać jakikolwiek użyteczny wynik, musisz zrozumieć nie tylko obszar tematyczny, ale także mieć określoną listę kryteriów, które wyznaczą wektor badań. Nie udając, że analizujemy wszystkie możliwe przypadki wykorzystania Ingress/Kubernetes, staraliśmy się naświetlić najbardziej ogólne wymagania wobec kontrolerów – bądź przygotowany, że w każdym przypadku będziesz musiał przestudiować wszystkie swoje specyfiki i dane z osobna.
Ale zacznę od cech, które stały się tak znajome, że są implementowane we wszystkich rozwiązaniach i nie są brane pod uwagę:
- dynamiczne wykrywanie usług (odkrywanie usług);
- zakończenie SSL;
- praca z websocketami
A teraz punkty porównawcze:
Obsługiwane protokoły
Jedno z podstawowych kryteriów wyboru. Twoje oprogramowanie może nie działać na standardowym HTTP lub może wymagać pracy na wielu protokołach jednocześnie. Jeśli Twój przypadek jest niestandardowy, pamiętaj o uwzględnieniu tego czynnika, aby nie musieć później rekonfigurować klastra. W przypadku wszystkich kontrolerów lista obsługiwanych protokołów jest różna.
oprogramowanie w centrum
Istnieje kilka odmian 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 sposób odbierania i przesyłania ruchu, ale zawsze warto znać potencjalne niuanse i cechy tego, co jest „pod maską”.
Kierowanie ruchem
Na podstawie czego można podjąć decyzję o skierowaniu ruchu do konkretnego serwisu? Zwykle są to host i ścieżka, ale są też dodatkowe możliwości.
Przestrzeń nazw w klastrze
Namespace (namespace) – możliwość logicznego podziału zasobów w Kubernetes (np. na scenę, produkcję itp.). Istnieją kontrolery Ingress, które należy zainstalować osobno w każdej przestrzeni nazw (i wtedy może kierować ruchem tylko do strąków tej przestrzeni). A są takie (i ich zdecydowana większość), które działają globalnie dla całego klastra – w nich ruch kierowany jest do dowolnego poda klastra, niezależnie od przestrzeni nazw.
Próbki dla upstreamów
W jaki sposób ruch jest kierowany do sprawnych instancji aplikacji, usług? Istnieją opcje z aktywnymi i pasywnymi kontrolami, ponownymi próbami, wyłącznikami automatycznymi (Więcej informacji można znaleźć np. ), własne implementacje kontroli stanu (niestandardowe kontrole stanu) itp. Bardzo ważny parametr, jeśli masz wysokie wymagania dotyczące dostępności i terminowego usuwania nieudanych usług z bilansowania.
Algorytmy równoważenia
Istnieje wiele opcji: od tradycyjnych do egzotyki , a także indywidualne funkcje, takie jak .
Uwierzytelnianie
Jakie schematy uprawnień obsługuje kontroler? Basic, digest, oauth, external-auth - myślę, że te opcje powinny być znajome. Jest to ważne kryterium, jeśli istnieje wiele pętli deweloperskich (i/lub tylko prywatnych), do których dostęp uzyskuje się za pośrednictwem Ingress.
Dystrybucja ruchu
Czy kontroler wspiera tak powszechnie stosowane mechanizmy dystrybucji ruchu jak canary rollouts (canary), testy A/B, mirroring ruchu (mirroring/shadowing)? Jest to naprawdę drażliwy temat dla aplikacji, które wymagają dokładnego i precyzyjnego zarządzania ruchem w celu produktywnego testowania, debugowania błędów produktu w trybie offline (lub przy minimalnych stratach), analizy ruchu i tak dalej.
Płatny abonament
Czy istnieje płatna opcja dla kontrolera, z zaawansowaną funkcjonalnością i/lub wsparciem technicznym?
Graficzny interfejs użytkownika (interfejs internetowy)
Czy istnieje GUI do zarządzania konfiguracją kontrolera? Głównie dla "poręczności" i/lub dla tych, którzy potrzebują wprowadzić jakieś zmiany w konfiguracji Ingress'a, ale praca z "surowymi" szablonami jest niewygodna. Może to być przydatne, jeśli programiści chcą przeprowadzać eksperymenty z ruchem w locie.
Walidacja JWT
Obecność wbudowanej walidacji tokenów sieciowych JSON do autoryzacji i walidacji użytkownika do aplikacji końcowej.
Możliwości dostosowania konfiguracji
Rozszerzalność szablonu w sensie posiadania mechanizmów pozwalających na dodawanie własnych dyrektyw, flag itp. do standardowych szablonów konfiguracyjnych.
Podstawowe mechanizmy ochrony DDOS
Proste algorytmy limitów szybkości lub bardziej złożone opcje filtrowania ruchu na podstawie adresów, białych list, krajów itp.
Poproś o śledzenie
Możliwość monitorowania, śledzenia i debugowania żądań z Ingress do określonych usług/podów, a najlepiej także między usługami/podami.
WAF
Wsparcie .
Kontrolery
Lista kontrolerów została utworzona na podstawie и . Niektóre z nich wyłączyliśmy z przeglądu ze względu na specyfikę lub niską częstość występowania (wczesna faza rozwoju). Resztę omówiono poniżej. Zacznijmy od ogólnego opisu rozwiązań i przejdźmy do tabeli podsumowującej.
Ingres z Kubernetes
Strona WWW:
Licencja: Apache 2.0
Jest to oficjalny kontroler dla Kubernetes i jest rozwijany przez społeczność. Oczywiście z nazwy bazuje na nginx i jest uzupełniony innym zestawem wtyczek Lua służących do implementacji dodatkowych funkcji. Ze względu na popularność samego nginx i minimalne modyfikacje, gdy jest używany jako kontroler, ta opcja może być najłatwiejsza i najłatwiejsza do skonfigurowania dla przeciętnego inżyniera (z doświadczeniem w sieci).
Ingres firmy NGINX Inc.
Strona WWW:
Licencja: Apache 2.0
Oficjalny produkt twórców nginx. Ma płatną wersję opartą na . Główną ideą jest wysoki poziom stabilności, stała kompatybilność wsteczna, brak jakichkolwiek dodatkowych modułów i deklarowana zwiększona prędkość (w porównaniu z oficjalnym kontrolerem), osiągnięta dzięki odrzuceniu Lua.
Darmowa wersja jest znacznie zmniejszona, w tym nawet w porównaniu z oficjalnym kontrolerem (ze względu na brak tych samych modułów Lua). Jednocześnie płatny ma dość szeroką dodatkową funkcjonalność: metryki w czasie rzeczywistym, walidację JWT, aktywne kontrole kondycji i więcej. Istotną przewagą nad NGINX Ingress jest pełna obsługa ruchu TCP/UDP (i to w wersji community też!). Minus - funkcja dystrybucji ruchu, która jednak „ma najwyższy priorytet dla programistów”, ale jej wdrożenie wymaga czasu.
Ingres Konga
Strona WWW:
Licencja: Apache 2.0
Produkt opracowany przez Kong Inc. w dwóch wersjach: komercyjnej i bezpłatnej. Oparty na nginx, który został rozszerzony o dużą liczbę modułów Lua.
Początkowo koncentrowała się na przetwarzaniu i routingu żądań API, tj. jako API Gateway, ale w tej chwili stał się pełnoprawnym kontrolerem Ingress. Główne zalety: wiele dodatkowych modułów (w tym od zewnętrznych programistów), które są łatwe w instalacji i konfiguracji oraz za pomocą których wdrażany jest szeroki zakres dodatkowych funkcji. Jednak wbudowane funkcje dają już wiele możliwości. Konfiguracja zadania odbywa się przy użyciu zasobów CRD.
Ważna cecha produktu - praca w obrębie tego samego konturu (zamiast cross-namespaced) jest tematem kontrowersyjnym: dla jednych będzie to wadą (trzeba produkować byty dla każdego konturu), a dla kogoś cechą ( BоWiększy poziom izolacji, jak jeśli jeden kontroler jest uszkodzony, problem ogranicza się do samego obwodu).
Traefik
Strona WWW:
Licencja: MIT
Serwer proxy, który został pierwotnie utworzony do pracy z routingiem żądań dla mikrousług i ich dynamicznego środowiska. Stąd wiele przydatnych funkcji: aktualizacja konfiguracji bez ponownego uruchamiania, obsługa dużej liczby metod równoważenia, interfejs sieciowy, przekazywanie metryk, obsługa różnych protokołów, REST API, wydania kanaryjskie i wiele więcej. Kolejną fajną funkcją jest obsługa certyfikatów Let's Encrypt od razu po wyjęciu z pudełka. Wadą jest to, że w celu zorganizowania wysokiej dostępności (HA) kontroler będzie musiał zainstalować i podłączyć własną pamięć KV.
HAPROXY
Strona WWW:
Licencja: Apache 2.0
HAProxy od dawna jest znany jako proxy i równoważenie ruchu. W ramach klastra Kubernetes oferuje „miękką” aktualizację konfiguracji (bez utraty ruchu), wykrywanie usług w oparciu o DNS, dynamiczną konfigurację z wykorzystaniem API. Atrakcyjne może być całkowite dostosowanie szablonu konfiguracji poprzez wymianę CM, a także możliwość wykorzystania w nim funkcji biblioteki Sprig. Ogólnie rzecz biorąc, główny nacisk rozwiązania kładzie się na dużą prędkość, jej optymalizację i efektywność w zużywanych zasobach. Zaletą sterownika jest obsługa rekordowej liczby różnych metod wyważania.
Podróżnik
Strona WWW:
Licencja: Apache 2.0
Oparte na kontrolerze HAproxy, który jest pozycjonowany jako rozwiązanie uniwersalne obsługujące szeroki zakres funkcji u dużej liczby dostawców. Oferowana jest możliwość równoważenia ruchu na L7 i L4, a równoważenie ruchu TCP L4 jako całości można nazwać jedną z kluczowych cech rozwiązania.
Kontur
Strona WWW:
Licencja: Apache 2.0
To rozwiązanie nie opiera się tylko na Envoy: zostało opracowane przez wspólnie z autorami tego popularnego proxy. Ważną cechą jest możliwość rozdzielenia kontroli zasobów Ingress za pomocą zasobów IngressRoute CRD. W przypadku organizacji z wieloma zespołami programistycznymi korzystającymi z tego samego klastra pomaga to zmaksymalizować bezpieczeństwo pracy z ruchem w sąsiednich pętlach i chronić je przed błędami podczas zmiany zasobów Ingress.
Oferuje również rozszerzony zestaw metod równoważenia (jest dublowanie żądań, automatyczne powtarzanie, ograniczanie szybkości żądań i wiele więcej), szczegółowe monitorowanie przepływu ruchu i awarii. Być może dla kogoś sporym mankamentem będzie brak wsparcia dla sesji sticky (choć praca ).
Istio Ingres
Strona WWW:
Licencja: Apache 2.0
Kompleksowe rozwiązanie service mesh, które jest nie tylko kontrolerem Ingress zarządzającym ruchem przychodzącym z zewnątrz, ale także kontroluje cały ruch wewnątrz klastra. Pod maską Envoy jest używany jako sidecar proxy dla każdej usługi. Zasadniczo jest to duży kombajn, który „może zrobić wszystko”, a jego główną ideą jest maksymalna łatwość zarządzania, rozszerzalność, bezpieczeństwo i przejrzystość. Dzięki niemu możesz precyzyjnie dostroić routing ruchu, autoryzację dostępu między usługami, równoważenie, monitorowanie, zwolnienia kanaryjskie i wiele więcej. Przeczytaj więcej o Istio w serii artykułów "".
Ambasador
Strona WWW:
Licencja: Apache 2.0
Kolejne rozwiązanie oparte na Envoy. Ma wersje darmowe i komercyjne. Jest pozycjonowany jako „w pełni natywny dla Kubernetes”, co przynosi odpowiednie korzyści (ścisła integracja z metodami i podmiotami klastra K8s).
Tabela porównawcza
Tak więc zwieńczeniem artykułu jest ten ogromny stół:
Można go kliknąć, aby zobaczyć go z bliska, a także jest dostępny w formacie .
Podsumowując
Celem tego artykułu jest zapewnienie pełniejszego zrozumienia (jednak nie wyczerpującego!) wyboru, jakiego należy dokonać w konkretnym przypadku. Jak zwykle każdy kontroler ma swoje zalety i wady…
Klasyczny Ingress od Kubernetes jest dobry ze względu na swoją dostępność i praktyczność, wystarczająco bogaty w funkcje – w ogólnym przypadku powinien „wystarczać dla oczu”. Jeśli jednak pojawiają się zwiększone wymagania dotyczące stabilności, poziomu funkcjonalności i rozwoju, warto zwrócić uwagę na Ingress z NGINX Plus i płatną subskrypcją. Kong ma najbogatszy zestaw wtyczek (a co za tym idzie możliwości, jakie dają), aw wersji płatnej jest ich jeszcze więcej. Posiada szerokie możliwości pracy jako API Gateway, dynamiczną konfigurację opartą na zasobach CRD, a także podstawowe usługi Kubernetes.
Przy zwiększonych wymaganiach dotyczących metod bilansowania i autoryzacji, spójrz na Traefik i HAProxy. Są to sprawdzone przez lata projekty Open Source, bardzo stabilne i aktywnie rozwijające się. Contour jest już dostępny od kilku lat, ale wciąż wygląda zbyt młodo i ma tylko podstawowe funkcje dodane do Envoy. Jeśli są wymagania dotyczące obecności/osadzenia WAF przed aplikacją, należy zwrócić uwagę na ten sam Ingress z Kubernetes lub HAProxy.
A najbogatsze pod względem funkcji są produkty zbudowane na bazie Envoy, zwłaszcza Istio. Wydaje się, że jest to kompleksowe rozwiązanie, które „może zrobić wszystko”, co jednak oznacza również znacznie wyższy próg wejścia na konfigurację/uruchomienie/administrację niż inne rozwiązania.
Wybraliśmy i nadal używamy Ingress od Kubernetes jako standardowego kontrolera, który pokrywa 80-90% potrzeb. Jest dość niezawodny, łatwy w konfiguracji i rozbudowie. Generalnie przy braku konkretnych wymagań powinien pasować do większości klastrów/aplikacji. Z tych samych uniwersalnych i stosunkowo prostych produktów można polecić Traefik i HAProxy.
PS
Przeczytaj także na naszym blogu:
- „Powrót do mikroserwisów z Istio”: , , ;
- «";
- «".
Źródło: www.habr.com