Have you ever wondered where the API traffic is going in Kubernetes?
When you think about it, any action you take on a Kubernetes cluster is an API call. Whether you’re creating new Pods or listing Ingress Controllers, it’s all an API call.
A few GET and PUT requests and before you know it, Kubernetes is declaratively deploying resources.
In this blog post, you’ll learn how to monitor and observe that traffic with Kubeshark.
What’s Wireshark?
Before jumping into Kubeshark, it’s important to talk briefly about Wireshark. Why? Because when you see Kubeshark talked about, you’ll see it compared to Wireshark.
With that said, what’s Wireshark?
Wireshark is a network packet analyzer.
If you haven’t worked in the networking space as a Network Admin/Engineer, the breakdown of what a packet analyzer is it essentially views the traffic coming in and going out of your network.
Any time that your computer, your iPad, cell phone, or any network-connected device makes “talks to” or “connects to” another device, there’s a packet that’s sent. For example, if you download an app on your iPad, your iPad is making a call that “talks to” or “connects to” a server where the app is hosted.
In the networking world, it’s all packets. Packets send data and the receiving end (server, computer, etc.) knows what to do with them based on the request.
The major upside that Wireshark helps out network admins/engineers with is troubleshooting. Because it captures every packet that’s sent and received on a particular interface, it makes understanding what’s happening on the network significantly more straightforward.
Kubeshark, much like Wireshark, is showcasing what’s occurring for every call that’s made. The difference is Wireshark looks at packets. Kubeshark looks at API calls.
API Calls?
If you’re not familiar with what an API call is, it means that you’re interacting with an endpoint (that has an API) programmatically.
In Kubernetes, it may not seem that you’re making an API call. You run a few commands that look something like kubectl get pods and think it’s just a command, but that command is actually making an API call. When you run kubectl get pods, what you’re actually doing is performing a GET request against the Kubernetes API server.
Whether you’re creating a new Kubernetes resource, like a Deployment or a Service, or you’re retrieving information about a Kubernetes resource, you’re making an API call. Any time you interact with Kubernetes, you’re making an API call.
As you can imagine, that’s a lot of traffic going to the API server, right? Think about how many times you or an automated system (like GitOps) is interacting with Kubernetes to deploy resources (Pods, Services, etc.). Because of that, it would only make sense to want the ability to monitor that traffic. This is especially helpful for troubleshooting. If a Kubernetes resource isn’t being created, something like seeing the API call could help troubleshoot why and what’s wrong.
Why Kubeshark?
Kubeshark fills the void that Kubernetes has had for a long time - seeing API calls in a visual way.
Can you see API calls done without Kubeshark? Absolutely.
The command below will show you the API call for retrieving Pod information.
kubectl get pods -v=8
You’d see an output similar to the screenshot below showcasing the API call.
The problem with this is it’s not very visual and it’s a lot of information that can look a bit messy. That’s where the visual piece of Kubeshark comes into play and fills the need of seeing API calls in a cleaner fashion.
The CLI is all that you need as it’s interacting directly with the Kubernetes API. Once you install the CLI, which you’ll see in the upcoming section, Kubeshark resources get deployed in the kubeshark Namespace.
kubectl get all -n kubeshark
NAME READY STATUS RESTARTS AGE
pod/kubeshark-front 1/1 Running 0 119s
pod/kubeshark-hub 1/1 Running 0 119s
pod/kubeshark-worker-daemon-set-blvl2 1/1 Running 0 112s
pod/kubeshark-worker-daemon-set-lnssq 1/1 Running 0 112s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/kubeshark-front ClusterIP 10.0.192.218 <none> 80/TCP 119s
service/kubeshark-hub ClusterIP 10.0.132.146 <none> 80/TCP 119s
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
daemonset.apps/kubeshark-worker-daemon-set 2 2 2 2 2 <none> 112s
When you run the CLI and the Kubeshark Kubernetes resources are deployed, you’ll use a command like the following:
kubeshark tap
Once you run the tap subcommand, you’ll see some output which includes the deployment of the UI that you can access from your localhost.
2023-01-01T15:18:33Z INF tapRunner.go:437 > Hub is available at: url=http://localhost:8898
The downside is that:
- It requires full sudo permissions, so weigh the pros and cons accordingly from a security perspective.
- It uses the existing Kubeconfig in your
.kubedirectory and you run the CLI tool either locally or on the Kubernetes cluster, so there’s no central management for Kubeshark.
However, these downsides are expected as the Kubeshark project is still very new. It’s still an amazing tool to try.
Installing and Getting Started With Kubeshark
Now that you know a bit of the theory behind API calls, let’s learn how to install Kubeshark and get started with it.
To install Kubeshark, run the following:
sh <(curl -Ls https://kubeshark.co/install)
You’ll see an output similar to the screenshot below.
Next, run the tap subcommand.
kubeshark tap -A &
The -A flag scans all namespaces. You can also specify a specific namespace like in the example below.
kubeshark tap -n default
You’ll see an output similar to the screenshot below, which shows you the port where you can reach the Kubeshark frontend service on.
The UI for Kubeshark will pop up automatically in a web browser and you’ll be able to see any resources that are running in your Kubernetes cluster.
The screenshot below shows every API call that’s occurring across all namespaces in the Kubernetes cluster.
To clean up the Kubeshark deployment (delete the Kubeshark resources), run the following:
kubeshark clean
Top comments (0)