Explicación detallada del modo proxy kube-proxy
kube-proxy actualmente admite los siguientes modos de proxy:
1. Espacio de usuario: la primera solución de equilibrio de carga, escucha un puerto en el espacio de usuario y todos los servicios se reenvían a este puerto a través de iptables, y luego la carga interna se equilibra con el Pod real. El principal problema de este método es la baja eficiencia y el evidente cuello de botella en el rendimiento, por lo que ya no se recomienda.
Por ejemplo, para crear un servicio, la IP correspondiente: 1.2.3.4, puerto: 8888, el puerto seleccionado aleatoriamente por kube-proxy es 32890, se agregará en iptables
-A PREROUTING -j KUBE-PORTALS-CONTAINER
-A KUBE-PORTALS-CONTAINER -d 1.2.3.4/32 -p tcp --dport 8888 -j REDIRECT --to-ports 32890
KUBE-PORTALS-CONTAINER es la cadena de reglas creada por kube-proxy en iptable, que se ejecuta en la fase PREROUTING
Proceso de implementación:
- Cuando exista una solicitud de acceso al servicio, en la etapa PREROUTING se solicitará jumpKUBE-PORTALS-CONTAINER;
- Este registro en KUBE-PORTALS-CONTAINER funciona, redirigiendo la solicitud al puerto 32890 que kube-proxy acaba de escuchar, y el paquete de datos ingresa al proceso de kube-proxy;
- Luego, kube-proxy seleccionará uno del punto final correspondiente al servicio de acuerdo con SessionAffinity como la solicitud de respuesta del servicio real.
2. iptables: la solución actualmente recomendada utiliza las reglas de iptables para lograr el equilibrio de carga del servicio. El principal problema con este método es que se generan demasiadas reglas de iptables cuando hay muchos servicios, y las actualizaciones no incrementales introducirán cierto retraso, y hay problemas de rendimiento obvios en casos a gran escala.
Por ejemplo, si se crea un servicio, la IP correspondiente: 1.2.3.4, puerto: 8888 y una dirección de backend correspondiente: 10.1.0.8: 8080, se agregará en iptables (reglas principales):
-A PREROUTING -j KUBE-SERVICES
-A KUBE-SERVICES -d 1.2.3.4/32 -p tcp –dport 8888 -j KUBE-SVC-XXXXXXXXXXXXXXXX
-A KUBE-SVC-XXXXXXXXXXXXXXXX -j KUBE-SEP-XXXXXXXXXXXXXXXX
-A KUBE-SEP-XXXXXXXXXXXXXXXX -p tcp -j DNAT –to-destination 10.1.0.8:8080
KUBE-SERVICES es la cadena de reglas creada por kube-proxy en iptable, que se ejecuta en la etapa PREROUTING
Proceso de implementación:
- Al solicitar acceder al servicio, iptables saltará a KUBE-SERVICES durante la etapa de preenrutamiento;
- Haga coincidir el primer criterio anterior en KUBE-SERVICES, continúe saltando a KUBE-SVC-XXXXXXXXXXXXXXXX;
- Saltar a KUBE-SEP-XXXXXXXXXXXXXXXX de acuerdo con esta regla;
- En la regla KUBE-SEP-XXXXXXXXXXXXXXXX, acceda a la dirección del pod real 10.1.0.8:8080 a través de la acción DNAT.
3. ipvs: para resolver el problema de rendimiento del modo iptables, v1.11 agregó el modo ipvs (v1.8 comenzó a admitir la versión beta y v1.11 GA), usando actualización incremental y puede garantizar la conexión durante el servicio actualizar Mantenerlo intacto.
En el modo IPVS, kube-proxy observa los cambios de los objetos de punto final y de servicio en Kubernetes, crea las reglas IPVS correspondientes llamando a la interfaz netlink y sincroniza periódicamente las reglas de servicio, punto final e IPVS de Kubernetes. Al acceder a un servicio, IPVS es responsable de seleccionar un backend real para proporcionar servicios.
El modo IPVS también se basa en la función de enlace de netfilter (etapa INPUT), que es lo mismo que el modo iptables, pero usa la tabla hash del espacio de trabajo del núcleo como la estructura de datos almacenada. solicitud cumple una regla. Cuando cambia el servicio, solo es necesario actualizar los registros en ipset y no es necesario cambiar la cadena de reglas de iptables. Por lo tanto, se puede garantizar que las reglas en iptables no aumentarán con el aumento de los servicios y brindarán rendimiento consistente en el caso de clústeres de servicios de ultra gran escala Efecto.
El rendimiento al sincronizar las reglas también es mayor que el de iptables (solo se actualiza una tabla hash específica, en lugar de operar en toda la tabla de reglas en modo iptables), por lo que puede proporcionar un mayor tráfico de red.
IPVS también proporciona algoritmos más flexibles en la selección de servicios de backend:
- rr: round-robin (algoritmo round-robin)
- lc: mínima conexión (algoritmo de número mínimo de conexión)
- dh: hash de destino (algoritmo hash de dirección de destino)
- sh: hashing de origen (algoritmo de hash de dirección original)
- sed: retraso esperado más corto (algoritmo de retraso esperado más corto)
- nq: nunca en cola (algoritmo nunca en cola)
4. winuserspace: Igual que el espacio de usuario, pero solo funciona en nodos de Windows.
Este es el final del intercambio de hoy.
