fix: open Flannel/K3s ports in gpu-node's UFW rules
Some checks failed
validate / lint (push) Failing after 1s
Some checks failed
validate / lint (push) Failing after 1s
host_vars/gpu-node.yaml's ufw_allowed_ports has overridden (not extended) the common role's default list since the node was added, silently dropping the Flannel VXLAN (8472/udp), K3s API (6443/tcp), and Kubelet (10250/tcp) rules every other node gets. Went unnoticed because kubectl logs/exec/stats tunnel through the agent's outbound connection to the k3s server rather than needing a direct inbound path - but real pod dataplane traffic (e.g. tts-gateway on nik-gpu resolving DNS against CoreDNS on nik-debian) needs actual VXLAN connectivity and was blackholing. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
parent
f2261a2676
commit
69d880186a
@ -20,6 +20,15 @@ ufw_allowed_ports:
|
||||
- { port: "430", proto: tcp, comment: "SSH" }
|
||||
- { port: "11434", proto: tcp, comment: "Ollama API" }
|
||||
- { port: "61208", proto: tcp, comment: "Glances web UI" }
|
||||
# host_vars replaces (not merges) the common role's ufw_allowed_ports
|
||||
# default, so the K3s/flannel ports below must be repeated here - without
|
||||
# them, cross-node pod traffic (e.g. DNS to CoreDNS on nik-debian) blackholes
|
||||
# even though kubectl logs/exec/stats still work (those tunnel through the
|
||||
# agent's outbound connection to the k3s server on 6443, not a direct
|
||||
# inbound connection).
|
||||
- { port: "6443", proto: tcp, comment: "K3s API server" }
|
||||
- { port: "10250", proto: tcp, comment: "Kubelet" }
|
||||
- { port: "8472", proto: udp, comment: "Flannel VXLAN" }
|
||||
|
||||
data_dirs:
|
||||
- /data/tts-gateway
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user