OCPBUGS-49933:adds link to KI and updates attribute

release_notes/ocp-4-18-release-notes.adoc

@@ -529,7 +529,7 @@ For more information, see xref:../nodes/clusters/nodes-cluster-enabling-features
 
 In this release, enhancements have been made to the Rapid Recommendations mechanism for remotely configuring the rules that determine the data that the Insights Operator collects.
 
-The Rapid Recommendations feature is version-independent, and builds on the existing conditional data gathering mechanism. 
+The Rapid Recommendations feature is version-independent, and builds on the existing conditional data gathering mechanism.
 
 
 The Insights Operator connects to a secure remote endpoint service running on _console.redhat.com_ to retrieve definitions that contain the rules for determining which container log messages are filtered and collected by Red{nbsp}Hat.
@@ -609,7 +609,7 @@ You must configure {rh-openstack} prior to deploying your {product-title} cluste
 
 [id="ocp-4-18-installation-and-update-nutanix-multiple-nics_{context}"]
 ==== Installing a cluster on Nutanix with multiple subnets
-With this release, you can install a Nutanix cluster with more than one subnet for the Prism Element into which you are deploying an {product-title} cluster. 
+With this release, you can install a Nutanix cluster with more than one subnet for the Prism Element into which you are deploying an {product-title} cluster.
 
 For more information, see xref:../installing/installing_nutanix/installing-nutanix-installer-provisioned.adoc#installation-configuring-nutanix-failure-domains_installing-nutanix-installer-provisioned[Configuring failure domains] and xref:../installing/installing_nutanix/installation-config-parameters-nutanix.adoc#installation-configuration-parameters-additional-nutanix_installation-config-parameters-nutanix[Additional Nutanix configuration parameters].
 
@@ -2570,18 +2570,18 @@ There is no workaround for this issue.
 
  * The following known issues exist for configuring multiple subnets for an existing Nutanix cluster by using a control plane machine set:
 +
--- 
+--
 ** Adding subnets above the existing subnet in the `subnets` stanza causes a control plane node to become stuck in the `Deleting` state.
 As a workaround, only add subnets below the existing subnet in the `subnets` stanza.
 
 ** Sometimes, after adding a subnet, the updated control plane machines appear in the Nutanix console but the {product-title} cluster is unreachable.
 There is no workaround for this issue.
--- 
+--
 +
 These issues occur on clusters that use a control plane machine set to configure subnets regardless of whether subnets are specified in a failure domain or the provider specification.
-(link:https://issues.redhat.com/browse/OCPBUGS-50904[*OCPBUGS-50904*]) 
+(link:https://issues.redhat.com/browse/OCPBUGS-50904[*OCPBUGS-50904*])
 
-* There is a known issue with {op-base-system} 8 worker nodes that  use `cgroupv1` Linux Control Groups (cgroup). The following is an example of the error message displayed for impacted nodes: `UDN are not supported on the node ip-10-0-51-120.us-east-2.compute.internal as it uses cgroup v1.` As a workaround, users should migrate worker nodes from `cgroupv1` to `cgroupv2`. (link:https://issues.redhat.com/browse/OCPBUGS-49933[*OCPBUGS-49933*])
+* There is a known issue with nodes that use `cgroupv1` Linux Control Groups (cgroup). The following is an example of the error message displayed for impacted nodes: `UDN are not supported on the node ip-10-0-51-120.us-east-2.compute.internal as it uses cgroup v1.` An event of type `Warning` `UDNKubeletProbesNotSupported` is triggered for impacted nodes. As a workaround, users must reconfigure their nodes from `cgroupv1` to `cgroupv2` before creating a user-defined network. For more information, see xref:../nodes/clusters/nodes-cluster-cgroups-2.adoc#nodes-cluster-cgroups-2[Configuring Linux cgroup]. (link:https://issues.redhat.com/browse/OCPBUGS-49933[*OCPBUGS-49933*])
 
 * The current PTP grandmaster clock (T-GM) implementation has a single National Marine Electronics Association (NMEA) sentence generator sourced from the GNSS without a backup NMEA sentence generator. If NMEA sentences are lost before reaching the e810 NIC, the T-GM cannot synchronize the devices in the network synchronization chain and the PTP Operator reports an error. A proposed fix is to report a `FREERUN` event when the NMEA string is lost. Until this limitation is addressed, T-GM does not support PTP clock holdover state. (link:https://issues.redhat.com/browse/OCPBUGS-19838[*OCPBUGS-19838*])