Kubernetes fonctionne bien dans deux environnements différents, à savoir mon environnement local (MacBook sous minikube) et le moteur de conteneur de Google (GCE, Kubernetes sur Google Cloud). J'utilise l'environnement MacBook/local pour développer et tester mes fichiers YAML puis, une fois terminé, les essayer sur GCE.
Actuellement, je dois travailler avec chaque environnement individuellement: je dois modifier les fichiers YAML dans mon environnement local et, une fois prêt, (git) les cloner dans un environnement GCE puis les utiliser/les déployer. C'est un processus quelque peu fastidieux.
Idéalement, j'aimerais utiliser kubectl de mon Macbook pour basculer facilement entre les environnements locaux de minikube ou GCE Kubernetes et pour déterminer facilement où les fichiers YAML sont utilisés. Existe-t-il un moyen simple de changer de contexte pour le faire?
Vous pouvez passer de local (minikube) à gcloud et revenir avec:
kubectl config use-context CONTEXT_NAME
pour lister tous les contextes:
kubectl config get-contexts
Vous pouvez créer différents environnements pour local et gcloud et les placer dans des fichiers yaml distincts.
Si vous recherchez une solution graphique pour Mac et que Docker Desktop est installé, vous pouvez utiliser l'icône de la barre de menus Docker. Ici vous pouvez trouver le menu "Kubernetes" avec tous les contextes que vous avez dans votre kubeconfig et basculer facilement entre eux.
Le clonage des fichiers YAML dans des dépôts pour différents environnements est certainement idéal. Vous modélisez vos fichiers YAML en extrayant les paramètres qui diffèrent d’un environnement à l’autre.
Vous pouvez bien sûr utiliser un moteur de modélisation, séparer les valeurs dans un YAML et produire le YAML pour un environnement spécifique. Mais ceci est facilement faisable si vous adoptez le Helm Charts . Pour voir quelques exemples de graphiques, allez dans le répertoire stable de ce répertoire Github repo
Pour prendre un exemple du graphique Wordpress , vous pouvez avoir deux commandes différentes pour deux environnements:
Pour Dev:
helm install --name dev-release --set \
wordpressUsername=dev_admin, \
wordpressPassword=dev_password, \
mariadb.mariadbRootPassword=dev_secretpassword \
stable/wordpress
Il n’est pas nécessaire de transmettre ces valeurs à la CLI, vous pouvez cependant les stocker dans un fichier appelé justement values.yml
et vous pourriez avoir différents fichiers pour différents environnements
Vous aurez besoin de travail pour convertir les normes de Helm chart, mais l'effort en vaudra la peine.
TL; DR: J'ai créé une interface graphique pour changer de contexte Kubernetes via AppleScript. Je l'activer via shift-cmd-x.
Moi aussi j'ai eu le même problème. C'était une douleur de changer de contexte par la ligne de commande. J'ai utilisé FastScripts pour définir une combinaison de touches (shift-cmd-x) permettant d'exécuter le code AppleScript suivant (placé dans ce répertoire: $ (HOME)/Bibliothèque/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
Un raccourci plus rapide vers les commandes kubectl standard consiste à utiliser kubectx :
kubectx
kubectl config get-contexts
kubectx foo
kubectl config use-context foo
Pour installer sur macOS: brew install kubectx
Le paquet kubectx comprend également un outil similaire pour changer d’espace de nommage appelé kubens
.
Ces deux méthodes sont extrêmement pratiques si vous travaillez régulièrement dans plusieurs contextes et espaces de noms.
Plus d'infos: https://ahmet.im/blog/kubectx/
Vérifiez également la dernière (docker 19.03) docker context
commande .
Ajeet Singh Raina ) l’illustre dans " Docker 19.03.0 Pre-Release: Changement rapide de contexte, Rootless Docker, support Sysctl pour Swarm Services "
Un contexte est essentiellement la configuration que vous utilisez pour accéder à un cluster particulier.
Supposons, par exemple, que dans mon cas particulier, j'ai 4 grappes différentes - un mélange de Swarm et de Kubernetes fonctionnant localement et à distance.
Supposons que je dispose d’un cluster par défaut sur mon ordinateur de bureau, d’un cluster Swarm à 2 nœuds sous Google Cloud Platform, d’un cluster à 5 nœuds sous Play avec Docker et d’un cluster Kubernetes à nœud unique sous Minikube, et que J'ai besoin d'accéder assez régulièrement.Utilisation de la CLI en contexte de menu fixe Je peux facilement passer d'un cluster (qui pourrait être mon cluster de développement) à des tests en cluster de production en quelques secondes.
$ 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.
Par exemple:
[:)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
La réponse canonique de commutation/lecture/manipulation de différents environnements kubernetes (ou contextes kubernètes) est, comme le mentionne Mark, d'utiliser kubectl config
, voir ci-dessous:
$ 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]
En coulisse, il existe un fichier ~/.kube/config
YAML qui stocke tous les contextes disponibles avec les informations d'identification et les points de terminaison correspondants pour chaque contexte.
Kubectl sur étagère ne facilite pas la gestion de différents contextes kubernètes comme vous le savez probablement déjà. Plutôt que de lancer votre propre script pour gérer tout cela, une meilleure approche consiste à utiliser un outil évolué appelé kubectx
, créé par un googleur nommé "Ahmet Alp Balkan" qui fait partie de la communauté des développeurs de Kubernetes/Google Cloud Platform. Je le recommande fortement.
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
Je me suis ennuyé de taper cela encore et encore alors j'ai écrit un utilitaire bash simple pour changer de contexte
Vous pouvez le trouver ici https://github.com/josefkorbel/kube-switch