Ich habe Kubernetes in zwei verschiedenen Umgebungen, nämlich in meiner lokalen Umgebung (MacBook mit Minikube) und in der Container Engine von Google (GCE, Kubernetes in Google Cloud). Ich verwende die MacBook/local-Umgebung, um meine YAML-Dateien zu entwickeln und zu testen, und probiere sie nach Fertigstellung bei GCE aus.
Momentan muss ich mit jeder Umgebung einzeln arbeiten: Ich muss die YAML-Dateien in meiner lokalen Umgebung bearbeiten und, wenn fertig, (git) sie in eine GCE-Umgebung klonen und sie dann verwenden/bereitstellen. Dies ist ein etwas umständlicher Prozess.
Im Idealfall möchte ich kubectl von meinem Macbook verwenden, um problemlos zwischen den lokalen Minikube- oder GCE-Kubernetes-Umgebungen zu wechseln und zu ermitteln, wo die YAML-Dateien verwendet werden. Gibt es eine einfache Möglichkeit, den Kontext dafür zu wechseln?
Sie können von local (minikube) zu gcloud und zurück wechseln mit:
kubectl config use-context CONTEXT_NAME
um alle Kontexte aufzulisten:
kubectl config get-contexts
Sie können verschiedene Umgebungen für local und gcloud erstellen und diese in separaten yaml-Dateien ablegen.
Wenn Sie nach einer GUI-basierten Lösung für Mac suchen und Docker Desktop installiert haben, können Sie das Docker-Menüleisten-Symbol verwenden. Hier finden Sie das Menü "Kubernetes" mit allen Kontexten, die Sie in Ihrer kubeconfig haben, und wechseln Sie einfach zwischen ihnen.
Das Klonen der YAML-Dateien über verschiedene Repos hinweg für verschiedene Umgebungen ist auf jeden Fall ideal. Was Sie tun müssen, ist eine Vorlage für Ihre YAML-Dateien - indem Sie die Parameter extrahieren, die sich von Umgebung zu Umgebung unterscheiden.
Sie können natürlich ein Templating Engine verwenden, um die Werte in einer YAML zu trennen und die YAML für eine bestimmte Umgebung zu erstellen. Dies ist jedoch problemlos möglich, wenn Sie die Helm-Charts übernehmen. Um einige Beispieldiagramme anzusehen, gehen Sie in das Stable-Verzeichnis unter/ Github Repo
Um ein Beispiel für das Wordpress-Diagramm zu erhalten, können Sie zwei verschiedene Befehle für zwei Umgebungen verwenden:
Für Dev:
helm install --name dev-release --set \
wordpressUsername=dev_admin, \
wordpressPassword=dev_password, \
mariadb.mariadbRootPassword=dev_secretpassword \
stable/wordpress
Es ist nicht erforderlich, diese Werte an die CLI zu übergeben. Sie können die Werte in einer Datei mit dem Namen aptly values.yml
speichern. Möglicherweise haben Sie unterschiedliche Dateien für verschiedene Umgebungen
Bei der Konvertierung in Helm-Chart-Standards sind einige Arbeiten erforderlich, aber der Aufwand lohnt sich.
TL; DR: Ich habe eine GUI erstellt, um den Kontext von Kubernetes über AppleScript zu ändern. Ich aktiviere es über shift-cmd-x.
Ich hatte auch das gleiche Problem. Es war ein schmerzhaftes Wechseln von Kontexten durch die Befehlszeile. Ich habe FastScripts verwendet, um eine Tastenkombination (shift-cmd-x) festzulegen, um das folgende AppleScript auszuführen (in diesem Verzeichnis abgelegt: $ (HOME)/Library/Scripts/Applications/Terminal).
use AppleScript version "2.4" -- Yosemite (10.10) or later
use scripting additions
do Shell script "/usr/local/bin/kubectl config current-context"
set curcontext to result
do Shell script "/usr/local/bin/kubectl config get-contexts -o name"
set contexts to paragraphs of result
choose from list contexts with Prompt "Select Context:" with title "K8s Context Selector" default items {curcontext}
set scriptArguments to item 1 of result
do Shell script "/usr/local/bin/kubectl config use-context " & scriptArguments
display dialog "Switched to " & scriptArguments buttons {"ok"} default button 1
Eine schnellere Verknüpfung zu den Standardbefehlen von kubectl ist die Verwendung von kubectx :
kubectx
kubectl config get-contexts
kubectx foo
kubectl config use-context foo
Installation unter macOS: brew install kubectx
Das kubectx-Paket enthält auch ein ähnliches Tool zum Wechseln von Namespaces mit dem Namen kubens
.
Diese beiden sind sehr praktisch, wenn Sie regelmäßig in mehreren Kontexten und Namespaces arbeiten.
Weitere Informationen: https://ahmet.im/blog/kubectx/
Überprüfen Sie auch den neuesten (Docker 19.03) docker context
Befehl .
Ajeet Singh Raina ) illustriert es in " Docker 19.03.0 Pre-Release: Schnelle Kontextumschaltung, Rootless Docker, Sysctl-Unterstützung für Swarm Services "
Ein Kontext ist im Wesentlichen die Konfiguration, mit der Sie auf einen bestimmten Cluster zugreifen.
Angenommen, in meinem speziellen Fall habe ich 4 verschiedene Cluster - eine Mischung aus Swarm und Kubernetes, die lokal und remote ausgeführt werden.
Angenommen, auf meinem Desktop-Computer wird ein Standardcluster ausgeführt, auf Google Cloud Platform ein 2-Knoten-Schwarmcluster, auf Play with Docker ein 5-Knoten-Cluster und auf Minikube ein Einzelknoten-Kubernetes-Cluster Ich muss ziemlich regelmäßig zugreifen.Mithilfe der Docker-Kontext-CLI kann ich problemlos innerhalb von Sekunden von einem Cluster (der möglicherweise mein Entwicklungscluster ist) zum Produktionscluster wechseln.
$ Sudo docker context --help
Usage: docker context COMMAND
Manage contexts
Commands:
create Create a context
export Export a context to a tar or kubeconfig file
import Import a context from a tar file
inspect Display detailed information on one or more contexts
ls List contexts
rm Remove one or more contexts
update Update a context
use Set the current docker context
Run 'docker context COMMAND --help' for more information on a command.
Zum Beispiel:
[:)Captain'sBay=>Sudo docker context ls NAME DESCRIPTION DOCKER ENDPOINT KUBERNETES ENDPOINT ORCHESTRATOR default * Current DOCKER_Host based configuration unix:///var/run/docker.sock https://127.0.0.1:16443 (default) swarm swarm-context1
Die kanonische Antwort des Umschaltens/Lesens/Manipulierens verschiedener Kubernetes-Umgebungen (aka Kubernetes-Kontexte) ist, wie Mark erwähnte, kubectl config
zu verwenden, siehe unten:
$ kubectl config
Modify kubeconfig files using subcommands like "kubectl config set current-context my-context"
Available Commands:
current-context Displays the current-context
delete-cluster Delete the specified cluster from the kubeconfig
delete-context Delete the specified context from the kubeconfig
get-clusters Display clusters defined in the kubeconfig
get-contexts Describe one or many contexts
rename-context Renames a context from the kubeconfig file.
set Sets an individual value in a kubeconfig file
set-cluster Sets a cluster entry in kubeconfig
set-context Sets a context entry in kubeconfig
set-credentials Sets a user entry in kubeconfig
unset Unsets an individual value in a kubeconfig file
use-context Sets the current-context in a kubeconfig file
view Display merged kubeconfig settings or a specified kubeconfig file
Usage:
kubectl config SUBCOMMAND [options]
Hinter den Kulissen befindet sich eine YAML-Datei mit ~/.kube/config
, in der alle verfügbaren Kontexte mit den entsprechenden Anmeldeinformationen und Endpunkten für die einzelnen Kontexte gespeichert werden.
Kubectl von der Stange macht es nicht einfach, verschiedene Kubernetes-Kontexte zu verwalten, wie Sie wahrscheinlich bereits wissen. Anstatt ein eigenes Skript zu erstellen, um all das zu verwalten, ist es besser, ein ausgereiftes Tool namens kubectx
zu verwenden, das von einem Googler namens "Ahmet Alp Balkan" erstellt wurde, der auf Kubernetes/Google Cloud Platform arbeitet. Ich empfehle es sehr.
https://github.com/ahmetb/kubectx
$ kctx --help
USAGE:
kubectx : list the contexts
kubectx <NAME> : switch to context <NAME>
kubectx - : switch to the previous context
kubectx <NEW_NAME>=<NAME> : rename context <NAME> to <NEW_NAME>
kubectx <NEW_NAME>=. : rename current-context to <NEW_NAME>
kubectx -d <NAME> [<NAME...>] : delete context <NAME> ('.' for current-context)
(this command won't delete the user/cluster entry
that is used by the context)
kubectx -h,--help : show this message
Mir wurde langweilig, dies immer und immer wieder zu tippen, also schrieb ich ein einfaches Bash-Dienstprogramm, um den Kontext zu wechseln
Sie finden es hier https://github.com/josefkorbel/kube-switch