Does a basic Kubernetes ClusterIP Service run on OSI Layer 4? There's musings of calling a Service Mesh 4.5, but out-of-the-box Kubernetes services... What OSI layer would you put them on?

📌

The question with the OSI layer is a tricky one....

In a nutshell the cluster IP is just a virtual IP - it is based upon iptables / routing.

https://kubernetes.io/docs/...

Kube-proxy handles the incoming and outgoing cluster traffic and thus handling of IP addresses / ports.

For a deeper insight :

https://k8s.networkop.co.uk/service...

Found it just via Google...

If we're talking just about the IP setup and the IP routing - it would be OSI layer 3 in my opinion.

If we're talking about transmitting data via TCP / UDP - layer 4.

TLS transfer between kube-proxy / kubernetes - layer 5.

If we're talking about DNS service discovery - layer 7.

@IntrusionCM thanks! I quoted layer 4 in a meeting recently and then started doubting myself Specifically, this was a RoR app being serviced by a clusterIP service. People were wondering why we couldn’t get rich HTTP status logs out of our setup natively. Can we get them? Yes. Natively? Depends on how you define that term.

@devphobe Well....

kubectl logs

Technically the Ruby on Rails pod just has to generate proper logs entries, spit them out to stdout - being bit careful about multiline messages and message limits - then kubectl cluster logging can collect them.

I wonder what you mean by natively...?

Kubectl logs like above or sth entirely different?

@IntrusionCM my team has no control of the Ruby app… the discussion was around how to do it if we can’t control what gets logged out.

@devphobe

Hm. Interesting.

Like no control at all over only the App?

Or the whole K8S cluster?

If you have control over the K8S cluster, add an HAPRoxy between.

You can get all the statistics, http logs and have an abundance of options

@IntrusionCM that’s what we’re thinking too. We have full cluster control…. But the Ruby image is built out by another team. It’s not that we couldn’t ask them to log it for us, but as we scale out we’re trying to do as
much autonomously as we can without needing other devs to add specific logging mechanisms. Adding in some type of ALB in a higher layer than can inspect HTTP traffic is going to be a likely outcome.

@IntrusionCM you gave the the confidence I needed. You can’t really
do HTTP traffic inspection if you’re operating on layer 4.

@devphobe Nope.

You could do TCP analysis like e.g. feed it to Wireshark.

Given that this is pretty much insane for such a simple task and that decrypting TLS > 1.3 will be pretty much impossible, it's not viable.

XD

Loadbalancery like HAProxy are ideal for such a task - just stay away from e.g. Nginx as it is without a license pretty inferior.

Plus you can most likely gain performance and increase security, it's a win win.