Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Retina – eBPF distributed networking observability tool for Kubernetes

github.com

Post reply on HN
Print view View original

21–30 of 31 posts

Re: Retina – eBPF distributed networking observability tool for Kubernetes

#21

Post by chronid »

hacker_newz wrote: post #13
p_l wrote: post #3

Earlier quoted context omitted.

Just today at $DAYJOB we had a complaint that one teams Azure Kubernetes clusters was "slow". About only metric out of norm was network traffic - but lack of detailed instrumentation meant we couldn't really isolate the cause to specific container or process

If the only explanation someone can provide is that "a cluster is slow", the issue isn't with network observability. They need to do at least the minimum level of analysis before escalating.

Yes, that would be great, but unfortunately there are application teams (particularly in the enterprise) lacking such tact when blaming infrastructure for issues.

Good old silos are alive and well, and ownership is not always part of the culture.

Re: Retina – eBPF distributed networking observability tool for Kubernetes

#22

Post by nullify88 »

FridgeSeal wrote: post #8
hosh wrote: post #6

Earlier quoted context omitted.

Cillium has been bought out by Cisco, so its monetization is only a matter of time. Also, not everyone needs to implement a service mesh.

Neither Cilium nor Hubble are service meshes. Cilium is a CNI - the functionality that provides the K8s cluster inter-pod networking. The fact that it uses eBPF to deliver its functionality is what gives it the impressive observability you usually only get from a service mesh. I agree that not everyone needs a service mesh.

You are right that cilium is a CNI but one of its many features is also providing a sidecar-less service mesh using eBPF. https://cilium.io/use-cases/service-mesh/

Re: Retina – eBPF distributed networking observability tool for Kubernetes

#24

Post by p_l »

chronid wrote: post #21
hacker_newz wrote: post #13

Earlier quoted context omitted.

If the only explanation someone can provide is that "a cluster is slow", the issue isn't with network observability. They need to do at least the minimum level of analysis before escalating.

Yes, that would be great, but unfortunately there are application teams (particularly in the enterprise) lacking such tact when blaming infrastructure for issues. Good old silos are alive and well, and ownership is not always part of the culture.

In our case the expected golden path is that once our team figures the proper procedure, we will establish it for the downstream teams that are direct supports of the application teams.

So at least in theory things are somewhat well set up, but there's too much siloing at our level (wildly separate network teams, teams for specific clouds, etc.)

Re: Retina – eBPF distributed networking observability tool for Kubernetes

#25

Post by nextaccountic »

scottlamb wrote: post #11

Sigh, anyone have a name suggestion for a (Rust) RTSP library? https://crates.io/crates/retina

Don't change the name of this crate, it is in an unrelated domain. (Also unrelated to retina displays and uhh.. this Brazilian intrusion detection system https://sunsoftware.com.br/retina/ and whatever this thing is https://retina.ai/ among other things)

Re: Retina – eBPF distributed networking observability tool for Kubernetes

#26

Post by worthless-trash »

jookat wrote: post #18

Red Hat has a similar eBPF based tool https://github.com/netobserv/network-observability-operator (Disclaimer: i work on it) - the cool thing imho with retina or redhat netobserv or pixie is they aren't tied to a specific CNI. Now one of the problems that arises is potential conflicts and lack of collaboration between eBPF based tools, as there are more and more. Something called bpfman aims to address this aspect

I've used this in OpenShift and it is -very- neat. Saved incredible amounts of time trying to solve problems.

Re: Retina – eBPF distributed networking observability tool for Kubernetes

#27

Post by vamsi1105 »

xyst wrote: post #17

Speaking of observability tools. Anybody here know how to gather more in-depth metrics on mTLS requests? Have an internal (self signed) CA and just want to know which issued certs are presented to nodes. Would be nice to get cert serial number and other metadata as well

https://github.com/microsoft/retina/issues/85

That is a very interesting ask, let me raise an issue against the repo and see how we can solve this with eBPF in this repo. I am pretty sure this is a very common problem for a lot of kube admins.

Re: Retina – eBPF distributed networking observability tool for Kubernetes

#28

Post by xyst »

vamsi1105 wrote: post #27
xyst wrote: post #17

Speaking of observability tools. Anybody here know how to gather more in-depth metrics on mTLS requests? Have an internal (self signed) CA and just want to know which issued certs are presented to nodes. Would be nice to get cert serial number and other metadata as well

https://github.com/microsoft/retina/issues/85 That is a very interesting ask, let me raise an issue against the repo and see how we can solve this with eBPF in this repo. I am pretty sure this is a very common problem for a lot of kube admins.

oh, thank you! Will follow the issue

Re: Retina – eBPF distributed networking observability tool for Kubernetes

#29

Post by sharangxy »

emmanueloga_ wrote: post #15

There is a flood of observability tools based on eBPF coming out these days [1]. eBPF is used to collect metrics without the need to instrument the code. -- 1: https://ebpf.io/applications/

DeepFlow [1][2] is one of them, where we implemented distributed tracing for microservices using eBPF.

1. https://deepflow.io 2. https://github.com/deepflowio/deepflow

Re: Retina – eBPF distributed networking observability tool for Kubernetes

#30

Post by sharangxy »

jookat wrote: post #18

Red Hat has a similar eBPF based tool https://github.com/netobserv/network-observability-operator (Disclaimer: i work on it) - the cool thing imho with retina or redhat netobserv or pixie is they aren't tied to a specific CNI. Now one of the problems that arises is potential conflicts and lack of collaboration between eBPF based tools, as there are more and more. Something called bpfman aims to address this aspect

You can also check out DeepFlow [1], where we implemented distributed tracing for microservices using eBPF, which of course also includes observability of K8s networks.

1. https://deepflow.io

Post reply on HN