Kubernetes: Ingress vs Load Balancer

Jestem dość zdezorientowany co do roli 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.

Rola load balancer polega na przekazywaniu ruchu do hosta. Czym ingress różni się od load balancer? Jaka jest również koncepcja load balancer wewnątrz kubernetes w porównaniu do Amazon ELB i ALB?

Author: arunkjn, 2017-07-13

3 answers

Load Balancer: usługa LoadBalancer kubernetes to usługa, która wskazuje na zewnętrzne Równoważniki obciążenia, które nie znajdują się w klastrze kubernetes, ale istnieją gdzie indziej. Mogą pracować z Twoimi strąkami, zakładając, że strąki są zewnętrzne. Google i AWS zapewniają tę możliwość natywnie. Jeśli chodzi o Amazon, to mapy bezpośrednio z ELB i kubernetes podczas pracy w AWS mogą automatycznie dostarczać i konfigurować wystąpienie ELB dla każdej usługi LoadBalancer rozmieszczone.

Ingress: ingress jest tak naprawdę tylko zestawem reguł, które należy przekazać kontrolerowi, który ich słucha. Możesz wdrożyć kilka reguł ingress, ale nic się nie stanie, jeśli nie masz kontrolera, który może je przetwarzać. Usługa LoadBalancer może nasłuchiwać reguł ingress, jeśli jest tak skonfigurowana.

Możesz również utworzyć usługę NodePort , która ma zewnętrznie routowalny adres IP poza klastrem, ale wskazuje na pod, który istnieje w Twoim klaster. To może być kontroler Ingress.

Kontroler Ingress jest po prostu pod, który jest skonfigurowany do interpretacji reguł ingress. Jednym z najpopularniejszych kontrolerów ingress obsługiwanych przez kubernetes jest nginx. W przypadku Amazon, ALB może być używany jako kontroler ingress.

Na przykład, ten kontroler Nginx jest w stanie przechwycić zdefiniowane reguły ingress i przetłumaczyć je na nginx.plik conf, który ładuje i uruchamia się w swoim pod.

Let ' s na przykład powiedzmy, że zdefiniowałeś Ingres 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 chcesz sprawdzić 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;

    }
W związku z tym, że nie jesteśmy w stanie zrealizować zamówienia, nie będziemy w stanie zrealizować zamówienia w terminie 14 dni od daty otrzymania zamówienia. W ten sposób można uzyskać więcej informacji na temat klastra kubernetes, a także uzyskać więcej informacji na temat klastra kubernetes. Mam nadzieję, że to pomoże!
 75
Author: Lindsay Landry,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-10-24 05:03:24

Znalazłembardzo ciekawy artykuł , który wyjaśnia różnice między NodePort, LoadBalancer i Ingress.

Z treści zawartej w artykule:

LoadBalancer:

Usługa LoadBalancer jest standardowym sposobem na wystawienie usługi na internet. Na GKE, spowoduje to uruchomienie Network Load Balancer, który będzie daje jeden adres IP, który przekaże cały ruch do twojego obsługa.

Jeśli chcesz bezpośrednio expose usługi, jest to metoda domyślna. Cały ruch na wskazanym przez Ciebie porcie zostanie przekierowany do serwisu. Nie ma filtrowania, routingu itp. Oznacza to, że możesz wysłać prawie każdy rodzaj ruchu do niego, jak HTTP, TCP, UDP, Websockets, gRPC lub nieważne.

Dużym minusem jest to, że każda usługa, którą wystawiasz z LoadBalancer dostanie swój własny adres IP, i trzeba zapłacić za LoadBalancer za usługę, która może uzyskać drogie!

Ingress:

Ingress nie jest w rzeczywistości rodzajem usługi. Zamiast tego siedzi z przodu wielu usług i działać jako "inteligentny router" lub entrypoint do twoja Gromada.

Można zrobić wiele różnych rzeczy z Ingress, a są wiele typów kontrolerów Ingress, które mają różne możliwości.

Domyślny kontroler GKE ingress uruchomi Ładowanie HTTP (S) Balancer dla Ciebie. To pozwoli Ci zrobić zarówno oparte na ścieżkach, jak i subdomena routing oparty na usługach zaplecza. Na przykład możesz wysłać wszystko na foo.yourdomain.com do serwisu foo i wszystko pod yourdomain.com/bar / align = "left" /

