DIY kubectl plugins as aliases

󰃭 2024-10-27

The Problem

I often find myself googling for some kubectl command that I have used before but can’t quite recall. If I thought long enough about it, I could usually construct most of these, but I like to choose where I deploy my brain cycles carefully, and repetitive CLI commands are not usually at the top of my list of things I want to think deeply about. For example, the command for pulling the initial admin password from a freshly deployed ArgoCD. The command is not that complex:

kubectl -n argocd get secret argocd-initial-admin-secret \
        -o jsonpath="{.data.password}" \
        | base64 -d; echo

I just need to remember the command to get a secret, the secret name, and the JSON path to extract the password from that secret. If I can manage that, that gives me a base64 string I need to decode. Oh, and I need to remember to run echo right after to remove the % character that is not actually part of the password but is added by my shell to indicate there was no new line.

This is not something I have to do every day, but it is common enough that I would like a shortcut. So, this sounds like a good candidate for an alias, but I don’t want a zsh alias for each of these things, as they just become an unwieldy mess, and I don’t like the aesthetics or ergonomics. What I want is something like the git aliases I have previously posted about. Unfortunately, kubectl doesn’t have aliases, so at first glance it appears I am out of luck, but it does have plugins 🤔. A closer inspection of the plugin documentation reveals this nugget of information:

A plugin is a standalone executable file, whose name begins with kubectl-. To install a plugin, move its executable file to anywhere on your PATH.

Which is essentially how git aliases work 🙌. It actually gets better; it turns out that kubectl will use hyphens as command separators, so a script called kubectl-foo-bar in your $PATH can be called as kubectl foo bar.

Let’s Make an Alias a Plugin

Armed with that knowledge, we can set about making an ArgoCD plugin for kubectl to get the initial admin password. The script itself is very simple:

#!/bin/bash
kubectl -n argocd get secret argocd-initial-admin-secret \
        -o jsonpath="{.data.password}" \
        | base64 -d; echo

Save this somewhere in your $PATH as kubectl-argocd-pwd. Make sure to make the script executable (chmod +x kubectl-argocd-pwd), and that should be it. You can now run kubectl argocd pwd to fetch the value of the initial admin password.

Another command I find myself using fairly often is the one to port forward to the ArgoCD Service so i can use the Web UI. To add this to our ArgoCD plugin, we just create another script with the correct prefix, so let’s call this one kubectl-argocd-portforward and use the code below:

#!/bin/bash
kubectl port-forward svc/argocd-server -n argocd 8899:443

Again, save this in your $PATH and make it executable. Now run kubectl argocd portforward and visit https://localhost:8899. Assuming you actually have an ArgoCD install, then Voila! If you want to go further, you can have the bash script open your browser too, but I will leave that as an exercise for you, dear reader.

Final Thoughts

Plugins in kubectl are a simple but powerful productivity booster that are often overlooked, partly, I expect, because plugins sound more complicated than aliases. In this post I have given examples that are useful with ArgoCD but that is not really the point. What I hope you take from this is that kubectl plugins can be very quick and simple to create and allow you to create a short cuts to anything that you can do with kubectl. If you find yourself running large and unwieldy kubectl commands with any frequency, you really should give them a spin.