Управление контекстами kubectl: практическое руководство

Быстрые ссылки

• Что такое контекст?

• Подготовка к работе с контекстами

• Создание контекста

• Выбор и использование контекстов

• Указание namespace в контексте

• Переименование и удаление контекстов

• Как упростить переключение контекстов

• Расширенные практики и чек-листы

Контексты kubectl — это механизм для быстрого переключения между разными кластерами, учётными записями и пространствами имён (namespaces) в командной строке. Они упрощают работу с несколькими окружениями без необходимости постоянно менять активный файл конфигурации kubectl.

В этой статье показано, как создавать, управлять и выбирать контексты с помощью kubectl. Убедитесь, что kubectl установлен и корректно настроен перед продолжением.

Что такое контекст?

Контекст агрегирует набор настроек, необходимых для подключения к Kubernetes-кластеру: адрес API-сервера, учётные данные пользователя и namespace по умолчанию. Контекст — это просто именованная ссылка на уже описанные в файле конфигурации объекты «cluster», «user» и необязательно «namespace».

Без контекстов часто создают отдельный kubeconfig-файл для каждого окружения и передают его через переменную окружения KUBECONFIG или флаг –kubeconfig:

$ export KUBECONFIG=.kube/cluster-1-user-1.yaml

$ kubectl get pods

Контексты позволяют объединить параметры всех окружений в одном файле (обычно ~/.kube/config), избавляя от необходимости указывать флаги или менять переменные окружения для типичных задач. kubectl предоставляет подкоманды для управления текущим контекстом.

Подготовка к работе с контекстами

Контексты управляются через группу команд kubectl config. Список доступных контекстов загружается из активного файла конфигурации, выбранного по переменной KUBECONFIG, флагу –kubeconfig или по умолчанию из ~/.kube/config.

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

# Создаём два подключения к кластерам: qa и prod

$ kubectl config set-cluster qa –server=https://192.168.0.1 –insecure-skip-tls-verify

$ kubectl config set-cluster prod –server=https://192.168.0.2 –insecure-skip-tls-verify

# Создаём две пары учётных данных

$ kubectl config set-credentials qa-user –username=demo –password=demoP@ss_qa

$ kubectl config set-credentials prod-user –username=demo –password=demoP@ss_prod

Теперь файл конфигурации содержит описания двух кластеров и двух пользователей. Следующий шаг — создать контексты, которые свяжут кластеры с конкретными учётными записями.

Создание контекста

Команда kubectl config set-context добавляет новый контекст в файл конфигурации. Нужно указать имя контекста и через флаги указать, к какому кластеру и какому пользователю он относится.

# Создаём контексты для ранее добавленных кластеров

$ kubectl config set-context qa-context –cluster=qa –user=qa-user

$ kubectl config set-context prod-context –cluster=prod –user=prod-user

После этого можно просмотреть содержимое файла конфигурации:

apiVersion: v1
kind: Config
current-context: ""
clusters:
- cluster:
    name: qa
    server: https://192.168.0.1
    insecure-skip-tls-verify: true
- cluster:
    name: prod
    server: https://192.168.0.2
    insecure-skip-tls-verify: true
contexts:
- context:
    name: qa-context
    cluster: qa
    user: qa-user
- context:
    name: prod-context
    cluster: prod
    user: prod-user
users:
- name: qa-user
  user:
    username: demo
    password: demoP@ss_qa
- name: prod-user
  user:
    username: demo
    password: demoP@ss_prod

Определения контекстов ссылаются на другие объекты внутри того же kubeconfig-файла.

Выбор и использование контекстов

Переключение активного контекста выполняется командой:

$ kubectl config use-context qa-context

Имя активного контекста хранится в поле current-context в файле kubeconfig. Все последующие команды kubectl будут выполняться по отношению к кластеру, указанному в выбранном контексте.

Пример работы:

# Подключится к https://192.168.0.1 как demo:demoP@ss_qa
$ kubectl get pods

# Переключаемся на prod
$ kubectl config use-context prod-context

# Подключится к https://192.168.0.2 как demo:demoP@ss_prod
$ kubectl get pods

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

$ kubectl config current-context

prod-context

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

$ kubectl config get-contexts

Табличный вывод показывает текущий контекст со звездочкой и колонки NAME, CLUSTER, AUTHINFO, NAMESPACE.

Указание namespace в контексте

Контекст может содержать namespace по умолчанию. Тогда kubectl будет автоматически применять этот namespace ко всем командам, если в них не указан флаг –namespace.

$ kubectl config set-context production-api --cluster=prod --user=prod-user --namespace=api

$ kubectl config use-context production-api

# Получит Pod'ы в namespace "api" кластера prod
$ kubectl get pods

Нет ограничения на количество контекстов. Один кластер может участвовать в нескольких контекстах, что удобно для работы с разными namespace без повторного указания –namespace.

Переименование и удаление контекстов

Переименовать можно командой:

$ kubectl config rename-context qa-context testing-context

Удаление контекста:

$ kubectl config delete-context testing-context

Чтобы изменить связанный кластер, пользователя или namespace контекста, повторно вызовите set-context с тем же именем или вручную отредактируйте файл ~/.kube/config.

Как упростить переключение контекстов

Стандартный workflow kubectl подходит при редком переключении. Если вы постоянно меняете контексты, полезны инструменты и подходы:

