Przygotowujemy obecnie konifiguracje naszego produktu na Kubernetesa i jako gateway api obecnie działa KrakenD.
Obecnie skonfigurowany KrakenD ma wpisane wszystkie mozliwe endpointy w swojej konfiguracji wraz z walidacja tokena JWT w Keycloak.
Wiem że podobnie można to zrobić w Ingress NGINX.
Pytanie co jest lepsze / szybsze / bezpieczniejsze KrakenD czy NGINX?
Lepsze to będzie to co już macie i działa, a każdy w zespole wie jak tam zajrzeć w logi i, czy zmienić konfigurację.
Czy to nie jest pytanie z serii, co lepsze musztarda czy kiełbasa? Ingress i API Gateway, to różne funkcje. Skoro mowa o produkcie, to potencjalnie wdrażany na różnych implementacjach k8s, w których mogą być różne implementacje Ingress. Admini klastrów nie zawsze lubią mieć różne implementacje ingresów do utrzymania. Skoro mają contoura czy haproxy, to dlaczego chciałbyś im dorzucać jeszcze nignxa?
Jak chcesz tego KrakenD z klastra wystawić na świat? Może warto być Ingress agnostic, a KrakenD wdrażać jako usługę? Czy będziesz chciał tego KrakenD aktualizować do nowszej wersji? Co wtedy? Będziesz chciał mieć canary deployment, które może wspierać ingress? Czy raczej idziesz w drobny downtime i redeployment?
yarel napisał(a):
Czy to nie jest pytanie z serii, co lepsze musztarda czy kiełbasa? Ingress i API Gateway, to różne funkcje. Skoro mowa o produkcie, to potencjalnie wdrażany na różnych implementacjach k8s, w których mogą być różne implementacje Ingress. Admini klastrów nie zawsze lubią mieć różne implementacje ingresów do utrzymania. Skoro mają contoura czy haproxy, to dlaczego chciałbyś im dorzucać jeszcze nignxa?
Jak chcesz tego KrakenD z klastra wystawić na świat? Może warto być Ingress agnostic, a KrakenD wdrażać jako usługę? Czy będziesz chciał tego KrakenD aktualizować do nowszej wersji? Co wtedy? Będziesz chciał mieć canary deployment, które może wspierać ingress? Czy raczej idziesz w drobny downtime i redeployment?
Byłby wystawiany na świat przy użyciu serwisu typu "LoadBalancer" w sumie tak samo jak to robi się z Ingress - NGINX.
Środowisko na którym będzie to wdrażane nie jest to żadna publiczna chmura tylko prywatna zamknieta serwerownia z zainstalowanym Kubernetesem.
Generalnie zalezy nam aby byl jeden punkt wejscia do zlozonego systemu, wydajnosc, authoryzacja, load balancing.
Co do aktualiacji to mamy 2 opcje: chwilowa przerwa lub wystawione conajmniej 2 instancje (o czym wie klient) wtedy przerwy w dzialaniu nie powinno, chyba ze bedzie zmiana w api...
Jeśli to zamknięta serwerownia z zainstalowanym K8s, to można przypuszczać, że infrastruktura jest współdzielona (= wspólny klaster ; np. dołożenie node do klastra, to fizycznie dostawienie maszyny, albo jeśli klient ma prywatnego clouda, dostawienie kolejnej instancji maszyny) i trzeba by myśleć o wejściu nie tyle do konkretnego systemu, ale do klastra, w ramach którego możesz mieć wiele systemów. Samo użycie serwisu typu "LoadBalancer" nie wystawi go na świat, bo taki load balancer najpierw trzeba: a) mieć b) skonfigurować.
W przypadku instalacji w "prywatnej serwerowni" , możesz doprecyzować:
Goły k8s, czy w ramach np. OpenStacka, inny? Goły k8s nie ma load balancera i wymaga dodatkowego komponentu, który ten Load Balancing zapewni. Dla k8s czasem używa się MetalLB, które może być zdeployowane w Layer2 mode, albo w trybie BGP. Przy MetalLB i layer2, nie będziesz miał prawdziwego load balancingu, a failover potrwa "wieki" (w sensie sieciowym), co może kłócić się z wizją wydajności.
Przy wyborze docelowej architektury starałbym się zrozumieć, nad którymi elementami nie będę miał kontroli i czy to może boleć, np. pomijając to co dzieje się za api gatewayem, chcę zaktualizować
KrakenD z wersji N do wersji N+1. Czy wystawiając via LoadBalancer 2 serwisy (API GW v.N i API GW v.N+1) będę w stanie 95% ruchu puścić przez serwis v.N ? Jak to zrobić? (mając ingressa raczej proste, bez ingressa? Kto mi zrobi taki load balancing? Czy to będzie kontrolowane z poziomu jakiegoś CRD, czy request do adminów, że mają coś ręcznie zmieniać w konfiguracji LoadBalancera, czy rollback takiej konfiguracji będzie prosty/automatyczny?).
Do tego zastanowiłbym się jak ma wyglądać obsługa szyfrowania E2E (zarządzania certyfikatami - czy wspierać centralne zarządzanie i korzystać z CA klienta, czy mieć w**ne i niech klient się martwi certyfikatami).
yarel napisał(a):
Jeśli to zamknięta serwerownia z zainstalowanym K8s, to można przypuszczać, że infrastruktura jest współdzielona (= wspólny klaster ; np. dołożenie node do klastra, to fizycznie dostawienie maszyny, albo jeśli klient ma prywatnego clouda, dostawienie kolejnej instancji maszyny) i trzeba by myśleć o wejściu nie tyle do konkretnego systemu, ale do klastra, w ramach którego możesz mieć wiele systemów. Samo użycie serwisu typu "LoadBalancer" nie wystawi go na świat, bo taki load balancer najpierw trzeba: a) mieć b) skonfigurować.
W przypadku instalacji w "prywatnej serwerowni" , możesz doprecyzować:
- jaka jest implementacja tego k8s?
- jaka jest implementacja LoadBalancera?
Goły k8s, czy w ramach np. OpenStacka, inny? Goły k8s nie ma load balancera i wymaga dodatkowego komponentu, który ten Load Balancing zapewni. Dla k8s czasem używa się MetalLB, które może być zdeployowane w Layer2 mode, albo w trybie BGP. Przy MetalLB i layer2, nie będziesz miał prawdziwego load balancingu, a failover potrwa "wieki" (w sensie sieciowym), co może kłócić się z wizją wydajności.
Przy wyborze docelowej architektury starałbym się zrozumieć, nad którymi elementami nie będę miał kontroli i czy to może boleć, np. pomijając to co dzieje się za api gatewayem, chcę zaktualizować
KrakenD z wersji N do wersji N+1. Czy wystawiając via LoadBalancer 2 serwisy (API GW v.N i API GW v.N+1) będę w stanie 95% ruchu puścić przez serwis v.N ? Jak to zrobić? (mając ingressa raczej proste, bez ingressa? Kto mi zrobi taki load balancing? Czy to będzie kontrolowane z poziomu jakiegoś CRD, czy request do adminów, że mają coś ręcznie zmieniać w konfiguracji LoadBalancera, czy rollback takiej konfiguracji będzie prosty/automatyczny?).Do tego zastanowiłbym się jak ma wyglądać obsługa szyfrowania E2E (zarządzania certyfikatami - czy wspierać centralne zarządzanie i korzystać z CA klienta, czy mieć w**ne i niech klient się martwi certyfikatami).
Nie ukrywam że Kubernetesa dopiero się uczę.
Obecna instalacja Kubernetesa była przeprowadzona na podstawie tej instrukcji: https://infotechys.com/install-a-kubernetes-cluster-on-rhel-9/
Na probe mamy wystawony serwis LoadBalancer na ip jednej maszyny control plane (jako gateway uderzajacy do np ingress nginx lub krakend) + kazdy nasz moduł ma skonfigurowany swoj serwis typu "ClusteIP" i kazdy serwis czy odwolanie do niego leci po naziwie selectora. Czyli jesli dobrze rozumiem to podstawowym prymitywnym load balancingiem będzie round robbin.
Bo jak dobrze widzialem to kazda kolejna uruchomiona instancja aplikacji pojawai sie w liscie ip danego seriwsu czy to "LoadBalancer" czy "ClusterIP".
Wiem że dla bardziej zaawansowanego load balancingu np oprartego o obicazenia itp. musimy dostarczyc implementacje typu MetalLB. Mamy go na razie wrzuconego bez dodatkowej kofniguracji.
Co do certów to w ingress nginx jak i krakend mozna skonfigurowac to na wiele sposobów.
A k8s nie wyeliminował potrzeby zewnętrznego load balancingu dodając https://kubernetes.io/docs/concepts/services-networking/gateway/ ?
piotrpo napisał(a):
A k8s nie wyeliminował potrzeby zewnętrznego load balancingu dodając https://kubernetes.io/docs/concepts/services-networking/gateway/ ?
Z tego co rozumiem (mogę się mylić, jako że jestem w trakcie poznawania chmury), Gateway API to tylko API, a faktyczne obowiązek realizacji zmian wynikających z użyci GW API będzie spoczywał na kontrolerze (=coś po stronie klastra implementuje to API). O ile w przypadku cloud providerów (Azure, GCP, AWS), K8S działa w ramach infrastruktury cloudowej (jest z nią zintegrowany i tworzenie np. serviceType LoadBalancer może w chmurze AWS skutkować utworzeniem instancji load balancera: ALB/NLB), o tyle przy instalacjach "standalone", nie zawsze taka infrastruktura jest (=z czym ten k8s miałby się integrować? :) ) .
Z perspektywy developera, GW API będzie sposobem wyrażenie wymagań odnośnie infrastrukury, ale z perspektywy dostawcy infrastruktury, zgodnie opisem GW Class: "We expect that one or more GatewayClasses will be created by the infrastructure provider for the user. It allows decoupling of which mechanism (e.g. controller) implements the Gateways from the user.". W przypadku prywatnej serwerowni, kto jest providerem tej infrastruktury? Zapewne klient/zespół zajmujący się jej utrzymaniem. IMO, zależy jak wygląda infrastruktura i jak wygląda proces jej provisioningu, czy jest ręczny/automatyczny/pół-automatyczny.
Kolega @maniek41 pisze, że w ich przypadku entry pointem dla serwisu jest routowalne IP przypisane do jednego z control plane nodów, co oznacza, że bez zaawansownego routingu, cały ruch będzie szedł do klastra przez jednego node'a (innymi słowy, mają bottlencek + single point of failure). Dopiero na poziomie kube-proxy wybranego node'a, ten ruch zostanie rozdzielony na PODy.
Co się wydarzy w przypadku awarii tego control plan node/prac serwisowych wymagających jego wyłaczenia/izolacji? W jaki sposób to routowalne IP zostanie przepięte na innego node'a klastra?
yarel napisał(a):
piotrpo napisał(a):
A k8s nie wyeliminował potrzeby zewnętrznego load balancingu dodając https://kubernetes.io/docs/concepts/services-networking/gateway/ ?
Z tego co rozumiem (mogę się mylić, jako że jestem w trakcie poznawania chmury), Gateway API to tylko API, a faktyczne obowiązek realizacji zmian wynikających z użyci GW API będzie spoczywał na kontrolerze (=coś po stronie klastra implementuje to API). O ile w przypadku cloud providerów (Azure, GCP, AWS), K8S działa w ramach infrastruktury cloudowej (jest z nią zintegrowany i tworzenie np. serviceType LoadBalancer może w chmurze AWS skutkować utworzeniem instancji load balancera: ALB/NLB), o tyle przy instalacjach "standalone", nie zawsze taka infrastruktura jest (=z czym ten k8s miałby się integrować? :) ) .
Z perspektywy developera, GW API będzie sposobem wyrażenie wymagań odnośnie infrastrukury, ale z perspektywy dostawcy infrastruktury, zgodnie opisem GW Class: "We expect that one or more GatewayClasses will be created by the infrastructure provider for the user. It allows decoupling of which mechanism (e.g. controller) implements the Gateways from the user.". W przypadku prywatnej serwerowni, kto jest providerem tej infrastruktury? Zapewne klient/zespół zajmujący się jej utrzymaniem. IMO, zależy jak wygląda infrastruktura i jak wygląda proces jej provisioningu, czy jest ręczny/automatyczny/pół-automatyczny.
Kolega @maniek41 pisze, że w ich przypadku entry pointem dla serwisu jest routowalne IP przypisane do jednego z control plane nodów, co oznacza, że bez zaawansownego routingu, cały ruch będzie szedł do klastra przez jednego node'a (innymi słowy, mają bottlencek + single point of failure). Dopiero na poziomie kube-proxy wybranego node'a, ten ruch zostanie rozdzielony na PODy.
Co się wydarzy w przypadku awarii tego control plan node/prac serwisowych wymagających jego wyłaczenia/izolacji? W jaki sposób to routowalne IP zostanie przepięte na innego node'a klastra?
A to co podał @piotrpo nie jest czasem następcą Ingress Controller'a? patrzac na opis w dokumentacji tak by to wyglądało. Chyba że masz na myśli że i tak ingress controller musi byc dostarczony nawet dla tego gateway api?
Co do jednego punktu wejscia to co proponujesz? Utworzenie wielu instancji i serwisu NodePort?
Pytanie co wybrać:
Wisi nad nami jeszcze temat autoryzacji do zasobów, ktore mozemy wdrozyc spinajac to np z KrakenD ale możemy tą odpowiedzialnosc zrzuić niżej na aplikacje...
Tzn. ja ze swojego mizernego poziomu znajomości kubnernetesa rozumiem, że są 2 oddzielne problwemy:
Te problemy można rozwiązywać oddzielnie, czyli przykładowo stawiamy sobie kontener z NGIX'em wewnątrz klastra, jest on external service, a na zewnątrz klastra chodzi usługa, która zlokalizuje te konkretne pody i przekieruje na nie żądanie. Można też zdefiniować API na zewnątrz klastra w jakiejś usłudze, która odpowiada za oba te zadania.
Umieszczenie czegoś wewnątrz klastra załatwia w tym obszarze nadmiarowość. Umieszczenie czegoś zewnętrznie wymaga ogarnięcia SPOF'a, albo pogodzenia się z jego istnieniem.
@maniek41 można np. tak:
Zaletą jest to, że LB konfigurujesz raz, a później masz elastyczność routingu do serwisów na poziomie ingressa (nie musisz mieć tylu instancji ingressa co nodów w klastrze, więc dodanie kolejnego noda do klastra nie będzie pociągało zmian w konfiguracji LB).
Bez ingressa możesz to samo osiągnąć przez usługę na NodePort, ale co w przypadku gdy będziesz na klastrze wdrożyć inną aplikację? Chcesz jeszcze raz przechodzić prze tematy infrastruktury?
Do tego jeśli między LB a klasterm jest firewall, to może generować przejście przez różne poziomy akceptacji security. Dużo zależy od tego jak biurokratyczny jest klient i co faktycznie ma się na tym klastrze dziać w przyszłości.
A co myślisz o podejsciu takim że na wejsciu mamy ingress nginx ze skonfigurowanym rotuingiem np.:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: ingress-resource
annotations:
nginx.ingress.kubernetes.io/ssl-redirect: "true"
nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
spec:
ingressClassName: nginx
tls:
- hosts:
- HOST_DNS_NAME_HERE
secretName: ingress-tls-secret
rules:
- host: HOST_DNS_NAME_HERE
http:
paths:
- path: /someWebUI
pathType: Prefix
backend:
service:
name: ui-viewer
port:
number: 50000
- path: /api #tutaj KrakenD API Gateway
pathType: Prefix
backend:
service:
name: krakend
port:
number: 8080
Pomijając na razie fakt że mamy jeden punkt wejscia.
Przy kofniguracji gdy /api kieruje do KrakenD ktory w konfigu ma wszystkie endpointy itd ale adresy aplikacji docelowych ma nazwy serwisow np http://nazwaSerwisuClusterIP:8080/ ,
czy tutaj za KrakenD zadziała kubernetesowy load balancing?
Czy może taka konfiguracja jest do d**y i krakenD tutaj tylko stworzy wąskie gardło?
Macie jakies doswiadczenia z Istio? Widze że implementauje Kubernetes API Gateway oraz Service Mesh. Posiada możliwości authoryzacji po JWT i ma wbudowany load balancing.
Informacyjnie dla nastepnych pokoleń ;) KrakenD może być zintegrowany z Kubernetesowym DNS wiec wbudowany w KrakenD load balancer będzie działał prawidłowo majac pelna liste dostepnych hostów: https://www.krakend.io/docs/backends/service-discovery/#dns-srv-service-discovery-kubernetesconsul