Ingress vs Load Balancer

Jestem dość zdezorientowany rolami Ingress i Load Balancer w Kubernetes.

O ile rozumiem, Ingress jest używany do mapowania ruchu przychodzącego z Internetu do usług działających w klastrze.

Rolą modułu równoważenia obciążenia jest przekazywanie ruchu do hosta. Pod tym względem czym różni się wejście od modułu równoważenia obciążenia? Jaka jest także koncepcja modułu równoważenia obciążenia w kubernetes w porównaniu do Amazon ELB i ALB?

Load Balancer: Usługa kubernetes LoadBalancer to usługa, która wskazuje na zewnętrzne usługi równoważenia obciążenia, które NIE znajdują się w klastrze kubernetes, ale istnieją gdzie indziej. Mogą pracować z twoimi zasobnikami, zakładając, że twoje zasobniki są zewnętrznie trasowalne. Google i AWS zapewniają tę funkcję natywnie. Jeśli chodzi o Amazon, to mapuje bezpośrednio za pomocą ELB i kubernetes, gdy uruchomiony w AWS może automatycznie udostępniać i konfigurować instancję ELB dla każdej wdrożonej usługi LoadBalancer.

Ingress: ingres to tak naprawdę zbiór reguł, które należy przekazać kontrolerowi, który ich słucha. Możesz wdrożyć kilka reguł wejściowych, ale nic się nie wydarzy, chyba że masz kontroler, który może je przetworzyć. Usługa LoadBalancer może nasłuchiwać reguł wejściowych, jeśli jest do tego skonfigurowana.

Możesz także utworzyć usługę NodePort , która ma zewnętrznie routowalny adres IP poza klastrem, ale wskazuje na pod, która istnieje w klastrze. Może to być kontroler Ingress.

Kontroler Ingress to po prostu kapsuła, która jest skonfigurowana do interpretowania reguł wejściowych. Jednym z najpopularniejszych kontrolerów wejściowych obsługiwanych przez kubernetes jest nginx. Jeśli chodzi o Amazon, ALB może być używany jako kontroler wejścia .

Na przykład ten kontroler nginx może pobierać zdefiniowane reguły wejściowe i tłumaczyć je na plik nginx.conf, który ładuje i uruchamia w swoim module.

Załóżmy na przykład, że zdefiniowałeś wejście w następujący sposób:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
   ingress.kubernetes.io/rewrite-target: /
 name: web-ingress
spec:
  rules:
  - host: kubernetes.foo.bar
    http:
      paths:
      - backend:
          serviceName: appsvc
          servicePort: 80
        path: /app

Jeśli następnie sprawdzisz swój kontroler nginx, zobaczysz następującą regułę zdefiniowaną w /etc/nginx.conf:

