Overview

Native Kubernetes support in Dockerman — workloads, networking, config, storage, RBAC, CRDs, Helm, and debug.

Dockerman's Kubernetes section runs and inspects a real cluster in the same desktop app you use for Docker.

Why Kubernetes in Dockerman

Use Dockerman when you want Kubernetes next to Docker in one app. It includes k3d for one-click local cluster setup, keeps the active Kubernetes cluster separate from the active Docker host, and targets local development, small clusters, and CI sanity checks. It is lighter than Docker Desktop's built-in Kubernetes path.

What's included

Cluster

Start local k3d clusters, import existing kubeconfigs, and switch between clusters independently from your Docker hosts.

Workloads

Browse Pods, Deployments, StatefulSets, DaemonSets, Jobs, CronJobs, and ReplicaSets.

Networking

Inspect Services, Ingresses, Endpoints, and NetworkPolicies.

Config & Storage

Work with ConfigMaps, Secrets, PVCs, PersistentVolumes, StorageClasses, and Namespaces.

RBAC

See who can do what across accounts, roles, and bindings.

Helm

Manage repositories and Helm releases from the GUI.

Port Forward & DNS

Forward ports and register automatic local DNS entries.

Debug Assistant

Forward an existing process's debug port and generate an editor attach configuration.

Custom Resources

List CRDs and browse or edit their instances as YAML.

Events

Browse cluster events with filters by type, reason, object, and namespace.

Cluster overview dashboard

Open the Kubernetes overview to see a live summary of the cluster.

CPU and memory cards — cluster usage as headline cards. Requires metrics-server in the target cluster.
Workload counts — running and pending Pods, Deployments, Services, and other resources counted across all namespaces, not just the active one.
Node status — node count and ready state.
Recent events — the most recent cluster events, with a link to the full Events browser.

Multi-cluster switching

Dockerman tracks the active Kubernetes cluster independently of the active Docker host. Switching clusters keeps your current K8s page where possible, restores deep pages (CRD instances, YAML editor) after an app restart, and refreshes the namespace selector to match the new cluster. Reconnecting to a cluster after a restart restores the last visited resource.

Two ways to start

Open Cluster and use the Start a local cluster with k3d flow when you want a disposable local cluster for development or testing.

Open Cluster and use the Import an existing cluster flow when you already have a kubeconfig for kind, minikube, EKS, GKE, AKS, or on-prem.

Namespaces

Use the namespace switcher in the top bar to scope every Kubernetes list. Switching namespaces does not disconnect from the cluster; workloads, networking, config, and RBAC lists update to the new namespace.

The Kubernetes sidebar has seven groups: Cluster, Workloads, Service & Network, Config & Storage, Access Control, Helm, and Tools.

Per-group default expand state — pick which groups open automatically when you connect to a cluster, decoupled from runtime collapse state.
Per-item visibility — hide individual resource entries you never use; runtime expand/collapse picks up where you left it next session.

Edit both from Settings → Sidebar.

Permission errors

Lists return typed K8sListResult<T> so a 403 Forbidden appears on that list instead of failing the whole page. You see which resource your context cannot access and can keep using the rest of the cluster while you fix RBAC.

What's not yet supported

These workflows are not in scope yet:

Cluster creation outside k3d, such as kubeadm or managed-service provisioning.
Gateway API beyond Ingress.
Visual CRD editors — use YAML editing instead.
Visual NetworkPolicy editor — author with YAML.