A step-by-step problem-solving method from the pod’s IP tackle to a cloud-native load balancer
Earlier than beginning with communication, a fast clarification on some primary phrases utilized in Kubernetes:
Pod — Smallest entity in Kubernetes. Every pod has an IP tackle. For simplicity, take into account them a wrapper round a container the place the appliance is working (like an utility working inside a docker container). It’s doable for a pod to have a number of containers; the extra containers act as helpers to the primary utility container. Maybe, I’ll maintain multicontainer pods for an additional write-up.
Nodes — Bodily or digital servers/machines the place the pods are deployed and kind the cluster.
Now, let’s say the pod is working an online utility, and two nodes and 4 pods serve it.
If the person someway will get the general public IP tackle of the pod, then can the consumer entry the online utility from exterior? The pods are on a separate community contained in the node. Secondly, pods are unstable, and each time a pod is created, it will get a brand new IP tackle.
We’re speaking about 4 pods from the instance, so whose IP tackle can we expose? Or can we expose 4 IP addresses to the skin world and let the consumer determine which IP tackle it desires to strive its luck on?
What we want is a few layer on high of the pods. This layer known as NodePort Service, because it creates a port on the node to entry pods.
NodePort Service has its personal IP tackle contained in the cluster, and it’s really a set of request forwarding guidelines. It takes a request from the skin world and spreads it throughout the pods, that are distributed on a number of nodes.
It’s additionally answerable for distributing site visitors to pods utilizing a random algorithm and session affinity. Internally, the NodePort Service makes use of one other part for communication with pods, the ClusterIP service.
All issues solved? Not likely, There are nonetheless three points:
The NodePort Service is accessed from exterior
It makes use of the IP tackle of the port
<IP-Deal with of Node>:<Port of NodePort service>. So, if the nodes had been everlasting, we might give the IP addresses of each nodes, and the consumer might use any of them. The primary drawback is that we’re giving them multiple tackle to succeed in the server.
The second drawback is all about elasticity and scale. Subsequently, the nodes are additionally unstable and might go down (Basically, it’s doable to beat this limitation by having a static IP tackle that’s uncovered to the skin world. And invoking a script at scale in and scale out occasions, which assigns this IP tackle to one of many nodes within the cluster).
There’s a restrict to the port’s vary
With NodePort Service, the port can solely be configured within the vary of
Safety is comprised
Because the ports of employee nodes are straight open to the skin world, many safety points come up.
Due to the above limitations, the NodePort Service could possibly be fascinating in improvement or check environments. It might even be helpful when some freedom is required in customized environments/integrations. Let’s take into account the options:
1. A further layer on high of the NodePort Service might assist. When the cluster is deployed in a public cloud, like AWS or Google, we will use the load balancer service from Kubernetes, which integrates with a cloud-native load stability like AWS ELB.
The load balancer service has a cluster IP tackle in addition to an exterior IP Deal with. The load balancer service is an abstraction over the NodePort Service (which is an abstraction over ClusterIP Service). Subsequently the NodePort Service is created, however the ports are accessible solely to the cloud-native load stability — not on to the skin world.
There could possibly be a DNS path to the load balancer, and the person might entry the service utilizing a site title. The service may be accessed straight by accessing the load balancer. The exterior load balancer controls how the site visitors is distributed to pods.
As a facet be aware, relying upon the kind of load balancer and the cloud platform, it’s doable to level to node/occasion (and have a hop at node degree) or straight get the IP tackle of the pod itself (avoiding the hop and making it extra environment friendly). For instance, it could be doable in AWS’s community load balancer.
If the cluster will not be on the cloud or it’s on the cloud however meant solely to cater to HTTP site visitors, you would have a Kubernetes Ingress as an alternative of a load balancer. Ingress is a layer 7 (HTTP) abstraction that specifies routing guidelines for incoming requests. The routing/redirection guidelines are applied by one other part referred to as the Ingress controller.
The ingress controller acts as a reverse-proxy/entry level contained in the cluster. Per the routing guidelines, any request coming from the consumer by way of the load balancer reaches the Ingress controller from the place it’s redirected to pods. There is no such thing as a want for NodePort Service.
Additionally, it’s price emphasizing that there are different Ingress setup prospects relying upon the service and the controller implementation.
Kubernetes makes use of companies to facilitate communication. We checked out NodePort Service, load balancer service, and touched on Cluster IP service. I’ll revisit it in my subsequent write-up once I cowl cluster communication.
Ingress is one other object in Kubernetes which might expose HTTP companies exterior the cluster. Offering routing, TLS termination, and cargo balancing.
Additionally, Kubernetes integrates fairly effectively with suppliers to ease cluster setup.