SYS.DOCS // DOCS

Cluster Explorer

Use Explorer inside a cluster when you need Kubernetes-level visibility without leaving Edka.

Path: Clusters -> your cluster -> Explorer

Explorer reads live Kubernetes resources from the selected cluster and groups them into operational views for workloads, networking, certificates, storage, configuration, External Secrets, access, Helm, namespaces, and nodes.

What Explorer shows

Explorer includes:

resource lists with namespace, health, search, and sort controls
detail panels with overview, containers, resources, pods, related resources, events, logs, exec, values, and YAML tabs where available
Helm releases and Helm chart resources
node inventory with cordon and drain state, taints, node conditions, events, resource usage, pod placement, and related workloads

Supported resources include pods, deployments, replica sets, stateful sets, daemon sets, jobs, cron jobs, services, endpoints, network policies, ingresses, Gateway API resources, cert-manager resources, PVCs, PVs, storage classes, ConfigMaps, Secrets, External Secrets resources, service accounts, RBAC resources, namespaces, nodes, Helm releases, and Helm charts. External Secrets covers ExternalSecret, SecretStore, ClusterSecretStore, ClusterExternalSecret and PushSecret resources with their sync or connection state.

Diagnose a pod

Pod status in Explorer matches the STATUS column of kubectl get pods, for example CrashLoopBackOff, ImagePullBackOff, Init:1/2, Terminating, Evicted, or OOMKilled.

When a pod is unhealthy, its Overview tab starts with a Diagnosis list. It covers:

a container waiting in a state such as CrashLoopBackOff, ImagePullBackOff, or CreateContainerConfigError, with the kubelet’s message
the last time a container exited, with the reason and exit code, for example OOMKilled (exit 137), and the restart count
a pod the scheduler could not place, with its message, for example 0/3 nodes are available: 3 Insufficient memory.
an evicted pod, with the eviction message
a failed init container
a running container that is not ready, with its readiness probe
how long a pod has been terminating

Under it, Recent warnings lists the latest warning events for the pod. The Overview tab also shows the pod’s node selector, tolerations, and priority class.

The Containers tab lists the regular, init, and debug containers with their current state, last termination, and restart count. Expand a container to see its state message, image, ports, liveness, readiness, and startup probes, and requests and limits. Containers that are failing open expanded.

Diagnose a workload, Service, or PVC

Deployments, stateful sets, daemon sets, replica sets, Services, and PVCs get the same Diagnosis list when something is wrong.

For a workload, it covers:

a rollout that passed its progress deadline (ProgressDeadlineExceeded)
pods the workload cannot create, for example because of a resource quota, with the message
replicas that are not ready, listing each pod with its status, for example web-7c9d-x2k4: CrashLoopBackOff
pods the scheduler could not place, with its message
a paused rollout, a rollout in progress with how many replicas are updated, and a stateful set rollout held at its partition

For a Service, it covers:

a selector that matches no running pod. When pods match every label but one, the list names that label and the value the pods have.
selected pods that are not ready, which receive no connections, unless the Service sets publishNotReadyAddresses
a named targetPort that some or all selected pods do not declare
a LoadBalancer Service with no address after five minutes

For a PVC, it covers:

a claim with no storage class, or with a storage class that does not exist
a WaitForFirstConsumer claim waiting for a pod, or whose pod cannot be scheduled, with the scheduler’s message
a claim that is still not bound after two minutes
a Lost claim whose volume no longer exists
a resize that waits for the pod to restart

Open the Events tab for the provisioner’s or controller’s messages.

The resource lists use the same checks. A Service with no ready pods shows NoEndpoints, a stuck rollout shows Degraded, and the row names the problem. Issues narrows a list to these resources. A WaitForFirstConsumer claim that no pod uses yet shows Waiting and does not count as an issue.

Events

The Events tab lists the Kubernetes events recorded for the resource, newest first, with the reason, message, repeat count, and when each was last seen. The tab count turns red when there are warnings, and Warnings filters the list to them.

For deployments, stateful sets, daemon sets, replica sets, jobs, and cron jobs, the tab also includes the events of the replica sets, jobs, and pods they own. Scheduling failures and FailedCreate errors are recorded on those objects, not on the workload. Each of these events names the object it belongs to and links to it.