server {
    server_name kubernetes.foo.bar;
    listen 80;
    listen [::]:80;
    set $proxy_upstream_name "-";
    location ~* ^/web2\/?(?<baseuri>.*) {
        set $proxy_upstream_name "apps-web2svc-8080";
        port_in_redirect off;

        client_max_body_size                    "1m";

        proxy_set_header Host                   $best_http_host;

        # Pass the extracted client certificate to the backend

        # Allow websocket connections
        proxy_set_header                        Upgrade           $http_upgrade;
        proxy_set_header                        Connection        $connection_upgrade;

        proxy_set_header X-Real-IP              $the_real_ip;
        proxy_set_header X-Forwarded-For        $the_x_forwarded_for;
        proxy_set_header X-Forwarded-Host       $best_http_host;
        proxy_set_header X-Forwarded-Port       $pass_port;
        proxy_set_header X-Forwarded-Proto      $pass_access_scheme;
        proxy_set_header X-Original-URI         $request_uri;
        proxy_set_header X-Scheme               $pass_access_scheme;

        # mitigate HTTPoxy Vulnerability
        # https://www.nginx.com/blog/mitigating-the-httpoxy-vulnerability-with-nginx/
        proxy_set_header Proxy                  "";

        # Custom headers

        proxy_connect_timeout                   5s;
        proxy_send_timeout                      60s;
        proxy_read_timeout                      60s;

        proxy_redirect                          off;
        proxy_buffering                         off;
        proxy_buffer_size                       "4k";
        proxy_buffers                           4 "4k";

        proxy_http_version                      1.1;

        proxy_cookie_domain                     off;
        proxy_cookie_path                       off;

    rewrite /app/(.*) /$1 break;
    rewrite /app / break;
    proxy_pass http://apps-appsvc-8080;

    }

Nginx właśnie utworzył regułę, aby kierować w http://kubernetes.foo.bar/appcelu wskazania usługi appsvcw klastrze.

Oto przykład implementacji klastra kubernetes za pomocą kontrolera wejściowego nginx. Mam nadzieję że to pomoże!

Znalazłem ten bardzo interesujący artykuł, który wyjaśnia różnice między NodePort, LoadBalancer i Ingress.

Z treści zawartych w artykule:

LoadBalancer:

Usługa LoadBalancer jest standardowym sposobem udostępniania usługi w Internecie. W GKE uruchomi to moduł równoważenia obciążenia sieciowego, który da ci jeden adres IP, który przekieruje cały ruch do twojej usługi.

Jeśli chcesz bezpośrednio udostępnić usługę, jest to metoda domyślna. Cały ruch na wybranym porcie zostanie przekierowany do usługi. Brak filtrowania, routingu itp. Oznacza to, że możesz wysyłać do niego prawie każdy ruch, taki jak HTTP, TCP, UDP, Websockets, gRPC lub cokolwiek innego.

Dużym minusem jest to, że każda usługa, którą udostępnisz za pomocą LoadBalancer, otrzyma własny adres IP i będziesz musiał zapłacić za LoadBalancer za odsłoniętą usługę, co może być drogie!

Ingres:

Ingress NIE jest właściwie rodzajem usługi. Zamiast tego znajduje się przed wieloma usługami i działa jako „inteligentny router” lub punkt wejścia do klastra.

Z Ingress możesz robić wiele różnych rzeczy, a istnieje wiele rodzajów kontrolerów Ingress, które mają różne możliwości.

Domyślny kontroler wejściowy GKE uruchomi dla ciebie moduł równoważenia obciążenia HTTP (S). Umożliwi to wykonywanie routingu opartego na ścieżkach i subdomenach do usług zaplecza. Na przykład możesz wysłać wszystko z witryny foo.twojadomena.com do usługi foo i wszystko pod ścieżką twojadomena.com/bar/ do usługi baru.

Ingress jest prawdopodobnie najskuteczniejszym sposobem na ujawnienie twoich usług, ale może być również najbardziej skomplikowany. Istnieje wiele rodzajów kontrolerów Ingress, od Google Cloud Load Balancer, Nginx, Contour, Istio i innych. Istnieją również wtyczki do kontrolerów Ingress, takich jak menedżer certyfikatów, które mogą automatycznie udostępniać certyfikaty SSL dla twoich usług.

Ingress jest najbardziej przydatny, jeśli chcesz udostępnić wiele usług pod tym samym adresem IP, a wszystkie te usługi korzystają z tego samego protokołu L7 (zazwyczaj HTTP). Płacisz tylko za jeden moduł równoważenia obciążenia, jeśli korzystasz z natywnej integracji GCP, a ponieważ Ingress jest „inteligentna”, możesz uzyskać wiele funkcji od razu po wyjęciu z pudełka (takich jak SSL, uwierzytelnianie, routing itp.)

TL: DR

1. Ingress znajduje się między siecią publiczną (Internet) a usługami Kubernetes, które publicznie ujawniają implementację naszego interfejsu API.
2. Ingress jest w stanie zapewnić równoważenie obciążenia, zakończenie SSL i hosting wirtualny oparty na nazwie.
3. Funkcje Ingress pozwalają bezpiecznie ujawniać wiele interfejsów API lub aplikacji z jednej nazwy domeny.

Zacznijmy od praktycznego przypadku użycia: masz wiele Apis wspieranych przez pakiety implementacji usług (ASIP dla klarowności i zwięzłości) do wdrożenia pod jedną nazwą domeny. Jako zaawansowany programista wdrożyłeś architekturę mikrousług, która wymaga osobnych wdrożeń dla każdego ASIP, aby można je było aktualizować lub skalować indywidualnie. Oczywiście, te ASIP są zamknięte w osobnym kontenerze dokowanym i dostępne dla Kubernetes (K8s) z repozytorium kontenerów.

Powiedzmy teraz, że chcesz wdrożyć to na GKE K8 Google. Aby wdrożyć trwałą dostępność, każda instancja ASIP (replika) jest wdrażana na różnych węzłach (VM), gdzie każda maszyna wirtualna ma swój własny wewnętrzny adres IP w chmurze. Każde wdrożenie ASIP jest skonfigurowane w trafnie nazwanym pliku „loyment.yaml ”, w którym deklaratywnie określa się, między innymi, liczbę replik danych ASIP K8, które powinny zostać wdrożone.

Następnym krokiem jest udostępnienie interfejsu API światu ouside i przesłanie żądań do jednej z wdrożonych instancji ASIP. Ponieważ mamy wiele replik tego samego ASIP działających na różnych węzłach, potrzebujemy czegoś, co rozdzieli żądanie między te repliki. Aby rozwiązać ten problem, możemy utworzyć i zastosować plik „service.yaml”, który skonfiguruje usługę K8s (KServ), która będzie widoczna zewnętrznie i dostępna za pośrednictwem adresu IP. Ten KServ przejmie dystrybucję zapytań API wśród skonfigurowanych ASIP. Zauważ, że KServ zostanie automatycznie zrekonfigurowany przez master K8s, gdy węzeł ASIP ulegnie awarii i zostanie zrestartowany. W takim przypadku wewnętrzny adres IP nigdy nie jest ponownie wykorzystywany i KServ musi zostać poinformowany o lokalizacji wdrożenia nowego ASIP.

Ale mamy inne pakiety usług interfejsu API, które będą widoczne w tej samej nazwie domeny. Przekręcenie nowego KServ spowoduje utworzenie nowego zewnętrznego adresu IP i nie będziemy w stanie udostępnić go pod tą samą nazwą domeny. Tutaj właśnie wchodzi Ingress.

Wejdź między Internet a wszystkie usługi, które wystawiamy na świat zewnętrzny. Ingress jest w stanie zapewnić równoważenie obciążenia, zakończenie SSL i wirtualny hosting oparty na nazwie. Ta ostatnia pojemność jest w stanie skierować przychodzące żądanie do właściwej usługi, analizując jej adres URL. Oczywiście Ingress musi zostać skonfigurowany i zastosowany za pomocą ... pliku „ingress.yaml”, który określi przepisania i trasy wymagane do wysłania żądania do właściwego KServ.

Internet -> Ingress -> Usługi K8s -> Repliki

Tak więc, przy odpowiednim wejściu, KServices i ASIPs, możemy bezpiecznie ujawnić wiele interfejsów API przy użyciu tej samej nazwy domeny.

Istnieją 4 sposoby na to, aby strąki w klastrze odbierały ruch zewnętrzny:
1.) Strąk za pomocą HostNetworking: true i (Pozwala 1 strąkowi na węzeł nasłuchiwać bezpośrednio portów w węźle hosta. Minikube, goły metal i rasberry pi czasami ta trasa, która pozwala węzłowi hosta nasłuchiwać na porcie 80/443, nie pozwala na użycie modułu równoważenia obciążenia lub zaawansowanych konfiguracji modułu równoważenia obciążenia w chmurze, omija także usługi Kubernetes, które mogą być przydatne do unikania SNAT / osiągnięcia podobnego efektu externalTrafficPolicy: lokalny w scenariuszach gdzie nie jest obsługiwany jak w AWS.)
2.) Usługa NodePort
3.) Usługa LoadBalancer (która opiera się na usłudze NodePort)
4.) Kontroler Ingress + Obiekty Ingress (które bazują na powyższym)

