fubectl: shell aliases that wrap kubectl for daily cluster work

A sourced script rather than a binary

fubectl is short for fancy kubectl, and the README opens with the reason it exists, to reduce repetitive interactions with kubectl. The whole thing is a shell file. You download fubectl.source, save it somewhere, and source it from your shell rc file, and what you get is a set of shell functions and aliases rather than an executable.

curl -LO https://raw.githubusercontent.com/kubermatic/fubectl/refs/heads/main/fubectl.source

[ -f <path-to>/fubectl.source ] && source <path-to>/fubectl.source

That design choice has a direct consequence. There is no binary to install and no version to manage, the shell picks the file up at start-up, and the functions run in your shell where they can use your existing aliases, completions and interactive tooling. It also means the file has to be trusted, because sourcing it executes it, and because a sourced script can be replaced by a newer version under you without any package manager telling you.

The repository is small and matches that shape. There is fubectl.source, a fubectl.plugin.zsh for the ZSH plugin manager route the README mentions, a demo_src/ directory holding the demo GIFs the README embeds, and a hack/ directory. There is a DCO file, which is the developer certificate of origin the contributing guide requires, alongside a LICENSE and a NOTICE, and the code of conduct and the owners file. The primary language is listed as Go, which is worth noting given the artefact is a shell script, and the licence is Apache-2.0.

The aliases, grouped by what you are actually doing

The command set is the substance of the project, and the README groups it by task rather than alphabetically.

The base one is k, an alias for kubectl, so k get nodes, k get pods and k version --short all work as you would expect. kw is an alias for watch kubectl, and it accepts a list of resources, so kw nodes, kw pods and kw nodes,pods,services all work. kall gets all pods in all namespaces, and kwall watches all pods in all namespaces every two seconds, which is the one to be careful with on a large cluster.

Then there are the resource operations. kdes describes a resource, taking a pod, a service or nodes. kdel deletes a resource, taking a pod, a secret or a pvc. klog prints the logs for a container in a pod, and the argument handling is worth reading: with no argument it prints the last 10 lines, klog 100 prints the last 100, klog 250 -f prints the last 250 and follows the output like tail -f, and klog 50 -p prints the last 50 lines of the previous container. kex executes a command in a container, so kex bash starts a shell and kex date prints the date inside. kfor forwards one or more local ports to a pod, so kfor 8000 forwards port 8000 to a pod and kfor 8000:80 forwards local 8000 to the pod's port 80.

The interactive helpers are the ones that make the biggest difference to a long session. kcl displays the contexts in your kubeconfig, and kcs sets the current context. kcns switches the default namespace, either interactively from a list or directly, so kcns kube-system sets it immediately. kdebug starts a debugging Pod in the cluster, and kp opens the Kubernetes dashboard by starting kubectl proxy and pointing your browser at localhost:8001/ui.

There is also ksearch for searching for a string in resources, and its example in the README is literally a TODO comment, which is a fair signal that it is the least finished of the set.

The prerequisites are the real dependency list

The README lists what you need before any of it works, and the list is longer than you might expect for a set of aliases. fzf is the fuzzy finder, and it is clearly central, because the interactive selection in kcl and kcns is fzf driven. kubectl is the obvious one. kubectl tree is listed as a prerequisite, and kubectl neat is listed specifically as only needed for kexp to work, which is the one place the README uses a command name that does not appear in the alias list, so treat that as the least certain part of the set. jq is the JSON processor, used to pick fields out of kubectl output for the interactive selections.

That is four separate tools beyond kubectl, and it is the price of the interactive part. If you only want the short aliases, k and kw and kdes and kdel need only kubectl, but kcl and kcns need fzf, and anything that parses JSON needs jq.

The customisation section shows the two escape hatches. FUBECTL_WATCH_CMD changes the watch command that kw and kwall use, and the example given is viddy as an alternative watcher. FUBECTL_NO_KCL disables the kcl alias, and the reason given is that it may conflict with the KCL language CLI, which is a small sign that the maintainers think about namespace collisions in a shared shell.

There is also a prompt integration. The README shows exporting PS1 with the current context name substituted in, and separately the current namespace, with a note that the namespace version is currently slow because it calls kubectl every time. That note is honest about a real cost, and it means you would only put the namespace in your prompt if you accept a kubectl call per prompt redraw.

Where fubectl is the wrong tool

Three cases argue against it. The first is a team that needs audited, scriptable cluster access. Aliases are interactive conveniences, and the whole design assumes a human at a terminal making one off decisions. A runbook that says kget pods is not a runbook, and a script that depends on a function defined by a sourced shell file inherits that file's fragility. The upstream kubectl is the right tool for anything that needs to be repeatable, and fubectl is a layer on top of it rather than a replacement for it.

The second case is a user who does not want to source a downloaded script into their shell. The install instructions are a curl download that you then source, and while the file is in a public repository under an Apache licence and the project is a well known Kubernetes vendor, it is still executable code running in your shell with your environment. A team with a strict change management process, or a machine where someone else administers the shell profile, will want a package instead, and there is not one here.

The third case is a user on a cluster where the interactive selections are unusable. kcl and kcns list every context and namespace, and fzf makes that navigable, but on a cluster with several hundred namespaces the list is long, and the README does not describe how the selections are filtered. The value of the package concentrates in the interactive commands, and the plain aliases are the part you could reproduce in a few lines of your own shell rc.

On the state of the work, the last push was on 2026-08-12 and the repository publishes no GitHub releases, so the file is tracked in the repository rather than versioned as an artefact. The troubleshooting path is the GitHub issue tracker and a channel on the Kubermatic Slack, and the contributing guide asks for the developer certificate of origin before a pull request.

Editorial conclusion

fubectl suits a cluster operator who runs the same kubectl commands all day and wants them shorter, especially one whose editor already integrates with fzf for resource selection. It does not suit a team that wants audited, scripted access to a cluster, because aliases are interactive conveniences, and it does not suit anyone without the listed prerequisites installed. Before you source it, install fzf, kubectl, kubectl tree, kubectl neat and jq, and note that the last push was on 2026-08-12.

Frequently asked questions

Official sources

1. Issues
2. kubermatic/fubectl on GitHub
3. License: Apache-2.0
4. README