Kubernetes Debugging with Traffic Interception
In this newsletter, we continue the discussion on Crafting for Kubernetes, focusing on helping developers quickly iterate their service in Kubernetes environments.
Traditionally, when a developer wants to update the service in the end-to-end Kubernetes environment for debugging or adding logs, it requires several steps:
Make local changes on local dev environment.
Push the code change to Git repo.
Trigger the CI pipeline to build the code and setup the container.
Wait for the new container to be deployed to Kubernetes.
This process could take a long time (e.g., > 30 minutes) even for a simple logging change, which slows down the debugging process significantly.
With Crafting, developers can bridge their Kubernetes environments with dev environments in sandbox and use traffic interception to virtually “plug-in” the dev version of their service instantly for testing and debugging.
As shown in the figure above, Crafting allows the incoming traffic to a Kubernetes service (e.g. API service) to be rerouted to a sandbox, and hit the dev version of the service running there instead. At the same time, the dev version of the service can access other services in Kubernetes just like running in the same namespace.
With that setup, the developer (e.g., developer A), can edit the dev version of the service directly in the sandbox and the changes get reflected in the Kubernetes end-to-end environment instantly, without requiring for building containers or redeploying them via slow CI/CD pipeline.
Start a traffic interception from your sandbox
There is a quick flow to start an Kubernetes interception from a Crafting sandbox, starting by clicking the INTERCEPT K8S action button from the sandbox page.
In the interception dialog, just select the target workload to be intercepted and ports to intercept. Crafting pulls the information from the connected Kubernetes cluster and provides a list for you to select from.
After we select the checkout service as the workload, select port 5050 to intercept, and click the START button, we get the interception started. In a few seconds, the interception is established and the status is shown below.
Debug your dev version of the service in Kubernetes context
With the interception ready, we can launch the dev version of the service in sandbox and debug there. For example, here we open the IDE and make some modification to the code in the workspace.
As shown above, we added one line of log in the PlaceOrder function in the checkout service, and we also placed a breakpoint on the line below our new logging.
Now, we run the dev version of the service on the workspace in debug mode and can go to the product page and initiate a product flow.
Then, we trigger that flow by going to the shopping cart and place an order.
As we click the "Place Order" button, we can see that the breakpoint in our dev version of the checkout service is hit, indicating the traffic is intercepted from the checkout service in the Kubernetes namespace to our dev workspace in the sandbox.
The log line we added is also effective and prints the log in there. When we click continue from the debugger, our dev version of checkout service will call other services like payment and email in the Kubernetes namespace to finish the checkout flow.
With traffic interception, you can code your dev version of the service in context and instantly test it with other services running in Kubernetes. By avoiding the repeated slow "build, upload, test" process, and debugging in place, your iteration speed is greatly improved!
For more information regarding develop Kubernetes services on Crafting, please see here.
What's next?
In the previous newsletter, we illustrated creating and managing per-developer namespace for Kubernetes dev. And in this newsletter, we cover using interception to greatly speed up iteration on Kubernetes.
To know more about Crafting for Kubernetes, please see our documentation on use case, user guide, and setup guide. Or see our video demo.
In future newsletters, we will discuss how to work with large Kubernetes apps with hundreds or thousands of services and how to use conditional routing to let developers test and debug independently based on a shared Kubernetes environment.
Apr 5, 2023