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 are an abstraction laying “ ” 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 . services logically 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 or reverse proxy if you may. loadbalancer 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 in any pod, so we get no “env=dev” 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 and out new releases “ ” ha. scaling rolling transparently Thank you
