Casos de uso: o Kubepier no dia a dia de quem opera Kubernetes
Oito situações comuns de quem cuida de clusters de vários clientes ou times, e o caminho no Kubepier, tela por tela. Encontre a sua e veja o que muda.
Cenários ilustrativos: os personagens são genéricos e não representam clientes reais. Os ganhos descritos são qualitativos ou estimativas, não resultados medidos.
Uma consultoria com 12 clientes e dezenas de kubeconfigs
Situação
Uma consultoria atende 12 clientes: alguns no AKS, outros no EKS, um no GKE e dois on-premises. Cada consultor tem uma pasta de kubeconfigs no notebook e nomes de context que só ele entende.
A dor
Achar o cluster certo vira busca. Trocar de context errado é um risco real: um comando no cluster de outro cliente. Quando alguém sai do time, ninguém sabe quais kubeconfigs foram junto.
O que custa: Minutos perdidos a cada troca de cliente, risco de ação no cluster errado e credenciais de cliente espalhadas em máquinas pessoais.
Como fica no Kubepier
- Entre em app.kubepier.com.br com o GitHub e crie a organização da consultoria.
- Cadastre cada cliente com nome, cor e palavra-chave. Um cluster cujo nome contém a palavra entra no cliente sozinho.
- Conecte os clusters colando o kubeconfig ou, no AKS e no EKS, pela conta Azure ou AWS, sem copiar kubeconfig. As credenciais ficam cifradas e nunca voltam para a tela.
- Abra o Início: um cartão por cliente com os clusters, os pods com problema e os avisos.
- No Team, convide cada consultor pelo GitHub e libere só os clientes que ele atende.
Resultado esperado
Você acha o cluster pelo cliente, com a cor dele em todas as telas, em vez de lembrar o nome do context. Em vez de procurar o kubeconfig certo, são dois cliques. Quem sai do time perde o acesso na hora.
Limites: O acesso por cliente do Team vale na web. No desktop, cada pessoa usa o kubeconfig da própria máquina.
Veja também:ClientesOrganizar vários kubeconfigsEquipe e permissõesWeb, celular ou desktop: qual usar
O alerta das 3h da manhã, com o notebook longe
Situação
O alerta toca de madrugada. O SRE de plantão está com o celular na mão e o notebook, com o kubeconfig, na outra sala.
A dor
Antes de saber se é grave, é preciso levantar, ligar o notebook, conectar a VPN e achar o context. Muitas vezes era um pod reiniciando que se resolveria sozinho.
O que custa: Minutos de indisponibilidade até a primeira olhada, sono perdido e decisões tomadas no escuro.
Como fica no Kubepier
- Abra app.kubepier.com.br no navegador do celular. A interface se ajusta à tela.
- No Início, o cliente com problema aparece com os pods em falha e os avisos da última hora.
- Abra o pod: motivo (CrashLoopBackOff, OOMKilled, ImagePullBackOff, Pending), código de saída, reinícios e eventos.
- Veja as últimas linhas de log (Free) ou os logs ao vivo (Pro).
- Peça o diagnóstico com IA: ele explica a falha a partir do status, dos eventos e dos logs, sem os segredos. No Pro e no Team, cada usuário tem 7 dias de IA sem cadastrar chave; a tela Análises com IA (novo) lista os pods com problema do cluster.
- No Pro, um admin reinicia ou escala o deployment dali mesmo, com confirmação.
Resultado esperado
A primeira triagem sai do celular. Você decide se precisa do notebook ou se pode voltar a dormir, com o contexto na mão.
Limites: Pela web, a API do cluster precisa aceitar os IPs de saída fixos do Kubepier. Cluster totalmente privado fica para o desktop, pela VPN.
Veja também:Kubernetes no celularResolver CrashLoopBackOffDiagnóstico com IAWeb, celular ou desktop: qual usar
Mostrar quem tem acesso e quem fez o quê, para LGPD ou ISO
Situação
A empresa passa por uma avaliação de LGPD ou de ISO 27001 e precisa mostrar como controla o acesso à produção. Hoje, o mesmo kubeconfig de admin circula no chat do time.
A dor
Ninguém consegue dizer quem tem acesso a qual cliente, nem quem reiniciou aquele deployment na sexta. A evidência é montada à mão, em planilha.
O que custa: Horas montando evidência, risco de apontamento na auditoria e credencial de produção que não dá para revogar de uma pessoa só.
Como fica no Kubepier
- No Team, cada pessoa entra com o próprio GitHub. Não há kubeconfig no chat.
- O admin libera, por pessoa, só os clientes que ela atende. O papel membro só lê: editar, escalar, reiniciar, apagar e shell são do admin.
- Para quem só precisa olhar, cadastre o cluster com uma ServiceAccount de leitura (o papel view). Nem o admin consegue alterar o cluster por ela.
- Na tela Auditoria, filtre por pessoa, cliente, cluster e ação, e exporte em CSV (até 90 dias por consulta nos planos pagos). O conteúdo nunca é gravado: nem logs, nem o que se digita no shell, nem valores.
- Quando alguém sai, remova da equipe: o acesso acaba na hora.
Resultado esperado
Você responde "quem tem acesso a quê" pela tela Equipe e "quem fez o quê" por um CSV, em vez de reconstruir a história pelo chat.
Limites: A auditoria registra as ações no cluster e nos serviços dos clientes; no desktop, ela fica no arquivo de cada máquina. O Kubepier ajuda a gerar evidência, mas não substitui o audit log do Kubernetes nem tem certificação SOC 2 ou ISO 27001.
Veja também:Equipe e permissõesAuditoriaSegurançaWeb, celular ou desktop: qual usar
O pod está Running, mas os pedidos não saem
Situação
Os pedidos param de ser processados. O worker está Running, sem reinício e sem erro no log. O time reinicia o pod duas vezes e nada muda.
A dor
O problema não está no pod: a fila cresceu, ou as mensagens foram todas para a DLQ. Mas a fila está em outra ferramenta, com outro login, que nem todo mundo tem.
O que custa: Horas olhando para o lugar errado, reinícios que não resolvem e pedidos atrasados enquanto isso.
Como fica no Kubepier
- Cadastre o RabbitMQ ou o Azure Service Bus do cliente no cadastro dele. A credencial fica cifrada.
- Na tela do pod, a aba Filas mostra as filas que ele usa, lidas das variáveis do container, com o tamanho de cada uma.
- No menu do serviço, o painel de filas mostra contagens e DLQ; no Pro, taxas, tendência e alertas.
- No Pro, espie as mensagens da DLQ para ver o erro que as derrubou.
- Depois de corrigir, purgue a fila se for o caso: pede para digitar o nome antes (na web, só admin).
Resultado esperado
A fila aparece ao lado do pod. O time vê na primeira olhada que o gargalo é a mensageria, não o container.
Veja também:Alertas de filas: DLQ e fila paradaRabbitMQAzure Service BusWeb, celular ou desktop: qual usar
O cliente só libera IP conhecido no firewall
Situação
O cliente exige que a API do Kubernetes e o MongoDB Atlas aceitem só IPs conhecidos. Cada consultor sai por um IP diferente, de casa, do escritório ou da VPN.
A dor
Cada mudança de IP vira chamado para o time de rede do cliente. Ou pior: alguém abre a API para a internet "só por hoje".
O que custa: Dias de chamados de firewall e uma API de produção exposta mais do que deveria.
Como fica no Kubepier
- No app, em Rede e segurança, copie os IPs de saída fixos do Kubepier Web.
- Peça ao cliente para liberar só esses IPs: authorized IP ranges no AKS, public access CIDRs no EKS, master authorized networks no GKE, IP Access List no Atlas e o firewall do Service Bus, do RabbitMQ e do Redis.
- Para serviços em rede privada, use a rota Pelo cluster: o acesso passa por um relay restrito dentro de um cluster do cliente.
Resultado esperado
Um pedido de liberação, uma vez, para a equipe inteira. A API do cliente continua fechada para o resto da internet.
Limites: Os IPs são compartilhados por todos os clientes do Kubepier Web: são uma camada de rede somada às credenciais, não no lugar delas. Cluster totalmente privado continua no desktop, pela VPN.
Veja também:Rede e IPs de saídaConectar serviçosWeb, celular ou desktop: qual usar
Gravar uma demo ou uma aula sem expor o cliente
Situação
Um consultor quer gravar um vídeo mostrando como investigou uma falha, ou compartilhar a tela numa reunião com outro cliente.
A dor
Na tela aparecem nomes de clientes, clusters, namespaces e IPs. Borrar quadro a quadro na edição toma horas, e um quadro esquecido expõe o cliente.
O que custa: Horas de edição de vídeo e o risco de expor dados de um cliente para outro.
Como fica no Kubepier
- No Kubepier Desktop, clique em Apresentação, na barra de status.
- Nomes de clientes, clusters, namespaces, nós, IPs e a coluna Quem da auditoria ficam borrados em todas as janelas.
- Status, tipos e contagens continuam legíveis: a gravação ainda mostra o que está com problema.
Resultado esperado
Você grava a tela sem pós-produção para esconder nomes e sem ensaiar o que não pode aparecer.
Limites: Terminais, YAML aberto, logs e valores aparecem como são: confira a tela antes de gravar. O modo apresentação ainda não existe na web.
Veja também:Modo apresentaçãoWeb, celular ou desktop: qual usar
O time que saiu do Lens e quer algo para todos
Situação
O time usava Lens ou OpenLens e procura uma alternativa. Cada pessoa tem a própria IDE e os próprios kubeconfigs, e quem não instala nada (gestão, suporte) fica sem ver.
A dor
Cada máquina é uma ilha: nada no celular, nada para quem não tem o kubeconfig e nenhuma visão por cliente.
O que custa: Tempo de onboarding a cada pessoa nova e pedidos de "me manda um print do cluster".
Como fica no Kubepier
- Instale o Kubepier Desktop no Windows, no macOS ou no Linux. Ele é construído sobre o Freelens: workloads, logs, shell, Helm e port-forward continuam onde você espera.
- Entre com a mesma conta da web. O plano da organização vale nos dois.
- Em Preferências › TR Clientes, agrupe os clusters por cliente.
- Para quem não quer instalar nada, o Kubepier Web abre no navegador, com o mesmo catálogo.
Resultado esperado
Quem gosta de desktop continua no desktop; quem precisa só ver usa o navegador. Todos com a mesma organização e o mesmo plano.
Limites: Se você cuida de poucos clusters, todos seus, o Freelens atende bem e é de código aberto.
Veja também:Alternativa ao LensKubepier vs FreelensInstalar o desktopWeb, celular ou desktop: qual usar
Entrar no nó sem SSH nas VMs
Situação
Um nó está com disco cheio ou o kubelet está estranho. As VMs do node pool não têm SSH liberado, e pedir acesso leva dias.
A dor
A saída comum é escrever à mão um pod privilegiado com hostPID e nsenter, e às vezes ele fica esquecido no cluster.
O que custa: Horas até conseguir olhar o nó e um pod privilegiado que ninguém lembra de apagar.
Como fica no Kubepier
- No Kubepier Desktop (Pro ou Team), abra o nó e use o shell no nó.
- Novo na web: um admin Pro ou Team clica em Shell no node e digita o nome do nó para confirmar.
- O Kubepier cria um pod privilegiado temporário no kube-system, fixo no nó, e o apaga ao fechar o terminal (na web, no máximo 2 horas).
- A auditoria registra quem abriu, quando, em qual cluster e nó e por quanto tempo, nunca o que foi digitado.
- Em breve: shell remoto via Tailscale, pelo seu tailnet, do celular ou do notebook (beta com lista de espera).
Resultado esperado
Você olha o nó em minutos, sem SSH nas VMs, e o pod some quando você termina.
Limites: Nós Windows: só pelo desktop. Nós AWS Fargate não aceitam pod privilegiado. Clusters que bloqueiam pod privilegiado (Pod Security, Azure Policy, Kyverno, Gatekeeper) precisam de uma exceção.
Veja também:Shell no pod e no nóShell remoto via Tailscale (em breve)Web, celular ou desktop: qual usar
Reconheceu a sua situação?
Conecte o primeiro cluster em modo leitura e veja o seu caso na sua tela. Sem cartão e sem instalar nada no cluster.
Web, celular ou desktop: qual usar