Connect to 14 Managed Kubernetes Providers Without Memorizing Their CLIs

Once you are connected, every managed Kubernetes cluster speaks the same API. The connection step is different for every vendor.

The per-vendor routine

Your tools talk to a cluster through a kubeconfig: a file holding the API endpoint, the CA certificate, and your credentials. Managed clusters do not hand you this file; you generate it with the vendor's CLI, and each vendor does it differently.

Done by hand, connecting to a single EKS cluster looks like this: install aws-cli, run aws configure sso and sign in through the browser, remember which region the cluster lives in, run aws eks list-clusters --region eu-west-1 to find its name, and finish with aws eks update-kubeconfig to write the file. For GKE the same steps go through gcloud, scoped by project and location instead of region. For AKS they go through az, scoped by subscription and resource group. None of it is hard, but none of it transfers between vendors.

The Cloud Providers extension folds this into one screen.

One table for fourteen clouds

Under Sources → Cloud Providers, Kunobi lists 14 managed Kubernetes providers:

• AWS EKS
• Google GKE
• Azure AKS
• DigitalOcean DOKS
• Exoscale SKS
• Nine NKE
• OVHcloud MKS
• Scaleway Kapsule
• Civo
• IBM Cloud IKS
• Linode LKE
• Oracle OKE
• UpCloud UKS
• Vultr VKE

Each row shows the CLI that provider needs, where the installed copy came from, and a live status.

The Status column carries the whole per-provider state: Not installed, Installing, Not authenticated, Auth failed, or Ready. Hovering over Ready shows the exact identity the CLI is signed in as. The by-hand equivalent is a different probe command per vendor (aws sts get-caller-identity, gcloud auth print-access-token), each with failure modes of its own to interpret.

The CLI is installed for you

Each provider row knows which binary it needs. If the CLI is missing, press i and Kunobi installs it through mise, the same tool manager it uses for binaries like kubectl and helm.

The row updates in place while the install runs, and uninstalling is equally one key. The Source column tells you whether the copy in use is Kunobi-managed or something already on your PATH. Kunobi never uninstalls a binary it does not own.

Expired sessions

Cloud CLI sessions expire by design, and the first sign is usually a command failing later with a vendor-specific error message. Here the row itself shows Auth failed before you have drilled anywhere.

Pressing a opens Kunobi's terminal with the provider's own login command already running: aws configure sso, gcloud auth login, az login. Authentication stays entirely inside the vendor's flow; it is the same command you would type yourself, just without having to remember which one this vendor uses. When the login command exits, Kunobi re-checks the session and the row flips to Ready.

Picking a cluster

Drilling into a ready provider walks that vendor's own hierarchy: Region then Cluster for AWS; Project, Location, Cluster for GKE; Subscription, Resource Group, Cluster for AKS. Every step is a plain list you can filter and move through, showing what actually exists in your account instead of asking you to recall which flag scopes the list command for this particular vendor.

The kubeconfig download

Selecting a cluster on the last step runs the vendor's own credentials command (aws eks update-kubeconfig, gcloud container clusters get-credentials, az aks get-credentials) and writes the kubeconfig into the directory you have configured. Kunobi remembers the destination, so the next download goes to the same place without asking.

Because the file lands in a directory Kunobi already watches, the new context appears alongside your other clusters immediately, and from there it behaves like any other source: connect, browse resources, open a shell.

Free, Pro, and coming soon

AWS EKS and Google GKE are available to every user. Six more (Azure AKS, DigitalOcean DOKS, Exoscale SKS, Nine NKE, OVHcloud MKS, and Scaleway Kapsule) are part of Pro.

License changes apply live: activating Pro unlocks the gated rows in place, without restarting the app. The remaining six (Civo, IBM Cloud, Linode/Akamai, Oracle, UpCloud, and Vultr) already ship in the list, marked Soon, so you can see where support is heading.

What it deliberately does not do

The extension connects to clusters that already exist; provisioning, cost, IAM, and node pool management are out of scope. Under the hood, every operation is the vendor's own CLI running on your machine with your credentials. Kunobi orchestrates the steps without reimplementing any cloud APIs.

Try it

Kunobi is free to download at kunobi.ninja. Open the Sources page, pick your cloud, and the cluster is just a few keystrokes away.