Paste a Service and the workload it is meant to reach, and find out whether it will actually have endpoints. A Service that selects nothing is accepted, reports healthy, and refuses every connection, with no warning anywhere.
Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.
The answer appears here
Paste on the left and press Check wiring. Nothing leaves this tab.
Nothing else to flag.
No formatting problems, and nothing the rules object to. Worth remembering what that covers: this reads the file you pasted, not the account or cluster it will be applied to.
No finding matches that filter.
Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.
The commonest reason a Service returns connection refused with nothing in the logs
apiVersion: v1
kind: Service
metadata:
name: api
spec:
selector:
app: api
ports:
- port: 80
targetPort: 8080
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: api
spec:
template:
metadata:
labels:
app: webSelector and pod labels agreeing, which is what the failing case should look like
apiVersion: v1
kind: Service
metadata:
name: api
spec:
selector:
app: api
ports:
- port: 80
targetPort: 8080
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: api
spec:
template:
metadata:
labels:
app: apiThese are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
A Service with no matching pods resolves fine and refuses connections. The symptom looks like networking and the cause is a label typo.
Instead:kubectl get endpoints <service> first. Empty means the selector matched nothing.
Only pods passing their readiness probe are added to endpoints. A failing probe removes the pod silently, which looks like intermittent failure.
Instead:Check readiness before checking anything else in the network path.
clusterIP: None gives DNS records per pod and no load balancing or virtual IP. Set unintentionally, clients connect to one pod forever.
Instead:Leave clusterIP unset unless you specifically want per-pod DNS.
All of it is determinable from the manifests, which is why it is worth knowing before you apply rather than after the pager goes off.
A Service selects pods, and pod labels live at spec.template.metadata.labels. A Deployment also has its own metadata.labels, and the two are usually written to look identical. Copy the wrong one and you get a Service with no endpoints, no error from kubectl, and a connection refused that looks like the application is down. This is reported by name, not as a generic no-match.
A selector is an exact AND across every key, so one wrong value is the same as no match at all. When a workload satisfies three of four labels, the report says which key differs, what the pod has, and what the selector wanted.
A numeric targetPort is informational and works whether or not a container declared it. A named one is resolved by the kubelet against the containers' port names, so a name nothing declares means the endpoint is never created. The two are treated differently because Kubernetes treats them differently.
A Service never selects pods in another namespace. If the only match is elsewhere, the report says so rather than reporting nothing. It also flags a selector matching two workloads at once, which is right for a blue/green cutover and a surprise the rest of the time.
There is no link between a Service and a Deployment. They never reference each other, and nothing validates that they agree. The only connection is that both mention the same labels, and if they stop agreeing, the two objects carry on existing happily while no traffic flows between them.
A Deployment manifest contains labels in three places and they do different jobs. The Service selector matches the third one, the pod template. Copying from the first is the classic failure, and because the blocks are usually written with the same values, everything looks correct in review.
kind: Deployment
metadata:
labels: <- the Deployment's own labels. Not this one.
app: api
spec:
selector:
matchLabels: <- how the Deployment finds its ReplicaSet. Not this one.
app: api
template:
metadata:
labels: <- the POD labels. A Service matches THIS.
app: apiEvery key in the selector must be present on the pod with exactly that value. There is no partial match and no ordering, and unlike a Deployment's own selector there are no matchExpressions: a Service selector is equality-only. So adding one key to a selector without adding it to the pod template silently disconnects the Service.
selector: pod labels: result
app: api app: api match
tier: web tier: web
app: api app: api no match
tier: web tier: backend (tier differs)
app: api app: api no match
version: v2 (version absent)Nothing. The Service is created, gets a ClusterIP, resolves in DNS, and appears in kubectl get svc looking exactly like a working one. It simply has no endpoints, so every connection to it is refused immediately. There is no warning at apply time and no event, which is why this is worth checking from the manifests rather than after deploying.
kubectl get endpoints api
NAME ENDPOINTS AGE
api <none> 4m
that <none> is the whole diagnosis, and nothing else shows itport is what the Service listens on. targetPort is the port on the pod it forwards to, and defaults to the same value as port when omitted, which is a common source of surprise. containerPort is only documentation: a container can listen on a port it never declared, and traffic still arrives. That last point cuts both ways, because it means a wrong targetPort produces a connection refused that is indistinguishable from a selector problem.
spec:
ports:
- port: 80 clients connect here
targetPort: 8080 forwarded to this port on the pod
targetPort omitted -> defaults to the value of port, not to
whatever the container happens to declareA selector only ever considers pods in the Service's own namespace. There is no way to select across one. Reaching a service in another namespace is done through DNS, using the full name, or with an ExternalName Service as an alias.
api.other-namespace.svc.cluster.local