> ## Documentation Index > Fetch the complete documentation index at: https://docs.coreweave.com/llms.txt > Use this file to discover all available pages before exploring further. # 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](/glossary) 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](/support/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 ```bash theme={"system"} # 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. ```bash theme={"system"} # 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 `` 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. ```bash theme={"system"} # 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](/products/networking/cilium-network-policy-cks-patterns) and [Deploy network policies](/security/tutorials/deploying-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: ```bash theme={"system"} # 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. | 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](/products/networking/ingress-service/expose-service-dns#choose-public-or-private-addressing) and [Get a publicly routable IP for your LoadBalancer Service](/support/networking/articles/how-do-i-get-a-publicly-routable-ip-for-my-loadbalancer-service). ## What this is not Consider the following points: * This isn't a DNS problem if your client connects successfully to a Service IP but fails on a Service name. For name resolution failures, see [Troubleshoot DNS resolution from a Pod](/support/networking/articles/why-is-dns-resolution-failing-from-my-pod). * `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. ## 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. Include the output of the preceding three checks, the exact error string, and the source and destination namespaces. For related symptoms, see [Troubleshoot networking](/support/networking). [Server Errors](/support/networking/tags/server-errors)