I was looking for an easy way to debug a Kubernetes pod so that I could debug an application running on WebSphere Liberty in a Kubernetes deployment. I found that this works well. It should work for other servers too, as long as you know how to modify the container to get the server into debug mode.

First, I decided to scale my deployment down to one pod to make it easier to debug. This ensures that all of the traffic is routed to the pod that I am debugging. I could attach debuggers to each pod, but scaling it down to one keeps it simple:

kubectl scale deployment <deployment name> --replicas 1

Next, I edited my deployment to put the server into debug mode:

kubectl edit deployment <deployment name>

or, for JSON:

kubectl edit deployment <deployment name> -o json

And then I modified my container specification to overwrite the container command and start the server in debug mode. One thing to keep in mind is that when you enable debug mode on Liberty, the JVM waits for a debugger to attach before it will actually start the server.

      - image: web1-liberty
        imagePullPolicy: IfNotPresent
        name: web1-liberty
        - /opt/ibm/docker/docker-server
        - /opt/ibm/wlp/bin/server
        - debug
        - defaultServer
        - containerPort: 9080
          protocol: TCP

I saved my changes and then used port forwarding to make the debug port available on my host machine. First get the pod name:

kubectl get pods

Then forward the debug port. I used 17777 for the host port but any free port can be used. The default debug port for Liberty is 7777:

kubectl port-forward <pod name> 17777:7777

Because my original application source was in Eclipse, I created an Eclipse Remote Java Application launch configuration (Debug menu > Debug Configurations > Remote Java Application). If your application consists of several projects, use the Source tab to add them to the source lookup:

After attaching the debugger, I used the kubectl logs command to check that the server was now up:

kubectl logs <pod name>

And then I was up and debugging: setting breakpoints, using hot code replace to test out changes, etc!

After I was done, I restored my deployment to its original state by doing the reverse of what I did to debug it: First I detached the debugger, then terminated the port forwarding (Ctrl C in the command window where I started it), and then I edited the deployment and removed the command entry:

kubectl edit deployment <deployment name>

And then scaled up the deployment to the original number of replicas:

kubectl scale deployment <deployment name> --replicas <number of replicas>

One thing to remember is that any changes made using hot code replace are no longer in the deployment because it will revert back the the original classes.

And that’s all there was to it!

4 comments on"Quickly debug a Kubernetes pod running WebSphere Liberty applications"

  1. David O'Connor February 18, 2020

    Rather than command I had to use args. Also if you have have a liveness probe in deployment spec you’ll have to remove it.

    – args:
    – /opt/ibm/wlp/bin/server
    – debug
    – defaultServer

  2. Carlos Galindo November 01, 2018

    Hello Erin… I came across with your post.

    I tried to follow the step you took to be able to debug a Liberty application running in K8s, but every time I try it my application does not start… it give an error that the “debug” command is not available.

    Do you know how to fix this?

    • Thank you for reporting this. It looks like the image has changed. Please use the following for the command. I will update the article shortly.

      – /opt/ibm/docker/docker-server
      – /opt/ibm/wlp/bin/server
      – debug
      – defaultServer

    • The article has been updated now.

Join The Discussion

Your email address will not be published. Required fields are marked *