The Kubernetes screen works with standard Kubernetes clusters directly. It is separate from servers and Compose deployments: you do not need an agent on the cluster.
Connect a cluster
Click Add cluster → Connect existing cluster, give it a name and paste a kubeconfig. PS-pocketEdge checks the credentials work before saving and stores the kubeconfig encrypted.
Create a local cluster
Add cluster → Create local cluster creates a kind cluster on the control plane machine, which needs kind and a running Docker Engine. It can take several minutes. Delete local cluster removes it and everything running in it; Disconnect on an external cluster only removes the saved connection and leaves its workloads running.
Explore a cluster
Open a cluster to see its nodes and their capacity and usage, deployments, pods and events, for one namespace or all of them. View logs shows a pod's most recent 200 lines. Large clusters show the first 500 objects of each kind.
Deploy a workload
Click Deploy workload and enter the namespace, name, image, replica count, CPU and memory (for example 500m and 1Gi), and optionally a GPU. Before applying, PS-pocketEdge estimates where the replicas would be placed, checks namespace quotas, and has Kubernetes validate the change in dry-run mode. Kubernetes still makes the final scheduling decision.
Deployments created by PS-pocketEdge can be updated, rolled back to an earlier revision Kubernetes still keeps, or deleted. Deleting removes its pods; separately created storage is kept.
Permissions the cluster credential needs
To view a cluster, the credential needs get and list on namespaces, nodes, pods, events, deployments and replica sets, list on resource quotas, and get on pod logs. To deploy workloads it also needs create, update and delete on deployments. A read-only credential works for viewing only.
Example: preview a small web workload
On a connected test cluster, choose Deploy workload with namespace default, name demo-web, image nginx:alpine, 1 replica, CPU 250m and memory 256Mi. Review the placement estimate and dry-run checks, then apply. Confirm its pod is running and read its logs. This workflow creates a deployment; it does not automatically publish an external URL for the web server.