turingpi/CLAUDE.md

turingpi

Home k3s cluster on a Turing Pi (arm64 nodes), GitOps-managed by ArgoCD.

Deploying changes

• Apps are ArgoCD Applications in applications/*.yaml, pointing at an internal Gitea repo (gitea-http.gitea.svc.cluster.local), targetRevision: HEAD.
• The git remote is gitea (git@192.168.222.26:admin/turingpi.git); working branch is master.
• To deploy: commit and push to gitea/master. Apps have syncPolicy.automated with selfHeal: true, so direct kubectl patch/edit is reverted — changes must go through git.
• Argo polls Gitea every ~3 min. Force a sync with: kubectl -n argocd annotate application <name> argocd.argoproj.io/refresh=hard --overwrite
• Helm values: helm-values/<app>_values.yaml. Custom charts: custom_helm_charts/<app>/.

Gotchas

qbittorrent + gluetun (AirVPN) — DNS / restart loop

AirVPN blocks outbound DNS-over-TLS (tcp/853) to force its own resolver. Gluetun's default DOT=on resolver (127.0.0.1) therefore never gets answers, all DNS fails, and the VPN startup healthcheck (lookup cloudflare.com) times out — gluetun restarts the VPN every ~6s in a permanent loop. The pod still shows 2/2 Running with 0 restarts, so it looks healthy while having no usable network.

The gluetun sidecar in helm-values/qbittorrent_values.yaml must keep:

- name: DOT
  value: "off"
- name: DNS_ADDRESS
  value: "10.128.0.1"   # AirVPN's pushed resolver, reached over the tunnel — no DNS leak

Diagnose: gluetun logs repeat restarting VPN ... lookup ... i/o timeout. Confirm with ping 8.8.8.8 (works) and nslookup x 10.128.0.1 (works) but curl 1.1.1.1:853 (times out).

Note: the 7e0a38d "pin gluetun to v3.41.1" commit message falsely claimed v3.41.1 fixed this DNS timeout. It did not — don't trust that claim.