Kubernetes services are Kubernetes native mechanisms for exposing and accessing pods and their resources as first-class objects. Services are a primary way to implement endpoints in Kubernetes, which can be used from other pods or from outside of the cluster (for instance, with service-based load balancing). In this article, we’ll see what services are, why we need them, and how they work.
What is a Kubernetes Service? #
A Kubernetes service is a first-class object in the Kubernetes API. It represents an exposed endpoint for pods that should be reachable by other pods in the cluster, as well as by clients outside of the cluster. The underlying implementation of services is pluggable, but they are most commonly implemented as an Ingress resource (see below) using the Kubernetes API to define the configuration. Kubernetes provides a basic set of well-known configuration options, but services can be anything you can implement as a Kubernetes resource.
Why do we need Services? #
Pods in Kubernetes are ephemeral – they come and go based on the state of their deployment. If a pod’s host dies, the pod is rescheduled somewhere else in the cluster. In order for pods to find each other, pods must be addressable by hostname/IP, which is not a default Kubernetes behaviour. In practice, this means that we need some mechanism to ensure that pods can discover each other via their hostnames, rather than just via their own IP addresses. This is where services come into play. Services allow pods to be addressable by their name, which is more friendly to users and can be used as an identifier for other objects in the cluster.
How does a Kubernetes Service work? #
A service is a Kubernetes resource that is typically defined as an Ingress, but can also be implemented as an endpoint. An Ingress is a special type of Kubernetes resource that allows configuration of services and routing of traffic to those services. Kubernetes services are, conceptually, really nothing more than an endpoint resource that has been exposed and label-driven, with a few special features enabled by the Kubernetes API. When an endpoint is exposed, the client is given a name and a set of rules that govern how it can be accessed (i.e. what ports it can be accessed on, what hostnames are valid, etc.).
Confirming: Did we actually create a service? #
Let’s confirm that our service has been created, and that it is accessible. We can do this by querying the Kubernetes API, and looking for our newly created service. We’ll use the kubectl tool to query the API, and the describe subcommand to inspect a specific resource. In our case, we’ll want to interrogate the service that we created. This command tells us all about the service, including the name, the labels applied to the resource, and associated endpoints. We can see that our service has a name, and that it has an IP address of 10.147.19.190 . That IP address might not mean anything to you, since it is an IP address internal to the cluster. Next, let’s see what ports and protocols are associated with this service.
Limitations of Services #
Kubernetes services are a fundamental building block for cluster services, and most applications will use them to expose themselves to other pods. However, it is important to understand that services are not a substitute for external load balancing. This means that services will not provide high availability in and of themselves. If a pod goes down, or the host that it is running on dies, the service will failover to another pod, but the external endpoints may not change. This could mean that external users are still accessing an unhealthy service. If you want high availability, you will need to use a mechanism like a service-based load balancer to route traffic to the most available pod (or pods).
Wrapping up #
Kubernetes services are a fundamental building block for exposing application functionality via endpoints in the cluster. The underlying implementation is pluggable and can be configured as an Ingress resource. If you’d like to code right away, check out our interactive kubernetes tutorial Where you can use kubectl to create a service, and then use curl or a browser to confirm that the service is working. You can also try out the Implicit AI Kubernetes tutorial to learn how to create a service, and then use a service-based load balancer to route traffic to a microservice.
Get your employees up-to-date with online courses and certifications in web tech, software development, and IT from London School of Emerging Technology.
