6 ms·

Can somebody explain what istio does in simple words? I see that it hooks into micro/services communication, but why do we need that? isnt policies enforced by

Can somebody explain what istio does in simple words? I see that it hooks into micro/services communication, but why do we need that? isnt policies enforced by cni plugins? and can microservices communicate already with k8s and mesos default setups? is istio an network abstraction layer for k8s and mesos? why would anyone want that, is there anybody who changes scheduling runtimes often?

parasubvert 8y ago
Fundamentally, it’s about programmable application networking. Like, make my network change the protocol, or data, or re-route the flow the way I want, without having to change underlying network wiring, equipment, or router config. It does this by using little out-of-process agents (Envoy) to sit next to your application as a sidecar. All application network flows go through the sidecars (which are localhost). Istio is the config engine for all these sidecars, and for the overall gateway to your clusters. They call this a service mesh. Istio in theory has little to do with Kubernetes or Mesos, except that it intitially assumed everyone will be running apps in Kubernetes (because Istio is from google). But It is designed to be independent of k8s as it can run with Mesos or Cloud Foundry. Some example use cases: 1. Configuring (mutual) TLS for apps so each app doesn’t have to. This is huge, as keypair handling is a major point of risk and annoyance. 2. Auto-renewing/installing (mutual) TLS certificates across an entire set of apps 3. Intercepting and re-routing network flows for A/B testing , traffic shedding, or failure tolerance (circuit breaking) 4. Global load balancing with more ability to tweak the algorithm (beyond just DNS) 5. Tracing / visibility of application network flows across a WAN for debugging Is it necessary? No. Is it useful? Yeah, it can be.
zinclozenge 8y ago
istio can/will inject a network proxy container into your pods. The proxy intercepts traffic to and from the pod. It also ships with a set of telemetry and metrics services that the proxies send data to. Coupled with that, it has a whole suite of custom resource definitions for fine grained configuration. I'd highly recommend reading the docs if you haven't already to get a better overview.
unscaled 8y ago
Kubernetes already gives you basic service discovery network policy and a network abstraction layer, but Istio is more about abstracting and enriching communication patterns on (sometimes) Layer 4 and (more often) Layer 7. It allows you to use kubernetes manifest to centrally control policies such as: - Canary load balancing (pushing a certain percentage of the traffic to a canary release) - TLS Mutual Authentication - Retries with exponential backoff - Circuit breakers - Instrumenting your traffic for distributed tracing (e.g. with Jaeger) - Adding your own custom HTTP headers All of that is transparent to your microservice. This comes instead of having to repeat the service mesh logic that does everything above in each microservice. From the microservice 's perspective they're just sending simple traffic without implementing retries, circuit breakers, HTTPS or instrumentation. Istio takes care of all the rest using sidecars and and ingress controllers.
- avita1 8y ago
  Is the Kubernetes native (for lack of a better word) service discovery used in many real world use cases? The sense I've gotten talking to people who use kubernetes is that they fall into one of two camps: - they're moving "legacy" infrastructure off EC2 or similar onto Kubernetes and their service discovery stack is already in place. They end up bypassing cluster IPs and dealing directly with pod IPs. - they're starting with Istio or something similar from the get go because the native service discovery is hard to grok and leaves out a lot of the nice things that Istio gets you for free (once you've set it up) There's lots of overlap, but I've not heard of anyone making a strong argument for the native service discovery.
  - the_duke 8y ago
    The native service discovery can be enough for small deployments with a handful of services where the complexity of operating a service mesh is not really worth it. I've seen plenty of those from smaller startups.
  - nprateem 8y ago
    Unless I've misunderstood you, if you're dealing with pod IPs instead of service DNS addresses you're not fault tolerant and you might as well not even bother with K8s.
dankohn1 8y ago
It's not ELI5, but the best explanation I've seen comes from Envoy-creator Matt Klein: https://blog.envoyproxy.io/service-mesh-data-plane-vs-control-plane-2774e720f7fc https://blog.envoyproxy.io/service-mesh-data-plane-vs-contro... "Istio is the control plane and Envoy is the data plane" "Ultimately, the goal of a control plane is to set policy that will eventually be enacted by the data plane."
kkapelon 8y ago
Without Istio - 4 K8s pods each one gets 25% of traffic and that is the only option With Istio - 1st pod takes 60% of traffic, second takes 30%, and last two take 5% each With Istio - 1st pod takes users from /foo, second from /baz, third with user-agent forby and fourth with user agent kirby Just some very simple examples. Istio has many more capabilities
orthoxerox 8y ago
It abstracts communication-layer logic out of your containers. You don't have to code stuff like TLS, retries, failovers, circuit breakers, load balancing, etc. You code business logic in your microservices and declare all this communication stuff in a shared config file. This configuration is picked up by Istio and deployed into more containers that serve as transparent proxies implementing communication-layer logic.
- lcalcote 8y ago
  Good summary.
