Over the last year, we have witnessed a shift in engineering working habits. COVID-19 forced many of us into lockdown. Instead of working from the office, coffee shops, and airport lounges, I found myself mostly working out of my (hastily built) home office. For many of us, this meant shifting back to a workstation over a trusty laptop.
Not surprisingly, this did nothing to abate the heated discussion over which computers and operating systems are best for developing software. And so, in this final blog post of the series, you’ll get to learn a bit more about setting up your development machine.
First things first, you need to pick your computer. You have to choose between countless hardware models, but only three major operating systems – macOS, Windows, and Linux.
Over the last decade, Macs have steadily risen in popularity with software engineers. macOS is part of the Unix family of operating systems and will provide a good approximation of the Linux distributions you will be running in production. More importantly, with most of the open-source community working on Macs, you will probably find it’s the most comfortable platform to utilize open-source software.
Microsoft has been investing heavily in cloud and cloud-native computing and has put a lot of work into their operating system as well. While not valid for every open-source project out there, you can expect all the critical Kubernetes tooling to work flawlessly with Windows. When working with Windows, you will probably find WSL 2 useful for when you end up needing a Linux machine.
And, last but most definitely not least, you can eschew away with all the emulations and just get a Linux desktop distribution for your development machine. Linux has many popular desktop distributions, and all of them will be closer to what will happen in production. Additionally, they all have built-in package managers and terminals, which you will have to add to Windows or Mac.
If adopting every open-source tool is out there is a priority, or if you are an Apple fan, you should go with Mac. PCs with Windows are the most versatile, enabling additional activities such as gaming. PCs with Linux offer limitless options and customizations, as well as a pure open-source approach.
Most of the tooling for Kubernetes is CLI based. So for Operating Systems that don’t have (a good) one built in, you better set one up on your development machine. For macOS, iTerm2 is the reigning king, and you should get YADR or ohmyzsh to customize it to perfection. For Windows, check out the new Windows terminal. It even allows you WSL shells in the same window with the command line and PowerShell.
Occasionally, you will want to build and run containers directly in your development environment. The obvious choice here is Docker Desktop that is easy to install and has everything you need. As a bonus, you even get (an admittedly resource-hungry) Kubernetes deployment you can turn on and off at will.
When it comes to Kubernetes tooling, kubectl is not the most important one in my book. Kubernetes is all about declarative configuration, which usually ends up stored in Git repositories. And so GitOps has become synonymous with cloud-native computing, and you will spend much of your time working with the Git CLI. If you happen to be using Github, you might want to check out their official CLI as well.
For working with Kubernetes itself, you will probably want kubectl (which is bundled with the latest versions of Docker Desktop), as well as Helm, and maybe even Kustomize. You can read more about them and the differences between them here.
When it comes to coding, a great IDE is priceless. The two most popular IDEs are Visual Studio Code (free) and JetBrains (paid). Both of them have significant Kubernetes support via plugins, and you can read more about them here. Of course, there are many more IDEs out there, such as Atom or Sublime.
As you are coding your way through Kubernetes, you need some way to view your cluster(s) live status. Here, my recommendations are k9s for CLI fans and Lens for those looking for a more IDE-like experience. But why choose when you can have both?
Selecting and setting up a development machine for your Kubernetes is not so different from how you would do it for any other environment. There are, however, a handful of extra tools you will want at your disposal to work within the ecosystem and its open-source projects to the best effect.
Over this five pieces series, we have gone through an up-to-date review of developer tooling for the Kubernetes ecosystem. I hope you enjoyed and learned as much reading it as I have when writing it. If you have any questions or other topics you would like me to cover, please feel free to contact me.
If you are interested in cloud-native developing tooling and have read this far, one small request before you go. Check out Rookout. You won’t regret it.
Check out the full Tools For Kubernetes Series:
Part 1: Helm, Kustomize & Skaffold
Part 2: Skaffold, Tilt & Garden
Part 3: Lens, VSCode, IntelliJ & Gitpod