fix: bridge docker k3s adapter to WSL API

2026-05-16 14:15:14 +00:00
parent fa5f0fa4d0
commit 5c5564aba5
6 changed files with 107 additions and 6 deletions
@@ -62,7 +62,7 @@
    - k3s Control Bridge Boundary
      - `k3sctl-adapter` is part of the UniDesk control plane, not a workload controlled by k3s. It must remain `deployment.mode=unidesk-direct` or an equivalent UniDesk-managed host service, and must not be converted to `k3sctl-managed`.
      - The adapter exists so UniDesk can inspect, deploy, and repair k3s-managed user services. Putting that bridge inside the k3s cluster would invert the dependency order: repairing or diagnosing k3s would first require the in-cluster adapter and service network to be healthy.
-      - On native k3s nodes, the adapter must read the host kubeconfig and connect to the host-local Kubernetes API endpoint, normally `/etc/rancher/k3s/k3s.yaml` and `https://127.0.0.1:6443`. If it is packaged as Docker, it must use a host-network or equivalent host-local topology; a future systemd service is also valid.
+      - On native k3s nodes, the adapter must read the host kubeconfig and connect to the host-local Kubernetes API endpoint, normally `/etc/rancher/k3s/k3s.yaml` and `https://127.0.0.1:6443`. If it is packaged as Docker on a Docker Desktop/WSL node, it must create an explicit host-local bridge such as an SSH local tunnel from the adapter container to the WSL host k3s API; a future systemd service is also valid.
      - k3s-managed business services such as Code Queue and MDTODO still enter through the adapter's Kubernetes API service proxy. The adapter itself is deliberately outside that managed workload graph so CNI, Service, EndpointSlice, or kube-proxy failures do not remove UniDesk's control path.
    - Connection Management
      - When registering, a node carries an authentication token to verify its identity and declares resources such as GPU/CPU