Initially we created a Pod .. next we wanted them to he highly available .. we learnt how to create Replica Set and made them available, so even it one pod goes down .. the functionality that the pod was offering is still available. But then the Pods could be running on different Workers (Nodes) and would have different IPs.
Also the fact that if one Pod goes down and we have a new Replacement pod coming up .. there is no guarantee that the new Pod will retain the same IP address.. it will get a new IP address.
This is where we Service comes in. Services are of various types:
- ClusterIP
- NodePort
- LoadBalancer
- External??
We use ClusterIP Service to load balance at the Service Level. When creating the same don't forget to map the SELECTOR to the Service that we want to Load Balance (name of the Application - metadata.labels.app -> name mentioned here). This also acts as a means for ensuring that the App accessing the service is actually using the NEW version that you intend to be used.
We use NodePort to load balance at the Node Level. Also to expose internal Port at the Cluster level. Here as well we use the Selector and a NEW port is created that is exposed at the Cluster level and maps back to the Pod's IP
We use LoadBalancer to load balance at the Internet / Route53 level. We map the Domain name to to IP of the Cluster IPs (ALL node IPs) so that the incoming requests can be routed to any of the Cluster machines, which internally maps to a NodePort, eventually to a ClusterIP and finally hitting the POD hosting the Service.
Top comments (0)