Ingress vs Load Balancer
Je suis assez confus quant aux rôles d'Ingress et Load Balancer dans Kubernetes.
Autant que je sache, Ingress est utilisé pour mapper le trafic entrant d'Internet vers les services en cours d'exécution 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 l'entrée diffère-t-elle de l'équilibreur de charge? De plus, quel est le concept d'équilibreur de charge dans kubernetes par rapport à Amazon ELB et ALB?
Equilibreur 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 fournissent cette capacité de manière native. En ce qui concerne Amazon, cela mappe directement avec ELB et kubernetes lors de l'exécution dans AWS peuvent 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 ensemble de règles d’entrée, mais rien ne se passera si vous n’avez pas un contrôleur capable de les traiter. Un service LoadBalancer pourrait écouter les règles d'entrée, s'il est configuré pour le faire.
Vous pouvez également créer un service NodePort , qui possède une adresse IP routable en externe en dehors du cluster, mais pointe vers un pod existant dans votre cluster. Cela pourrait être 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. Nginx est l’un des contrôleurs d’entrée les plus populaires pris en charge par kubernetes. En termes d'Amazon, ALB peut être utilisé en tant que contrôleur d'entrée.
Par exemple, this Le contrôleur nginx est capable d’intégrer 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.
Supposons par exemple que vous définissiez 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 contrôleur nginx, la règle suivante est 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 afin qu'il pointe vers le service appsvc de votre cluster.
Voici n exemple expliquant comment implémenter un cluster kubernetes avec un contrôleur d’infiltration 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.
A partir 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 adresse IP unique 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 transféré au service. Il n'y a pas de filtrage, pas de routage, etc. Cela signifie que vous pouvez envoyer presque tout type de trafic, comme HTTP, TCP, UDP, Websockets, gRPC, etc.
Le gros inconvénient est que chaque service que vous exposez avec un LoadBalancer aura sa propre adresse IP et que vous devrez payer pour un LoadBalancer par service exposé, ce qui peut coûter cher!
Entrée:
L'entrée n'est en réalité 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 une entrée, et il existe de nombreux types de contrôleurs d'entrée ayant des capacités différentes.
Le contrôleur d'entrée GKE par défaut créera un équilibreur de charge HTTP (S) à votre place. Cela vous permettra d'effectuer un routage basé sur un chemin d'accès et un sous-domaine vers des services principaux. Par exemple, vous pouvez envoyer tout ce qui se trouve sur foo.votredomaine.com au service foo, ainsi que tout ce qui se trouve sous le chemin votredomaine.com/bar/ du service de bar.
L'entrée 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 d’entrée, tels que l’équilibreur de charge Google Cloud, Nginx, Contour, Istio, etc. Il existe également des plugins pour les contrôleurs Ingress, comme le cert-manager, qui peut automatiquement fournir 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 GCP native et, comme Ingress est "intelligent", vous pouvez obtenir un grand nombre de fonctionnalités prêtes à l'emploi (telles que SSL, Auth, Routing, etc.).
TL: DR
- Une entrée se situe entre le réseau public (Internet) et les services Kubernetes qui exposent publiquement la mise en œuvre de notre API.
- Ingress est capable de fournir un équilibrage de charge, une terminaison SSL et un hébergement virtuel basé sur un nom.
- Les fonctionnalités d'Ingress permettent d'exposer de manière sécurisée plusieurs API ou applications à partir d'un même nom de domaine.
Commençons par le cas d'utilisation pratique: vous avez plusieurs Apis soutenus par des packages d'implémentation de service (ASIP pour clariy et brièveté) à déployer sous un seul nom de domaine. En tant que développeur Edge, vous avez mis en place une architecture de micro-services nécessitant des déploiements distincts pour chaque ASIP, de sorte qu'ils puissent être mis à niveau ou mis à l'échelle individuellement. Bien entendu, ces ASIP sont encapsulés dans un conteneur individuel et sont disponibles pour Kubernetes (K8) à partir du référentiel de conteneurs.
Disons maintenant que vous souhaitez déployer ceci sur les K8 K8 de Google. Pour mettre en œuvre une disponibilité soutenue, chaque instance ASIP (réplica) est déployée sur différents noeuds (VM) où chaque VM a sa propre adresse IP interne dans le 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 choses, le nombre de réplicas du AS8 K8 donné à déployer.
L'étape suivante consiste à exposer l'API au monde extérieur et à envoyer les demandes de tunnel à l'une des instances ASIP déployées. Étant donné que de nombreuses répliques du même ASIP s'exécutant sur des nœuds différents, 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 K8 (KServ) qui sera exposé de manière externe et accessible via 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 K8 lorsque le nœud d'un ASIP échoue et est redémarré. Les adresses IP internes ne sont jamais réutilisées dans ce cas et le KServ doit être informé du nouvel emplacement de déploiement du ASIP.
Mais nous avons d'autres packages de services Api qui doivent être 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à que Ingress entre en jeu.
La porte d'entrée entre Internet et tous les KServices auxquels nous sommes exposés est exposée au monde extérieur. Ingress est capable de fournir un équilibrage de charge, une terminaison SSL et un hébergement virtuel basé sur un nom. Cette dernière capacité est capable de router une demande entrante vers le bon service en analysant son URL. Bien entendu, Ingress doit être configuré et appliqué avec un fichier ... "ingress.yaml" qui spécifie les réécritures et les routes requises pour envoyer une demande au bon KServ.
Internet -> Entrée -> Services K8s -> Répliques
Ainsi, avec la bonne entrée, la configuration de KServices et ASIP, nous pouvons exposer de manière sécurisée de nombreuses API utilisant le même nom de domaine.
En termes simples, Load Balancer répartit les requêtes entre plusieurs services backend (du même type), tandis que Ingress ressemble davantage à une passerelle API (proxy inverse) qui achemine la requête vers un service backend spécifique, basé par exemple sur l'URL.
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 ingress 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 requête, le domaine de requête et le service kubernetes cible, alors 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, Nginx Ingress Controller pourrait utiliser un service pour écouter les ports 80 et 443, puis lire de nouveaux objets d’intrusion et les analyser dans de nouvelles sections du serveur {} qu’il place dynamiquement dans son nginx.conf.
LoadBalancer: Fournisseur externe d'équilibreur de charge + Type de service
Fournisseur externe d'équilibreur de charge:
Les fournisseurs d'équilibreur de charge externe sont généralement configurés dans des nuages tels que AWS et GKE et permettent d'affecter des adresses IP externes via la création d'équilibreurs de charge externes. Cette fonctionnalité peut être utilisée en désignant un service sous le 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 modules Kubernetes, leur attribuant ainsi des adresses IP externes.
Le contrôleur de service Kubernetes automatise la création de l’équilibreur de charge externe, des contrôles de santé (si nécessaire) et des règles de pare-feu (si nécessaire), et récupère l’adresse IP externe du LoadBalancer nouvellement créé ou configuré qui a été alloué par le fournisseur de cloud. objet de service.
Relations:
Les services Ingress Controller sont souvent configurés en tant que type LoadBalancer, de sorte que les demandes http et https peuvent être transmises par proxy/routées vers des services internes spécifiques via une adresse IP externe.
Cependant, LoadBalancer n'est pas strictement nécessaire pour cela. Étant donné que, grâce à hostNetwork ou hostPort, vous pouvez lier techniquement un port de l'hôte à un service (vous permettant de le visiter via l'adresse IP externe de l'hôte: port). Bien qu’officiellement, cela n’est 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/concepts/services-networking/ingress/
Il existe 3 façons d'autoriser les pods de votre cluster à recevoir du trafic externe:
1.) Service NodePort
2.) Service LoadBalancer (qui repose sur le service NodePort)
3..) Contrôleur d'entrée + Objets d'entrée (qui s'appuie sur le service LoadBalancer)
Disons que vous avez 10 sites Web hébergés dans votre cluster et que vous souhaitez les exposer tous 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 obtiendrez un équilibreur de charge HA Cloud (vous permettant d'économiser de l'argent) qui pointe vers un contrôleur Ingress en cours d'exécution dans votre cluster.
Un contrôleur d’entrée est:
- Un service de type Load Balancer soutenu par un déploiement de pods exécutés dans votre cluster.
- Chaque pod fait 2 choses:
- Agit comme un équilibreur de charge de couche 7 s'exécutant dans votre cluster. (Vient dans beaucoup de saveurs Nginx est populaire)
- Se configure de manière dynamique 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 traite le trafic 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 cert TLS et d'un objet Ingress qui le référence.)
