Ingress et équilibreur de charge

Question

Je suis assez confus quant aux rôles d'Ingress et d'équilibreur de charge dans Kubernetes.

D'après ce que j'ai compris, Ingress est utilisé pour faire correspondre le trafic entrant d'Internet aux services fonctionnant dans le cluster.

Le rôle de l'équilibreur de charge est de transmettre le trafic vers un hôte. À cet égard, quelle est la différence entre ingress et load balancer ? En outre, quel est le concept d'équilibreur de charge dans Kubernetes par rapport à Amazon ELB et ALB ?

Answer 1

É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 qui existent ailleurs. Ils peuvent fonctionner avec vos pods, en supposant que ces derniers soient routables en externe. Google et AWS offrent cette possibilité de manière native. En ce qui concerne Amazon, cela correspond directement à ELB et kubernetes, lorsqu'il est exécuté dans AWS, peut automatiquement fournir et configurer une instance ELB pour chaque service LoadBalancer déployé.

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

Vous pouvez également créer un NodePort qui a une adresse IP routable à l'extérieur du cluster, mais qui 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 pod qui est 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 ce qui concerne Amazon, ALB peut être utilisé en tant que contrôleur d'entrée.

Par exemple, ce Le contrôleur nginx est capable d'ingérer les règles d'entrée que vous avez définies et de les traduire en 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 pod 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 pour router http://kubernetes.foo.bar/app pour pointer vers le service appsvc dans votre cluster.

Voici un exemple de comment implémenter un cluster kubernetes avec un contrôleur d'entrée nginx. J'espère que cela vous aidera !

Answer 2

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

A partir du contenu présent dans l'article :

Equilibreur de charge :

Un service LoadBalancer est le moyen standard d'exposer un service à l'Internet. l'internet. Sur GKE, cela va faire tourner un équilibreur de charge réseau qui va une adresse IP unique qui transmettra tout le trafic vers votre service. 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 transféré vers le service. Il n'y a pas de filtrage, pas de routage, etc. Cela signifie que vous pouvez envoyer presque n'importe quel type de trafic, comme HTTP, TCP, UDP, Websockets, gRPC, etc. 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 pour un LoadBalancer par service exposé, ce qui peut coûter cher !

Ingress :

Ingress n'est en fait PAS un type de service. Au contraire, il se place devant services et agit comme un "routeur intelligent" ou un point d'entrée dans votre votre cluster.

Vous pouvez faire beaucoup de choses différentes avec un Ingress, et il existe 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 crée un équilibreur de charge HTTP(S) pour vous. pour vous. Cela vous permettra d'effectuer un routage basé sur les chemins et les sous-domaines vers les services backend. vers les services dorsaux. Par exemple, vous pouvez envoyer tout ce qui se trouve sur foo.votredomaine.com au service foo, et tout ce qui se trouve sous le chemin yourdomain.com/bar/ vers le service bar.

Ingress est probablement le moyen le plus puissant pour exposer vos services, mais peut aussi être le plus compliqué. Il existe de nombreux types de contrôleurs Ingress de Google Cloud Load Balancer, Nginx, Contour, Istio, et plus encore. Il existe également des plugins pour les contrôleurs Ingress, tels que le cert-manager, qui peut fournir automatiquement des certificats SSL pour vos services.

Ingress est le plus utile si vous souhaitez exposer plusieurs services sous la même adresse IP, et que 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 native de GCP. l'intégration native de GCP, et parce qu'Ingress est "intelligent", vous ne payez qu'un seul équilibreur de charge. vous pouvez obtenir un grand nombre de fonctionnalités prêtes à l'emploi (comme SSL, Auth, Routing, etc)

Answer 3

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 par 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 paquets de mise en œuvre de services (ASIP pour plus de clarté et de brièveté) à déployer sous un seul nom de domaine. En tant que développeur de pointe, vous avez mis en place une architecture de micro-services qui nécessite des déploiements séparés pour chaque ASIP afin qu'ils puissent être mis à jour ou adaptés individuellement. Bien sûr, ces ASIP sont encapsulés dans des conteneurs docker individuels et disponibles pour Kubernetes (K8s) à partir du dépôt de conteneurs.

Disons maintenant que vous souhaitez déployer ce système sur les GKE K8 de Google. Pour mettre en œuvre la disponibilité soutenue, 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 nuage. Chaque déploiement ASIP est configuré dans un fichier bien nommé "deployment.yaml" où vous spécifiez de manière déclarative, entre autres choses, le nombre de répliques de l'ASIP K8s donné à 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. Puisque nous avons plusieurs répliques de la même ASIP fonctionnant sur différents nœuds, nous avons besoin de quelque chose qui distribue la demande parmi 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é à l'extérieur et accessible par une adresse IP. Ce KServ prendra en charge la distribution des requêtes de l'API parmi ses ASIP configurés. Notez qu'un KServ sera automatiquement reconfiguré par le maître K8s lorsque le nœud d'un ASIP tombe en panne et est redémarré. Les adresses IP internes ne sont jamais réutilisées dans ce cas et le KServ doit être informé de l'emplacement du déploiement du nouvel ASIP.

Mais nous avons d'autres paquets de services Api qui doivent être exposés sur le même nom de domaine. La création d'un nouveau KServ créera une nouvelle adresse IP externe et nous ne serons pas en mesure de l'exposer sur le même nom de domaine. C'est là qu'Ingress entre en jeu.

Ingress se situe entre l'Internet et tous les services que nous exposons au monde extérieur. Ingress est capable d'assurer l'équilibrage des charges, la terminaison SSL et l'hébergement virtuel par nom. Cette dernière capacité est capable d'acheminer une requête 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 requête au bon KServ.

Internet -> Entrée -> Services K8s -> Répliques

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

Answer 4

En d'autres termes, l'équilibreur de charge distribue les demandes entre plusieurs services dorsaux (du même type), tandis que l'ingress ressemble davantage à une passerelle API (proxy inverse) qui achemine la demande vers un service dorsal spécifique en fonction, par exemple, de l'URL.

Answer 5

Ingress : Objet Ingress + Contrôleur Ingress

Objet d'entrée :

Tout comme un objet de service, sauf qu'il ne fait rien par lui-même. Un Ingress Object décrit simplement une façon de router le trafic de couche 7 dans votre cluster, en spécifiant des choses comme le chemin de la requête, le domaine de la requête 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 pourrait utiliser un service pour écouter sur les ports 80 et 443, puis lire les nouveaux objets Ingress et les analyser dans de nouvelles sections server{} qu'il place dynamiquement dans son fichier nginx.conf.

LoadBalancer : Fournisseur d'équilibreur de charge externe + Type de service

Fournisseur d'équilibreur 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 permettent d'attribuer des IP externes par la création d'équilibreurs de charge externes. Cette fonctionnalité peut être utilisée en désignant un service de 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 IP externes.

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

Les relations :

Les services de contrôleur d'entrée sont souvent provisionnés en tant que LoadBalancer, afin que les requêtes http et https puissent être proxiées / routées vers des services internes spécifiques via une adresse IP externe.

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

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/