Services

• k8s documentation: https://kubernetes.io/docs/concepts/services-networking/service/

• The Service API, part of Kubernetes, is an abstraction to help you expose groups of Pods over a network. Each Service object defines a logical set of endpoints (usually these endpoints are Pods) along with a policy about how to make those pods accessible.

• The set of Pods targeted by a Service is usually determined by a selector that you define.

• Kubernetes updates the EndpointSlices for a Service whenever the set of Pods in a Service changes.

• The controller for that Service continuously scans for Pods that match its selector, and then makes any necessary updates to the set of EndpointSlices for the Service.

Kubernetes Service types allow you to specify what kind of Service you want. The available type values and their behaviours are:

• ClusterIP
  Exposes the Service on a cluster-internal IP. Choosing this value makes the Service only reachable from within the cluster. This is the default that is used if you don't explicitly specify a type for a Service. You can expose the Service to the public internet using an Ingress or a Gateway.
  Example:
  
  
  
  
  
  
  
  
  
  
  
  
  
  If you have a cluster IP service x at port p in namespace y, then telnet http://x.y.svc.cluster.local:p will resolve to the service IP. This DNS resolution happens via internal K8s DNS coredns in the kube-system namespace. If your service A calls service B and it is not routing traffic to the correct pods corresponding to service B then the first thing to check is if even able to resolve to the service B endpoint or not.
  Well, the day before I was too lazy to give it a full stop here but I just had a coffee. So why not dive deep with some practical examples and see how can you create two cluster IP services and check how can they communicate?
  Copy service-1 into some file and apply this in a ns, and then copy the service-2 config in some other file and apply it in the same ns.
  After the pods are up for both services, exec into service-1 pod and curl service-2 from there as show below.
  
  
  

• NodePort
  Exposes the Service on each Node's IP at a static port (the NodePort). To make the node port available, Kubernetes sets up a cluster IP address, the same as if you had requested a Service of type: ClusterIP.
  NodePort services are helpful when you want to utilise Node IPs and NodePort to make requests to a certain service from outside the cluster.

• LoadBalancer
  Exposes the Service externally using an external load balancer. Kubernetes does not directly offer a load-balancing component; you must provide one, or you can integrate your Kubernetes cluster with a cloud provider.

• ExternalName
  Maps the Service to the contents of the externalName field (for example, to the hostname api.foo.bar.example). The mapping configures your cluster's DNS server to return a CNAME record with that external hostname value. No proxying of any kind is set up.