Kubernetes The Pokémon Way: Services!

One of the most confusing parts when starting to learn Kubernetes is be able to access your apps externally. With all the hype around it (Service, ClusterIP, Load Balancer, Ingress, Ingress Controllers, etc) you can easily get lost and for beginners; choosing a solution is not always an easy task.

In this series of articles, we will try to understand the basic concepts of Kubernetes using analogies from widely known cartoons and animes like Pokemon ;)

Googling Kubernetes Services

Let’s look for good definitions of Kubernetes Services on the web. The first one is abstract:

A Service in Kubernetes is an abstraction which defines a logical set of Pods and a policy by which to access them. Services enable a loose coupling between dependent Pods and provide an interface to be able to access them.

The second definition is more technical:

A service represents a TCP or UDP load-balanced service. As it is a load-balanced service, it must use destination NAT(DNAT) to redirect inbound traffics to back-end pods, which relies on iptables from Linux OS to do the job. When a service gets created, kube-proxy(daemonset) will inject a few of iptables chains & rules to agent node. Accessing kubernetes service relies on DNAT, also if source IP is from external network (Not in Pod IP CIDR), source IP will also be SNAT-ed.

Note: Both definitions are taken from articles trying to explain the services at different levels of detail.

Let’s try with Pokeballs:

Ok! As said Mr. Einstein, If you can’t explain it to a six year old, you don’t understand it yourself. Let’s do an analogy with Pokemon :

The flow is straightforward now! For ash to spawn(access) Pikachu, he needs to use a Pokeball that is somehow related to Pikachu. In Kuberentes, this relationships between Pokeballs and Pokemons is done through Selectors and Labels.

The differences is that the Kuberentes Services (Pokeballs) can be used by more than one User at a time. Hence, they may be selecting multiple Pods (Pokémons) matching the same labels at the same time.

But why do we even need Pokeballs (Services) ? The answer appears to be very simple: because Pokémons (Pods) are not reliable. They can get confused and get defeated in battles (containers inside Pods crash and restart all the time). Hence Pokeballs(Services) are smore reliable logical layer that does not get affected by the Pokemon(Pod) state and always in ashs bag (We can access Services with the DNS).

Pikachu is confused by all this complexity.


We use services to access objects in a reliable way inside Kubernetes. I hope that the concept is more clear now. Follow me to get notified for the other parts and leave me comments to know what you think of this.

Data Consultant. Databricks Certified Associate Developer.