Implementé un statefulset en AKS: mi objetivo es equilibrar la carga del tráfico en mi statefulset.
Según tengo entendido, puedo definir un servicio LoadBalancer que puede enrutar el tráfico en función de los selectores, algo como esto.
apiVersion: v1 kind: Service metadata: name: nginx labels: app: nginx spec: type: LoadBalancer ports: - port: 80 name: web selector: app: nginxSin embargo, no quiero seguir necesariamente la ruta LoadBalance y preferiría que Ingress haga este trabajo por mí. Mi pregunta es: ¿alguno de los controladores de ingreso admite reglas de enrutamiento que puedan hacer enrutamiento basado en rutas a puntos finales según selectores? En lugar de enrutar a otro servicio.
Actualizar Para elaborar más sobre el escenario: cada pod en mi statefulset es un nodo sin estado que realiza el procesamiento de datos de una fuente HTTP. Quiero que mi servicio de ingreso pueda equilibrar la carga del tráfico a través de estos pods statefulset (honorando a los keep-alives, etc.); sin embargo, dada la naturaleza de los statefulsets en k8, actualmente están expuestos a través de un servicio sin cabeza. No estoy seguro de si un servicio sin cabeza puede equilibrar la carga del tráfico en mis statefulsets.
Actualización 2 La búsqueda rápida revela que el servicio headless no equilibra la carga
Sometimes you don't need load-balancing and a single Service IP. In this case, you can create what are termed "headless" Services, by explicitly specifying "None" for the cluster IP (.spec.clusterIP).
Por lo que sé, no es posible hacer el enrutamiento basado en selector con ingreso.
El enrutamiento basado en selector se usa principalmente durante una implementación azul-verde o una implementación canary; solo puede lograr esto mediante el uso de la malla de servicio. Puede usar cualquiera de las mallas de servicio como istio o APP mesh y puede hacer el enrutamiento base del selector.
Implementé un statefulset en AKS: mi objetivo es equilibrar la carga del tráfico en mi statefulset.
Si su objetivo es simplemente equilibrar la carga del tráfico, puede usar el controlador de ingreso, tal vez aún no esté seguro del escenario que está tratando de explicar.
De forma predeterminada, el servicio de kubernetes también equilibra la carga del tráfico en los POD .
El flujo será algo así como DNS > ingress > ingress controller > Kubernetes service (Load balancing here) > any of statefulset
+1 a la respuesta de Harsh Manvar, pero permítanme agregar también mis 3 centavos.
Mi pregunta es: ¿alguno de los controladores de ingreso admite reglas de enrutamiento que puedan hacer enrutamiento basado en rutas a puntos finales en función de selectores? En lugar de enrutar a otro servicio.
Que yo sepa, la respuesta a su pregunta es no, no puede , ya que ni siquiera depende de una implementación particular del controlador de ingreso. Tenga en cuenta que varios controladores de entrada, sin importar cuán diferentes puedan ser en lo que respecta a la implementación, deben cumplir con la especificación general del recurso de entrada , descrita en la documentación oficial de kubernetes. No tiene diferentes tipos de ingresos, según el controlador que se use.
Ingress y Service funcionan en una capa diferente de abstracción. Mientras que Service expone un conjunto de pods usando un selector, por ejemplo:
apiVersion: v1 kind: Service metadata: name: my-service spec: selector: app: MyApp 👈 El enrutamiento basado en rutas realizado por Ingress siempre se realiza entre Services :
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: minimal-ingress annotations: nginx.ingress.kubernetes.io/rewrite-target: / spec: rules: - http: paths: - path: /testpath pathType: Prefix backend: service: name: test 👈 port: number: 80No estoy seguro de si un servicio sin cabeza puede equilibrar la carga del tráfico en mis statefulsets.
La primera respuesta es "no". ¿Por qué?
El servicio k8s es implementado por kube-proxy. El propio Kube-proxy puede funcionar de dos modos:
el equilibrio de carga en el caso del modo iptables es una regla de NAT iptables: desde la dirección ClusterIP hasta la lista de puntos finales
el equilibrio de carga en el caso del modo ipvs es un VIP (IP virtual LVS) con los puntos finales como aguas arriba
Entonces, cuando crea el Servicio k8s con clusterIP establecido en Ninguno, está diciendo exactamente:
"Necesito este servicio SIN balanceo de carga"
La configuración de clusterIP en Ninguno hace que kube-proxy NO CREE la regla NAT en modo iptables, VIP en modo ipvs. No habrá nada para equilibrar la carga de tráfico en los pods seleccionados por este selector de servicios en particular.
La segunda respuesta es "podría ser". ¿Por qué?
Puede crear un servicio sin cabeza con el selector de pods deseado. La consulta de DNS a este servicio devolverá la lista de registros A de DNS para los pods seleccionados. Luego puede usar estos datos para implementar el equilibrio de carga a SU manera