Ingress jest prawdopodobnie najpotężniejszym sposobem na ujawnienie swoich usług, ale może być również najbardziej skomplikowane. Istnieje wiele rodzajów wnikania Kontrolery, z Google Cloud Load Balancer, Nginx, Contour, Istio i nie tylko. Istnieją również wtyczki do Ingress Kontrolery, jak cert-manager, który może automatycznie udostępniać certyfikaty SSL za Twoje usługi.

Ingress jest najbardziej przydatny, jeśli chcesz ujawnić wiele usług pod tym samym adresem IP, a wszystkie te usługi używają tego samego L7 protokół (zazwyczaj HTTP). Płacisz tylko za jeden load balancer, jeśli korzystają z natywnej integracji GCP, a ponieważ Ingress jest " inteligentny" możesz uzyskać wiele funkcji po wyjęciu z pudełka (takich jak SSL, Auth, Routing, etc)

 6
Author: Ankit Agrawal,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2018-05-11 09:58:39

TL:DR

    [3]}Ingress znajduje się pomiędzy siecią publiczną (Internet) a usługami Kubernetes, które publicznie ujawniają implementację naszego Api. Ingress jest w stanie zapewnić Równoważenie Obciążenia, zakończenie SSL i hosting wirtualny oparty na nazwie.
  1. Funkcje Ingress pozwalają na bezpieczne wystawienie wielu API lub aplikacji z jednej nazwy domeny.

Zacznijmy od praktycznego przypadku użycia: masz wiele interfejsów API wspieranych przez implementację usługi Pakiety (ASIP dla clariy i zwięzłości) do wdrożenia pod jedną nazwą domeny. Ponieważ jesteś nowatorskim programistą, zaimplementowałeś architekturę mikrousług, która wymaga osobnych wdrożeń dla każdego ASIP, aby można było je aktualizować lub skalować indywidualnie. Oczywiście te Asip są zamknięte w indywidualnym kontenerze docker i dostępne dla Kubernetes (K8s) z repozytorium kontenerów.

Powiedzmy teraz, że chcesz wdrożyć to na GKE K8s Google. aby wdrożyć trwały dostępność, każda instancja ASIP (replika) jest wdrażana na różnych węzłach (VM), gdzie każda maszyna ma swój własny wewnętrzny adres IP w chmurze. Każde wdrożenie ASIP jest konfigurowane pod trafną nazwą " deployment.plik yaml", w którym deklaratywnie określa się m.in. liczbę replik danego ASIP K8s.

Następnym krokiem jest udostępnienie API światu ouside i przekierowanie żądań do jednej z wdrożonych instancji ASIP. Ponieważ mamy wiele replik tego samego ASIP uruchamiając się na różnych węzłach, potrzebujemy czegoś, co rozdzieli żądanie między tymi replikami. Aby to rozwiązać, możemy utworzyć i zastosować "usługę.yaml " plik, który skonfiguruje usługę K8s (KServ), która będzie wyświetlana zewnętrznie i dostępna za pośrednictwem adresu IP. Ten KServ zajmie się dystrybucją żądań API wśród skonfigurowanych Asip. Należy pamiętać, że KServ będzie automatycznie rekonfigurowany przez K8S master, gdy węzeł ASIP zawiedzie i zostanie uruchomiony ponownie. IP wewnętrzne adresy nigdy nie są ponownie używane w takim przypadku i KServ musi być poinformowany o lokalizacji wdrożenia nowego ASIP.

Ale mamy inne pakiety usług Api, które będą wystawione na tę samą nazwę domeny. Uruchomienie nowego KServ spowoduje utworzenie nowego zewnętrznego adresu IP i nie będziemy mogli go wystawić na tej samej nazwie domeny. Tutaj wkracza Ingress.

Ingress sit jest pomiędzy Internetem a wszystkimi KServices, które wystawiamy na zewnątrz. Ingress jest w stanie zapewnić równoważenie obciążenia, zakończenie SSL i hosting wirtualny oparty na nazwie. Ta ostatnia zdolność jest w stanie przekierować przychodzące żądanie do właściwej usługi, analizując jego adres URL. Oczywiście Ingress musi być skonfigurowany i zastosowany Z.. "ingress.yaml " plik, który określi poprawki i trasy wymagane do wysłania żądania do prawego KServ.

Internet -> Usługi K8s -> Repliki

Dzięki odpowiedniej konfiguracji ingress, KServices i ASIPs możemy bezpiecznie ujawnić wiele API używa tej samej nazwy domeny.

 3
Author: softjake,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2018-05-14 20:59:54