Como organizar vários kubeconfigs e trocar de contexto
Quem cuida de clusters de vários clientes acaba com vários kubeconfigs: um por nuvem, por cliente ou por ambiente. O kubectl junta esses arquivos e troca de contexto sem você copiar nada à mão. Estes são os comandos, e como o Kubepier organiza os mesmos clusters por cliente.
1. Veja os contextos do kubeconfig
Cada contexto liga um cluster a um usuário e, se você quiser, a um namespace. O asterisco marca o contexto atual:
kubectl config get-contexts
kubectl config current-context 2. Troque de contexto com kubectl config use-context
O use-context muda o contexto atual de todos os comandos seguintes. Para um comando só, sem trocar o atual, use --context:
kubectl config use-context <contexto>
kubectl config set-context --current --namespace=<namespace>
# Só neste comando:
kubectl get pods --context <contexto> -n <namespace> 3. KUBECONFIG com vários arquivos
A variável KUBECONFIG aceita uma lista de arquivos, separados por dois-pontos no Linux e no macOS e por ponto e vírgula no Windows. O kubectl lê todos como se fossem um só, e get-contexts mostra os contextos de todos eles.
Se o mesmo nome de contexto, cluster ou usuário aparece em dois arquivos, vale o do primeiro arquivo da lista. Por isso vale dar nomes únicos a cada contexto.
# Linux e macOS (bash/zsh)
export KUBECONFIG=~/.kube/config:~/.kube/cliente-a.yaml:~/.kube/cliente-b.yaml
# Windows (PowerShell)
$env:KUBECONFIG = "$HOME\.kube\config;$HOME\.kube\cliente-a.yaml" 4. Junte os kubeconfigs num arquivo só
Para ficar com um arquivo único, gere a versão combinada com --flatten, que também embute os certificados que estavam em arquivos separados. Grave num arquivo novo, guarde uma cópia do original e só depois troque:
cp ~/.kube/config ~/.kube/config.bak
KUBECONFIG=~/.kube/config:~/.kube/cliente-a.yaml kubectl config view --flatten > /tmp/kubeconfig-junto
mv /tmp/kubeconfig-junto ~/.kube/config
chmod 600 ~/.kube/config Não redirecione a saída direto para ~/.kube/config: o shell esvazia o arquivo antes de o kubectl ler.
Nomes de contexto que ajudam
- Ponha o cliente e o ambiente no nome do contexto: cliente-a-prd, cliente-a-hml. Fica claro onde você está antes de rodar um comando.
- kubectl config rename-context <antigo> <novo> renomeia sem mexer no cluster nem no usuário.
- No AKS, az aks get-credentials --context <nome> já grava o contexto com o nome que você escolher; no EKS, aws eks update-kubeconfig --alias <nome>.
- kubectl config delete-context <nome> apaga só o contexto. O cluster e o usuário ficam no arquivo até você apagar com delete-cluster e delete-user.
- kubectx e kubens fazem a troca de contexto e de namespace com menos digitação.
Cuidados com vários kubeconfigs
- O kubeconfig leva token ou certificado: deixe o arquivo só para o seu usuário (chmod 600) e não mande pelo chat.
- Antes de um comando que altera algo, confira o contexto atual. Errar o contexto é o jeito mais comum de mexer no cluster de outro cliente.
- Contextos com plugin exec (kubelogin, aws, gke-gcloud-auth-plugin) dependem do binário na sua máquina; o arquivo sozinho não basta em outra máquina.
Como o Kubepier organiza clusters por cliente
No Kubepier, cada cluster pertence a um cliente, com nome, cor e uma palavra-chave. Um cluster cujo nome contém a palavra-chave entra no cliente sozinho, e você corrige a atribuição na gaveta de detalhes do cluster.
No desktop, os clusters vêm do kubeconfig da sua máquina (~/.kube/config), inclusive os contextos com plugins exec; outros arquivos e pastas entram em Preferências › Kubernetes, em Kubeconfig Syncs, como no Freelens. O catálogo agrupa todos pelo cliente dono, e você cadastra os clientes em Preferências › TR Clientes.
Na web, você cola o kubeconfig em Clusters › Colar kubeconfig: cada contexto do arquivo vira um cluster, e o cliente sai da palavra-chave ou do cliente que você escolher na importação. Contextos que a web não aceita (plugin exec, credencial em arquivo local) aparecem com o motivo; os outros do mesmo arquivo entram. AKS e EKS também entram pela conta de nuvem, sem kubeconfig.