Hacker News Reader

Comment by altmind | Hacker News Reader

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?

View on HN

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.

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 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.

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.

Well you're not necessarily dealing with a single pod IP. Two versions of skipping cluster IPs are either having smart client libraries that are capable of multiplexing between different IPs, or using something like consul DNS to resolve a URL into multiple pod IPs and rely on client DNS to do the right thing.

That is untrue. Client-side load balancing is a common thing. The service construct also doesn't necessarily map to what external clients need. Kafka or Cassandra, for example, prefer client direct access to pods via headless services.

> There's lots of overlap, but I've not heard of anyone making a strong argument for the native service discovery.

Native service discovery works a lot better than using pod IPs, which are intended to be transient.

A standard ClusterIp service includes DNS records by default and it's good enough for simple use cases.

> They end up bypassing cluster IPs and dealing directly with pod IPs

Why the heck are they even using Kubernetes then? Just deploy a bunch of docker containers with the autorestart flag.

This is terrible design.

No, it isn't terrible design, it's a requirement. Try running any distributed data services without direct pod accessibility. This is why StatefulSets and headless services exist.

Lots of real world use cases involve load balanced TCP or UDP services, the service discovery is optimized for that.

If you need pod-direct accessibility, the StatefulSet headless service feature will give each pod a unique DNS name and auto-update it when the pod IPs change.

That said, legacy migration into Kubernetes was WAY Oversold by some.

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.

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.

CNCF is tracking 10 service proxy options, 8 API gateways, and 4 service mesh alternatives: https://landscape.cncf.io/category=service-proxy,api-gateway...

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-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."

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

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.

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.

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.

Good summary.

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

NGINX have since discontinued work on their service mesh called Nginmesh [0]

0. https://github.com/nginxinc/nginmesh#important-project-notic...

anybody has more insights on what happened here?

Reply on news.ycombinator.com