deleted 8y ago
[deleted]
peterwwillis 8y ago
It's a kubernetes service mesh. https://www.nginx.com/blog/what-is-a-service-mesh/ https://www.nginx.com/blog/what-is-a-service-mesh/
- moderation 8y ago
  NGINX have since discontinued work on their service mesh called Nginmesh [0] 0. https://github.com/nginxinc/nginmesh#important-project-notice https://github.com/nginxinc/nginmesh#important-project-notic...
  - olafmol 8y ago
    anybody has more insights on what happened here?
rdli 8y ago
Because in modern-day cloud systems there is a lot of service-to-service communication, L7 becomes really important (i.e., you're building a distributed system). Istio (and other meshes) try to abstract away the nuances of distributed computing away from developers, by magically adding timeouts, retries, circuit breakers, observability, etc. In practice, Istio is pretty complex and not for the faint of heart. You can think of Istio and its cousins (Linkerd, Consul Connect, etc) as the spiritual successors of the original Netflix OSS stack and Finagle.
manigandham 8y ago
Istio manages east-west traffic (between programs in your cluster) vs north-south traffic (in and out of your cluster). Kubernetes only provides basic service discovery with "service.namespace.cluster" DNS entries to communicate between apps in the cluster. The standard routing is just ip tables configured on each node. It works well but may be limiting for complex deployments. What Istio does is replace all that with several components. The foundation is the Envoy proxy which runs as a sidecar to all of your pods and handles all the network traffic, providing much better performance, more load-balancing algorithms, advanced routing, retries, rate limiting, observability and tracing (at protocol level), grpc/http2 in both directions, TLS management, traffic shadowing, and custom filters that you can use to do whatever you want with the traffic. There are also several "control plane" components which actually do the wiring and config management and work in the background. There are several alternatives in this space like Linkerd, Consul Connect, Kong, and even Nginx and Haproxy getting into it. Some are focused only on Kubernetes while others let you communicate across clusters and standalone VMs.
- dankohn1 8y ago
  CNCF is tracking 10 service proxy options, 8 API gateways, and 4 service mesh alternatives: https://landscape.cncf.io/category=service-proxy,api-gateway,service-mesh&format=card-mode&grouping=category https://landscape.cncf.io/category=service-proxy,api-gateway...

parasubvert 8y ago

Fundamentally, it’s about programmable application networking. Like, make my network change the protocol, or data, or re-route the flow the way I want, without having to change underlying network wiring, equipment, or router config. It does this by using little out-of-process agents (Envoy) to sit next to your application as a sidecar. All application network flows go through the sidecars (which are localhost). Istio is the config engine for all these sidecars, and for the overall gateway to your clusters. They call this a service mesh. Istio in theory has little to do with Kubernetes or Mesos, except that it intitially assumed everyone will be running apps in Kubernetes (because Istio is from google). But It is designed to be independent of k8s as it can run with Mesos or Cloud Foundry. Some example use cases: 1. Configuring (mutual) TLS for apps so each app doesn’t have to. This is huge, as keypair handling is a major point of risk and annoyance. 2. Auto-renewing/installing (mutual) TLS certificates across an entire set of apps 3. Intercepting and re-routing network flows for A/B testing , traffic shedding, or failure tolerance (circuit breaking) 4. Global load balancing with more ability to tweak the algorithm (beyond just DNS) 5. Tracing / visibility of application network flows across a WAN for debugging Is it necessary? No. Is it useful? Yeah, it can be.

zinclozenge 8y ago

istio can/will inject a network proxy container into your pods. The proxy intercepts traffic to and from the pod. It also ships with a set of telemetry and metrics services that the proxies send data to. Coupled with that, it has a whole suite of custom resource definitions for fine grained configuration. I'd highly recommend reading the docs if you haven't already to get a better overview.

unscaled 8y ago

Kubernetes already gives you basic service discovery network policy and a network abstraction layer, but Istio is more about abstracting and enriching communication patterns on (sometimes) Layer 4 and (more often) Layer 7. It allows you to use kubernetes manifest to centrally control policies such as: - Canary load balancing (pushing a certain percentage of the traffic to a canary release) - TLS Mutual Authentication - Retries with exponential backoff - Circuit breakers - Instrumenting your traffic for distributed tracing (e.g. with Jaeger) - Adding your own custom HTTP headers All of that is transparent to your microservice. This comes instead of having to repeat the service mesh logic that does everything above in each microservice. From the microservice 's perspective they're just sending simple traffic without implementing retries, circuit breakers, HTTPS or instrumentation. Istio takes care of all the rest using sidecars and and ingress controllers.

avita1 8y ago
Is the Kubernetes native (for lack of a better word) service discovery used in many real world use cases? The sense I've gotten talking to people who use kubernetes is that they fall into one of two camps: - they're moving "legacy" infrastructure off EC2 or similar onto Kubernetes and their service discovery stack is already in place. They end up bypassing cluster IPs and dealing directly with pod IPs. - they're starting with Istio or something similar from the get go because the native service discovery is hard to grok and leaves out a lot of the nice things that Istio gets you for free (once you've set it up) There's lots of overlap, but I've not heard of anyone making a strong argument for the native service discovery.
- the_duke 8y ago
  The native service discovery can be enough for small deployments with a handful of services where the complexity of operating a service mesh is not really worth it. I've seen plenty of those from smaller startups.
