Ingress vs Load Balancer

Je suis assez confus quant aux rôles d'Ingress et de Load Balancer dans Kubernetes.

Autant que je sache, Ingress est utilisé pour mapper le trafic entrant depuis Internet vers les services exécutés dans le cluster.

Le rôle de l'équilibreur de charge est de transférer le trafic vers un hôte. À cet égard, en quoi la pénétration diffère-t-elle de l'équilibreur de charge? Quel est également le concept d'équilibreur de charge dans kubernetes par rapport à Amazon ELB et ALB?

Équilibreur de charge: un service LoadBalancer kubernetes est un service qui pointe vers des équilibreurs de charge externes qui NE SONT PAS dans votre cluster kubernetes, mais existent ailleurs. Ils peuvent fonctionner avec vos pods, en supposant que vos pods sont routables en externe. Google et AWS offrent cette capacité de manière native. En termes d'Amazon, cette correspondance directe avec ELB et kubernetes lors de l'exécution dans AWS peut automatiquement provisionner et configurer une instance ELB pour chaque service LoadBalancer déployé.

Entrée: Une entrée n'est en réalité qu'un ensemble de règles à transmettre à un contrôleur qui les écoute. Vous pouvez déployer un tas de règles d'entrée, mais rien ne se passera si vous ne disposez pas d'un contrôleur capable de les traiter. Un service LoadBalancer peut écouter les règles d'entrée, s'il est configuré pour le faire.

Vous pouvez également créer un service NodePort , qui a une adresse IP routable en dehors du cluster, mais pointe vers un pod qui existe dans votre cluster. Il peut s'agir d'un contrôleur d'entrée.

Un contrôleur d'entrée est simplement un module configuré pour interpréter les règles d'entrée. L'un des contrôleurs d'entrée les plus populaires pris en charge par kubernetes est nginx. En termes d'Amazon, ALB peut être utilisé comme contrôleur d'entrée.

Par exemple, ce contrôleur nginx est capable d'ingérer des règles d'entrée que vous avez définies et de les traduire dans un fichier nginx.conf qu'il charge et démarre dans son pod.

Disons par exemple que vous avez défini une entrée comme suit:

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

Si vous inspectez ensuite votre module contrôleur nginx, vous verrez la règle suivante définie dans /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 vient de créer une règle à acheminer http://kubernetes.foo.bar/apppour pointer vers le service appsvcde votre cluster.

Voici un exemple de mise en œuvre d'un cluster kubernetes avec un contrôleur d'entrée nginx. J'espère que cela t'aides!

J'ai trouvé cet article très intéressant qui explique les différences entre NodePort, LoadBalancer et Ingress.

Du contenu présent dans l'article:

LoadBalancer:

Un service LoadBalancer est le moyen standard d'exposer un service à Internet. Sur GKE, cela fera tourner un équilibreur de charge réseau qui vous donnera une seule adresse IP qui transmettra tout le trafic à votre service.

Si vous souhaitez exposer directement un service, il s'agit de la méthode par défaut. Tout le trafic sur le port que vous spécifiez sera transmis au service. Il n'y a pas de filtrage, pas de routage, etc. Cela signifie que vous pouvez lui envoyer presque tout type de trafic, comme HTTP, TCP, UDP, Websockets, gRPC ou autre.

Le gros inconvénient est que chaque service que vous exposez avec un LoadBalancer aura sa propre adresse IP, et vous devez payer un LoadBalancer par service exposé, ce qui peut coûter cher!

Entrée:

L'entrée n'est en fait PAS un type de service. Au lieu de cela, il se trouve devant plusieurs services et agit comme un «routeur intelligent» ou un point d'entrée dans votre cluster.

Vous pouvez faire beaucoup de choses différentes avec un Ingress, et il existe de nombreux types de contrôleurs Ingress qui ont des capacités différentes.

Le contrôleur d'entrée GKE par défaut fera tourner un équilibreur de charge HTTP (S) pour vous. Cela vous permettra de faire à la fois un routage basé sur un chemin et un sous-domaine vers des services backend. Par exemple, vous pouvez tout envoyer sur foo.votredomaine.com au service foo, et tout ce qui se trouve sous le chemin yourdomain.com/bar/ vers le service de bar.

