mirrors/pikasTech-HWLAB
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fix: enforce D601 native k3s guards

Browse Source
This commit is contained in:
root
2026-05-23 12:56:17 +00:00
parent 6a83de219f
commit f2984016f3
13 changed files with 195 additions and 33 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/reference/dev-runtime-boundary.md
+20 -1
View File
@@ -43,7 +43,26 @@ KUBECONFIG=/etc/rancher/k3s/k3s.yaml kubectl -n hwlab-dev get deploy,svc,pod -o
```
Do not trust the default `kubectl` context as a DEV runtime signal. On D601 it
may point at another cluster such as `docker-desktop`.
may point at another cluster such as `docker-desktop`. The 2026-05-23 control
plane incident is tracked in
[pikasTech/unidesk#138](https://github.com/pikasTech/unidesk/issues/138), with
hotfix context in
[pikasTech/unidesk#118](https://github.com/pikasTech/unidesk/issues/118):
Docker Desktop Kubernetes has been disabled and cleaned, but the default
`/home/ubuntu/.kube/config` may still point at the dead
`docker-desktop`/`127.0.0.1:11700` entry. Treat that as residual bad config, not
as DEV runtime evidence.
Before any DEV deploy, rollback, smoke, or manual k3s observation, confirm the
native node explicitly:
```sh
KUBECONFIG=/etc/rancher/k3s/k3s.yaml kubectl get nodes -o jsonpath='{.items[*].metadata.name}'
```
The result must contain `d601`. Seeing `desktop-control-plane`,
`docker-desktop`, or `127.0.0.1:11700` means the command is on the wrong
control-plane path and must stop before mutation or acceptance.
Use the read-only preflight when a runner needs to report k3s visibility: