Kubernetes Service Concepts: Difference between revisions
| Line 14: | Line 14: | ||
A service is a Kubernetes resource that provides stable network access to a set of ephemeral | A service is a Kubernetes resource that provides stable network access to a set of ephemeral [[Kubernetes_Pod_and_Container_Concepts|pods]]. The need for such a resource is explained in the [[#Need_for_Services|Need for Services]] section. | ||
=Need for Services= | =Need for Services= | ||
Revision as of 20:12, 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
The pods come and go - if a pod dies, it is not resurrected, but its failure is detected by the lack of response from 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, it 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, to burden the application's clients running outside the Kubernetes cluster with the responsibility of keeping track of ephemeral IP addresses.
The solution is
access for a continuously changing set of pods. A Service's IP address and port can be relied on to not change for the life of the service. All live pods represented by a service at a moment in time are known as the service's "endpoints". There are several types of services: ClusterIP, NodePort and LoadBalancer. The association between services and pods they expose is loose, established logically by the service's Selector, which is a label-based mechanism: a pod "belongs" to a service if the service's selector matches the pod's labels. A layer 5 alternative to service, named Ingress is available. Services are explained at length in the Service Concepts section.
Service
A Service is a mechanism that provides reliable TCP and UDP networking to a set of pods. As described in the Pod Lifecycle section, pods may come and go, and every time a new replacement pod is brought up, it comes with a new IP address; the process results in a fair amount of IP churn. The service fronts an inherently dynamic set of pods. It provides a reliable name and a stable IP address and port for the pods "represented" by that service. The service is automatically registered with the cluster's DNS service so cluster components can find services by name, which becomes DNS-resolvable. More details between a service and the DNS service are available in the Services and DNS section. In case of two or more pods, the service load balances requests between the available pods.
If the number of pods is increased by explicitly scaling the deployment, no service modification is required - the service dynamically identifies the new pods and starts to load-balance requests to them, using a mechanism involving labels and a selector. If a pod dies, the service dynamically and transparently clears the relationship to the defunct pod, and stops sending requests into it.
Services operate at the TCP/UDP layer (level 3) and in consequence cannot provide application-layer routing. If application-layer routing is needed, a primitive named Ingress is available.
A Service is a Kubernetes API Resource, an object whose state is maintained by the Kubernetes API server, and for which we define a manifest that is then POSTed to the API server.
Service Manifest
Connecting Pods to Services
Pods and services are loose coupled via labels and label selectors.
The service maintains the label selector, which is a list of all the labels a pod must possess in order for it to receive traffic from the service. The service will send traffic to all ready pods - a pod whose containers have all passed the readiness check - that posses all the labels contained by the service's selector. The pod may have extra labels in additions with those specified by the service's selector, and those will not interfere with the service selection process. In other words, the label selector needs to match some of the labels on a pod, but for a pod to match a service, in must have ll of the labels the service is looking for.
As pods fail or get started, the service in front of them observes these events and updates its knowledge of the pods, but it never changes the stable IP address, port and DNS name that it exposes.
Services and DNS
A service is automatically registered with the cluster's DNS service so cluster components can find services by name, which becomes DNS-resolvable.
Service Types
TODO: https://www.ibm.com/support/knowledgecenter/en/SSBS6K_3.1.1/manage_network/kubernetes_types.html
ClusterIP
NodePort
apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
type: NodePort
ports:
- port: 8080
targetPort: 8080
nodePort: 30001
protocol: TCP
selector:
app: my-app
LoadBalancer
ExternalName
Endpoint
Endpoint Controller
The endpoint controller is part of the controller manager.