Починить kubectl, когда контекст «не найден»

kubectl config get-contexts
kubectl config current-context
kubectl config view --minify

kubectl config set-context kt --cluster=k8s-tula --user=admin@k8s-tula
kubectl config use-context kt

kubectl --kubeconfig ~/.kube/config-omsk get pods
kubectl --kubeconfig ~/.kube/config-omsk config get-contexts

Симптом обманчивый: kubectl пишет «context was not found», и кажется, что доступа нет. На деле в ~/.kube/config секции clusters и users заполнены, а contexts пустая — current-context ссылается на имя, которого не существует. Так бывает, когда конфиг собирали руками или склеивали из кусков.

Контекст — это просто связка «кластер + пользователь (+ неймспейс по умолчанию)». Если обе части уже есть, чинится одной командой, никаких новых сертификатов запрашивать не нужно.

Имя контекста произвольное — короткое удобнее, потому что оно мелькает в каждом use-context.

Для второго кластера чаще всего проще не сливать конфиги, а держать отдельный файл и указывать --kubeconfig. Слияние через KUBECONFIG=a:b работает, но потом трудно понять, откуда взялся конкретный контекст, и легко применить манифест не туда.

config view --minify показывает только текущий контекст — удобно, чтобы убедиться, куда именно вы сейчас смотрите, перед командой, которая что-то меняет.