Kubernetes: настройка kubectl для работы с несколькими кластерами
О технологиях

Kubernetes: настройка kubectl для работы с несколькими кластерами

8585
4 минуты

Для большинства людей знакомство с Kubernetes заканчивается на установке единственного кластера и настройке kubectl по умолчанию. Но что если возникает необходимость управлять несколькими кластерами? В этой статье я решил рассказать об использовании kubectl с различными контекстами.

В большинстве случаев нет однозначного ответа на вопрос «Как настроить kubectl для использования с несколькими кластерами?». В первую очередь это зависит от того, настроили ли вы кластер на использование сертификатов или нет. Далее я буду предполагать, что настроили, т.к. такая настройка кластера является наилучшей практикой.


kubectl обычно записывает свой конфигурационный файл в директорию .kube в вашей домашней директории. Когда вы установите его для первого кластера, файл конфигурации будет выглядеть примерно так:



apiVersion: v1
clusters:
- cluster:
    certificate-authority: /path/to/ca.pem
    server: https://default-master.domain
  name: default-cluster
contexts:
- context:
    cluster: default-cluster
    user: default-admin
  name: default-system
current-context: default-system
kind: Config
preferences: {}
users:
- name: default-admin
  user:
    client-certificate: /path/to/admin.pem
    client-key: /path/to/admin-key.pem

Поэтому, как только у нас появляется второй кластера, например, для клиента образно называемый «customer-cluster», нам нужно добавить в кластер следующую запись:



- cluster:
    certificate-authority: /path/to/customer/ca.pem
    server: https://customer-master.domain
  name: customer-cluster

Эта настройка именует кластер и указывает kubectl на CA сертификат и URL-адрес его сервера API.

Затем контекст:



- context:
    cluster: customer-cluster
    user: customer-admin
  name: customer-cluster

Контекст связывает кластер и пользователя для доступа к кластеру. kubectl будет использовать этот контекст для доступ к нему. Наконец, секция пользователя для этого кластера:



- name: customer-admin
  user:
    client-certificate: /path/to/customer/admin.pem
    client-key: /path/to/customer/admin-key.pem

Здесь мы указываем путь к сертификату и ключу для этого пользователя. Таким образом, весь файл будет выглядеть следующим образом:



apiVersion: v1
clusters:
- cluster:
    certificate-authority: /path/to/ca.pem
    server: https://default-master.domain
  name: default-cluster
- cluster:
    certificate-authority: /path/to/customer/ca.pem
    server: https://customer-master.domain
  name: customer-cluster
contexts:
- context:
    cluster: default-cluster
    user: default-admin
  name: default-system
- context:
    cluster: customer-cluster
    user: customer-admin
  name: customer-cluster
current-context: default-system
kind: Config
preferences: {}
users:
- name: default-admin
  user:
    client-certificate: /path/to/admin.pem
    client-key: /path/to/admin-key.pem
- name: customer-admin
  user:
    client-certificate: /path/to/customer/admin.pem
    client-key: /path/to/customer/admin-key.pem

Теперь при использовании kubectl, вы можете использовать —context для указания того, какой кластер вам нужен. Вам не нужно использовать —contextпри использовании кластера по умолчанию.

Например, команда:


kubectl --context customer-cluster get nodes

Возвращает узлы в кластере клиента, авторизуясь на сервере API с помощью сертификата пользователя и ключа customer-admin. Вы можете установить контекст, используя команду:


kubectl config use-context customer-cluster

Теперь команда


kubectl get nodes

Покажет узлы кластера клиента, а не узлы предыдущего кластера по умолчанию. Чтобы вернуться обратно к настройкам по умолчанию, выполните команду:


kubectl config use-context default-system

Чтобы узнать, в каком контексте вы сейчас работаете, выполните команду:


kubectl config current-context

Не смотря на удобство использования контекста по умолчанию, я рекомендую всегда использовать явное указание контекста при помощи —context в ваших командах kubectl, т.к. очень легко забыть, в каком контексте вы находитесь, и если у вас несколько кластеров, случайно создать или что еще хуже удалить объекты в неправильном кластере.

Внедряем и поддерживаем Kubernetes/DevOps
Развертываем и сопровождаем инфраструктуру для бизнес-приложений на базе микросервисов и контейнеров

19 июня 2023
Семь трендов на рынке облачных услуг в 2023 году
До 2022 года на рынке облаков в России главенствовали мировые тренды, но сейчас наша страна пошла своим путем. О том, для чего сейчас компании используют облачные технологии и как меняется рынок, рассказал директор по развитию КРОК Облачные сервисы Сергей Зинкевич.
1 минута
2461
16 июня 2023
Рулевой в океане контейнеров
Выпуск#3 видеоподкаста «Откровенно об ИТ-инфраструктуре» посвящен Kubernetes и профессиональным платформам оркестрации контейнеров. Обсудили, как сегодня складывается ситуация на российском рынке контейнерных платформ, что востребовано и почему, особенности и перспективы работы с Kubernetes.

В гостях Александр Баталов, Генеральный директор Флант
1 минута
1637
29 марта 2023
Сетевые балансировщики нагрузки и другие обновления Облака КРОК

Мы рады вам представить новый сервис Облака КРОК для распределения трафика между экземплярами – Балансировщики нагрузки. Кроме того, мы автоматизировали обновление сертификатов Kubernetes и добавили возможность удаления рабочих узлов из кластера Kubernetes.

2 минуты
984
13 февраля 2023
Замена игрока: выбираем альтернативу зарубежному системному ПО (взгляд облачного провайдера)

На поле ИТ сегодня захватывающая интрига – выбор адекватной замены зарубежным системам, производители которых массово вышли из игры. На онлайн-митапе поделились опытом подбора, внедрения и сопровождения решений, способных заместить платформу виртуализации, почту, файловое хранилище, каталог пользователей, backup и др.

Предлагаем вашему вниманию запись и расшифровку митапа.

2 минуты
2294
15 ноября 2022
OpenShift остался без поддержки – как решить проблему российским клиентам
Интерес к семейству ПО для контейнеризации OpenShift был довольно высоким в корпоративном сегменте в прежние годы. По данным мониторинговой службы Datadog, только за прошлый год во всем мире количество пользователей платформ от RedHat увеличилось на 28%. Весной IBM объявил об уходе из России и прекращении поддержки всех программных продуктов для текущих клиентов. Разберемся, насколько критичной оказалась данная ситуация для заказчиков, и какие варианты действий существуют, чтобы минимизировать возможные риски отключения от сервиса.
1 минута
1107
scrollup