Załóżmy, że masz 10 witryn hostowanych w klastrze i chcesz je wszystkie narazić na ruch zewnętrzny.
* Jeśli używasz usługi LoadBalancer, odradzasz 10 HA równoważenia obciążenia chmurą (każda kosztuje pieniądze)
* Jeśli używasz kontrolera Ingress, odradzasz 1 HA równoważenia obciążenia chmurą (oszczędza pieniądze) i wskaże Ingress Kontroler działający w klastrze.

Kontroler Ingress to:

• Usługa typu Load Balancer wspierana przez wdrożenie podsystemów działających w klastrze.
• Każda kapsuła robi 2 rzeczy:
  1. Działa jako moduł równoważenia obciążenia warstwy 7 działający w klastrze. (Dostępny w wielu smakach, popularny jest Nginx)
  2. Dynamicznie konfiguruje się w oparciu o obiekty Ingress w klastrze
     (Obiekty Ingress można traktować jako deklaratywne fragmenty konfiguracji modułu równoważenia obciążenia warstwy 7).

Kontroler L7 LB / Ingress w klastrze Równoważenie obciążenia / zwrotny serwer proxy do usług klastrowych IP w klastrze, może również zakończyć HTTPS, jeśli masz certyfikat Kubernetes Secret typu TLS i obiekt Ingress, który się do niego odwołuje.)

