Kubernetes Service Concepts: Difference between revisions
| Line 12: | Line 12: | ||
=Service= | =Service= | ||
A Service is a mechanism that provides reliable TCP and UDP networking to a set of pods. As described in the [[Kubernetes_Pod_and_Container_Concepts#Lifecycle|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. Additionally, the service is automatically registered with the [[Kubernetes_Networking_Concepts#The_DNS_Service|cluster's DNS service]] so cluster components can find services by name, which becomes DNS-resolvable. Also, in case of two or more pods, the service load balances requests between the available pods. | A Service is a mechanism that provides reliable TCP and UDP networking to a set of pods. As described in the [[Kubernetes_Pod_and_Container_Concepts#Lifecycle|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. Additionally, the service is automatically registered with the [[Kubernetes_Networking_Concepts#The_DNS_Service|cluster's DNS service]] so cluster components can find services by name, which becomes DNS-resolvable. Also, 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 [[#Connecting_Pods_to_Services|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. | 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 [[#Connecting_Pods_to_Services|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. | ||
Revision as of 23:43, 11 November 2019
External
Internal
Playground
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. Additionally, the service is automatically registered with the cluster's DNS service so cluster components can find services by name, which becomes DNS-resolvable. Also, 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.
Connecting Pods to Services
A service has a 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.
Service Types
TODO: https://www.ibm.com/support/knowledgecenter/en/SSBS6K_3.1.1/manage_network/kubernetes_types.html
ClusterIP
NodePort
LoadBalancer
ExternalName
Endpoint
Endpoint Controller
The endpoint controller is part of the controller manager.