1. Introduction
In Kubernetes, a NodePort service is exposed for every node in the cluster using the nodePort field in the service definition, which can be either user specified or automatically assigned.
By default, the nodePort is allowed to be in a range between 30000 and 32767. In this article, we’ll discuss why this range is the default.
2. Primary Reasons
Kubernetes NodePort services use the 30000 to 32767 range mainly to avoid conflicts with reserved port numbers and other ports on a node.
2.1. To Avoid Conflict With Other Ports Used by Nodes
Having NodePort services fall within the 30000 to 32767 range reduces the chances of assigning them the same number as other ports used by worker nodes. This also includes a pod’s hostPort, where applicable.
Specifically, the 30000 to 32767 range includes 2768 potential port numbers out of a possible 65,535 port numbers. This is around a 4.2% chance of having the same number as other ports on the node.
2.2. To Avoid Conflict With Reserved Port Numbers
In line with the previous point, the high port range of Kubernetes NodePort services ensures that the port numbers never coincide with reserved port numbers. This makes it unlikely for them to conflict with crucial services like SSH or DNS on the node, preventing unusual behavior.
For instance, if a service’s nodePort were 22, the default SSH server port, we may have trouble accessing the node’s SSH services.
3. Other Potential Benefits
Besides preventing conflicts with other ports on a node, the default port range of Kubernetes NodePort services may offer some other benefits, such as predictability, security, and scalability.
3.1. Security
Security may not be one of the primary reasons why NodePort services have their port range. However, having high port numbers might offer them some level of security.
A basic port scan typically focuses on port numbers below 10000. So, the chances of a nodePort showing up in an attacker’s scan are relatively low.
That said, having a high port number alone is an insufficient way to keep services on a cluster secure. Other security measures like authentication, security patch updates, and encryption should be integrated where applicable.
3.2. Predictability
Knowing that NodePort services have a nodePort number anywhere between 30000 and 32767, we can readily identify them. But beyond that, we can easily manage access to them.
For one, if we want external access to NodePort services in our cluster, all we have to do is specify the port range (30000 – 32767) in our firewall rules. With that range not conflicting with reserved port numbers and many other services in cluster, we can be almost sure that we won’t mistakenly grant access to restricted cluster services.
3.3. Consistency
Since a NodePort service’s nodePort falls within a predictable port range, there’s some level of consistency in their configuration. For one, we can always use the same or a similar firewall configuration to grant access to them.
All in all, this makes for easy configuration even in clusters running numerous N**odePort services.
3.4. Standardization
The default high port range of NodePort services suggests a standard practice expected of Kubernetes administrators. We know that even if we have to change the default port range to a custom range, selecting a high port range is often the best way to go.
As we also hinted in the previous two points, the consistency of the default port range means that we know the standards to expect when managing nodePort values in different clusters.
3.5. Low Chances of Conflicts With Reserved Ports in the Future
If the Internet Assigned Numbers Authority (IANA) decides to reserve a specific port number for a system service in the future, it’s unlikely to conflict with the NodePort services nodePort range.
The IANA is more likely to select from within the 0 – 1023 range instead of going deep into the high port number territories.
3.6. Scalability
With over 2768 port numbers to choose from, there’s a fair level of scalability while allocating port numbers to NodePort services. In other words, there are very low chances of running out of port numbers, even in large K8s clusters.
4. How to Change the Default nodePort Range
We can change the default nodePort range in our cluster by editing the kube-apiserver‘s configuration. To do this, we’ll edit the –service-node-port-range command in the /etc/kubernetes/manifests/kube-apiserver.yaml manifest.
Let’s change our nodePort range to 35000 – 37797:
$ cat /etc/kubernetes/manifests/kube-apiserver.yaml
apiVersion: v1
kind: Pod
metadata:
annotations:
kubeadm.kubernetes.io/kube-apiserver.advertise-address.endpoint: 192.168.49.2:8443
creationTimestamp: null
labels:
component: kube-apiserver
tier: control-plane
name: kube-apiserver
namespace: kube-system
spec:
containers:
- command:
...truncated...
- --service-cluster-ip-range=10.96.0.0/12
- --service-node-port-range=35000-37767
...truncated...
We can grep our cluster’s kubectl cluster-info dump to confirm this change:
$ kubectl cluster-info dump -n kube-system | grep service-node-port-range
"--service-node-port-range=35000-37767",
Alternatively, we could display information about a NodePort service using kubectl describe to confirm that its port is within our chosen range.
5. Conclusion
The externally exposed nodePort of a NodePort service ranges between 30000 and 32767 primarily to avoid conflicts with reserved ports and ports used by nodes. But beyond that, the range makes for consistency and predictability, which allow for easier cluster management. It also offers enough port numbers, so even large clusters can create many NodePort services without running out of port numbers very quickly.