Services
In this section, we will see the need for Services in the Kubernetes cluster and their architecture. As we know that Pods IP's are constantly changing for every new deployment, so it will be hard to use pods IPs for any loadbalance configuration. Services offers,
- Stable IP
- Stable DNS, and
- Stable Port
Services Architecture:
NodePort:
NodePort helps you to expose the Kubernetes cluster ports to outside world. The NodePort range is between 30000 and 32767. You can access the pods using this port in your web browser. Let us assume, you have an application running in the Kubernetes cluster and it's node IP is 192.168.2.244 and you have given nodePort as 30001 in your service manifest file, then you can access your application outside your cluster as
http://192.168.2.244:30001/
So, when you hit the URL, it goes inside the Kubernetes cluster, then it authenticates the request using the API server, and then sends it to Kube-Proxy. The role of the Kube-Proxy is to look for the services that are listening to 30001. Once it finds the match, the HTTP request is sent it to the appropriate service to honor the request.
Port:
This is the port used in the service manifest file, where it will forward your HTTP request to the listener port where the pods are running. In my example, I have used 9090, where this port receives the request from the nodePort(30001) and sends it to the pods that are listening for this request.
kubectl get svc vcdemo -o wide
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
vcdemo NodePort 10.98.179.98 <none> 9090:30001/TCP 15h app=nginxapp
ClusterIP:
When you create a service, it automatically creates a new IP, and that IP will be used to interact with all the pods within the cluster. ClusterIP is not meant for accessing the pods outside the cluster.
TargetPort
In this example, the nginx pod is listening to the port 80, which is ready to accept any request that comes to it. Below is the snippet from service.yaml
