Skip to content
All projects

kube-aliases

A Bash experiment that maps familiar Linux service commands to Kubernetes operations, exploring where those similarities help and where they break down.

Experiment3 min readView source
  • 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 command

They’re Bash functions, so they have to be sourced:

source experiments/kube-aliases.sh

The 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.