Tips Tricks and Rants

Purpose

This page contains opinions, random brain dumps of tid bits and some background on kubernetes that might be useful for those that are self-taught or new to kubernetes. It is also just as likely to have nonsense theories and ideas that are not useful, and could annoy Kubernetes SMEs. Feel free to use the feedback buttons at the end of the page to suggest improvements.

A bit of background, tips and tricks

• Kubernetes is often shortened to ‘K8’.

• The kubectl cli is the most common way to communicate with Kubernetes clusters APIs and while there is of tons of CI/CD related automation that can abstract the CLI tooling away from you, it is better to embrace kubectl at least at first since if you are debugging issues or ever want to get certified you won’t be able avoid it.

• If you can want to avoid yaml when using Kubernetes, its probably best you just avoid Kubernetes instead.

• Create deployments last if possible, especially so if they are going to be routed traffic via services, since that will give the Kubernetes scheduler a hint that the PODs for the deployment should be fanned out across multiple nodes.

Opinion / Rants

k9s

Once you truly know your way around kubectl and kubernetes in general, take a look at k9s, it honestly saves me more keystrokes than I normally type in a year. A real godsend when needing to debug issues on-the-fly in immature setups with poor monitoring. If you like it then be a good soul and sponsor the maintainer & author.

yaml rant

Most people that live the kubernetes lifestyle are buried in yaml, since it is the primary means to configure pretty much everything. Whilst it is possible to use json natively with some k8 tooling, its pretty rare unless you are working as a platform engineer underlying systems with k8 internals or when trying to debug yaml syntax/formatting errors. Whilst you might think another option is third party tools (e.g., Ansible, Terraform etc) which have their own idiosyncratic languages, you will be limiting your knowledge and ability to administrate kubernetes.

I only write this rant because I’ve worked with software engineers that are great people but have randomly strong and somewhat strange opinions on <for i in $software;echo ad-infinitum opinion on $software;done> e.g., yaml. If you really hate yaml, you should probably look as far away from K8 for fun as possible. Maybe get into specialising with retro mainframe technologies - work in a bank, invest well and then retire early - just don’t work with Kubernetes, it will make you sad.

Helm rant

If you are using Helm to load or upgrade 3rd party applications onto your cluster, it can be great and easy to use. However, I would caution people jumping onto the Helm (or similar tool) bandwagon by packaging their own applications with Helm especially if the customers are internal to your organisation, since it can create unneeded complexity and technical overhead.

You may read, hear or have someone suggest that you look to ‘Helm’ as a solution to orchestrate the provisioning of your Kubernetes based applications, and whilst it can seem like a neat solution and with a bit of effort Helm (and other tools) can address most of the common application lifecycle requirements - it is not a magic bullet. Helm is fairly opinionated and as a lazy good team mate I personally find it is best to avoid burdening development practices with additional technologies that are not strictly needed, especially when other approaches exist that can meet the most common requirements e.g., using a simple name conventions, Kustomise (now available via Kubectl -k) templates or even a simple shell script.

If you get to a point that you actually need Helm, congratulations but by that stage you’ll know why exactly Helm is the best solution for you and why exactly everyone will just have to swallow the overhead of maintaining Helm charts etc. Also I bet at that stage you would be a pro at devops bingo and would probably love to be using Helm with kustomize, git ops and some degree of chaos testing.

Kubernetes magic

Kubernetes checks are not fool proof and states which are syntactically valid and technical possible can break things, especially when working with a vanilla OOB cluster that hasn’t had the love and attention of someone who has felt the true horror of having everything completely fall apart in production (for no obvious reason) in the middle of the night on a weekend. If you work anywhere near production systems, it is never wrong to ask someone else for a code review (even if it is an over the shoulder review!). This is even the case when working with cloud based managed solutions e.g., AWS’s EKS, which can be great if you need someone to blame or want to have someone to call to help fix issues but just because Kubernetes abstracts cloud native practices from most users it does not mean that somebody somewhere is not living the pain the system administrators of what can be extremely complex multi-layered systems, full of some of the most finicky services known to humankind.