Comment by unscaled | Hacker News Reader

Comment by unscaled | Hacker News Reader

Parent Full thread

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.

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

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.

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.

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.

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

Reply on news.ycombinator.com