hostNetwork: true can change the Node’s firewall rules. These changes can disrupt access to CoreWeave Kubernetes Service (CKS) internal services. They can remain after the Pod stops, leaving one or more affected Nodes NotReady.
Tailscale’s carrier-grade network address translation (CGNAT) drop rule matches traffic from 100.64.0.0/10 arriving outside the Tailscale interface. CKS uses 100.124.0.0/18 within that range for internal services. When a privileged Tailscale workload installs this rule in the host network namespace, the impact can extend beyond its own Pod.
The operator setup in the CoreWeave chart guide doesn’t enable host networking. For proxy failures in that setup, see Tailscale proxy Pods in CrashLoopBackOff.
Recover affected Nodes
If Nodes becomeNotReady after you deploy a self-managed Tailscale workload, follow these steps:
- Inspect the affected workload’s Pod specification for
hostNetwork: true. - If host networking is enabled, stop the controller or workload that created the Pod. Update its deployment configuration to prevent the Pod from being recreated. If you delete only the Pod, its controller can recreate it.
- If affected Nodes remain unhealthy, contact Support with their names and the Tailscale workload configuration. Host firewall changes can persist after the workload stops, and recovery may require a support-coordinated reboot.
Ready:
Nodes