Português Web version Download for Linux
Use cases

Use cases: Kubepier in the day-to-day of running Kubernetes

Eight common situations for people who look after clusters for many clients or teams, and the path in Kubepier, screen by screen. Find yours and see what changes.

Illustrative scenarios: the characters are generic and do not represent real customers. The gains described are qualitative or estimates, not measured results.

01 · Consultancy or MSP

A consultancy with 12 clients and dozens of kubeconfigs

Where
Web and desktop (the client catalog exists on both)
Plan
Free to organize and view; Team for the team with per-client access

Situation

A consultancy serves 12 clients: some on AKS, others on EKS, one on GKE and two on-premises. Each consultant keeps a folder of kubeconfigs on their laptop, with context names only they understand.

The pain

Finding the right cluster becomes a search. Switching to the wrong context is a real risk: a command on another client’s cluster. When someone leaves, nobody knows which kubeconfigs left with them.

What it costs: Minutes lost on every client switch, the risk of acting on the wrong cluster and client credentials spread across personal machines.

How it works in Kubepier

  1. Sign in at app.kubepier.com.br with GitHub: the consultancy’s organization is created on first sign-in, and you complete the profile.
  2. Add each client with a name, color and keyword. A cluster whose name contains the keyword joins the client on its own.
  3. Connect clusters by pasting the kubeconfig or, for AKS and EKS, through the Azure or AWS account, with no kubeconfig to copy. Credentials are encrypted and never come back to the screen.
  4. Open Home: one card per client with its clusters, failing pods and warnings.
  5. On Team, invite each consultant via GitHub and grant only the clients they serve.

Expected result

You find the cluster by client, with its color on every screen, instead of remembering the context name. Instead of hunting for the right kubeconfig, it takes two clicks. Whoever leaves the team loses web access right away (within 6 h on desktop).

Limits: Team’s per-client access applies on the web. On desktop, each person uses the kubeconfig on their own machine.

See also:ClientsManage multiple kubeconfigsTeam and permissionsWeb, phone or desktop: which to use

02 · On-call SRE

The 3 a.m. alert, with the laptop out of reach

Where
Web, in the phone browser
Plan
Free to view; Pro for live logs, AI and actions

Situation

The alert fires at night. The on-call SRE has the phone in hand and the laptop, with the kubeconfig, in the other room.

The pain

Before knowing whether it is serious, you have to get up, boot the laptop, connect the VPN and find the context. Often it was a restarting pod that would have recovered on its own.

What it costs: Minutes of downtime before the first look, lost sleep and decisions made in the dark.

How it works in Kubepier

  1. Open app.kubepier.com.br in your phone’s browser. The interface fits the screen.
  2. On Home, the client with a problem shows its failing pods and the warnings from the last hour.
  3. Open the pod: reason (CrashLoopBackOff, OOMKilled, ImagePullBackOff, Pending), exit code, restarts and events.
  4. See the last log lines (Free) or live logs (Pro).
  5. Ask for the AI diagnosis: it explains the failure from the status, events and logs, minus the secrets. On Pro and Team, each user gets 7 days of AI with no key to set up; the AI analyses screen (new) lists the cluster’s failing pods.
  6. On Pro, an admin restarts or scales the deployment right there, with confirmation.

Expected result

The first triage happens on the phone. You decide whether you need the laptop or can go back to sleep, with the context in hand.

Limits: On the web, the cluster API must accept Kubepier’s fixed egress IPs. A fully private cluster stays on desktop, over the VPN.

See also:Kubernetes on your phoneFix CrashLoopBackOffAI diagnosisWeb, phone or desktop: which to use

03 · CTO or head of infrastructure

Showing who has access and who did what, for LGPD or ISO

Where
Web
Plan
Team

Situation

The company is going through an LGPD or ISO 27001 assessment and must show how it controls production access. Today, the same admin kubeconfig goes around the team chat.

The pain

Nobody can say who has access to which client, or who restarted that deployment on Friday. Evidence is assembled by hand, in a spreadsheet.

What it costs: Hours building evidence, the risk of an audit finding and a production credential you cannot revoke from a single person.

How it works in Kubepier

  1. On Team, each person signs in with their own GitHub. No kubeconfig in the chat.
  2. The admin grants, per person, only the clients they serve (on the web). The member role is read-only: edit, scale, restart, delete and shell belong to admins, on the web and, from version 2.7.0, on desktop.
  3. For people who only need to look, add the cluster with a read-only ServiceAccount (the view role). Not even an admin can change the cluster through it.
  4. On the Audit screen, filter by person, client, cluster and action, and export CSV (up to 90 days per query on paid plans). Content is never stored: no logs, no shell input, no values.
  5. When someone leaves, remove them from the team: web access ends right away; on desktop, paid features stop at the next licence check, within 6 h.

Expected result

You answer "who has access to what" from the Team screen and "who did what" with a CSV, instead of rebuilding the story from the chat.

Limits: The audit log records actions on the cluster and on client services; on desktop, it stays in each machine’s file. Kubepier helps you produce evidence, but it does not replace the Kubernetes audit log and has no SOC 2 or ISO 27001 certification.

See also:Team and permissionsAudit logSecurityWeb, phone or desktop: which to use

04 · Product and operations team

The pod is Running, but orders are not going out

Where
Web and desktop
Plan
Free to see queues and counts; Pro to peek, purge, rates and alerts

Situation

Orders stop being processed. The worker is Running, with no restarts and no errors in the log. The team restarts the pod twice and nothing changes.

The pain

The problem is not the pod: the queue grew, or every message went to the DLQ. But the queue lives in another tool, with another login, that not everyone has.

What it costs: Hours looking in the wrong place, restarts that fix nothing and delayed orders in the meantime.

