Kubernetes Service Concepts: Difference between revisions
Line 4: | Line 4: | ||
=Service= | =Service= | ||
A Service is a mechanism that provides reliable networking to a set of pods. As described in the [[Kubernetes_Pod_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 service fronts an inherently dynamic set of pods and provides a reliable name and IP for the pods "represented" by that service. Additionally, the 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_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 service fronts an inherently dynamic set of pods and provides a reliable name and IP for the pods "represented" by that service. Additionally, the 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. | 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. |
Revision as of 23:12, 21 August 2019
Internal
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 service fronts an inherently dynamic set of pods and provides a reliable name and IP for the pods "represented" by that service. Additionally, the 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.
If a pod dies, the service dynamically and transparently clears the relationship to the defunct pod, and stops sending requests into it.
ClusterIP
NodePort
LoadBalancer
ExternalName
Endpoint
Endpoint Controller
The endpoint controller is part of the controller manager.