Why can't my Pod reach a Service on CKS?

A Pod usually can’t reach a Service on CoreWeave Kubernetes Service (CKS) for one of four reasons: the Service has no Ready backends, a NetworkPolicy silently drops the traffic, the client uses the wrong address or port, or a Node-level routing problem breaks the path. Start with the error string: connection refused points at the Service and its Endpoints, while connection timed out points at a NetworkPolicy or a wrong target. CKS uses Cilium as its container network interface (CNI), and Cilium replaces kube-proxy for in-cluster Service load balancing. You configure Services, Endpoints, and NetworkPolicy. CoreWeave manages the underlying data plane.

What you see

Most pod-to-service failures surface as one of four errors when a client Pod attempts to connect to a Service. The error string indicates which layer to check first.

Error string	What it usually means
`connection refused`	The destination is reachable but actively rejects the connection. On CKS this most often means the Service has no Ready backends, so the data plane returns a REJECT.
`connection timed out` / `i/o timeout`	Packets are dropped silently before a reply returns. This is the signature of a `NetworkPolicy` blocking the traffic, or a wrong address or port.
`no route to host`	A routing or Node-level network problem. The client can’t find a path to the destination address at all.
`Insufficient` or `0/N nodes are available` (at schedule time)	Not a connectivity error. The Pod never started, so it has no network yet. Resolve the scheduling problem first, then return to this page once the Pod is Running. For the symptom index, see Troubleshoot networking.

The most useful single discriminator: connection refused means a reachable host said no, while connection timed out means the packets vanished. Refused points at the Service and its backends. Timed out points at a NetworkPolicy or a wrong target.

First three checks

Run these read-only checks in order. They resolve most pod-to-service tickets.

1. Confirm the client Pod has an IP and is Running

Replace [POD-NAME] and [NAMESPACE] with the client Pod and its namespace, and [SERVICE-NAME] with the target Service, throughout this page:

# Confirm the source Pod is scheduled, Running, and has a Pod IP.
# Safe to run anytime; read-only.
kubectl get pod [POD-NAME] -n [NAMESPACE] -o wide

A Pod with no IP, or stuck in Pending or ContainerCreating, hasn’t joined the network yet. Resolve the scheduling or startup problem before testing connectivity.

2. Confirm the target Service has Endpoints

An empty Endpoints list is the single most common cause of connection refused. When a ClusterIP Service has no Ready backend Pods, the CKS data plane issues a REJECT, which surfaces to the client as connection refused, not a timeout.

# List the Endpoints (backend Pod IPs) behind a Service.
# An empty result means no Ready Pods match the Service selector.
# Safe to run anytime; read-only.
kubectl get endpoints [SERVICE-NAME] -n [NAMESPACE]

If the output shows <none> or an empty endpoints set, check two things:

Are the backend Pods Ready? A failing readiness probe removes a Pod from Endpoints. Run kubectl get pods -n [NAMESPACE] -l [SELECTOR] and confirm the READY column shows all containers ready.
Does the Service selector match the Pod labels? A typo in spec.selector produces a Service with zero Endpoints. Compare kubectl get svc [SERVICE-NAME] -n [NAMESPACE] -o jsonpath='{.spec.selector}' against the Pod labels.

3. Check for a NetworkPolicy in the namespace

A connection timed out between Pods that should be allowed to communicate usually means a NetworkPolicy (or CiliumNetworkPolicy) drops the traffic.

# List NetworkPolicies and CiliumNetworkPolicies in the namespace.
# Safe to run anytime; read-only.
kubectl get networkpolicy,ciliumnetworkpolicy -n [NAMESPACE]

If a default-deny policy is in place, confirm it explicitly allows the traffic you expect. Almost every default-deny policy on CKS must allow egress to the platform services range 100.124.0.0/18 (Kubernetes API and platform services) and DNS egress to node-local-dns rather than kube-dns. Both are common causes of a connection timed out to a Service that should be reachable. For the exact rules and a full default-deny example, see Cilium network policy on CKS and Deploy network policies.

It works in-cluster but not externally

If a curl from inside the cluster succeeds but an external client fails, the problem isn’t your Service or its backends. Use this discriminator, replacing [SERVICE-IP] and [PORT] with the Service’s ClusterIP and port:

# From inside the cluster: exec into any Pod and curl the Service.
# Read-only test.
kubectl exec [POD-NAME] -n [NAMESPACE] -- curl -sS -m 5 http://[SERVICE-IP]:[PORT]

Then curl http://[LOADBALANCER-IP]:[PORT] from your laptop, replacing [LOADBALANCER-IP] with the Service’s external IP.

In-cluster	External	Diagnosis
Fails	Fails	Application or Service problem. Re-run the first three checks.
Works	Fails	External reachability problem. Confirm the Service requested a public IP. If the public IP is still unreachable, open a ticket. This isn’t a customer-side fix.
Fails	Works	Unusual. Most often an `Endpoints` or selector mismatch on the internal path.

A LoadBalancer Service receives an internet-facing IP only when you request public addressing. Without it, the Service receives a private address reachable only from inside the cluster or a connected VPC. See Choose public or private addressing and Get a publicly routable IP for your LoadBalancer Service.

What this is not

Consider the following points:

If your client connects successfully to a Service IP but fails on its name, check DNS resolution from the Pod. If the name resolves to the expected IP but the connection still fails, continue troubleshooting Service connectivity.
connection refused isn’t a firewall block. Firewalls and NetworkPolicy drops produce timeouts, not refusals. A refusal means a reachable host rejected the connection, most often an empty Endpoints set.
You don’t need to inspect or tune the CNI data plane. See What CoreWeave manages.

When to open a ticket

Open a support ticket in any of these situations:

An in-cluster curl to the Service IP works but the external client still can’t reach a public LoadBalancer IP after you confirmed the public annotation.
You see intermittent connection refused to an internal LoadBalancer virtual IP that you can’t tie to an empty Endpoints set.
Connectivity fails with no route to host for traffic that has no NetworkPolicy in the path.

Alongside the details every ticket needs, listed in Support ticket templates, include the output of the preceding three checks, the exact error string, and the source and destination namespaces. For related symptoms, see Troubleshoot networking, or use Error message lookup to match an exact message. Server Errors

Infrastructure Support

Forge Support

Support resources

Why can't my Pod reach a Service on CKS?

What you see

First three checks

1. Confirm the client Pod has an IP and is Running

2. Confirm the target Service has Endpoints

3. Check for a NetworkPolicy in the namespace

It works in-cluster but not externally

What this is not

When to open a ticket

​What you see

​First three checks

​1. Confirm the client Pod has an IP and is Running

​2. Confirm the target Service has Endpoints

​3. Check for a NetworkPolicy in the namespace

​It works in-cluster but not externally

​What this is not

​When to open a ticket

What you see

First three checks

1. Confirm the client Pod has an IP and is Running

2. Confirm the target Service has Endpoints

3. Check for a NetworkPolicy in the namespace

It works in-cluster but not externally

What this is not

When to open a ticket