A few weeks ago we started a series on developer tooling for Kubernetes. The tools that we have been reviewing are based upon those chosen to highlight in our weekly online meetup, ‘Developing on Kubernetes Office Hours” with the DX team at Weaveworks.
Much like Telepresence, Ksync is also designed to help you debug issues when you’re developing new features for apps running on Kubernetes. It saves you time during new feature development and it allows you to iterate on the code without the overhead of running through your entire automated pipeline every single time. This can be particularly useful if you are in the prototyping or you’re in the ‘get it working’ stages of development.
Ksync transparently updates containers running on the cluster from your local dev environment. This means you are working from inside the cluster right from your IDE where you can step through and debug your code more easily. And because you are not sending new code through a pipeline each time you make a change, you won’t have to wait several minutes to test the changes.
Ksync works from whatever your local dev environment you’re using, be it a laptop running Minikube or another cluster.
(From Ksync documentation)
How Ksync works
Ksync consists of two parts: a server and a client. The server is a DaemonSet that gets installed to the cluster, and provides access to each node’s filesystem. The client, on the other hand, watches your local environment, and when there is a change, it starts a new job. This allows the Kubernetes API to deploy the change from your local environment.
The following command puts the client into the background:
ksync watch --daemon
Ksync is bi-directional, and therefore, it can move all the files from your local container to the one that is running on the cluster. If you're working with a local copy, the most recently updated files are transferred between the container and your local machine.When you check the status after a sync, you should see a watching state with a pod name in the list.
Other live coding/debugging tools and how they compare
Like Telepresence, which is also a tool that allows you to go beyond simple debugging, with Ksync you can test and run services from your local environment to a running cluster on the fly. If you didn’t have a tool that allowed this type of development, you may have to resort to one of the following configurations:
- Run your entire distributed application locally with Docker Compose. Provides a fast dev/debug cycle, but, doesn’t reflect a real running cluster. If you are using any cloud services (such as RDS) these also might not be easy to access locally.
- Run Minikube. You can't do live coding/debugging with minikube by itself, but you can if you’re using a tool like Telepresence or Ksync.
- Run everything in a remote Kubernetes staging cluster. Allows you to perform live coding/debugging against the remote Kubernetes cluster. You can do this with both Telepresence and Ksync.
For more on Telepresence, see the post, ‘Debugging microservices - Squash vs. Telepresence’
In this post we discussed Ksync which is a tool that allows developers to use their local IDE environments in order to more quickly iterate on new features. For a live discussion on Developer’s toolkits, tune in and participate in our online meetup “Developing on Kubernetes” every Thursday at 10:00 PT / 18:00 BST (British Standard Time).
We can help you accelerate your Kubernetes journey with our subscription service that supports installing production-grade Kubernetes on-premise, in AWS and GCP from dev to production. For the past 3 years, Kubernetes has been powering Weave Cloud, our operations as a service offering, so we’re taking our knowledge and helping teams embrace the benefits of cloud native tooling. We've focused on creating GitOps workflows - our approach uses developer-centric tooling (e.g. git) and a tested approach to help you install, set-up, operate and upgrade Kubernetes. Contact us for more details.