Siehe auch: [Kubectl Überblick](/docs/reference/kubectl/overview/) und [JsonPath Dokumentation](/docs/reference/kubectl/jsonpath).
Diese Seite ist eine Übersicht über den Befehl `kubectl`.
{{% /capture %}}
{{% capture body %}}
# kubectl - Spickzettel
## Kubectl Autovervollständigung
### BASH
```bash
source <(kubectl completion bash) # Wenn Sie autocomplete in bash in der aktuellen Shell einrichten, sollte zuerst das bash-completion-Paket installiert werden.
echo "source <(kubectl completion bash)" >> ~/.bashrc # Fügen Sie der Bash-Shell dauerhaft Autocomplete hinzu.
source <(kubectl completion zsh) # Richten Sie Autocomplete in zsh in der aktuellen Shell ein
echo "if [ $commands[kubectl] ]; then source <(kubectl completion zsh); fi" >> ~/.zshrc # Fügen Sie der Zsh-Shell dauerhaft Autocomplete hinzu
```
## Kubectl Kontext und Konfiguration
Legen Sie fest, welcher Kubernetes-Cluster mit `kubectl` kommuniziert und dessen Konfiguration ändert. Lesen Sie die Dokumentation [Authentifizierung mit kubeconfig über mehrere Cluster hinweg](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) für ausführliche Informationen zur Konfigurationsdatei.
`apply` verwaltet Anwendungen durch Dateien, die Kubernetes-Ressourcen definieren. Es erstellt und aktualisiert Ressourcen in einem Cluster durch Ausführen von `kubectl apply`. Dies ist die empfohlene Methode zur Verwaltung von Kubernetes-Anwendungen in der Produktion. Lesen Sie die ausführliche [Kubectl Dokumentation](https://kubectl.docs.kubernetes.io) für weitere Informationen.
## Objekte erstellen
Kubernetes Manifeste können in Json oder Yaml definiert werden. Die Dateierweiterungen `.yaml`,
Ab Version 1.11 ist das `rolling-update` veraltet (Lesen Sie [CHANGELOG-1.11.md](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.11.md) für weitere Informationen), verwenden Sie stattdessen `rollout`.
kubectl set image deployment/frontend www=image:v2 # Fortlaufende Aktualisierung der "www" Container der "Frontend"-Bereitstellung, Aktualisierung des Images
kubectl rollout undo deployment/frontend # Rollback zur vorherigen Bereitstellung
kubectl rollout status -w deployment/frontend # Beobachten Sie den fortlaufenden Aktualisierungsstatus der "Frontend"-Bereitstellung bis zum Abschluss.
# veraltet ab Version 1.11
kubectl rolling-update frontend-v1 -f frontend-v2.json # (veraltet) Fortlaufendes Update der Pods von Frontend-v1
kubectl rolling-update frontend-v1 frontend-v2 --image=image:v2 # (veraltet) Ändern Sie den Namen der Ressource und aktualisieren Sie das Image
kubectl rolling-update frontend --image=image:v2 # (veraltet) Aktualisieren Sie das Pod-Image des Frontends
kubectl rolling-update frontend-v1 frontend-v2 --rollback # (veraltet) Bricht das laufende Rollout ab
cat pod.json | kubectl replace -f - # Ersetzen Sie einen Pod basierend auf der in std übergebenen JSON
# Ersetzen, löschen und Ressource neu erstellen. Dies führt zu einer temprären Unerreichbarkeit des Dienstes.
kubectl replace --force -f ./pod.json
# Erstellen Sie einen Dienst für eien replizierten nginx Webserver, der an Port 80 und in den Containern an Port 8000 lauscht
Bearbeiten Sie eine beliebige API-Ressource in einem Editor.
```bash
kubectl edit svc/docker-registry # Bearbeiten Sie den Dienst docker-registry
KUBE_EDITOR="nano" kubectl edit svc/docker-registry # Verwenden Sie einen alternativen Texteditor
```
## Ressourcen skalieren
```bash
kubectl scale --replicas=3 rs/foo # Skaliert ein Replikat mit dem Namen 'foo' auf 3
kubectl scale --replicas=3 -f foo.yaml # Skaliert eine in "foo.yaml" angegebene Ressource auf 3
kubectl scale --current-replicas=2 --replicas=3 deployment/mysql # Wenn die aktuelle Konfiguration der Replikation von mysql 2 ist, skaliert mysql auf 3
kubectl scale --replicas=5 rc/foo rc/bar rc/baz # Skaliert mehrere Replikationscontroller
```
## Ressourcen löschen
```bash
kubectl delete -f ./pod.json # Löscht einen Pod mit dem in pod.json angegebenen Typ und Namen
kubectl delete pod,service baz foo # Löscht Pods und Services mit den gleichen Namen "baz" und "foo"
kubectl delete pods,services -l name=myLabel # Löscht Pods und Services mit dem Label name=myLabel
kubectl logs my-pod -c my-container --previous # Pod Container-Logdatei für eine vorherige Instantiierung eines Containers ausgeben (stdout, multi-container case)
Liste aller unterstützten Ressourcentypen mit ihren Kurzbezeichnungen, der [API-Gruppe](/docs/concepts/overview/kubernetes-api/#api-groups), unabhängig davon ob sie im Namespace liegen, und der [Art](/docs/concepts/overview/working-with-objects/kubernetes-objects):
```bash
kubectl api-resources
```
Andere Operationen zum Erkunden von API-Ressourcen:
```bash
kubectl api-resources --namespaced=true # Alle Ressourcen im Namespace
kubectl api-resources --namespaced=false # Alle nicht im Namespace befindlichen Ressourcen
kubectl api-resources -o name # Alle Ressourcen mit einfacher Ausgabe (nur der Ressourcenname)
kubectl api-resources -o wide # Alle Ressourcen mit erweiterter Ausgabe (aka "Wide")
kubectl api-resources --verbs=list,get # Alle Ressourcen, die "list" und "get" Verben unterstützen anfordern
kubectl api-resources --api-group=extensions # Alle Ressourcen in der API-Gruppe "extensions"
```
### Ausgabe formatieren
Um Details in einem bestimmten Format an Ihr Terminalfenster auszugeben, können Sie entweder das `-o` oder `--output` Flag zu einem unterstützten `kubectl` Befehl anhängens.
Ausgabeformat | Beschreibung
--------------| -----------
`-o=custom-columns=<spec>` | Ausgabe einer Tabelle mit einer durch Kommas getrennten Liste benutzerdefinierter Spalten
`-o=custom-columns-file=<dateiname>` | Drucken Sie eine Tabelle mit der benutzerdefinierten Spaltenvorlage in der `<dateiname>` Datei
`-o=json` | Ausgabe eines JSON-formatierten API-Objekts
`-o=jsonpath=<template>` | Ausgabe der in einem [jsonpath](/docs/reference/kubectl/jsonpath)-Ausdruck definierten Felder
`-o=jsonpath-file=<dateiname>` | Ausgabe der in einem [jsonpath](/docs/reference/kubectl/jsonpath)-Ausdruck definierten Felder in der `<dateiname>` Datei
`-o=name` | Ausgabe von nur dem Ressourcennamen und nichts anderes
`-o=wide` | Ausgabe im Klartextformat mit zusätzlichen Informationen. Bei Pods ist der Node-Name enthalten
`-o=yaml` | Gibt ein YAML-formatiertes API-Objekt aus
Die Ausführlichkeit von Kubectl wird mit den Flags `-v` oder `--v ` gesteuert, gefolgt von einer Ganzzahl, die die Protokollebene darstellt. Allgemeine Protokollierungskonventionen für Kubernetes und die zugehörigen Protokollebenen werden [hier](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md) beschrieben.
`--v=0` | Allgemein nützlich, damit dies für den Bediener IMMER sichtbar ist.
`--v=1` | Eine vernünftige Standardprotokollebene, wenn Sie keine Ausführlichkeit wünschen.
`--v=2` | Nützliche Informationen zum stabilen Status des Dienstes und wichtige Protokollnachrichten, die möglicherweise zu erheblichen Änderungen im System führen. Dies ist die empfohlene Standardprotokollebene für die meisten Systeme.
`--v=3` | Erweiterte Informationen zu Änderungen.
`--v=4` | Debug-Level-Ausführlichkeit.
`--v=6` | Angeforderte Ressourcen anzeigen
`--v=7` | HTTP-Anforderungsheader anzeigen
`--v=8` | HTTP-Anforderungsinhalt anzeigen
`--v=9` | HTTP-Anforderungsinhalt anzeigen, ohne den Inhalt zu kürzen.
{{% /capture %}}
{{% capture whatsnext %}}
* Lernen Sie mehr im [Überblick auf kubectl](/docs/reference/kubectl/overview/).
* Erkunden Sie [kubectl](/docs/reference/kubectl/kubectl/) Optionen.
* Und ebenfalls die [kubectl Nutzungskonventionen](/docs/reference/kubectl/conventions/) um zu verstehen, wie man es in wiederverwendbaren Skripten verwendet.
* Entdecken Sie mehr Community [kubectl Spickzettel](https://github.com/dennyzhang/cheatsheet-kubernetes-A4).