Kubernetes Service Concepts: Difference between revisions
| Line 18: | Line 18: | ||
=Need for Services= | =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. | Most [[Kubernetes_Pod_and_Container_Concepts|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. | ||
The | The pods come and go - if a pod fails, it is not resurrected, but its failure is detected by the lack of response from the liveness probe embedded within it and another pod is usually scheduled as replacement. In consequence, the IP address of an individual pod cannot be relied on. | ||
First off, the IP address is dynamically allocated at the time of pod initialization, and secondly, it 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 to keep track of ephemeral pod IP addresses. | First off, the IP address is dynamically allocated at the time of pod initialization, and secondly, it 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 to keep track of ephemeral pod IP addresses. | ||
Revision as of 21:07, 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.
The pods come and go - if a pod fails, it is not resurrected, but its failure is detected by the lack of response from the liveness probe embedded within it and another pod is usually scheduled as replacement. In consequence, the IP address of an individual pod cannot be relied on.
First off, the IP address is dynamically allocated at the time of pod initialization, and secondly, it 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 to keep track of ephemeral pod IP addresses.
The solution 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
Is is ClusterIP by default?
Service Manifest
Associating the Service with Pods
Manifest Syntax
Endpoints