There are several ways to grant end users access to the services in a Kubernetes cluster. But with different options to choose from, how do you know which path to take?
In Kubernetes, service types dictate how users or external traffic can access Services, which define a group of Pods and how to access them. There are three major types:
However, a fourth way to control traffic to services is to use the Kubernetes Ingress. Let's take a look at the differences between Kubernetes Ingress versus these service types.
While the Kubernetes Ingress also handles external access to the services, it is not a Service, like the other options, but rather an API object. This works differently than Services in that it creates an Ingress resource that routes traffic based on a set of rules.
To do this, it sets up an external load balancer that connects to the Ingress, and then routes traffic to the service, following the set rules. With this, admins can route multiple back-end services via one IP address.
A load balancer spreads out workloads evenly across servers or, in this case, Kubernetes clusters. In addition to connecting users with a Service, load balancers provide failover: If a server fails, the workload is directed to a backup server, which reduces the effect on users.
Load balancers sit between servers and the internet. They direct user requests to available servers. If demand is high, they can add servers; if demand is low, they can drop servers. However, each service requires its own load balancer -- they don't share. This means that if you have a lot of services, you will also need a lot of load balancers.
NodePort vs. ClusterIP
Another Kubernetes networking option is to set the service type as NodePort. With NodePort, you can set up your own load balancers to configure environments Kubernetes doesn't fully support, or you can expose the IP address of one or more nodes. This opens a way for external traffic to reach the nodes.
NodePort differs from Kubernetes' default service type, ClusterIP, which limits access to the service from only within the cluster by using a cluster-internal IP. ClusterIP enables pods to communicate with each other within a cluster, but not outside of it.