- nprateem 8y ago
  Unless I've misunderstood you, if you're dealing with pod IPs instead of service DNS addresses you're not fault tolerant and you might as well not even bother with K8s.

dankohn1 8y ago

It's not ELI5, but the best explanation I've seen comes from Envoy-creator Matt Klein: https://blog.envoyproxy.io/service-mesh-data-plane-vs-control-plane-2774e720f7fc https://blog.envoyproxy.io/service-mesh-data-plane-vs-contro... "Istio is the control plane and Envoy is the data plane" "Ultimately, the goal of a control plane is to set policy that will eventually be enacted by the data plane."

kkapelon 8y ago

Without Istio - 4 K8s pods each one gets 25% of traffic and that is the only option With Istio - 1st pod takes 60% of traffic, second takes 30%, and last two take 5% each With Istio - 1st pod takes users from /foo, second from /baz, third with user-agent forby and fourth with user agent kirby Just some very simple examples. Istio has many more capabilities

orthoxerox 8y ago

It abstracts communication-layer logic out of your containers. You don't have to code stuff like TLS, retries, failovers, circuit breakers, load balancing, etc. You code business logic in your microservices and declare all this communication stuff in a shared config file. This configuration is picked up by Istio and deployed into more containers that serve as transparent proxies implementing communication-layer logic.

lcalcote 8y ago
Good summary.

deleted 8y ago

[deleted]

peterwwillis 8y ago

It's a kubernetes service mesh. https://www.nginx.com/blog/what-is-a-service-mesh/ https://www.nginx.com/blog/what-is-a-service-mesh/

moderation 8y ago
NGINX have since discontinued work on their service mesh called Nginmesh [0] 0. https://github.com/nginxinc/nginmesh#important-project-notice https://github.com/nginxinc/nginmesh#important-project-notic...
- olafmol 8y ago
  anybody has more insights on what happened here?

rdli 8y ago

Because in modern-day cloud systems there is a lot of service-to-service communication, L7 becomes really important (i.e., you're building a distributed system). Istio (and other meshes) try to abstract away the nuances of distributed computing away from developers, by magically adding timeouts, retries, circuit breakers, observability, etc. In practice, Istio is pretty complex and not for the faint of heart. You can think of Istio and its cousins (Linkerd, Consul Connect, etc) as the spiritual successors of the original Netflix OSS stack and Finagle.

manigandham 8y ago

Istio manages east-west traffic (between programs in your cluster) vs north-south traffic (in and out of your cluster). Kubernetes only provides basic service discovery with "service.namespace.cluster" DNS entries to communicate between apps in the cluster. The standard routing is just ip tables configured on each node. It works well but may be limiting for complex deployments. What Istio does is replace all that with several components. The foundation is the Envoy proxy which runs as a sidecar to all of your pods and handles all the network traffic, providing much better performance, more load-balancing algorithms, advanced routing, retries, rate limiting, observability and tracing (at protocol level), grpc/http2 in both directions, TLS management, traffic shadowing, and custom filters that you can use to do whatever you want with the traffic. There are also several "control plane" components which actually do the wiring and config management and work in the background. There are several alternatives in this space like Linkerd, Consul Connect, Kong, and even Nginx and Haproxy getting into it. Some are focused only on Kubernetes while others let you communicate across clusters and standalone VMs.

dankohn1 8y ago
CNCF is tracking 10 service proxy options, 8 API gateways, and 4 service mesh alternatives: https://landscape.cncf.io/category=service-proxy,api-gateway,service-mesh&format=card-mode&grouping=category https://landscape.cncf.io/category=service-proxy,api-gateway...