Kubernetes

Kubernetes

kube-guard: ask before changing production

kubectl, kubecolor (k) and helm are zsh functions (kube-guard.zsh) that ask a Go binary (.config/kube-guard) before running the real command. On a production context, a command that changes the cluster asks first:

? kube-guard: prod-eu is production. kubectl delete pod x? [y/N]

• Asks for: apply, create, delete, edit, patch, replace, scale, set, label, annotate, taint, drain, cordon, uncordon, autoscale, expose, run, exec, debug, cp, rollout restart|undo|pause|resume; helm install|upgrade|uninstall|rollback.
• Passes: reads (get, describe, logs, diff, rollout status, helm template, helm diff), and a kubectl plugin's own arguments (kubectl who-can delete pods is a read).
• The context is the one the command runs on: --context / --kube-context anywhere on the line, else the current one of --kubeconfig when given, else of KUBECONFIG / ~/.kube/config. A flag's value before the subcommand (--as admin delete, -v 6 delete) is not mistaken for it.
• The answer is read from the terminal, so cat x.yaml | kubectl apply -f - still gets its manifest.
• Skip it once: KUBE_GUARD=0 kubectl apply -f x.yaml.
• Scripts call the real binaries and are not guarded; only your interactive shell is.
• Until the binary is built (dotfiles-sync), every kubectl / helm command asks.

What production is

A context is production when its name matches the production regex, in any case. In order:

1. KUBE_PROD_REGEX, in a shell (e.g. set in ~/.zshrc.local)
2. the first line of ~/.config/kube-guard/prod-regex on this machine (never committed, backed up by local-backup)
3. prod|prd

Use the file for a machine's own naming: it is the only one SketchyBar and launchd see, as they never read ~/.zshrc.local.

echo 'prod|prd|live' > ~/.config/kube-guard/prod-regex

k9s and sofka: read-only on production

k9s and sofka open with --readonly on a production context; --write opens them writable. A context switched to inside them keeps the mode they started with. sofka also has guardrails of its own that block deletes on production contexts (.config/sofka/conf.d/00-k9s.yaml). References: k9s README, sofka README (plugins, Shift-digit views).

⌘K: sofka on the pane's context

⌘K opens sofka in a tmux or Rex popup on the kube context of the pane it was pressed in, a ktx -s shell's own included: each interactive shell writes its KUBECONFIG to ~/.cache/kube-pane when it changes.

Contexts and namespaces

• ktx (kubectx): ktx <ctx> switches, ktx -s <ctx> gives this shell a context of its own, ktx -r read-only
• kns (kubens): no argument picks with fzf, - the previous one
• The SketchyBar kube item shows context/namespace, red on production.
• Tab completion covers the krew plugins (kubectl neat, tree, view-secret, who-can).
• logcli reads Loki's logs (deleted pods and finished jobs too), port-forwarding to LOKI_SERVICE when LOKI_ADDR is unset.