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:
|Static band start||30000|
|Static band end||30085|
|Dynamic band start||30086|
|Dynamic band end||32767|
|Static band start||30000|
|Static band end||30015|
|Dynamic band start||N/A|
|Dynamic band end||N/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: v12kind: Service3metadata:4 name: minio5spec:6 ports:7 - name: api8 nodePort: 300099 port: 900010 protocol: TCP11 targetPort: 900012 selector:13 app: minio14 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.
MeshMap is here!
Design your deployments the way you want. Drag-and-drop your cloud native infrastructure using a pallete of thousands of versioned Kubernetes components. Say goodbye to YAML configurations. Have your cloud native deployments automatically diagrammed. Deployments configured and modeled in Designer mode, can be deployed into your environment and managed using Visualizer. Discover a catalog of best practice cloud native patterns