Ingress est probablement le moyen le plus puissant d'exposer vos services, mais peut aussi être le plus compliqué. Il existe de nombreux types de contrôleurs Ingress, tels que Google Cloud Load Balancer, Nginx, Contour, Istio, etc. Il existe également des plugins pour les contrôleurs Ingress, comme le gestionnaire de certificats, qui peuvent automatiquement provisionner des certificats SSL pour vos services.

Ingress est le plus utile si vous souhaitez exposer plusieurs services sous la même adresse IP, et ces services utilisent tous le même protocole L7 (généralement HTTP). Vous ne payez qu'un seul équilibreur de charge si vous utilisez l'intégration GCP native, et parce qu'Ingress est «intelligent», vous pouvez obtenir de nombreuses fonctionnalités prêtes à l'emploi (comme SSL, Auth, Routing, etc.)

TL: DR

1. Ingress se situe entre le réseau public (Internet) et les services Kubernetes qui exposent publiquement la mise en œuvre de notre Api.
2. Ingress est capable de fournir l'équilibrage de charge, la terminaison SSL et l'hébergement virtuel basé sur le nom.
3. Les capacités d'entrée permettent d'exposer en toute sécurité plusieurs API ou applications à partir d'un seul nom de domaine.

Commençons par un cas d'utilisation pratique: vous avez plusieurs Apis soutenus par des packages d'implémentation de service (ASIP pour la clarté et la brièveté) à déployer sous un seul nom de domaine. En tant que développeur de pointe, vous avez implémenté une architecture de micro-services qui nécessite des déploiements séparés pour chaque ASIP afin qu'ils puissent être mis à niveau ou mis à l'échelle individuellement. Bien sûr, ces ASIP sont encapsulés dans un conteneur Docker individuel et disponibles pour Kubernetes (K8) à partir du référentiel de conteneurs.

Disons maintenant que vous souhaitez déployer cela sur les GKE K8 de Google. Pour implémenter une disponibilité durable, chaque instance ASIP (réplique) est déployée sur différents nœuds (VM) où chaque VM a sa propre adresse IP interne au cloud. Chaque déploiement ASIP est configuré dans un fichier bien nommé "deployment.yaml" dans lequel vous spécifiez de manière déclarative, entre autres, le nombre de répliques des ASIP K8 donnés à déployer.

L'étape suivante consiste à exposer l'API au monde extérieur et à canaliser les demandes vers l'une des instances ASIP déployées. Comme nous avons de nombreuses répliques du même ASIP s'exécutant sur différents nœuds, nous avons besoin de quelque chose qui répartira la demande entre ces répliques. Pour résoudre ce problème, nous pouvons créer et appliquer un fichier "service.yaml" qui configurera un service K8s (KServ) qui sera exposé en externe et accessible via une adresse IP. Ce KServ prendra en charge la distribution des demandes de l'API parmi ses ASIP configurés. Notez qu'un KServ sera automatiquement reconfiguré par le maître K8 en cas de défaillance d'un nœud ASIP et redémarré. L'adresse IP interne n'est jamais réutilisée dans ce cas et le KServ doit être informé de l'emplacement de déploiement du nouvel ASIP.

Mais nous avons d'autres packages de services Api qui seront exposés sur le même nom de domaine. Faire tourner un nouveau KServ créera une nouvelle adresse IP externe et nous ne pourrons pas l'exposer sur le même nom de domaine. Eh bien, c'est là qu'intervient Ingress.

Ingress se situe entre Internet et tous les KServices que nous exposons au monde extérieur. Ingress est capable de fournir l'équilibrage de charge, la terminaison SSL et l'hébergement virtuel basé sur le nom. Cette dernière capacité est en mesure d'acheminer une demande entrante vers le bon service en analysant son URL. Bien sûr, Ingress doit être configuré et appliqué avec un fichier ... "ingress.yaml" qui spécifiera les réécritures et les routes nécessaires pour envoyer une demande au bon KServ.

Internet -> Ingress -> Services K8s -> Répliques

Ainsi, avec la bonne configuration d'entrée, de KServices et d'ASIP, nous pouvons exposer en toute sécurité de nombreuses API en utilisant le même nom de domaine.

