Ho Kubernetes che funziona bene in due ambienti diversi, vale a dire nel mio ambiente locale (MacBook con minikube) e anche su Container Engine di Google (GCE, Kubernetes su Google Cloud). Uso il MacBook / ambiente locale per sviluppare e testare i miei file YAML e poi, al termine, provarli su GCE.

Attualmente ho bisogno di lavorare con ogni ambiente individualmente: ho bisogno di modificare i file YAML nel mio ambiente locale e, quando pronto, (git) clonarli in un ambiente GCE e quindi usarli / distribuirli. Questo è un processo un po 'complicato.

Idealmente, vorrei utilizzare kubectl dal mio Macbook per passare facilmente dall'ambiente minikube locale o GCE Kubernetes e per determinare facilmente dove vengono utilizzati i file YAML. C'è un modo semplice per cambiare contesto per farlo?

Puoi passare da locale (minikube) a gcloud e viceversa con:

kubectl config use-context CONTEXT_NAME

per elencare tutti i contesti:

kubectl config get-contexts

Puoi creare diversi ambienti per local e gcloud e metterli in file yaml separati.

Una scorciatoia più veloce per i comandi kubectl standard consiste nell'usare kubectx :

• Contesti elenco: kubectx
  • Equivalente a kubectl config get-contexts
• Cambia contesto (in foo): kubectx foo
  • Equivalente a kubectl config use-context foo

Per installare su macOS: brew install kubectx

Il pacchetto kubectx include anche uno strumento simile per cambiare spazio dei nomi chiamato kubens.

Questi due sono super convenienti se lavori regolarmente in più contesti e spazi dei nomi.

Maggiori informazioni: https://ahmet.im/blog/kubectx/

Se stai cercando una soluzione basata su GUI per Mac e hai installato Docker Desktop, puoi utilizzare l'icona della barra dei menu Docker. Qui puoi trovare il menu "Kubernetes" con tutti i contesti che hai nel tuo kubeconfig e passare facilmente da uno all'altro.

L'ultima risposta del 2020 è qui,

Un modo semplice per passare dal contesto kubectl,

kubectl top nodes **--context=**context01name

kubectl top nodes --context=context02name

Puoi anche memorizzare il nome del contesto come env come context01name = gke _ $ {GOOGLE_CLOUD_PROJECT} _us-central1-a_standard-cluster-1

TL; DR: ho creato una GUI per cambiare i contesti di Kubernetes tramite AppleScript. Lo attivo tramite shift-cmd-x.

Anch'io ho avuto lo stesso problema. È stato un problema cambiare contesto dalla riga di comando. Ho usato FastScripts per impostare una combinazione di tasti (shift-cmd-x) per eseguire il seguente AppleScript (posizionato in questa directory: $ (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

Mi annoiavo a scriverlo più e più volte, quindi ho scritto una semplice utility bash per cambiare contesto

Puoi trovarlo qui https://github.com/josefkorbel/kube-switch

La clonazione dei file YAML tra repository per ambienti diversi è decisamente l'ideale. Quello che devi fare è creare modelli dei tuoi file YAML - estraendo i parametri che differiscono da ambiente a ambiente.

Ovviamente puoi usare un motore di template e separare i valori in uno YAML e produrre lo YAML per un ambiente specifico. Ma questo è facilmente realizzabile se adotti i grafici del timone . Per dare un'occhiata ad alcuni grafici di esempio, vai alla directory stabile in questo repository Github

Per fare un esempio del grafico di Wordpress , potresti avere due diversi comandi per due ambienti:

Per Dev:

helm install --name dev-release --set \ wordpressUsername=dev_admin, \ wordpressPassword=dev_password, \ mariadb.mariadbRootPassword=dev_secretpassword \ stable/wordpress

Tuttavia non è necessario passare questi valori sulla CLI, puoi memorizzare i valori in un file chiamato in modo appropriato values.ymle potresti avere file diversi per ambienti diversi

Avrai bisogno di un po 'di lavoro per la conversione agli standard dei grafici Helm, ma ne varrà la pena.

