1

As far as I understood, Istio Destination Rules can define load balancing policies to reach a subset of a service, e.g. subset based on different versions of the service. So the Destination Rules are the first level of load balancing.

The request will eventually reach a K8s service which is generally implemented by kube-proxy. Kube-proxy does a simple load-balancing with the pods in its back-end. Here is the second level of load balancing.

Is there a way to remove the second load-balancer? For example, could we create a lot of services instances that offer the same service and can be load-balanced by Destination Rules and then have only one pod per service instance, so that kube-proxy does not apply load-balancing?

M. Buil
  • 529
  • 1
  • 4
  • 22
  • Hi, what are You trying to achieve? `Kube-Proxy` is implemented using each nodes `iptables`. So with or without loadbalancing there might be no performance differences. – Piotr Malec Mar 27 '20 at 15:25
  • I am just trying to understand if traffic inside the service mesh is still using the iptables created by kube-proxy for the service – M. Buil Mar 27 '20 at 17:36

1 Answers1

0

According to istio documentation:

Istio’s traffic routing rules let you easily control the flow of traffic and API calls between services. Istio simplifies configuration of service-level properties like circuit breakers, timeouts, and retries, and makes it easy to set up important tasks like A/B testing, canary rollouts, and staged rollouts with percentage-based traffic splits. It also provides out-of-box failure recovery features that help make your application more robust against failures of dependent services or the network.

Istio’s traffic management model relies on the Envoy proxies that are deployed along with your services. All traffic that your mesh services send and receive (data plane traffic) is proxied through Envoy, making it easy to direct and control traffic around your mesh without making any changes to your services.

If you’re interested in the details of how the features described in this guide work, you can find out more about Istio’s traffic management implementation in the architecture overview. The rest of this guide introduces Istio’s traffic management features.

This means that the istio service mesh is communicating via envoy proxy which in turn relies on kubernetes networking.

We can have an example where a VirtualService that is using istio ingress gateway load-balances it's traffic to two different services based on labels. Then those services can have multiple pods.

Istio load-balancing in this case works only on (layer 7) which results with route to specific endpoint (one of the services) and relies on kubernetes to handle connections and the rest including service round-robin load-balancing (layer 4) in case of multiple pods.

The advantage of having single service with multiple pods is obviously easier configuration and management. In case of 1 pod per service, each service would need to be reconfigured separately and loses all of its ability to scale features.

There is a great video on Youtube which partially covers this topic: Life of a packet through Istio by Matt Turner.

I highly recommend watching as it explains how istio works on a fundamental level.

Community
  • 1
  • 1
Piotr Malec
  • 3,429
  • 11
  • 16