How it works in Kubepier

  1. Add the client’s RabbitMQ or Azure Service Bus in the client settings. The credential is encrypted.
  2. On the pod screen, the Queues tab shows the queues it uses, read from the container variables, with each one’s depth.
  3. In the service menu, the queue dashboard shows counts and the DLQ; on Pro, rates, trend and alerts.
  4. On Pro, peek at the DLQ messages to see the error that dropped them.
  5. After the fix, purge the queue if needed: you type its name first (on the web, admins only).

Expected result

The queue shows up next to the pod. The team sees at first glance that the bottleneck is messaging, not the container.

See also:Queue alerts: DLQ and stuck queuesRabbitMQAzure Service BusWeb, phone or desktop: which to use

05 · Consultancy serving regulated companies

The client only allows known IPs through the firewall

Where
Web
Plan
All plans, Free included

Situation

The client requires the Kubernetes API and MongoDB Atlas to accept only known IPs. Each consultant connects from a different IP: home, office or VPN.

The pain

Every IP change becomes a ticket for the client’s network team. Or worse: someone opens the API to the internet "just for today".

What it costs: Days of firewall tickets and a production API more exposed than it should be.

How it works in Kubepier

  1. In the app, under Network and security, copy Kubepier Web’s fixed egress IPs.
  2. Ask the client to allow only those IPs: authorized IP ranges on AKS, public access CIDRs on EKS, master authorized networks on GKE, the IP Access List on Atlas and the Service Bus, RabbitMQ and Redis firewalls.
  3. For services on a private network, use the Through the cluster route: access goes through a restricted relay inside one of the client’s clusters.

Expected result

One allowlist request, once, for the whole team. The client’s API stays closed to the rest of the internet.

Limits: The IPs are shared by all Kubepier Web customers: they are a network layer on top of credentials, not a replacement. A fully private cluster stays on desktop, over the VPN.

See also:Network and egress IPsConnect servicesWeb, phone or desktop: which to use

06 · Consultant or instructor

Recording a demo or a class without exposing the client

Where
Desktop
Plan
All plans, Free included

Situation

A consultant wants to record a video showing how they investigated a failure, or share the screen in a meeting with another client.

The pain

The screen shows client, cluster, namespace and IP names. Blurring frame by frame in editing takes hours, and one missed frame exposes the client.

What it costs: Hours of video editing and the risk of showing one client’s data to another.

How it works in Kubepier

  1. In Kubepier Desktop, click Presentation in the status bar.
  2. Client, cluster, namespace, node and IP names, and the audit Who column, are blurred in every window.
  3. Status, kinds and counts stay readable: the recording still shows what is failing.

Expected result

You record the screen with no post-production to hide names and no rehearsal of what cannot appear.

Limits: Terminals, open YAML, logs and values show as they are: check the screen before recording. Presentation mode is not on the web yet.

See also:Presentation modeWeb, phone or desktop: which to use

07 · Platform team

The team that left Lens and wants one tool for everyone

Where
Desktop and web
Plan
Free to start; Pro to act; Team for the team on the web

Situation

The team used Lens or OpenLens and is looking for an alternative. Each person has their own IDE and kubeconfigs, and those who install nothing (management, support) cannot see anything.

The pain

Every machine is an island: nothing on the phone, nothing for those without the kubeconfig and no per-client view.

What it costs: Onboarding time for every new person and requests like "send me a screenshot of the cluster".

How it works in Kubepier

  1. Install Kubepier Desktop on Windows, macOS or Linux. It is built on Freelens: workloads, logs, shell, Helm and port-forward are where you expect them.
  2. Sign in with the same account as the web. The organization plan applies to both.
  3. In Preferences › TR Clients, group clusters by client.
  4. For people who do not want to install anything, Kubepier Web opens in the browser, with the same catalog.

Expected result

Desktop fans stay on desktop; people who only need to look use the browser. Everyone on the same organization and plan.

Limits: If you look after a few clusters, all your own, Freelens serves you well and is open source.

See also:Lens alternativeKubepier vs FreelensInstall the desktop appWeb, phone or desktop: which to use

08 · Dev or SRE investigating a node

Getting into the node without SSH on the VMs

Where
Desktop; on the web, admins only
Plan
Pro and Team

Situation

A node has a full disk or the kubelet is acting up. The node pool VMs have no SSH access, and requesting it takes days.

The pain

The usual workaround is a hand-written privileged pod with hostPID and nsenter, which sometimes gets forgotten in the cluster.

What it costs: Hours before you can look at the node, and a privileged pod nobody remembers to delete.

How it works in Kubepier

  1. In Kubepier Desktop (Pro or Team), open the node and use the node shell.
  2. New on the web: a Pro or Team admin clicks Node shell and types the node name to confirm.
  3. Kubepier creates a temporary privileged pod in kube-system, pinned to the node, and deletes it when you close the terminal (on the web, after 2 hours at most).
  4. The audit log records who opened it, when, on which cluster and node and for how long, never what was typed.
  5. Coming soon: remote shell over Tailscale, through your tailnet, from your phone or laptop (beta with a waitlist).

Expected result

You look at the node in minutes, without SSH on the VMs, and the pod is gone when you finish.

Limits: Windows nodes: desktop only. AWS Fargate nodes do not accept privileged pods. Clusters that block privileged pods (Pod Security, Azure Policy, Kyverno, Gatekeeper) need an exception.

See also:Pod and node shellRemote shell over Tailscale (coming soon)Web, phone or desktop: which to use

Recognized your situation?

Connect your first cluster read-only and see your own case on your screen. No card and nothing installed in the cluster.

Start free — read-only, no card See pricing
Web, phone or desktop: which to use