Add netpol endport documentation before release

content/en/docs/concepts/services-networking/network-policies.md

@@ -221,6 +221,48 @@ When the feature gate is enabled, you can set the `protocol` field of a NetworkP
 You must be using a {{< glossary_tooltip text="CNI" term_id="cni" >}} plugin that supports SCTP protocol NetworkPolicies.
 {{< /note >}}
 
+## Targeting a range of Ports
+
+{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
+
+When writing a Network Policy, you can target a range of Ports instead of a single port.
+
+This is achiveable with the usage of the `endPort` field, as the following example:
+
+```yaml
+apiVersion: networking.k8s.io/v1
+kind: NetworkPolicy
+metadata:
+  name: multi-port-egress
+  namespace: default
+spec:
+  podSelector:
+    matchLabels:
+      role: db
+  policyTypes:
+  - Egress
+  egress:
+  - to:
+    - ipBlock:
+        cidr: 10.0.0.0/24
+    ports:
+    - protocol: TCP
+      port: 32000
+      endPort: 32768
+```
+
+The above rule will allow a Pod with label `db` on the namespace `default` to communicate with any IP within the range `10.0.0.0/24` if the target port is between the range 32000 and 32768.
+
+The following restrictions apply when using this field:
+* As an alpha feature, this is disabled by default. To enable endPort field at a cluster level, you (or your cluster administrator) will need to enable the `NetworkPolicyEndPort` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) for the API server with `--feature-gates=NetworkPolicyEndPort=true,…`.
+* The `endPort` field must be equal than or greater to `port` field.
+* `endPort` can only be defined if `port` is also defined.
+* When using `endPort` field, the `port` field must be numeric.
+
+{{< note >}}
+You must be using a {{< glossary_tooltip text="CNI" term_id="cni" >}} plugin that supports endPort field in NetworkPolicies ports specification.
+{{< /note >}}
+
 ## What you can't do with network policies (at least, not yet)
 
 As of Kubernetes 1.20, the following functionality does not exist in the NetworkPolicy API, but you might be able to implement workarounds using Operating System components (such as SELinux, OpenVSwitch, IPTables, and so on) or Layer 7 technologies (Ingress controllers, Service Mesh implementations) or admission controllers.  In case you are new to network security in Kubernetes, its worth noting that the following User Stories cannot (yet) be implemented using the NetworkPolicy API.  Some (but not all) of these user stories are actively being discussed for future releases of the NetworkPolicy API.
@@ -232,7 +274,6 @@ As of Kubernetes 1.20, the following functionality does not exist in the Network
 - Creation or management of "Policy requests" that are fulfilled by a third party.
 - Default policies which are applied to all namespaces or pods (there are some third party Kubernetes distributions and projects which can do this).
 - Advanced policy querying and reachability tooling.
-- The ability to target ranges of Ports in a single policy declaration.
 - The ability to log network security events (for example connections that are blocked or accepted).
 - The ability to explicitly deny policies (currently the model for NetworkPolicies are deny by default, with only the ability to add allow rules).
 - The ability to prevent loopback or incoming host traffic (Pods cannot currently block localhost access, nor do they have the ability to block access from their resident node).