Ingreso vs balanceador de carga
Estoy bastante confundido acerca de las funciones de Ingress y Load Balancer en Kubernetes.
Hasta donde tengo entendido, Ingress se utiliza para asignar el tráfico entrante de Internet a los servicios que se ejecutan en el clúster.
La función del equilibrador de carga es reenviar el tráfico a un host. En ese sentido, ¿en qué se diferencia el ingreso del balanceador de carga? Además, ¿cuál es el concepto de equilibrador de carga dentro de Kubernetes en comparación con Amazon ELB y ALB?
Equilibrador de carga: un servicio LoadBalancer de Kubernetes es un servicio que apunta a equilibradores de carga externos que NO están en su clúster de Kubernetes, pero que existen en otros lugares. Pueden trabajar con sus pods, suponiendo que sus pods sean enrutables externamente. Google y AWS proporcionan esta capacidad de forma nativa. En términos de Amazon, esto se asigna directamente con ELB y kubernetes cuando se ejecuta en AWS puede aprovisionar y configurar automáticamente una instancia de ELB para cada servicio LoadBalancer implementado.
Ingreso: un ingreso es en realidad solo un conjunto de reglas para pasar a un controlador que las está escuchando. Puedes implementar un montón de reglas de ingreso, pero no sucederá nada a menos que tengas un controlador que pueda procesarlas. Un servicio LoadBalancer podría escuchar las reglas de ingreso, si está configurado para hacerlo.
También puede crear un servicio NodePort , que tiene una IP enrutable externamente fuera del clúster, pero apunta a un pod que existe dentro de su clúster. Este podría ser un controlador de ingreso.
Un controlador de ingreso es simplemente un pod configurado para interpretar reglas de ingreso. Uno de los controladores de ingreso más populares admitidos por Kubernetes es nginx. En términos de Amazon, ALB se puede utilizar como controlador de ingreso.
Por ejemplo, este controlador nginx puede ingerir reglas de ingreso que haya definido y traducirlas a un archivo nginx.conf que carga e inicia en su pod.
Digamos, por ejemplo, que definiste una entrada de la siguiente manera:
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 luego inspecciona el módulo de su controlador nginx, verá la siguiente regla definida en /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 acaba de crear una regla para http://kubernetes.foo.bar/appenrutar el servicio appsvcen su clúster.
A continuación se muestra un ejemplo de cómo implementar un clúster de Kubernetes con un controlador de entrada nginx.
Encontré este artículo muy interesante que explica las diferencias entre NodePort, LoadBalancer e Ingress.
Del contenido presente en el artículo:
Equilibrador de carga:
Un servicio LoadBalancer es la forma estándar de exponer un servicio a Internet. En GKE, esto activará un balanceador de carga de red que le brindará una única dirección IP que reenviará todo el tráfico a su servicio.
Si desea exponer directamente un servicio, este es el método predeterminado. Todo el tráfico en el puerto que especifique se reenviará al servicio. No hay filtrado, ni enrutamiento, etc. Esto significa que puede enviarle casi cualquier tipo de tráfico, como HTTP, TCP, UDP, Websockets, gRPC o lo que sea.
La gran desventaja es que cada servicio que exponga con un LoadBalancer obtendrá su propia dirección IP y tendrá que pagar por un LoadBalancer por cada servicio expuesto, ¡lo que puede resultar costoso!
Ingreso:
En realidad, Ingress NO es un tipo de servicio. En cambio, se ubica frente a múltiples servicios y actúa como un "enrutador inteligente" o punto de entrada a su clúster.
Puedes hacer muchas cosas diferentes con un Ingress y hay muchos tipos de controladores Ingress que tienen diferentes capacidades.
El controlador de ingreso predeterminado de GKE activará un balanceador de carga HTTP(S) por usted. Esto le permitirá realizar enrutamiento basado en rutas y subdominios a servicios backend. Por ejemplo, puede enviar todo
foo.yourdomain.exampleal servicio foo y todo lo que se encuentra en layourdomain.example/bar/ruta al servicio de bar.El ingreso es probablemente la forma más poderosa de exponer sus servicios, pero también puede ser la más complicada. Hay muchos tipos de controladores de Ingress, desde Google Cloud Load Balancer, Nginx, Contour, Istio y más. También hay complementos para los controladores de Ingress, como el administrador de certificados, que pueden proporcionar automáticamente certificados SSL para sus servicios.
Ingress es el más útil si desea exponer varios servicios bajo la misma dirección IP, y todos estos servicios utilizan el mismo protocolo L7 (normalmente HTTP). Solo paga por un balanceador de carga si está utilizando la integración nativa de GCP y, debido a que Ingress es "inteligente", puede obtener muchas funciones listas para usar (como SSL, autenticación, enrutamiento, etc.)
Hay 4 formas de permitir que los pods en su clúster reciban tráfico externo:
1.) Pod usando HostNetworking: verdadero y (Permite que 1 pod por nodo escuche directamente los puertos en el nodo host. Minikube, bare metal y rasberry pi a veces van esta ruta, que puede permitir que el nodo host escuche en el puerto 80/443, permite no utilizar un balanceador de carga o configuraciones avanzadas de balanceador de carga en la nube, también omite los servicios de Kubernetes, que pueden ser útiles para evitar SNAT/lograr un efecto similar de externalTrafficPolicy: Local en escenarios donde no es compatible como en AWS.)
2.) Servicio NodePort
3.) Servicio LoadBalancer (que se basa en el servicio NodePort)
4.) Controlador de ingreso + objetos de ingreso (que se basa en lo anterior)
Digamos que tiene 10 sitios web alojados en su clúster y desea exponerlos todos al tráfico externo.
*Si usa el tipo LoadBalancer Service, generará 10 balanceadores de carga de HA Cloud (cada uno cuesta dinero)
*Si usa el tipo Ingress Controller, generará 1 balanceador de carga de HA Cloud (ahorra dinero) y apuntará a un Ingress Controlador ejecutándose en su clúster.
Un controlador de ingreso es:
- Un servicio de tipo Load Balancer respaldado por una implementación de pods que se ejecutan en su clúster.
- Cada módulo hace 2 cosas:
- Actúa como un equilibrador de carga de capa 7 que se ejecuta dentro de su clúster. (Viene en muchos sabores, Nginx es popular)
- Se configura dinámicamente en función de los objetos de ingreso en su clúster
(los objetos de ingreso se pueden considerar como fragmentos de configuración declarativa de un balanceador de carga de capa 7).
El controlador L7 LB/Ingress dentro de su clúster equilibra la carga/proxy inverso el tráfico a los servicios IP del clúster dentro de su clúster; también puede terminar HTTPS si tiene un secreto de Kubernetes de tipo certificado TLS y un objeto Ingress que hace referencia a él).
En palabras simples, el balanceador de carga distribuye las solicitudes entre múltiples servicios backend (del mismo tipo), mientras que el ingreso se parece más a una puerta de enlace API (proxy inverso) que enruta la solicitud a un servicio backend específico basándose, por ejemplo, en la URL.
