Kubernetes: Services

Let’s step back a little.

When you are working with Docker Swarm or simply using docker-compose one notices how the world is so beautiful. When you do a stack deploy or docker-compose up the DNS names are by default the name of your containers mentioned in your yml files. 😃

http://nginx:8080

When you are learning Kubernetes and come ample amount of time with swarm and compose, it can be quite confusing what to expect from Kubernetes. Especially when you’re a developer and need to “creates services” in it. When you created that application listening to requests on port 8080 (for example) inside that container which is inside of that pod, you need to be able to make a request to it. I mean that’s what a service is!

Problem

However, the pod you create have it’s own IP address. This IS the problem. Pods created using deployments have dynamic ips. Perhaps the node was running out of memory or someone accidentally spilled coffee on that worker node. In that situation, ReplicaController will create a new instance of the pod in another running node. This new pod will have a new IP address. If an another application of mine is using this application in the pod, wouldn’t it be nice if I didn’t have to change my application to point to the new pod address and it simply just was resilient to those types of issues?

Official doc states

While the actual Pods that compose the backend set may change, the frontend clients should not need to be aware of that, nor should they need to keep track of the set of backends themselves.

Service

Kubernetes is new to me and so far my learning process has been around services mostly that I feel needs a bit of slowing down (and meditating). I think once we can demystify the workings of services in the Kubernetes scope and understand the “why” behind it, it will hopefully help me make better decision about when to use it.

A service is a stable ip address over a set of pods. This ip address will NEVER change unless it goes down. Moreover, these pods run containers (applications) that provide the same functionality. The functionality is provided in form of requests listened on ports inside the containers. Once you hit the service with the request, service abstraction simply responds back with your appropriate response.

Conclusion

The very nature of Kubernetes service of unchanging IP address (or service DNS name) makes it alluring when it comes to providing better resiliency, transparency, and availability of your service — make a request and get a response with pod faulterance. Now let’s look at how your requests are routed to the pods.