Services
While Pods do have their own unique IP across the cluster, those IP’s are not exposed outside Kubernetes. Taking into account that over time Pods may be terminated, deleted or replaced by other Pods, we need a way to let other Pods and applications automatically discover each other. Kubernetes addresses this by grouping Pods in Services. A Kubernetes Service is an abstraction layer which defines a logical set of Pods and enables external traffic exposure, load balancing and service discovery for those Pods.
This abstraction will allow us to expose Pods to traffic originating from outside the cluster. Services have their own unique cluster-private IP address and expose a port to receive traffic. If you choose to expose the service outside the cluster, the options are:
- LoadBalancer - provides a public IP address (what you would typically use when you run Kubernetes on GKE or AWS)
- NodePort - exposes the Service on the same port on each Node of the cluster using NAT (available on all Kubernetes clusters, and in Minikube)
Summary:
- Exposing Pods to external traffic
- Load balancing traffic across multiple Pods
- Using labels
A Kubernetes Service is an abstraction layer which defines a logical set of Pods and enables external traffic exposure, load balancing and service discovery for those Pods.
Services overview
A Service provides load balancing of traffic across the contained set of Pods. This is useful when a service is created to group all Pods from a specific Deployment (our application will make use of this in the next module, when we’ll have multiple instances running).
Services are also responsible for service-discovery within the cluster (covered in Module 6). This will for example allow a frontend service (like a webserver) to receive traffic from a backend service (like a database) without worrying about Pods.
Services match a set of Pods using Label Selectors, a grouping primitive that allows logical operation on Labels.
You can create a Service when you start a Deployment by adding --expose as a parameter for the kubectl run command
Labels are key/value pairs that are attached to objects, such as Pods and you can think of them as hashtags from social media. They are used to organize related objects in a way meaningful to the users like:
- Production environment (production, test, dev)
- Application version (beta, v1.3)
- Type of service/server (frontend, backend, database)
Labels are key/value pairs that are attached to objects
Labels
Labels can be attached to objects at the creation time or later and can be modified at any time. The kubectl run command sets some default Labels/Label Selectors on the new Pods/ Deployment. The link between Labels and Label Selectors defines the relationship between the Deployment and the Pods it creates.
Let’s expose now our application with the help of a Service, and apply some new Labels.