Mam Kubernetes działającego dobrze w dwóch różnych środowiskach, a mianowicie w moim środowisku lokalnym (MacBook z minikube) oraz w Google Container Engine (GCE, Kubernetes on Google Cloud). Używam MacBooka / środowiska lokalnego do tworzenia i testowania moich plików YAML, a po zakończeniu wypróbuj je na GCE.

Obecnie muszę pracować z każdym środowiskiem indywidualnie: muszę edytować pliki YAML w moim środowisku lokalnym i, gdy będą gotowe, (git) sklonować je do środowiska GCE, a następnie użyć / wdrożyć. Jest to nieco uciążliwy proces.

Idealnie chciałbym użyć kubectl z mojego Macbooka, aby łatwo przełączać się między lokalnymi środowiskami minikube lub GCE Kubernetes i łatwo określić, gdzie są używane pliki YAML. Czy istnieje prosty sposób zmiany kontekstów, aby to zrobić?

Możesz przełączyć się z lokalnego (minikube) na gcloud iz powrotem za pomocą:

kubectl config use-context CONTEXT_NAME

aby wyświetlić wszystkie konteksty:

kubectl config get-contexts

Możesz tworzyć różne środowiska dla lokalnego i gcloud i umieszczać je w osobnych plikach yaml.

Szybszym skrótem do standardowych poleceń kubectl jest użycie kubectx :

• Lista kontekstów: kubectx
  • Równoważny kubectl config get-contexts
• Przełącz kontekst (na foo): kubectx foo
  • Równoważny kubectl config use-context foo

Aby zainstalować w systemie macOS: brew install kubectx

Pakiet kubectx zawiera również podobne narzędzie do przełączania przestrzeni nazw o nazwie kubens.

Te dwa są bardzo wygodne, jeśli regularnie pracujesz w wielu kontekstach i przestrzeniach nazw.

Więcej informacji: https://ahmet.im/blog/kubectx/

Jeśli szukasz rozwiązania opartego na graficznym interfejsie użytkownika dla komputerów Mac i masz zainstalowany Docker Desktop, możesz użyć ikony paska menu Docker. Tutaj możesz znaleźć menu „Kubernetes” ze wszystkimi kontekstami, które masz w swoim kubeconfig i łatwo przełączać się między nimi.

Najnowsza odpowiedź na rok 2020 jest tutaj,

Prosty sposób na przełączanie się między kontekstem kubectl,

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

kubectl top nodes --context=context02name

Możesz również zapisać nazwę kontekstu jako env, na przykład context01name = gke _ $ {GOOGLE_CLOUD_PROJECT} _us-central1-a_standard-cluster-1

TL; DR: stworzyłem GUI do przełączania kontekstów Kubernetes przez AppleScript. Aktywuję go przez shift-cmd-x.