• kubectx — плагин, сокращающий синтаксис переключения, пример:

# Эквивалент kubectl config use-context prod-context
$ kubectx prod-context

• Автокоманда в shell (bash/zsh/fish), которая при открытии новой вкладки устанавливает нужный kubeconfig и контекст.

• Aliases для частых команд, например alias kg=’kubectl get’

• Интеграция с kube-ps1 или другими prompt-расширениями, показывающими текущий контекст прямо в приглашении оболочки.

Безопасность и конфиденциальность

Важно: kubeconfig может содержать чувствительные данные — токены, пароли, client-cert/key. Храните файлы с конфигурацией в безопасном месте, не добавляйте их в систему контроля версий в открытом виде.

Рекомендации:

• Используйте RBAC и минимальные привилегии для учётных записей.
• Для CI/CD и автоматизации применяйте сервисные аккаунты с ограниченным набором прав.
• Если возможно, используйте внешние менеджеры секретов и интеграцию с OIDC вместо хранения паролей в kubeconfig.
• Ограничьте доступ к ~/.kube/config правами файловой системы (например, chmod 600).

Расширенные сценарии и советы

Когда контексты не подходят:

• Если политики безопасности требуют отдельного изолированного файла kubeconfig для каждого окружения, объединение в один файл может быть запрещено.
• В сценариях, где необходимо динамически менять переменные окружения CI (например, разные облачные проекты), проще переключать файлы kubeconfig, чем контексты.

Альтернативные подходы:

• Несколько kubeconfig-файлов и объединение через переменную KUBECONFIG, когда вы хотите четко разделять секреты.
• Использование контекста + kubectl plugin-ов/скриптов для установки временных привилегий.

Ментальные модели:

• Контекст — это указатель: имя контекста указывает на конкретный кластер + пользователя + namespace.
• kubeconfig — это адресная книга: в ней хранятся все кластеры и пользователи; контексты комбинируют записи адресной книги.

Чек-листы по ролям

Разработчик:

• Проверить текущий контекст перед деплоем.
• Использовать namespace dev/test.
• Не хранить секреты в локальном kubeconfig в открытом виде.

Оператор/администратор:

• Иметь отдельный профиль/контекст для админских задач.
• Настроить MFA/OIDC для админских пользователей.
• Регулярно ревью прав RBAC.

SRE:

• Автоматизировать переключение в CI/CD через явный kubeconfig или контекст.
• Включить мониторинг и оповещения о изменениях конфигурации кластера.

Мини-методология для безопасного переключения

1. Всегда выводите kubectl config current-context.
2. При сложных операциях создавайте скрипт, который явно задаёт контекст и проверяет соединение (kubectl cluster-info).
3. Логируйте изменения контекста в командной истории или централизованно в CI.

Пример простого скрипта проверки:

#!/bin/bash
set -e
kubectl config use-context "$1"
echo "Текущий контекст: $(kubectl config current-context)"
kubectl cluster-info

Полезная шпаргалка (cheat sheet)

• kubectl config set-cluster NAME –server=URL [–certificate-authority=FILE]
• kubectl config set-credentials NAME –username=USER –password=PASS
• kubectl config set-context NAME –cluster=CLUSTER –user=USER [–namespace=NS]
• kubectl config use-context NAME
• kubectl config current-context
• kubectl config get-contexts
• kubectl config rename-context OLD NEW
• kubectl config delete-context NAME

Decision flowchart

flowchart TD
  A[Нужно переключить контекст?] -->|Да| B{Имеется kubeconfig с нужным контекстом?}
  B -->|Да| C[kubectl config use-context <имя>]
  B -->|Нет| D{Нужен новый контекст или файл?}
  D -->|Новый контекст| E[kubectl config set-context ...]
  D -->|Новый файл| F[Установить KUBECONFIG или --kubeconfig]
  A -->|Нет| G[Никаких действий]

Критерии приёмки

• Контекст существует в ~/.kube/config и корректно ссылается на cluster и user.
• kubectl config current-context выводит ожидаемое имя.
• kubectl get pods возвращает информацию из ожидаемого кластера и namespace.

Частые ошибки и как их исправить

• Проблема: вызываете kubectl, а команды работают в другом кластере. Решение: kubectl config current-context и kubectl config use-context <имя>.
• Проблема: отсутствует namespace, команды возвращают ресурсы из default. Решение: задать namespace в контексте или использовать –namespace.
• Проблема: утекли креденшалы в репозиторий. Решение: отозвать ключи, обновить секреты и пометить в gitignore.

Приватность и соответствие требованиям

Если конфигурация содержит персональные данные или доступы к данным пользователей, оцените соответствие внутренним правилам безопасности и требованиям регуляторов. Для обработки персональных данных используйте минимально необходимые привилегии и механизмы аудита.

Резюме

Контексты kubectl упрощают работу с множественными кластерами и пространствами имён, собирая в одном файле адреса серверов, учётные записи и namespace по умолчанию. Используйте kubectl config set-context для создания, kubectl config use-context для переключения и дополнительные инструменты (kubectx, алиасы, prompt-интеграции) для повышения удобства. Всегда проверяйте текущий контекст и защищайте kubeconfig как чувствительный артефакт.

Важно: храните секреты безопасно, применяйте принципы наименьших привилегий и автоматизируйте проверки перед критическими операциями.