Networking is a crucial component within any Kubernetes cluster. It ranges from internal cluster communication between resources to facilitating connectivity with external services and the wider internet. Kubernetes Pods are ephemeral. Applications are designed so that containers can be terminated with a simple sigterm command and recreated when required without affecting application functionality. Thus, there should be a mechanism to provide reliable access to Pods without recreating network mappings each time a Pod gets created or destroyed. This is where Kubernetes services come into play.
Service in Kubernetes
Service in Kubernetes is a logical abstraction of a set of pods where an application or a specific component is running. It allows users to group a set of pods that provide specific functionality and assign a name and IP address. This way, there will be a constant connection with services managing what Pod to talk to, regardless of the state of underlying Pods.
A Service selects Pods based on their labeled key-value pairs. When a network request is made to the service, it selects all the Pods in the cluster matching the specified selector, chooses one of them, and forwards the request.
Service vs. Deployment
Kubernetes Deployments are used to deploy containerized applications within a cluster. A deployment is responsible for keeping the deployed set of pods running while ensuring that the specified number of replicas are always available. Even though these deployed Pods can be accessed directly, any change will require a new network mapping.
Meanwhile, the service is responsible for providing a network interface for the deployed pods to enable network access for either internal or external entities to access the pods. Deployment is not required for a Kubernetes service to function. Users can create pods individually, and the service will pick them using the labels. However, you can simplify pod management and network routing by using a service with a deployment.
Components of a Kubernetes Service
Services connect a set of pods to an abstracted service name and IP and enable discovery and routing between pods. A service is defined using YAML or JSON like any other Kubernetes object. A service definition will contain the following components.
- A label selector to select the appropriate pods
- The service type
- Port definitions
- Optional port mapping from incoming ports to targeted ports.
A service is defined without a selector pointing to a set of pods. It allows using services to abstract other kinds of objects or backends. Some examples of services without selectors are services used to point to other services in different namespaces or clusters, connect to external services like databases, etc. The service will not automatically create an endpoint object as it does not have a selector. Thus users will have to create endpoint objects manually and map the corresponding ports.
What are the Available Service Types in Kubernetes
Users can define different types of services depending on the requirements. This service type determines how the service is connected to the network. There are four service types available within Kubernetes.
- ClusterIP – This is the default service type in K8s. ClusterIP will expose the service to an internal cluster IP address, accessible only within the cluster.
- NodePort – This service type opens a specific port in all the cluster nodes. Any traffic that reaches the port will be routed to the service, even if it is not located in the node which receives the traffic. It allows the service to handle requests that originate outside the cluster.
- LoadBalancer – This is the preferred way to expose services externally to be accessed via the internet. An external load balancer from the service provider is utilized in a cloud environment to expose the service. The underlying ClusterIP and NodePort services will be created automatically to route traffic from the load balancer to the service within the cluster.
- ExternalName – This service type allows users to map a service to an external DNS name. It returns a CNAME record defined within the “externalName” field in the service configuration.
While Kubernetes ingress can also expose a service, it is not a service type. Instead, it acts as an entry point to the cluster, enabling users to expose multiple services using a single IP address. Then the ingress controller will route the traffic to the appropriate services.
Conclusion
Kubernetes services simplify the networking within a cluster. They provide a standardized way to access a set of Pods without individually managing network routing. Moreover, the flexibility offered by services helps expose any resource within a cluster, both internally and externally. It even allows routing traffic to other services and backends outside the cluster. All these things enable users to quickly implement any network architecture that exactly suits their needs.
