So i wanted to talk a little bit about services and addressing today , when you create a deployment , “A declarative update for pods and replicasets” , like the one we’ve created in the previous article you get:

  • pod (with x ammount of replicas)
  • replicaset image

So we will need services , services are an abstraction laying “logically” on top of pods , the idea is that as pods are sort of non static entities , as in pods died (old releases) and new ones are created .

Having a service on top of pods would let you always point to the same address and you somehow would land on a “selected” pod , like a loadbalancer or reverse proxy if you may.


A service would look like:

apiVersion: v1  
kind: Service  
    app: nginx  
    role: web  
    env: prod  
  name: nginxservice  
    - port: 80  
    app: nginx  
    role: web  
    env: prod  
  type: NodePort

When you run this you will get:


The most important thing about the service is the binding against pods , and this is done through selectors.

As you see the selectors that we’ve declared on the service are


and these match the labels that we have on the pods:


and that’s how the binding is done.

So selectors can match some of the labels , or all of them , but they can’t have negative matches for example:


there’s not “env=dev” in any pod, so we get no Endpoints .

Selectors and labels are one of the most important kubernetes primitives so it is important to know a bit about them.

So fixing the selectors now we can hit the pods through the service:


And that’s all for now.

Next time I’d like to talk about scaling and rolling out new releases “transparently” ha.

Thank you