Veilig werken met kubectl: installatiekit en een lokaal testcluster

Een installatiekit waarmee collega's op Windows, WSL of Linux in een paar minuten toegang hebben tot de clusters, en een lokaal kind-cluster met een ingebouwde vangrail tegen per ongeluk productie raken.

Toegang voor collega's

Collega's die met de clusters willen werken, liepen telkens tegen hetzelfde aan: welke kubectl-versie, welke OIDC-plugin, waarom opent de browser niet in WSL? De kit bestaat uit:

install-kube-tools.ps1 voor Windows en install-kube-tools.sh voor Linux en WSL (getest in containers);
installatie van kubectl (vastgezet op de minorversie van het cluster), k9s en de OIDC-loginplugin;
twee handleidingen: kubectl en k9s gebruiken, en een handmatige WSL-route voor wie liever zelf installeert.

Een paar valkuilen die de kit afvangt:

In WSL zit wslview in het pakket wslu, niet in xdg-utils. Zonder die helper opent de OIDC-login vaak niets. Het script zet een eigen browserhelper neer.
De installer van Oh My Zsh vervangt ~/.zshrc. De kit schrijft daarom naar ~/.zshenv.
kubectl mag maar één minorversie van de API-server afwijken. Bij een clusterupgrade moeten script én handleiding mee; dat staat in de upgradechecklist.

Een lokaal cluster met een vangrail

Voor het testen van manifests en Helm-charts staat er een kind-cluster op de werkplek, bediend via één commando (k8s-lokaal up, k8s-lokaal shell, optioneel een lokale Istio-gateway en registry).

Het belangrijkste onderdeel is niet het cluster maar de guard: het commando gebruikt een eigen kubeconfig en weigert alles als de API-server niet 127.0.0.1 is. In k8s-lokaal shell is alleen het lokale cluster zichtbaar. De standaard kubeconfig wijst naar acceptatie; zo kan een testcommando nooit per ongeluk daar terechtkomen.

Een eerdere versie met vier nodes, drie gateways, MetalLB en Flux is weer weggegooid. Een testcluster dat productie nabootst, wordt zelf een platform om te onderhouden. Simpel en wegwerpbaar werkt beter.