1 minute read

Removing building and debugging tools from the images we use to run services on containers is one of the security best practices. However, you can’t debug a container if it is not shipped with the debugging tools. Security and easy of debug seems to mutual exclusive but Kubernetes provides a solution: ephemeralContainers. As the name suggests, they are ephemeral containers attached to the same pod we want to debug and they share the same linux process namespace. The ephemeral container contains all the tools needed to troubleshoot the main container, but it is stopped as soon as we ended our debugging session.

At the time of writing this post, the latest version of Kubernetes is 1.27.

Demo

Create a pod with the python image (Alpine flavoured) that runs an http server on the port 8080. This image doesn’t provide tools like curl.

Python allows run a http server on port 8080 in one line: python3 -m http.server 8080.

If you try to test the server with the command curl, it is not found:

$ kubectl run server --image=python:3.12.0b4-alpine3.18 -- python3 -m http.server 8080
If you don't see a command prompt, try pressing enter.
/ # curl
/bin/sh: curl: not found
/ # exit

kubectl debug command allows to create an ephemeral container in the same pod we want to debug. Using the image curlimages/curl and curl the python http server:

$ kubectl debug -it pod/server --image=curlimages/curl -- /bin/sh
Defaulting debug container name to debugger-t492c.
If you don't see a command prompt, try pressing enter.
~ $ curl localhost:8080
<!DOCTYPE HTML>
...
</html>
~ $ exit
Session ended, the ephemeral container will not be restarted but may be reattached using 'kubectl attach server -c debugger-t492c -i -t' if it is still running

Leave a comment

You may also enjoy

Implementing an HTTP proxy in Go

4 minute read

I was looking for a simple project to get my hands dirty with Go again and I came up with the HTTP proxy server. At a first glance, it seems a trivial project: create an HTTP server read the HTTP method, the URL, and the HOST from the request send an identical request to the target server.

Avoid name conflicts in Terraform workspaces

2 minute read

Terraform workspaces are a feature of some backends to associate many terraform states to the same configuration. It is convenient to have a workspace where you can try changes to infrastructure. When the changes have been tested, you can switch to the production workspace and apply the changes.

Change Kubernetes service type from LoadBalancer to NodePort and viceversa

2 minute read

Changing the Service type from NodePort to LoadBalancer and viceversa is useful depending on the cluster you are working on. If you are doing experiments in a local development cluster, like Kind, you don’t have a real load balancer in front of your cluster and you need to expose your services externally using a NodePort service. On contrary, if you are w...