Ingress vs Load Balancer

Ich bin ziemlich verwirrt über die Rollen von Ingress und Load Balancer in Kubernetes.

Soweit ich weiß, wird Ingress verwendet, um eingehenden Datenverkehr aus dem Internet den im Cluster ausgeführten Diensten zuzuordnen.

Die Rolle des Load Balancers besteht darin, den Datenverkehr an einen Host weiterzuleiten. Inwiefern unterscheidet sich Ingress vom Load Balancer? Was ist das Konzept des Load Balancers in Kubernetes im Vergleich zu Amazon ELB und ALB?

Load Balancer: Ein kubernetes LoadBalancer-Dienst ist ein Dienst, der auf externe Load Balancer verweist, die sich NICHT in Ihrem kubernetes-Cluster befinden, aber an anderer Stelle vorhanden sind. Sie können mit Ihren Pods arbeiten, vorausgesetzt, Ihre Pods sind extern routbar. Google und AWS bieten diese Funktion nativ an. In Bezug auf Amazon kann diese Zuordnung direkt zu ELB und Kubernetes unter AWS automatisch eine ELB-Instanz für jeden bereitgestellten LoadBalancer-Dienst bereitstellen und konfigurieren.

Ingress: Ein Ingress ist eigentlich nur ein Satz von Regeln, die an einen Controller übergeben werden, der auf sie wartet. Sie können eine Reihe von Eingangsregeln bereitstellen, aber nichts passiert, wenn Sie nicht über einen Controller verfügen, der sie verarbeiten kann. Ein LoadBalancer-Dienst kann auf Eingangsregeln warten, wenn er dafür konfiguriert ist.

Sie können auch einen NodePort- Dienst erstellen , der eine extern routbare IP außerhalb des Clusters hat, jedoch auf einen Pod verweist, der in Ihrem Cluster vorhanden ist. Dies könnte ein Ingress Controller sein.

Ein Ingress Controller ist einfach ein Pod, der zur Interpretation von Ingress-Regeln konfiguriert ist. Einer der beliebtesten von kubernetes unterstützten Ingress-Controller ist nginx. In Bezug auf der Amazon, ALB kann verwendet werden als eine Eingangssteuerung.

Beispielsweise kann dieser Nginx-Controller die von Ihnen definierten Eingangsregeln erfassen und in eine Datei nginx.conf übersetzen, die er lädt und in seinem Pod startet.

Angenommen, Sie haben einen Eingang wie folgt definiert:

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

Wenn Sie dann Ihren Nginx-Controller-Pod überprüfen, wird die folgende Regel definiert /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 hat gerade eine Regel erstellt, http://kubernetes.foo.bar/appum auf den Dienst appsvcin Ihrem Cluster zu verweisen .

Hier ist ein Beispiel für die Implementierung eines Kubernetes-Clusters mit einem Nginx-Ingress-Controller. Hoffe das hilft!

Ich fand diesen sehr interessanten Artikel, der die Unterschiede zwischen NodePort, LoadBalancer und Ingress erklärt.

Aus dem Inhalt des Artikels:

Lastenausgleicher:

Ein LoadBalancer-Dienst ist die Standardmethode, um einen Dienst dem Internet zugänglich zu machen. Unter GKE wird dadurch ein Netzwerklastenausgleich gestartet, der Ihnen eine einzige IP-Adresse gibt, die den gesamten Datenverkehr an Ihren Dienst weiterleitet.

Wenn Sie einen Dienst direkt verfügbar machen möchten, ist dies die Standardmethode. Der gesamte Datenverkehr auf dem von Ihnen angegebenen Port wird an den Dienst weitergeleitet. Es gibt keine Filterung, kein Routing usw. Dies bedeutet, dass Sie fast jede Art von Datenverkehr an ihn senden können, z. B. HTTP, TCP, UDP, Websockets, gRPC oder was auch immer.

Der große Nachteil ist, dass jeder Dienst, den Sie mit einem LoadBalancer verfügbar machen, eine eigene IP-Adresse erhält und Sie für einen LoadBalancer pro verfügbarem Dienst bezahlen müssen, was teuer werden kann!

Eintritt:

Ingress ist eigentlich KEINE Art von Service. Stattdessen befindet es sich vor mehreren Diensten und fungiert als „intelligenter Router“ oder Einstiegspunkt in Ihren Cluster.

Mit einem Ingress können Sie viele verschiedene Dinge tun, und es gibt viele Arten von Ingress-Controllern mit unterschiedlichen Funktionen.

Der Standard-GKE-Ingress-Controller startet einen HTTP (S) Load Balancer für Sie. Auf diese Weise können Sie sowohl pfadbasiertes als auch subdomänenbasiertes Routing zu Backend-Diensten durchführen. Sie können beispielsweise alles auf foo.yourdomain.com an den foo-Dienst und alles unter dem Pfad yourdomain.com/bar/ an den Bar-Dienst senden.