Ja też miałem ten sam problem. To był problem przełączania kontekstów przez wiersz poleceń. Użyłem FastScripts do ustawienia kombinacji klawiszy (shift-cmd-x) do uruchomienia następującego AppleScript (umieszczonego w tym katalogu: $ (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

Znudziło mi się pisanie tego w kółko, więc napisałem proste narzędzie bash do przełączania kontekstów

Możesz go znaleźć tutaj https://github.com/josefkorbel/kube-switch

Klonowanie plików YAML w repozytoriach dla różnych środowisk jest zdecydowanie idealne. To, co musisz zrobić, to utworzyć szablony plików YAML - poprzez wyodrębnienie parametrów, które różnią się w zależności od środowiska.

Możesz oczywiście użyć jakiegoś silnika szablonów i oddzielić wartości w YAML i stworzyć YAML dla określonego środowiska. Ale jest to łatwe do wykonania, jeśli zastosujesz wykresy sterowe . Aby rzucić okiem na przykładowe wykresy, przejdź do katalogu stabilnego w tym repozytorium Github

Aby wziąć przykład wykresu Wordpress , możesz mieć dwa różne polecenia dla dwóch środowisk:

Dla programistów:

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

Nie jest jednak konieczne przekazywanie tych wartości do CLI, możesz przechowywać wartości w pliku o nazwie aptly values.ymli możesz mieć różne pliki dla różnych środowisk

Będziesz potrzebować trochę pracy przy konwersji do standardów wykresów Helm, ale wysiłek będzie tego wart.

Kanoniczną odpowiedzią na przełączanie / odczytywanie / manipulowanie różnymi środowiskami kubernetes (zwanymi też kontekstami kubernetes) jest, jak wspomniał Mark, użycie kubectl config, patrz poniżej:

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

Za kulisami znajduje się ~/.kube/configplik YAML, który przechowuje wszystkie dostępne konteksty z odpowiadającymi im poświadczeniami i punktami końcowymi dla każdego kontekstu.

Gotowy Kubectl nie ułatwia zarządzania różnymi kontekstami kubernetes, jak prawdopodobnie już wiesz. Zamiast kubectxtworzyć własny skrypt, aby zarządzać tym wszystkim, lepszym podejściem jest użycie dojrzałego narzędzia o nazwie „Ahmet Alp Balkan”, który jest członkiem zespołu ds. Doświadczeń deweloperów Kubernetes / Google Cloud Platform, który tworzy takie narzędzia. Gorąco polecam.

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

Sprawdź też ostatnią (19.03 Döcker) docker contextpolecenia .

Ajeet Singh Raina ) ilustruje to w „ Docker 19.03.0 Pre-Release: Fast Context Switching, Rootless Docker, Sysctl support for Swarm Services ”

Kontekst to zasadniczo konfiguracja używana do uzyskiwania dostępu do określonego klastra.

Załóżmy na przykład, że w moim konkretnym przypadku mam 4 różne klastry - połączenie Swarm i Kubernetes działające lokalnie i zdalnie.
Załóżmy, że mam domyślny klaster działający na moim komputerze stacjonarnym, klaster Swarm z 2 węzłami działający na platformie Google Cloud Platform, klaster 5-węzłowy działający w Play z placem zabaw Docker oraz klaster Kubernetes z jednym węzłem działający na Minikube i że muszę uzyskać dostęp do całkiem regularnie.

Korzystając z CLI kontekstu Dockera, mogę łatwo przełączyć się z jednego klastra (który mógłby być moim klastrem programistycznym), aby testować na klaster produkcyjny w ciągu kilku sekund.

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

Na przykład:

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

Jeśli szukasz prostego sposobu na przełączanie się między różnymi kontekstami, może to być pomocne.

Zostałem zainspirowany kubectxi kswitchskrypty już wspomniano, które mogę polecić dla większości przypadków użycia. Pomagają w rozwiązaniu zadania przełączania, ale psują mi się w niektórych większych lub mniej standardowych konfiguracjach ~/.kube/config. Utworzyłem więc opakowanie wywołania sys-exec i krótką dłoń kubectl.

Jeśli wywołasz k bez parametrów, zobaczysz przechwycony monit o przełączenie kontekstu.

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

Ponadto knadal działa jako short-hand. Poniższe jest równoważne:

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

Lista kontekstów

kubectl config get-contexts

Przełącz konteksty

kubectl config set current-contex MY-CONTEXT

Aby uzyskać pełny kontekst

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

Aby uzyskać aktualny kontekst

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

Aby zmienić kontekst

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

tak, myślę, że o to pytasz. Aby wyświetlić bieżącą konfigurację, użyj widoku konfiguracji kubectl. kubectl ładuje i łączy konfigurację z następujących lokalizacji (w kolejności)

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

używam --kubeconfig, ponieważ często przełączam się między wieloma klastrami. jest nieco uciążliwy, ale działa dobrze.

zobacz je, aby uzyskać więcej informacji. https://kubernetes.io/docs/tasks/administer-cluster/share-configuration/ i https://kubernetes.io/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/