Remove KEP links from headings

Update 2024-11-04-kubernetes-1.32-sneak-peek.md

Author: mbianchidev

content/en/blog/_posts/2024-11-04-kubernetes-1.32-sneak-peek.md

@@ -101,33 +101,33 @@ Before this release, Kubernetes provided graceful node shutdown functionality fo
 
 KEP [#4885](https://github.com/kubernetes/enhancements/issues/4885) adds CPU and memory affinity support to Windows nodes in Kubernetes, thus improving performance for workloads that benefit from cache vicinity and NUMA optimizations; this effort also aligns Windows capabilities with Linux nodes.
 
-### Allow special characters in environment variables - [KEP #4369](https://github.com/kubernetes/enhancements/issues/4369)
+### Allow special characters in environment variables
 
-With the graduation of KEP-4369 to beta, Kubernetes now allows almost all printable ASCII characters (excluding "=") to be used as environment variable names. This change addresses the limitations previously imposed on variable naming, facilitating a broader adoption of Kubernetes by accommodating various application needs. The relaxed validation will be enabled by default via the `RelaxedEnvironmentVariableValidation` feature gate, ensuring that users can easily utilize environment variables without strict constraints, enhancing flexibility for developers working with applications like .NET Core that require special characters in their configurations.
+With the graduation of [this feature](https://github.com/kubernetes/enhancements/issues/4369) to beta, Kubernetes now allows almost all printable ASCII characters (excluding "=") to be used as environment variable names. This change addresses the limitations previously imposed on variable naming, facilitating a broader adoption of Kubernetes by accommodating various application needs. The relaxed validation will be enabled by default via the `RelaxedEnvironmentVariableValidation` feature gate, ensuring that users can easily utilize environment variables without strict constraints, enhancing flexibility for developers working with applications like .NET Core that require special characters in their configurations.
 
-### Field status.hostIPs added for Pod - [KEP #2681](https://github.com/kubernetes/enhancements/issues/2681)
+### Field status.hostIPs added for Pod
 
-This enhancement introduces a new field, `status.hostIPs`, to the Kubernetes Pod API, enabling support for multiple IP addresses (IPv4 and IPv6) assigned to a node. Previously, the Pod status only included a singular HostIP field, which limited address configurations, particularly in dual-stack networks. This enhancement allows the API to store multiple IP addresses in an array, accessible via the Downward API, which applications can leverage for environments with complex IP requirements, such as IPv6 migrations. 
+[This enhancement](https://github.com/kubernetes/enhancements/issues/2681) introduces a new field, `status.hostIPs`, to the Kubernetes Pod API, enabling support for multiple IP addresses (IPv4 and IPv6) assigned to a node. Previously, the Pod status only included a singular HostIP field, which limited address configurations, particularly in dual-stack networks. This enhancement allows the API to store multiple IP addresses in an array, accessible via the Downward API, which applications can leverage for environments with complex IP requirements, such as IPv6 migrations. 
 The feature is controlled by the PodHostIPs feature gate, supporting flexibility for gradual rollout.
 
-### Make Kubernetes aware of the LoadBalancer behavior - [KEP #1860](https://github.com/kubernetes/enhancements/issues/1860)
+### Make Kubernetes aware of the LoadBalancer behavior
 
 KEP [#1860](https://github.com/kubernetes/enhancements/issues/1860) graduates to GA, introducing the `ipMode` field for a Service of `type: LoadBalancer`, which can be set to either `"VIP"` or `"Proxy"`. This enhancement is aimed at improving how cloud providers load balancers interact with kube-proxy and it is a change transparent to the end user. The existing behavior of kube-proxy is preserved when using `"VIP"`, where kube-proxy handles the load balancing. Using `"Proxy"` results in traffic sent directly to the load balancer, providing cloud providers greater control over relying on kube-proxy; this means that you could see an improvement in the performance of your load balancer for some cloud providers.
 
-### Support PSI based on cgroupv2 - [KEP #4205](https://github.com/kubernetes/enhancements/issues/4205)
-This KEP adds support in the Kubelet to read Pressure Stall Information (PSI) metrics for CPU, Memory and I/O resources exposed from cAdvisor and runc. Pressure metrics are like a barometer that can warn about impending resource shortages on a node. This will enable the Kubelet to report node conditions, which can be utilized to prevent the scheduling of Pods on nodes experiencing significant resource constraints.
+### Support PSI based on cgroupv2
+[This KEP](https://github.com/kubernetes/enhancements/issues/4205) adds support in the Kubelet to read Pressure Stall Information (PSI) metrics for CPU, Memory and I/O resources exposed from cAdvisor and runc. Pressure metrics are like a barometer that can warn about impending resource shortages on a node. This will enable the Kubelet to report node conditions, which can be utilized to prevent the scheduling of Pods on nodes experiencing significant resource constraints.
 
-### Retry generate name for resources - [KEP #4420](https://github.com/kubernetes/enhancements/issues/4420)
-This enhancement improves how name conflicts are handled for Kubernetes resources created with the `generateName` field. Previously, if a name conflict occurred, the API server returned a 409 HTTP Conflict error and clients had to manually retry the request. With this update, the API server automatically retries generating a new name up to seven times in case of a conflict. This significantly reduces the chances of collision, ensuring smooth generation of up to 1 million names with less than a 0.1% probability of a conflict, providing more resilience for large-scale workloads.
+### Retry generate name for resources
+[This enhancement](https://github.com/kubernetes/enhancements/issues/4420) improves how name conflicts are handled for Kubernetes resources created with the `generateName` field. Previously, if a name conflict occurred, the API server returned a 409 HTTP Conflict error and clients had to manually retry the request. With this update, the API server automatically retries generating a new name up to seven times in case of a conflict. This significantly reduces the chances of collision, ensuring smooth generation of up to 1 million names with less than a 0.1% probability of a conflict, providing more resilience for large-scale workloads.
 
-### Mutating admission policies - [KEP #3962](https://github.com/kubernetes/enhancements/issues/3962)
+### Mutating admission policies
 
-This enhancement introduces "Mutating Admission Policies" using CEL (Common Expression Language), allowing Kubernetes users to define in-line mutating policies without complex admission webhooks. 
+[This enhancement](https://github.com/kubernetes/enhancements/issues/3962) introduces "Mutating Admission Policies" using CEL (Common Expression Language), allowing Kubernetes users to define in-line mutating policies without complex admission webhooks. 
 This enhancement simplifies common mutating tasks—such as adding labels, setting fields, or injecting sidecars—by enabling policies to be directly defined within the Kubernetes API server. With CEL's object instantiation and Server-Side Apply merge algorithms, these policies can minimize reinvocation, reduce latency, and eliminate the overhead associated with webhook management. This new approach enhances Kubernetes extensibility by reducing operational complexity, while providing a scalable, built-in solution for secure and efficient policy management across diverse use cases like GitOps and CI/CD. Making Kubernetes admission control more accessible and powerful for developers and administrators alike.
 
-### Control over terminating Pods in deployments - [KEP #3973](https://github.com/kubernetes/enhancements/issues/3973)
+### Control over terminating Pods in deployments
 
-This enhancement adds a new field `.spec.podReplacementPolicy` to Deployments to specify whether new Pods can be created only after old Pods have finished terminating or once old Pods start terminating. The default behavior depends on the deployment strategy. Specifying this Pod replacement policy can better control the speed of rollouts/scaling and potentially avoid problems with excessive resource usage.
+[This enhancement](https://github.com/kubernetes/enhancements/issues/3973) adds a new field `.spec.podReplacementPolicy` to Deployments to specify whether new Pods can be created only after old Pods have finished terminating or once old Pods start terminating. The default behavior depends on the deployment strategy. Specifying this Pod replacement policy can better control the speed of rollouts/scaling and potentially avoid problems with excessive resource usage.
 
 ## Want to know more?
 New features and deprecations are also announced in the Kubernetes release notes. We will formally announce what's new in [Kubernetes v1.32](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.32.md) as part of the CHANGELOG for this release.