Kubernetes Service Concepts: Difference between revisions
| Line 33: | Line 33: | ||
Designating a service as ClusterIP service by specifying [[Kubernetes_Service_Manifest#type|spec.type]]=ClusterIP in the service's manifest is optional. If the type is not explicitly specified, is it assumed "ClusterIP". | Designating a service as ClusterIP service by specifying [[Kubernetes_Service_Manifest#type|spec.type]]=ClusterIP in the service's manifest is optional. If the type is not explicitly specified, is it assumed "ClusterIP". | ||
==Service Manifest== | ==Service Manifest== | ||
Revision as of 21:42, 19 September 2020
External
Internal
Playground
Overview
A service is a Kubernetes resource that provides stable network access to a set of ephemeral pods. The need for such a resource is explained in the Need for Services section.
Need for Services
Most pods exist to serve requests sent over the network, so the pods' clients need to know how to open a network connection into the pod - they need an IP address and a port. This is true for clients external to the Kubernetes cluster, and also for pods running inside the cluster, which act as clients for other pods.
However, the pods are ephemeral, they come and go. If a pod fails, it is not resurrected, but its failure is detected as result of lack of response from the liveness probe embedded within it and another pod is usually scheduled as replacement. The pod does not need to fail to be removed, the removal can be the result of a normal scale-down operation. In consequence, the IP address of an individual pod cannot be relied on.
First off, the IP address is dynamically allocated to the pod at the time of pod initialization, after the pod has been scheduled to a node and before the pod is started, and secondly, the IP address becomes obsolete the moment the pod disappears. As such, it is practically very difficult, if not impossible for application's clients running outside the Kubernetes cluster, or even for other pods acting as clients to keep track of ephemeral pod IP addresses.
Multiple pods may be providing the same service, and each of them has its own IP address, and it is not the client's job to choose a specific pod.
The solution to all these problems is maintain an instance of a specialized resource, the service, for each of such group of pods. The service instance exposes a stable IP address and set of ports for the life of the service instance.
Service
In its simplest form, a service provides a stable Cluster IP address and exposes a set of ports. Internal Kubernetes cluster clients, for example other pods, can use the service's IP address to connect to the pods exposed by the service. This type of service is know as a ClusterIP service. Only internal clients can use a ClusterIP service, because the Cluster IP address is only routable from inside the Kubernetes cluster.
Designating a service as ClusterIP service by specifying spec.type=ClusterIP in the service's manifest is optional. If the type is not explicitly specified, is it assumed "ClusterIP".
Service Manifest
Associating a Service with Pods
Manifest Syntax
Endpoints