kube-aliases
A Bash experiment that maps familiar Linux service commands to Kubernetes operations, exploring where those similarities help and where they break down.
- Bash
- Kubernetes
- Developer Experience
I built a set of Bash functions to explore whether familiar systemctl and
journalctl commands could make Kubernetes easier to navigate. The experiment
helped me understand the differences between managing a Linux service and managing
workloads through Kubernetes controllers.
How it works
A target with a / in it is read as namespace/workload and routed to kubectl.
Anything else falls through to the real command.
journalctl -u mender/mender-gui
# Runs: kubectl -n mender logs deploy/mender-gui --tail=200
systemctl status sshd
# Uses the normal systemctl commandThey’re Bash functions, so they have to be sourced:
source experiments/kube-aliases.shThe mappings cover reading logs, describing a Deployment, restarting its pods and changing the replica count.
Shell overrides and scope
Limitations of the approach
start invents a replica count. stop scales to zero and start scales to
one. If the Deployment was running three replicas before I stopped it, starting it
gives me one back and says nothing about the two that went missing.
Everything is assumed to be a Deployment. DaemonSets and StatefulSets fail, and they fail with “not found”, which reads as “your workload isn’t there” when it actually means “you asked for the wrong kind of object”. That is a bad error to hand to someone who is already lost.
It follows whatever context kubectl is on. There is no cluster selection
anywhere in it. A command that changes a workload goes wherever the current context
points, which is precisely the wrong property for a command that changes a
workload.
Similar commands, different behaviour
Restarting a systemd unit stops a process and starts it again. kubectl rollout restart replaces every pod in the Deployment, with a controller doing it gradually
underneath you. Both are spelled “restart”. They are not the same event and they do
not fail the same way.
Logs are the same story. journalctl -u sshd is one service on one box.
logs deploy/... is picking one pod out of however many are running, and the
interesting one is frequently a pod that has already died.
Translating the command name removes none of that. It hides it, which is worse than not helping at all.
What I learned
Extending this approach would require explicit context selection, workload-type
handling and a way to preserve replica counts. For my own workflow, I prefer using
kubectl directly and k9s for interactive navigation. The script remains in the
experiments/ directory as a record of the approach and its limitations.