Exploring Kubernetes API using Wireshark part 1: Creating, Listing and Deleting Pods

Related Articles:

Exploring Kubernetes API using Wireshark part 2: Namespaces

Exploring Kubernetes API using Wireshark part 3: Python Client API

Quick Intro

This article answers the following question:

What happens when we create, list and delete pods under the hood? More specifically on the wire.

I used these 3 commands:

I'll show you on Wireshark the communication between kubectl client and master node (API) for each of the above commands.

I used a proxy so we don't have to worry about TLS layer and focus on HTTP only.

Creating NGINX pod

pcap: creating_pod.pcap (use http filter on Wireshark)

Here's our YAML file:

Here's how we create this pod:

Here's what we see on Wireshark:

Behind the scenes, kubectl command sent an HTTP POST with our YAML file converted to JSON but notice the same thing was sent (kind, apiVersion, metadata, spec):

You can even expand it if you want to but I didn't to keep it short.

Then, Kubernetes master (API) responds with HTTP 201 Created to confirm our pod has been created:

Notice that master node replies with similar data with the additional status column because after pod is created it's supposed to have a status too. 

Listing Pods

pcap: listing_pods.pcap (use http filter on Wireshark)

When we list pods, kubectl just sends a HTTP GET request instead of POST because we don't need to submit any data apart from headers:

This is the full GET request:

And here's the HTTP 200 OK with JSON file that contains all information about all pods from default's namespace:

I just wanted to emphasise that when you list a pod the resource type that comes back is PodList and when we created our pod it was just Pod. Remember?

The other thing I'd like to point out is that all of your pods' information should be listed under items. 

All kubectl does is to display some of the API's info in a humanly readable way. 

Deleting NGINX pod

pcap: deleting_pod.pcap (use http filter on Wireshark)

Behind the scenes, we're just sending an HTTP DELETE to Kubernetes master:

Also notice that the pod's name is also included in the URI: /api/v1/namespaces/default/pods/nginx ← this is pods' name

HTTP DELETE just like HTTP GET is pretty straightforward:

Our master node replies with HTTP 200 OK as well as some json file with all the info about the pod, including about it's termination:

It's also good to emphasise here that when our pod is deleted, master node returns JSON file with all information available about the pod.

I highlighted some interesting info. For example, resource type is now just Pod (not PodList when we're just listing our pods).