About the Author

Lee Calcote

Lee Calcote is an innovative product and technology leader, passionate about empowering engineers and enabling organizations. As Founder of Layer5, he is at the forefront of the cloud native movement. Open source, advanced and emerging technologies have been a consistent focus through Calcote’s time at SolarWinds, Seagate, Cisco and Schneider Electric. An advisor, author, and speaker, Calcote is active in the community as a Docker Captain, Cloud Native Ambassador and GSoC, GSoD, and LFX Mentor.

MeshMap

MeshMap is the world's only visual and collaborative designer for Kubernetes and all cloud native infrastructure.

Kubernetes provides a Service to offer a unified traffic endpoint for the Pods. While it offers a VIP to the clients for access and Kubernetes ensures traffic balancing for the accessing back-end Pods, it has a limitation of routing traffic from outside the cluster. The Kubernetes Service setting of "NodePort" was created to overcome this issue.

By setting up a mapping to a specific port of all nodes in the cluster, a NodePort Service redirects traffic from the outside to the inside of the cluster. When a NodePort Service is created, Kubernetes control plane allocates its corresponding ports in two ways. The first is dynamic, where Kubernetes control plane automatically assigns an unused port at the creation time. The second is static, which assigns a port within the nodeport port range configuration. It is crucial to assign a unique nodePort across the entire cluster while manually assigning nodePort, or it will result in an error if a service of type NodePort already uses that port.

Sometimes, there is a need to run a NodePort Service on well-known ports so that other components and users inside or outside the cluster can use them. In such cases, users need to reserve the required ports before using them. Kubernetes 1.27 introduced a new feature gate "ServiceNodePortStaticSubrange" that allows users to use a different port allocation strategy for type NodePort Services. Enabling this feature gate will divide the port range for NodePort Services based on a formula that uses nodeport size and determines the size of the static port range.

Here are a few examples of different port ranges and their band offset values:

Range propertiesValues
service-node-port-range30000-32767
Band Offset86
Static band start30000
Static band end30085
Dynamic band start30086
Dynamic band end32767

Range propertiesValues
service-node-port-range30000-30015
Band Offset16
Static band start30000
Static band end30015
Dynamic band startN/A
Dynamic band endN/A

NodePort Services can be useful in many scenarios. For example, consider a user that needs to expose a Minio object storage service on Kubernetes to clients running outside the Kubernetes cluster. The agreed port is 30009, and the user needs to create a Service as follows:

1apiVersion: v1
2kind: Service
3metadata:
4 name: minio
5spec:
6 ports:
7 - name: api
8 nodePort: 30009
9 port: 9000
10 protocol: TCP
11 targetPort: 9000
12 selector:
13 app: minio
14 type: NodePort

If the port required for the Minio Service is not reserved and another NodePort (or possibly LoadBalancer) Service is created and dynamically allocated before or concurrently with the Minio Service, the TCP port 30009 might be allocated to that other Service. In this case, creation of the Minio Service will fail due to a node port collision.

In conclusion, using the NodePort Service will help Kubernetes users by allowing traffic to be routed from outside to inside the cluster, providing a unified traffic endpoint for the Pods. By enabling the ServiceNodePortStaticSubrange feature gate, users can adopt a different port allocation strategy, reducing the risk of collisions while using a different range of ports.

Related Blogs

Layer5, the cloud native management company

An empowerer of engineers, Layer5 helps you extract more value from your infrastructure. Creator and maintainer of cloud native standards. Maker of Meshery, the cloud native manager.