La risposta canonica di cambiare / leggere / manipolare diversi ambienti kubernetes (aka contesti kubernetes) è, come ha detto Mark, da usare kubectl config, vedi sotto:

$ 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]

Dietro le quinte, c'è un ~/.kube/configfile YAML che memorizza tutti i contesti disponibili con le credenziali e gli endpoint corrispondenti per ogni contesto.

Kubectl pronto all'uso non semplifica la gestione di diversi contesti kubernetes come probabilmente già saprai. Piuttosto che eseguire il rollio del tuo script per gestire tutto ciò, un approccio migliore consiste nell'usare uno strumento maturo chiamato kubectx, creato da un googler di nome "Ahmet Alp Balkan" che fa parte delle esperienze degli sviluppatori di Kubernetes / Google Cloud Platform Team che costruisce strumenti come questo. Lo consiglio vivamente.

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

Controlla anche l'ultimo docker contextcomando (docker 19.03) .

Ajeet Singh Raina ) lo illustra in " Docker 19.03.0 Pre-Release: Fast Context Switching, Rootless Docker, Sysctl support for Swarm Services "

Un contesto è essenzialmente la configurazione utilizzata per accedere a un particolare cluster.

Supponiamo, ad esempio, nel mio caso particolare, di avere 4 cluster diversi: un mix di Swarm e Kubernetes in esecuzione localmente e in remoto.
Supponiamo di avere un cluster predefinito in esecuzione sul mio computer desktop, un cluster Swarm a 2 nodi in esecuzione su Google Cloud Platform, un cluster a 5 nodi in esecuzione su Play con Docker playground e un cluster Kubernetes a nodo singolo in esecuzione su Minikube e che ho bisogno di accedere abbastanza regolarmente.

Utilizzando la CLI del contesto Docker posso passare facilmente da un cluster (che potrebbe essere il mio cluster di sviluppo) al test al cluster di produzione in pochi secondi.

$ 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.

Per esempio:

[:)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 

Nel caso tu stia cercando un modo semplice per passare da un contesto all'altro, forse questo sarà di aiuto.

Mi sono ispirato kubectxe gli kswitchscript già menzionati, che posso consigliare per la maggior parte dei casi d'uso. Stanno aiutando a risolvere il compito di commutazione, ma per me si stanno rompendo su alcune configurazioni più grandi o meno standard di ~/.kube/config. Quindi ho creato un wrapper di invocazione sys-exec e una scorciatoia kubectl.

Se chiami k senza parametri, vedrai un prompt intercettato per cambiare contesto.

Switch kubectl to a different context/cluster/namespace.
Found following options to select from:
 >>> context: [1] franz
 >>> context: [2] gke_foo_us-central1-a_live-v1
 >>> context: [3] minikube
 --> new num [?/q]:

Inoltre, kcontinua ad agire come una mano corta. Quanto segue è equivalente:

kubectl get pods --all-namespaces
k get pods -A
k p -A

Elenca contesti

kubectl config get-contexts

Cambia contesto

kubectl config set current-contex MY-CONTEXT

Per ottenere tutto il contesto

C:\Users\arun>kubectl config get-contexts

Per ottenere il contesto attuale

C:\Users\arun>kubectl config current-context

Per cambiare contesto

C:\Users\arun>kubectl config use-context <any context name from above list>

sì, penso che questo sia ciò che stai chiedendo. Per visualizzare la configurazione corrente, usa la visualizzazione della configurazione di kubectl. kubectl carica e unisce la configurazione dalle seguenti posizioni (in ordine)

--kubeconfig=/path/to/.kube/config command line flag
KUBECONFIG=/path/to/.kube/config env variable
$HOME/.kube/config  - The DEFAULT

io uso --kubeconfig poiché cambio molto tra più cluster. è leggermente ingombrante ma funziona bene.

vedi questi per maggiori informazioni. https://kubernetes.io/docs/tasks/administer-cluster/share-configuration/ e https://kubernetes.io/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/