Ingress ist wahrscheinlich die leistungsstärkste Methode, um Ihre Dienste verfügbar zu machen, kann aber auch die komplizierteste sein. Es gibt viele Arten von Ingress-Controllern, darunter Google Cloud Load Balancer, Nginx, Contour, Istio und andere. Es gibt auch Plugins für Ingress-Controller wie den Cert-Manager, die automatisch SSL-Zertifikate für Ihre Dienste bereitstellen können.

Ingress ist am nützlichsten, wenn Sie mehrere Dienste unter derselben IP-Adresse verfügbar machen möchten und diese Dienste alle dasselbe L7-Protokoll (normalerweise HTTP) verwenden. Sie zahlen nur für einen Load Balancer, wenn Sie die native GCP-Integration verwenden. Da Ingress „intelligent“ ist, können Sie viele Funktionen sofort nutzen (z. B. SSL, Auth, Routing usw.).

TL: DR

1. Ingress befindet sich zwischen dem öffentlichen Netzwerk (Internet) und den Kubernetes-Diensten, die die Implementierung unserer API öffentlich zugänglich machen.
2. Ingress ist in der Lage, Load Balancing, SSL-Terminierung und namenbasiertes virtuelles Hosting bereitzustellen.
3. Mit den Ingress-Funktionen können mehrere APIs oder Anwendungen aus einem einzigen Domänennamen sicher verfügbar gemacht werden.

Beginnen wir mit dem praktischen Anwendungsfall: Sie haben mehrere Apis, die von Service-Implementierungspaketen (ASIP für Klarheit und Kürze) unterstützt werden, um sie unter einem einzigen Domänennamen bereitzustellen. Als innovativer Entwickler haben Sie eine Mikrodienstarchitektur implementiert, die separate Bereitstellungen für jedes ASIP erfordert, damit diese einzeln aktualisiert oder skaliert werden können. Natürlich sind diese ASIPs in einzelnen Docker-Containern gekapselt und stehen Kubernetes (K8s) aus dem Container-Repository zur Verfügung.

Angenommen, Sie möchten dies auf Googles GKE K8s bereitstellen. Um eine dauerhafte Verfügbarkeit zu implementieren, wird jede ASIP-Instanz (Replikat) auf verschiedenen Knoten (VM) bereitgestellt, auf denen jede VM ihre eigene Cloud-interne IP-Adresse hat. Jede ASIP-Bereitstellung wird in einer Datei mit dem passenden Namen "deploy.yaml" konfiguriert, in der Sie unter anderem deklarativ die Anzahl der Replikate der angegebenen ASIP-K8-Bereitstellungen angeben.

Der nächste Schritt besteht darin, die API für die Außenwelt und Trichteranforderungen für eine der bereitgestellten ASIP-Instanzen verfügbar zu machen. Da viele Replikate desselben ASIP auf verschiedenen Knoten ausgeführt werden, benötigen wir etwas, das die Anforderung auf diese Replikate verteilt. Um dies zu beheben, können wir eine "service.yaml" -Datei erstellen und anwenden, die einen K8s-Dienst (KServ) konfiguriert, der extern verfügbar gemacht wird und über eine IP-Adresse zugänglich ist. Dieser KServ übernimmt die Verteilung der API-Anforderungen auf die konfigurierten ASIPs. Beachten Sie, dass ein KServ vom K8s-Master automatisch neu konfiguriert wird, wenn der Knoten eines ASIP ausfällt und neu gestartet wird. Interne IP-Adressen werden in diesem Fall niemals wiederverwendet, und der KServ muss über den Bereitstellungsort des neuen ASIP informiert werden.

Wir haben jedoch andere Api-Servicepakete, die unter demselben Domainnamen verfügbar gemacht werden sollen. Durch Drehen eines neuen KServ wird eine neue externe IP-Adresse erstellt, die nicht unter demselben Domainnamen verfügbar gemacht werden kann. Nun, hier kommt Ingress ins Spiel.

Ingress sitzt zwischen dem Internet und allen KServices, denen wir der Außenwelt ausgesetzt sind. Ingress ist in der Lage, Lastausgleich, SSL-Terminierung und namenbasiertes virtuelles Hosting bereitzustellen. Die letztere Kapazität kann eine eingehende Anfrage an den richtigen Dienst weiterleiten, indem die URL analysiert wird. Natürlich muss Ingress mit einer ... "ingress.yaml" -Datei konfiguriert und angewendet werden, in der die Umschreibungen und Routen angegeben sind, die zum Senden einer Anforderung an den richtigen KServ erforderlich sind.

Internet -> Ingress -> K8s Services -> Replikate

Mit der richtigen Konfiguration von Ingress, KServices und ASIPs können wir also viele APIs mit demselben Domänennamen sicher verfügbar machen.