Kubernetes keeps events for one hour by default, so a healthy resource often has none. Resources that never record events, such as ConfigMaps, Secrets, and RBAC objects, have no Events tab. For warning events across the whole cluster, use Cluster Diagnostics.

Logs and manifests

For pods and pod-backed resources, Explorer can show recent container logs directly in the detail panel.

The YAML (manifest) tab shows the live Kubernetes manifest for the selected resource. Use this when comparing what Edka configured with what is currently running in the cluster.

Workload resources

The Resources tab on a pod, deployment, stateful set, daemon set, replica set, job, or cron job shows CPU and memory usage over the last 7 days for the whole workload, next to each container’s requests and limits and the values Edka advises. Copy YAML copies the advised resources block. It needs VictoriaMetrics. For every workload in one table, see Workload Resources.

ConfigMap and Secret values

Explorer can show ConfigMap values and Secret keys for supported resources. Secret values remain protected; sensitive reads require the same recent identity verification used by the Secrets workspace.

Use Secrets Management when you need to create, update, or delete Edka-managed user secrets.

Pod exec and debug containers

For pod troubleshooting, Explorer includes an exec workflow. When a target container does not have a useful shell, Edka can attach an ephemeral debug container from its debug toolbox image and then open a terminal session.

Use this for interactive inspection after checking the higher-level health, events, and logs. Debug sessions run inside the target cluster and should be treated like direct cluster access.

Nodes

The Cluster tab lists the nodes grouped by pool, with CPU, memory, and root disk usage for each. Issues narrows the list to nodes that are not ready, under pressure, at 85% or more CPU, memory, or disk usage, or cordoned.

A cordoned node shows its state in the list and in the node header, and the summary strip counts cordoned nodes next to Ready:

cordoned means the scheduler places no new pods on the node, and pods other than DaemonSet and static pods still run on it.
draining means some of those pods are terminating.
drained means only DaemonSet and static pods remain.

The node’s Overview tab shows the same state and lists the node’s taints.

The Failover figure in the summary strip shows the worst case across nodes: how many pods would stay Pending if that node went down, because no other ready, schedulable node has room for them. When every pod fits elsewhere but a node runs pods without a controller, it shows how many of those would not start again. It reads OK when neither applies. Select it to open that node. Each node’s Overview tab has a Failover line with the same check for that node, counting only the pods that would move, so DaemonSet pods are left out. Its Show toggle lists the pods that would stay Pending and why. The check uses the same rules as the drain dialog.

The other node tabs:

Usage shows the CPU and memory of the node’s pods over the last 7 days and ranks the pods and containers that use the most. It needs VictoriaMetrics.
Pods and Workloads list what runs on the node.
Conditions lists every condition the node reports, including ones added by node-problem-detector, with the message, when it last changed, and the last heartbeat.
Events lists node events such as NodeNotReady, Rebooted, and EvictionThresholdMet.
Metadata shows capacity, host, network, and filesystem details.

Cordon, uncordon, and drain

The node header has Cordon (or Uncordon on a cordoned node) and Drain. All three need cluster write access and a recent identity verification.

Cordon stops the scheduler from placing new pods on the node. Pods already running on it stay.
Uncordon lets the scheduler place pods on the node again.
Drain cordons the node and evicts its pods, except DaemonSet and static pods. Before you confirm, it lists the pods it will evict and flags pods without a controller, which are not recreated, pods whose emptyDir data is deleted, and pods a PodDisruptionBudget protects.

The drain dialog also checks whether the pods that start again elsewhere fit on the other ready, schedulable nodes. It takes their CPU and memory requests, node selectors and required node affinity, taints, volumes that only attach to certain nodes, required anti-affinity, and the node pod limit into account. Pods that fit nowhere are listed first with the reason, for example a local-path volume stored on the node being drained, and would stay Pending until a node with room joins. Preferred scheduling rules and topology spread constraints are not part of the check.

Evictions honor PodDisruptionBudgets, the same as kubectl drain. A pod whose budget allows no disruption right now stays on the node, and the result names it. Run Drain again once the budget allows it. Evicted pods terminate on their own schedule, so the node shows draining until they are gone and then drained.

For cluster-wide health, warning events, volume usage, and K3s signals, use Cluster Diagnostics.

Access

Explorer requires cluster read access. Actions that mutate resources or open interactive sessions require the corresponding cluster permission and may be blocked on archived clusters.