Why you can’t ping a Kubernetes Service

Jan 14, 2020

3 min read

0

18

0

It’s pretty annoying when you’re troubleshooting an issue with a Kubernetes Service and you realise you can’t use ping to test it.

So… here’s a technical explanation why ping doesn’t work with Kubernetes Services.

Quick bit of background

A Kubernetes Service is a stable networking endpoint that sits in front of a set of application Pods. Instead of accessing Pods directly you access them through the Service. The Service exposes a DNS name, virtual IP, and network port that you can use to connect to the Pods behind it.

Combinations that work include:

name:port
IP:port

In the example above, you can reach the application Pods via either of the following sockets:

web-svc:8080
10.20.30.40:8080

The reason why you an’t use ping is due to the port requirement!

The short reason it doesn’t work

The short reason is that a Kubernetes Service only activates when connections arrive on the correct port. Unfortunately ping doesn’t use ports 🙁

Read on if you’re interested in more detail…

A bit of Service detail

The following events occur when an application connects to another application via a Service:

The application uses the cluster DNS to resolve the name of the Service to a ClusterIP (virtual IP) and port
The application sends traffic that the ClusterIP on the specific port
The ClusterIP is on a special network that has no routes to it, so requests go to default gateways
Requests are processed by the Nodes kernel when being sent to the default gateway of a cluster Node
All cluster Nodes are configured to trap on requests going ClusterIP addresses on the port the Service is using
The trap results in the packet headers being re-written so that the request is redirected to a particular Pod
The Pod receives the traffic and services the request

The problem lies in the fact that the trap only happens when requests are heading for the ClusterIP on the port specified in the Service definition. Ping traffic cannot be sent to a particular port, so the trap never happens.

A bit of ping detail

The ping utility is based on a protocol called ICMP (internet control message protocol). Who knew!?!?

Well, I kinda knew.

I knew that ping used ICMP, but I didn’t know that ICMP is its own full-blown protocol in the IP protocol suite. So I knew the buzzword, but I had no clue what the real-world implications were.

I guess I though ICMP was like HTTPS and DNS that are essentially services that operate over well-known TCP/UDP ports (HTTPS usually operates on port 443 and DNS on 53) .

But it’s not, ICMP is a whole different protocol to TCP and UDP (but it still runs on IP networks).

Anyway, don’t get lost in the detail. The point is… ICMP doesn’t run over TCP/UDP and therefore doesn’t have the notion of TCP/UDP ports. So there’s no way to use ping on the port that a Service is configured to listen and trap on.

Don’t stress though, other tools come to the rescue.

Other tools to the rescue

While it’s sad that we can’t use ping to test a Kubernetes Service, we abso-freakin-lutely can use others tools to test connectivity. A personal favourite is curl.