Es gibt vier Möglichkeiten, wie Pods in Ihrem Cluster externen Datenverkehr empfangen können:
1.) Pod mit HostNetworking: true und (Ermöglicht 1 Pod pro Knoten, direkt auf Ports auf dem Hostknoten zu lauschen. Minikube-, Bare-Metal- und Rasberry-Pi gehen manchmal aus Diese Route, die es dem Hostknoten ermöglicht, Port 80/443 abzuhören, ermöglicht die Nichtverwendung eines Load Balancers oder erweiterter Cloud Load Balancer-Konfigurationen. Sie umgeht auch Kubernetes Services, die nützlich sein können, um SNAT zu vermeiden / einen ähnlichen Effekt von externalTrafficPolicy: Local in Szenarien zu erzielen wo es nicht wie in AWS unterstützt wird.)
2.) NodePort-Dienst
3.) LoadBalancer-Dienst (der auf dem NodePort-Dienst aufbaut)
4.) Ingress Controller + Ingress-Objekte (der auf dem oben genannten aufbaut)

Nehmen wir an, Sie haben 10 Websites in Ihrem Cluster gehostet und möchten sie alle externem Datenverkehr aussetzen.
* Wenn Sie den Typ LoadBalancer Service verwenden, erzeugen Sie 10 HA Cloud Load Balancer (jeder kostet Geld).
* Wenn Sie den Typ Ingress Controller verwenden, erzeugen Sie 1 HA Cloud Load Balancer (spart Geld) und es wird auf einen Ingress verwiesen Controller, der in Ihrem Cluster ausgeführt wird.

Ein Ingress Controller ist:

• Ein Dienst vom Typ Load Balancer, der durch die Bereitstellung von Pods in Ihrem Cluster unterstützt wird.
• Jeder Pod macht zwei Dinge:
  1. Dient als Layer 7 Load Balancer, der in Ihrem Cluster ausgeführt wird. (Kommt in vielen Geschmacksrichtungen Nginx ist beliebt)
  2. Konfiguriert sich dynamisch basierend auf Ingress-Objekten in Ihrem Cluster
     (Ingress-Objekte können als deklarative Konfigurations-Snippits eines Layer 7-Load-Balancers betrachtet werden.)

Der L7 LB / Ingress Controller in Ihrem Cluster Lastenausgleich / Reverse-Proxy-Verkehr zu Cluster-IP-Diensten in Ihrem Cluster kann HTTPS auch beenden, wenn Sie über ein Kubernetes Secret vom Typ TLS-Zertifikat und ein Ingress-Objekt verfügen, das darauf verweist.)

Ingress: Ingress Object + Ingress Controller

Eingangsobjekt:

Genau wie ein Serviceobjekt, außer dass es nichts alleine macht. Ein Ingress-Objekt beschreibt lediglich eine Möglichkeit, den Layer 7-Verkehr in Ihren Cluster weiterzuleiten, indem Dinge wie der Anforderungspfad, die Anforderungsdomäne und der Zubernetes-Zieldienst angegeben werden, während ein Dienstobjekt tatsächlich Dienste erstellt

Ingress Controller:

Ein Service, der:

  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

Beispielsweise könnte der Nginx Ingress Controller mithilfe eines Dienstes die Ports 80 und 443 abhören, dann neue Ingress-Objekte lesen und sie in neue Serverabschnitte analysieren, die er dynamisch in die Datei nginx.conf einfügt

LoadBalancer: Externer Load Balancer-Anbieter + Diensttyp

Externer Load Balancer-Anbieter:

Externe Load Balancer-Anbieter werden normalerweise in Clouds wie AWS und GKE konfiguriert und bieten eine Möglichkeit, externe IPs durch die Erstellung externer Load Balancer zuzuweisen. Diese Funktionalität kann verwendet werden, indem ein Dienst als Typ "LoadBalancer" festgelegt wird.

Servicetyp:

Wenn der Diensttyp auf LoadBalancer festgelegt ist, versucht Kubernetes, einen externen Load Balancer mit Einträgen für die Kubernetes-Pods zu erstellen und anschließend zu programmieren, um ihnen externe IPs zuzuweisen.

Der Kubernetes Service Controller automatisiert die Erstellung des externen Load Balancers, Integritätsprüfungen (falls erforderlich), Firewall-Regeln (falls erforderlich) und ruft die externe IP des neu erstellten oder konfigurierten LoadBalancer ab, der vom Cloud-Anbieter zugewiesen wurde, und füllt sie im Serviceobjekt.

Beziehungen:

Ingress Controller-Dienste werden häufig als LoadBalancer-Typ bereitgestellt, sodass http- und https-Anforderungen über eine externe IP-Adresse an bestimmte interne Dienste weitergeleitet werden können.

Ein LoadBalancer wird hierfür jedoch nicht unbedingt benötigt. Da Sie mithilfe von hostNetwork oder hostPort einen Port auf dem Host technisch an einen Dienst binden können (sodass Sie ihn über den externen IP-Port des Hosts aufrufen können). Obwohl dies offiziell nicht empfohlen wird, werden Ports auf dem eigentlichen Knoten verbraucht.

Verweise:

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/

Mit einfachen Worten, Load Balancer verteilt die Anforderungen auf mehrere Backend-Dienste (desselben Typs), während Ingress eher einem API-Gateway (Reverse Proxy) ähnelt, das die Anforderung beispielsweise anhand der URL an einen bestimmten Backend-Dienst weiterleitet.