Ingress: Ingress Object + Ingress Controller

Obiekt Ingress:

Podobnie jak obiekt usługi, z tym wyjątkiem, że sam nic nie robi. Obiekt Ingress opisuje po prostu sposób kierowania ruchu warstwy 7 do klastra, określając takie rzeczy, jak ścieżka żądania, domena żądania i docelowa usługa kubernetes, podczas gdy obiekt usługi faktycznie tworzy usługi

Kontroler Ingress:

Usługa, która:

  1. listens on specific ports (usually 80 and 443) for web traffic
  2. Listens for the creation, modification, or deletion of Ingress Objects
  3. Creates internal L7 routing rules based on these Ingress Objects

Na przykład kontroler Ingress Nginx mógłby użyć usługi do nasłuchiwania na portach 80 i 443, a następnie odczytać nowe Obiekty Ingress i parsować je w nowych sekcjach serwera {}, które dynamicznie umieszcza w swoim pliku nginx.conf

LoadBalancer: zewnętrzny dostawca modułu równoważenia obciążenia + typ usługi

Zewnętrzny dostawca modułu równoważenia obciążenia:

Zewnętrzni dostawcy modułu równoważenia obciążenia są zwykle skonfigurowani w chmurach, takich jak AWS i GKE, i zapewniają sposób przypisywania zewnętrznych adresów IP poprzez tworzenie zewnętrznych modułów równoważenia obciążenia. Funkcji tej można użyć, wyznaczając usługę jako typ „LoadBalancer”.

Rodzaj usługi:

Gdy typ usługi jest ustawiony na LoadBalancer, Kubernetes próbuje utworzyć, a następnie zaprogramować zewnętrzny moduł równoważenia obciążenia z wpisami dla strąków Kubernetes, przypisując im tym samym zewnętrzne adresy IP.

Kontroler usługi Kubernetes automatyzuje tworzenie zewnętrznego modułu równoważenia obciążenia, kontrole kondycji (w razie potrzeby), reguły zapory (w razie potrzeby) i pobiera zewnętrzny adres IP nowo utworzonego lub skonfigurowanego modułu LoadBalancer, który został przydzielony przez dostawcę chmury i umieszcza go w obiekt usługi.

Relacje:

Usługi Ingress Controller są często udostępniane jako typ LoadBalancer, dzięki czemu żądania http i https mogą być przekazywane / kierowane do określonych usług wewnętrznych za pośrednictwem zewnętrznego adresu IP.

Jednak LoadBalancer nie jest do tego absolutnie potrzebny. Ponieważ za pomocą hostNetwork lub hostPort można technicznie powiązać port na hoście z usługą (umożliwiając odwiedzanie go za pośrednictwem zewnętrznego adresu IP: hosta). Chociaż oficjalnie nie jest to zalecane, ponieważ zużywa porty w rzeczywistym węźle.

Bibliografia:

https://kubernetes.io/docs/concepts/configuration/overview/#services

https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/

https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/#external-load-balancer-providers

https://kubernetes.io/docs/concepts/services-networking/ingress/

Krótko mówiąc, moduł równoważenia obciążenia rozdziela żądania między wiele usług zaplecza (tego samego typu), natomiast ingress przypomina bramę API (odwrotne proxy), która kieruje żądanie do określonej usługi zaplecza na podstawie na przykład adresu URL.