Mizu – API traffic viewer for Kubernetes

https://github.com/up9inc/mizu

by kiyanwang • 4 years ago

132 23 4 years ago

github.com

dolni5• 4 years ago

Neat idea and a cool project.

That something like this is necessary is yet another testament to the complexity of Kubernetes.

eddieroger• 4 years ago

Is it necessary? I've operated in Kubernetes environments for several years and not had a visualizer like this and survived just fine. If anything, it's neat you can do this in k8s relatively easily and "for free" on an existing cluster. The only complexity this calls out is that of microservice architecture done to an extreme, but not that of Kubernetes.

dolni5• 4 years ago

Is it necessary?

I'm assuming that they didn't spend time authoring this for no good reason. It got 2700 stars on GitHub, which isn't nothing.

The only complexity this calls out is that of microservice architecture done to an extreme, but not that of Kubernetes.

There are better approaches to dealing with tracking requests through a microservice architecture than a ham-fisted packet capture.

By default, the way networking is configured in Kubernetes is exceptionally complex. It certainly stands to reason that a packet capture may be useful at some point.

cpitman• 4 years ago

At many of my clients, when an app breaks on kubernetes, it's generally on the admins to show that it wasn't the cluster's fault before the app team tales ownership of the issue. Tools that help very clearly show that traffic made it to the app, and what the app responded with, are super helpful.

throwanem3• 4 years ago

In the sense that the need for Wireshark is a testament to the complexity of IP, I suppose, sure.

dolni5• 4 years ago

Yes, but we're not talking about IP and this misses the point.

Kubernetes, as a technology, has support tooling being built around every interface it has.

Just to install Kubernetes you've got Kubespray, Kops, kubeadm, minikube, or you can choose from a smattering of managed Kubernetes options.

For performance you've got cAdvisor, and you probably need to export those metrics somewhere like Prometheus/Grafana.

Then there's Helm, which is yet another abstraction over deployments to Kubernetes, which is SUPPOSED to be the thing Kubernetes simplifies.

And let's not forget about Rancher. Can't run one Kubernetes cluster, because security and other reasons. So let's simplify running ten of them.

I can't think of a single other technology that was built to ostensibly simplify things, only to be completely enshrouded by support tooling.

boomskats• 4 years ago

This is a brilliant and ambitious project. However last time I tried it a few months ago, it seemed to drop a lot of traffic once the throughput became anything non-trivial (100+ requests per second across 50ish microservices).

Maybe it's a question of UX, more likely it's a question of user error (and therefore partly UX). In any case, I can't wait for it to get better!

xur172• 4 years ago

My original view was that this wold be used for development and staging environments - is the idea that this can be used in a production environment as well?

j4ah4n• 4 years ago

Neat project and will plan to kick the tires. I like the workflow and especially the cleanup aspect for a tool such as this.

remram3• 4 years ago

How does it work? The docs don't seem to mention.

ljloisnflwef• 4 years ago

Welcome to Kubernetes!

I don't know what went wrong but the ecosystem prefers software presented as a black box and shrouded with mystery.

If you contrast this with Envoy, it has stellar documentation -- Envoy wants you to know how it works!

Envoy is used and abused by Istio (k8s wrapper) which has terrible documentation, history of horrific upgrade/update story, (& software quality).

remram3• 4 years ago

That hasn't really been my experience, I have found an abundance of documentation (sometimes getting lost down the rabbit hole). But I have kept clear of the corporate buzzword solutions, that might be why.

thanos999• 4 years ago

Istio delivers encrypted packets across services/ pods but in the pod, envoy proxy does the decryption and puts the packet unencrypted back on the interface to be consumed by the application.

In kubernetes, for calico CNI, the pod networking is done using veth pair. One interface remains on the host to be hooked to the host bridge and the other interface is sent to the pod namespace.

Mizu is deployed as a daemon set(one pod per node) and with enough privilege you can "tcpdump" the pod interface(the one where the envoy proxy puts back the packets unencrypted) (similar to "ip netns exec")

Basically, they tap the pod interface from host level. (They have a blog post about this as well: https://up9.com/gain-visibility-into-istio-mtls-traffic-with...)

This is my understanding so I might be wrong

rednerrus• 4 years ago

How much latency is this going to add?

dbrowne• 4 years ago

Looks interesting.

xur172• 4 years ago

Just installed this in a dev cluster, and I'm ecstatic. Does a lot of what I've been looking for, including:

* log of all traffic

* service graph

* automatic swagger doc generation

THANK YOU!!

atlaschen• 4 years ago

actually used Mizu to quickly validate I dont have Spring4Shell in my dev/pre-prod, super cool product!

jumperabg• 4 years ago

Absolute miracle. This is a must-have tool.

Mizu – API traffic viewer for Kubernetes

Related Stories