Il existe 4 façons d'autoriser les pods de votre cluster à recevoir du trafic externe:
1.) Pod utilisant HostNetworking: true et (Permet à 1 pod par nœud d'écouter directement les ports du nœud hôte. Les minikube, bare metal et rasberry pi vont parfois cette route qui peut permettre au nœud hôte d'écouter sur le port 80/443 permet de ne pas utiliser d'équilibreur de charge ou de configurations avancées d'équilibreur de charge cloud, elle contourne également les services Kubernetes qui peuvent être utiles pour éviter SNAT / obtenir un effet similaire de externalTrafficPolicy: Local dans les scénarios où il n'est pas pris en charge comme sur AWS.)
2.) Service NodePort
3.) Service LoadBalancer (qui s'appuie sur le service NodePort)
4.) Contrôleur d'entrée + Objets d'entrée (qui s'appuie sur ce qui précède)

Disons que vous avez 10 sites Web hébergés dans votre cluster et que vous souhaitez tous les exposer au trafic externe.
* Si vous utilisez le type LoadBalancer Service, vous générerez 10 équilibreurs de charge cloud HA (chacun coûte de l'argent)
* Si vous utilisez le type Ingress Controller, vous générerez 1 équilibreur de charge cloud HA (économise de l'argent), et il pointera vers une entrée Contrôleur exécuté dans votre cluster.

Un contrôleur d'entrée est:

• Un service de type Load Balancer soutenu par un déploiement de pods s'exécutant dans votre cluster.
• Chaque pod fait 2 choses:
  1. Agit comme un équilibreur de charge de couche 7 exécuté à l'intérieur de votre cluster. (Livré dans de nombreuses saveurs Nginx est populaire)
  2. Se configure dynamiquement en fonction des objets d'entrée dans votre cluster
     (les objets d'entrée peuvent être considérés comme des extraits de configuration déclaratifs d'un équilibreur de charge de couche 7).

Le contrôleur L7 LB / Ingress à l'intérieur de votre cluster répartit le trafic / proxy inverse vers les services IP de cluster à l'intérieur de votre cluster, il peut également mettre fin à HTTPS si vous disposez d'un Kubernetes Secret de type TLS cert et d'un objet Ingress qui le référence.)

Entrée: Objet d'entrée + Contrôleur d'entrée

Objet d'entrée:

Tout comme un objet de service, sauf qu'il ne fait rien par lui-même. Un objet d'entrée décrit simplement un moyen d'acheminer le trafic de couche 7 dans votre cluster, en spécifiant des éléments tels que le chemin de demande, le domaine de demande et le service kubernetes cible, tandis qu'un objet de service crée réellement des services

Contrôleur d'entrée:

Un service qui:

  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

Par exemple, le contrôleur d'entrée Nginx peut utiliser un service pour écouter sur les ports 80 et 443, puis lire de nouveaux objets d'entrée et les analyser dans de nouvelles sections de serveur {} qu'il place dynamiquement dans son nginx.conf

LoadBalancer: fournisseur d'équilibreur de charge externe + type de service

Fournisseur d'équilibrage de charge externe:

Les fournisseurs d'équilibreurs de charge externes sont généralement configurés dans des clouds tels que AWS et GKE et fournissent un moyen d'attribuer des adresses IP externes via la création d'équilibreurs de charge externes. Cette fonctionnalité peut être utilisée en désignant un service comme type "LoadBalancer".

Type de service:

Lorsque le type de service est défini sur LoadBalancer, Kubernetes tente de créer puis de programmer un équilibreur de charge externe avec des entrées pour les pods Kubernetes, leur attribuant ainsi des adresses IP externes.

Le contrôleur de service Kubernetes automatise la création de l'équilibreur de charge externe, les vérifications de l'état (si nécessaire), les règles de pare-feu (si nécessaire) et récupère l'IP externe du LoadBalancer nouvellement créé ou configuré qui a été alloué par le fournisseur de cloud et le remplit dans le objet de service.

Des relations:

Les services de contrôleur d'entrée sont souvent fournis en tant que type LoadBalancer, de sorte que les requêtes http et https peuvent être transmises par proxy / routées vers des services internes spécifiques via une adresse IP externe.

Cependant, un LoadBalancer n'est pas strictement nécessaire pour cela. Depuis, grâce à l'utilisation de hostNetwork ou hostPort, vous pouvez techniquement lier un port sur l'hôte à un service (vous permettant de le visiter via le port externe ip: port). Bien qu'officiellement, cela ne soit pas recommandé car il utilise des ports sur le nœud réel.

Références:

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/

En termes simples, l'équilibreur de charge répartit les demandes entre plusieurs services backend (du même type) tandis que l'entrée est plus comme une passerelle API (proxy inverse) qui achemine la demande vers un service backend spécifique en fonction, par exemple, de l'URL.