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
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: v1kind: Servicemetadata:labels:app: nginxrole: webenv: prodname: nginxservicespec:ports:- port: 80selector:app: nginxrole: webenv: prodtype: 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
app=nginx,env=prod,role=web
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