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)
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 metadata: labels: app: nginx role: web env: prod name: nginxservice spec: ports: - port: 80 selector: 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.