add blog document for feature ServiceNodePortStaticSubrange

Author: xuzhenglun

content/en/blog/_posts/2023-03-08-nodeport-dynamic-and-static-allocation.md

@@ -0,0 +1,93 @@
+---
+layout: blog
+title: "Kubernetes 1.27: Avoid Collisions Assigning ports to Nodeport Services"
+date: 2023-03-08
+slug: nodeport-dynamic-and-static-allocation
+---
+
+**Author:** xuzhenglun
+
+In Kubernetes, the Service can be used to provide a unified traffic entry point for applications running on a set of Pods. Clients can use the virtual IP address provided by the Service for access, and Kubernetes provides load balancing for traffic accessing different back-end Pods, but ClusterIP-type Service is limited to providing access to nodes within the cluster, and traffic from outside the cluster cannot be routed. One way to solve this problem is to use NodePort-type Service, which maps a VIP's port to a specific port of all nodes in the cluster, thus redirecting traffic from the outside to the inside of the cluster.
+
+## How NodePort's ports are allocated? 
+
+When a NodePort-type Service is created, its corresponding port is allocated in two ways.
+
+**Dynamic** : If the Service type is NodePort and the corresponding `service.spec.ports.nodePort` is not specified, the Kubernetes controlpalne will automatically allocat a unused port to it at creation time.
+
+**Static** : In addition to the dynamic auto-assignment described above, you can also explicitly assign a port that is within the nodeport port configuration.
+
+the `service.spec.ports.nodePort` must be unique for each NodePort-type Service across the cluster. Attempting to create a NodePort-type Service with a port already allocated will return an error.
+
+## Why do you need to reserve ports of NodePort-type Service? 
+Sometimes, you may want to have the NodePort-type Service running on well-known ports so that other components and users inside and outside the cluster can use them.
+
+In some complex cluster deployments with a mix of K8S nodes and non-K8S nodes, it may be necessary to rely on some pre-defined port for communicating. In particular, some fundamental components cannot rely on the VIPs which provided by LoadBalancer-type  services, because the load balancing itself that provides the VIPs may also rely on these fundamental components.
+
+Now suppose we need to expose the Minio object storage service on K8S to services located on non-K8S nodes, and the agreed port is `30009`, we need to create a Service as follows:
+
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+  labels:
+    k8s-app: minio
+  name: minio
+  namespace: kube-system
+spec:
+  ports:
+  - name: http
+    nodePort: 30009
+    port: 9000
+    protocol: TCP
+    targetPort: 9000
+  selector:
+    app: minio
+  type: NodePort
+```
+
+However, as mentioned before, if the port `30009` required for the minio Service is not reserved, and another NodePort Service is created and dynamically allocated before or concurrently with minio Service, `30009` can be allocated to those NodePort Service, and minio Service will fail to be created due to a port conflict.
+
+## How can you avoid NodePort-type Service port conflicts? 
+In the Kubernetes 1.24, Service ClusterIP had already divided the CIDRs into two blocks, using different allocation policies to reduce the risk of conflicts. In Kubernetes 1.27, a similar policy can be adopted for NodePort. You can enable a new featuregate `ServiceNodePortStaticSubrange`. Turning this on allows you to use a different port allocation strategy for NodePort-type Services, and reducing the risk of collision.
+
+The port range for `NodePort` will be divided, based on the formula `min(max(16, nodeport-size / 32), 128)`, which can be described as _never less than 16 or more than 128 with a graduated step between them_.
+
+Dynamic port assignment will use the upper band by default, once this has been exhausted it will use the lower range. This will allow users to use static allocations on the lower band with a low risk of collision.
+
+## Examples:
+
+### default range
+service-node-port-range: 30000-32767
+Band Offset: min(max(16, 2768/32), 128) = min(max(16, 86), 128) = min(86, 128) = 86
+Static band start: 30000
+Static band end: 30085
+Range end: 32767
+
+### very small range
+service-node-port-range: 30000-30015
+Band Offset: 0
+Static band start: 30000
+Static band end: 30000
+Range end: 30015
+
+### small(lower boundary) range
+service-node-port-range: 30000-30127
+Band Offset: min(max(16, 128/32), 128) = min(max(16, 4), 128) = min(16, 128) = 16
+Static band start: 30000
+Static band end: 30015
+Range end: 30127
+
+### large(upper boundary) range
+service-node-port-range: 30000-34095
+Band Offset: min(max(16, 4096/32), 128) = min(max(16, 128), 128) = min(128, 128) = 128
+Static band start: 30000
+Static band end: 30127
+Range end: 34095
+
+### very large range
+service-node-port-range: 30000-38191
+Band Offset: min(max(16, 8192/32), 128) = min(max(16, 256), 128) = min(256, 128) = 128
+Static band start: 30000
+Static band end: 30127
+Range end: 38191

content/en/docs/reference/command-line-tools-reference/feature-gates.md

@@ -186,6 +186,7 @@ For a reference to old feature gates that are removed, please refer to
 | `SeccompDefault` | `true` | Beta | 1.25 | |
 | `ServerSideFieldValidation` | `false` | Alpha | 1.23 | 1.24 |
 | `ServerSideFieldValidation` | `true` | Beta | 1.25 | |
+| `ServiceNodePortStaticSubrange` | `false` | Alpha | 1.27 | |
 | `SizeMemoryBackedVolumes` | `false` | Alpha | 1.20 | 1.21 |
 | `SizeMemoryBackedVolumes` | `true` | Beta | 1.22 | |
 | `StatefulSetAutoDeletePVC` | `false` | Alpha | 1.22 | |