> ## Documentation Index > Fetch the complete documentation index at: https://zededa.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. > ## Agent Instructions > Use the documentation index to find relevant pages, then read the linked Markdown before answering and cite the source URL. > Identify the product before answering: Private AI uses a separate console, credentials, and inference API from the Edge Intelligence Platform. Do not apply instructions from one product to the other. > Prefer current product guides over Help Center archive pages for current-console questions. Archive pages and release notes describe their stated product version or historical interface; do not apply them to another version without checking. > Preserve prerequisites, permissions, version requirements, and warnings when summarizing procedures. Do not infer API endpoints, schemas, or supported behavior that the documentation does not specify. # Troubleshoot Edge Kubernetes > Diagnose and resolve issues with ZEDEDA Edge Kubernetes Service clusters using kubectl, the Cluster Shell, EdgeView, and SSH. This article covers diagnostic techniques for ZEDEDA Edge Kubernetes Service clusters. Use the Cluster Shell for quick in-browser access, or connect directly using a downloaded kubeconfig, EdgeView, or SSH for deeper troubleshooting. ## Access the Cluster Shell The Cluster Shell provides an in-browser `kubectl` session connected directly to your cluster. No local tooling is required. To open the Cluster Shell: 1. Navigate to the cluster detail page. 2. Select **Cluster Shell** in the page header. A terminal session opens in the browser. You can run `kubectl` commands immediately. ## Common kubectl Diagnostics ### Check node status Verify that all nodes are registered and in the `Ready` state: ``` kubectl get nodes kubectl get nodes -o wide ``` The `-o wide` flag shows additional columns including the node's IP address and the operating system image. ### List all pods List pods across all namespaces to identify failed or pending workloads: ``` kubectl get pods -A kubectl get pods -o wide ``` ### Describe a pod Get detailed information about a specific pod including events, resource requests, and container state: ``` kubectl describe pod -n ``` Replace `` and `` with the target values from the pod list. ### View pod logs Stream live logs from a running container: ``` kubectl logs -n -f ``` The `-f` flag follows the log stream. Omit it to retrieve existing log output only. ### View fleet agent logs (GitOps troubleshooting) The GitOps fleet agent in ZEDEDA Edge Kubernetes Service runs in the `zks-fleet-system` namespace, not in the default Rancher Fleet namespace. To view agent logs: ``` kubectl logs -l app=fleet-agent -n zks-fleet-system -f ``` These logs show repository polling activity, bundle application results, and any errors reported by the fleet agent. ### Collect full diagnostics For comprehensive diagnostic output from a node, run the `collect-info.sh` script directly on the node. Run it on each node where issues are observed. Share the output when contacting ZEDEDA support. ## Access a Cluster Without the Cluster Shell ### Download kubeconfig To use `kubectl` from your local workstation: 1. On the cluster detail page, open the header action dropdown. 2. Select **Download Kubeconfig**. 3. Save the file to your workstation. Use the downloaded file with any `kubectl` command: ``` kubectl --kubeconfig=/path/to/kube-config.yaml get nodes ``` ### Access via EdgeView Use the EdgeView TCP tunnel to retrieve the kubeconfig without navigating the Edge Infrastructure Services interface: ``` ./run.edge_node.edgeview.sh tcp/kube ``` The kubeconfig file downloads to `/tmp/download/kube-config.yaml`. Use it with `kubectl` as shown in the previous section. ### Access via SSH To open a shell directly on the cluster from an SSH session to the node, run: ``` eve enter kube ``` This drops you into a shell with cluster access on the node. ## Common Pod Status Reference | Status | Meaning | | - | - | | Pending | The pod has been accepted by the cluster but is not yet running. It might be waiting for resources, image pulls, or node scheduling. | | Running | The pod is bound to a node and all containers have started. | | Succeeded | All containers in the pod have terminated successfully and will not restart. | | Error | At least one container exited with a non-zero exit code. | | CrashLoopBackOff | A container is repeatedly crashing and Kubernetes is backing off restarts. Check logs with `kubectl logs`. | | Terminating | The pod is in the process of being deleted. | | Unknown | The pod state cannot be determined, usually because the node is unreachable. | ## Common Cluster Status Reference The following states appear during cluster provisioning and initialization: | State | Meaning | | - | - | | Created | The cluster record has been created in Edge Infrastructure Services. | | Initializing | The cluster is starting up and preparing the control plane. | | Control Plane | The control plane components are being deployed. | | Control Plane Ready | The control plane is running and healthy. | | Joining Nodes | Worker nodes are being registered with the control plane. | | Online | All nodes are registered and the cluster is ready for workloads. | ## Next Steps > [card] [Create and Manage a Kubernetes Cluster](https://zededa.mintlify.site/new-ui/infrastructure-services/edge-kubernetes/create-and-manage-a-kubernetes-cluster.md) > > Provision and configure ZEDEDA Edge Kubernetes Service clusters. > [card] [Create GitOps Repositories](https://zededa.mintlify.site/new-ui/infrastructure-services/edge-kubernetes/create-gitops-repositories.md) > > Set up automated app delivery from a Git repository. > [card] [VNC for EVE-k Apps](https://zededa.mintlify.site/new-ui/infrastructure-services/edge-kubernetes/vnc-for-eve-k-apps.md) > > Access VM consoles on EVE-k clusters using VNC and virtctl.