Zugang und kubectl

Alles, was du für den Zugriff auf den Cluster brauchst, steckt in einer Kubeconfig, die du dir im Portal herunterlädst. Sie zeigt bereits auf den richtigen API-Endpunkt, von Hand einzurichten gibt es daran nichts.

Kubeconfig herunterladen

Im Portal findest du sie im Bereich Kubernetes. Dort lädst du die Kubeconfig für deinen Namespace als Datei herunter. Hast du mehrere Namespaces, gibt es zu jedem eine eigene Kubeconfig.

Die Kubeconfig enthält Zugangsdaten

Sie ist der vollständige Zugang zu deinem Namespace. Behandle sie wie ein Passwort: nicht ins Repository committen, nicht an ein Ticket hängen, nicht per Chat verschicken.

Datei ablegen

Wenn du sonst keinen Cluster benutzt, ist ~/.kube/config der einfachste Weg. Ersetz den Quellpfad durch den deiner heruntergeladenen Datei:

mkdir -p ~/.kube
mv ~/Downloads/kubeconfig.yaml ~/.kube/config
chmod 600 ~/.kube/config

Arbeitest du mit mehreren Clustern, leg sie stattdessen als eigene Datei ab und zeig KUBECONFIG darauf:

mv ~/Downloads/kubeconfig.yaml ~/.kube/itsh.yaml
chmod 600 ~/.kube/itsh.yaml
export KUBECONFIG=~/.kube/itsh.yaml

KUBECONFIG nimmt auch mehrere Dateien, getrennt durch Doppelpunkte. kubectl führt sie dann zusammen, und du wechselst mit kubectl config use-context zwischen den Clustern:

export KUBECONFIG=~/.kube/config:~/.kube/itsh.yaml

Trag die Zeile in deine Shell-Konfiguration ein, sonst gilt sie nur für die aktuelle Sitzung.

Womit du prüfst, in welchem Kontext kubectl gerade arbeitet:

kubectl config current-context

Standard-Namespace setzen

Deine Kubeconfig gilt für genau einen Namespace, aber kubectl weiß das nicht von allein. Setz ihn einmal als Standard:

kubectl config set-context --current --namespace=<dein-namespace>

Wie dein Namespace heißt, steht im Portal an derselben Stelle wie die Kubeconfig. Ohne diesen Schritt musst du an jeden Befehl -n <dein-namespace> hängen, sonst läuft er gegen den Namespace default, auf den du keinen Zugriff hast.

Erster Test

kubectl get pods

Ist der Namespace noch leer, antwortet kubectl mit No resources found in <dein-namespace> namespace. Genau das ist der Erfolgsfall: Die Anmeldung hat funktioniert, es gibt nur noch nichts zu zeigen.

Danach geht es weiter mit Erstes Deployment.

Dein Zugang endet an deinem Namespace

Die Kubeconfig gilt ausschließlich für deinen eigenen Namespace. Einen clusterweiten Lesezugriff gibt es nicht, auch nicht auf harmlos wirkende Objekte:

Error from server (Forbidden): nodes is forbidden: User "..." cannot list
resource "nodes" in API group "" at the cluster scope

Das ist kein Fehler in deiner Einrichtung, sondern so gewollt.

Wenn ein Befehl Forbidden liefert

Drei Ursachen sind wahrscheinlich, in dieser Reihenfolge:

1. Der Standard-Namespace ist nicht gesetzt und der Befehl läuft gegen default. kubectl config view --minify zeigt dir, welcher Namespace im aktuellen Kontext hinterlegt ist.
2. Die Ressource gehört nicht zu dem, was dein Namespace anfassen darf. Was erlaubt ist, steht unter Berechtigungen und Richtlinien.
3. KUBECONFIG zeigt noch auf einen anderen Cluster. kubectl config current-context sagt dir, wo du gerade bist.

Gültigkeit und Austausch

Eine Kubeconfig ist ab dem Download ein Jahr gültig. Danach scheitert jeder Befehl damit an der Authentifizierung. Vor Ablauf bekommst du eine E-Mail; in einem Skript oder einer Pipeline warnt dich nichts. Wenn du eine Kubeconfig für Automatisierung nutzt, trag dir die Erneuerung also selbst ein.

Ein erneuter Download im Portal gibt dir eine frische Datei mit einem frischen Jahr. Das kannst du jederzeit und beliebig oft machen.

Ein neuer Download schaltet die alte Datei nicht ab

Jeder Download erzeugt einen zusätzlichen, eigenständigen Zugang. Er ersetzt oder widerruft die bestehenden nicht, und du kannst eine alte Kubeconfig auch nicht selbst abschalten.

Wenn eine Kubeconfig abhandenkommt, hilft ein neuer Download also nicht: Die alte Datei funktioniert den Rest ihres Jahres weiter. Melde dich beim Support, der den Zugriff auf den Namespace sperren kann.

Behandle die Datei deshalb als langlebiges Geheimnis: nicht ins Repository, nicht ins Ticket, nicht in den Chat, sondern zugriffsgeschützt ablegen und an Automatisierung als Secret übergeben, nicht als Datei im Checkout.

Wie es weitergeht

• Erstes Deployment, um etwas zum Laufen zu bringen
• Berechtigungen und Richtlinien, was du anlegen darfst