У мене Kubernetes добре працює у двох різних середовищах, а саме в моєму локальному середовищі (MacBook, що працює з minikube), а також в Google Container Engine (GCE, Kubernetes в Google Cloud). Я використовую MacBook / локальне середовище для розробки та тестування моїх файлів YAML, а потім по завершенні спробуйте їх на GCE.

В даний час мені потрібно працювати з кожним середовищем окремо: мені потрібно редагувати файли YAML в моєму локальному середовищі і, коли буде готово, (git) клонувати їх у середовище GCE, а потім використовувати / розгортати їх. Це дещо громіздкий процес.

В ідеалі, я хотів би використовувати kubectl зі свого Macbook, щоб легко переходити між локальним середовищем minikube або GCE Kubernetes та легко визначати, де використовуються файли YAML. Чи є простий спосіб переключення контекстів для цього?

Ви можете переключитися з локальної (minikube) на gcloud і назад за допомогою:

kubectl config use-context CONTEXT_NAME

щоб перелічити всі контексти:

kubectl config get-contexts

Ви можете створити різні середовища для локальних та gcloud та помістити їх в окремі файли yaml.

Більш швидким ярликом до стандартних команд kubectl є використання kubectx :

• Список контекстів: kubectx
  • Дорівнює kubectl config get-contexts
• Переключити контекст (на foo): kubectx foo
  • Дорівнює kubectl config use-context foo

Щоб встановити на macOS: brew install kubectx

У пакет kubectx також входить аналогічний інструмент для переключення просторів імен з назвою kubens.

Ці два дуже зручні, якщо ви працюєте в декількох контекстах та просторах імен регулярно.

Більше інформації: https://ahmet.im/blog/kubectx/

Якщо ви шукаєте рішення на основі GUI для Mac і встановили Docker Desktop, ви можете скористатися піктограмою Docker Menu Bar. Тут ви можете знайти меню "Kubernetes" з усіма контекстами, які є у вашій kubeconfig, і легко перемикатися між ними.

Остання відповідь до 2020 року тут

Простий спосіб переключення між контекстом kubectl,

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

kubectl top nodes --context=context02name

Ви також можете зберігати назву контексту як env, як context01name = gke _ $ {GOOGLE_CLOUD_PROJECT} _us-central1-a_standard-cluster-1

TL; DR: Я створив графічний інтерфейс для перемикання контекстів Kubernetes через AppleScript. Я активую його за допомогою shift-cmd-x.

У мене теж було те саме питання. Це було больовим переключенням контекстів командного рядка. Я використовував FastScripts, щоб встановити комбінацію клавіш (shift-cmd-x) для запуску наступного AppleScript (розміщеного в цьому каталозі: $ (HOME) / Бібліотека / Сценарії / Програми / Термінал).

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

Мені нудно було вводити це знову і знову, тому я написав просту утиліту bash для переключення контекстів

Ви можете знайти його тут https://github.com/josefkorbel/kube-switch

Клонування файлів YAML через репости для різних середовищ, безумовно, ідеально. Вам потрібно шаблонувати файли YAML - витягуючи параметри, які відрізняються від середовища до середовища.

Звичайно, ви можете використовувати деякий механізм шаблонування і розділяти значення в YAML і виробляти YAML для конкретного середовища. Але це легко здійснити, якщо ви приймете Helm Charts . Щоб ознайомитись з деякими зразками діаграм, перейдіть до стабільної директорії цього репортажу Github

Для прикладу діаграми Wordpress ви можете мати дві різні команди для двох середовищ:

Для Dev:

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

Не обов'язково передавати ці значення на CLI, проте ви можете зберігати значення у файлі, який називається влучно, values.ymlі у вас можуть бути різні файли для різних середовищ

Вам знадобиться певна робота з перетворення на стандарти Helm-діаграми, але зусилля того варті.

Як згадував Марк, канонічну відповідь про перемикання / читання / маніпулювання різними середовищами кубернетів (також контекстів кубернетів) можна використовувати kubectl config, див. Нижче:

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

За сценою є ~/.kube/configфайл YAML, який зберігає всі наявні контексти з відповідними обліковими записами та кінцевими точками для кожного контексту.

Kubectl з полиці не дозволяє легко керувати різними контекстами кубернетів, як ви, напевно, вже знаєте. Замість того, щоб прокручувати власний сценарій, щоб керувати усім цим, кращим підходом є використання зрілого інструменту під назвоюkubectx , створеного Googler на ім'я "Ahmet Alp Balkan", який працює в Kubernetes / Google Cloud Platform, розробник команди, яка створює подібні інструменти. Я дуже рекомендую його.

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

Перевірте також останню docker contextкоманду (docker 19.03) .

Ajeet Singh Raina ) проілюструє це у " Докері 19.03.0 передвипуск: швидка комутація контексту, бездоганний докер, підтримка Sysctl для послуг Swarm "

Контекст - це, по суті, конфігурація, яку ви використовуєте для доступу до певного кластеру.

Скажімо, у моєму конкретному випадку у мене є 4 різних кластери - суміш Swarm та Kubernetes, що працюють локально та віддалено.
Припустимо, що на моєму настільному комп’ютері працює кластер за замовчуванням, 2 вузловий кластер Swarm, що працює на платформі Google Cloud, 5-вузловий кластер, що працює в Play with Docker playground та одновузловий кластер Kubernetes, що працює на Minikube, і що мені потрібно отримати доступ регулярно.

Використовуючи CLI-контекст докера, я можу легко перейти з одного кластеру (який міг би бути моїм кластером розробки) для тестування на виробничий кластер за лічені секунди.

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

Наприклад:

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

У випадку, якщо ви можете шукати простий спосіб переключення між різними контекстами, можливо, це допоможе.

Мене надихнули kubectxі kswitchвже згадані сценарії, які я можу рекомендувати для більшості випадків використання. Вони допомагають вирішити задачу перемикання, але для мене порушують деякі великі або менш стандартні конфігурації ~/.kube/config. Тому я створив обгортку виклику sys-exec і короткий простір навколо kubectl.

Якщо ви зателефонуєте до k без парам, ви побачите перехоплений запит на переключення контексту.

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

Далі, kпродовжує діяти як короткометражна. Наступне:

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

Перелічіть контексти

kubectl config get-contexts

Переключення контекстів

kubectl config set current-contex MY-CONTEXT

Щоб отримати весь контекст

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

Щоб отримати поточний контекст

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

Для переключення контексту

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

так, я думаю, що це те, про що ти питаєш. Щоб переглянути поточну конфігурацію, використовуйте перегляд конфігурації kubectl. kubectl навантажує і зливає конфігурацію з наступних місць (для порядку)

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

я використовую --kubeconfig, оскільки я перемикаюся між кількома кластерами. він трохи громіздкий, але він працює добре.

див. їх для отримання додаткової інформації. https://kubernetes.io/docs/tasks/administer-cluster/share-configuration/ та https://kubernetes.io/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/