Update troubleshooting.adoc

Replaced the external link approach workaround with a fix that allows the preferred cross-reference syntax. Opening inline code with double backticks instead of single backticks was the true source of the problem.

latest/ug/troubleshooting/troubleshooting.adoc

@@ -36,7 +36,7 @@ If you receive the following error while attempting to create an Amazon EKS clus
 
 Retry creating your cluster with subnets in your cluster VPC that are hosted in the Availability Zones returned by this error message.
 
-There are Availability Zones that a cluster can't reside in. Compare the Availability Zones that your subnets are in with the list of Availability Zones in the link:/eks/latest/userguide/network-reqs.html#network-requirements-subnets[Subnet requirements and considerations,type="documentation"].
+There are Availability Zones that a cluster can't reside in. Compare the Availability Zones that your subnets are in with the list of Availability Zones in the <<network-requirements-subnets,Subnet requirements and considerations>>.
 
 [[worker-node-fail,worker-node-fail.title]]
 == Nodes fail to join cluster
@@ -45,9 +45,9 @@ There are a few common reasons that prevent nodes from joining the cluster:
 
 
 
-* If the nodes are managed nodes, Amazon EKS adds entries to the `aws-auth` `ConfigMap` when you create the node group. If the entry was removed or modified, then you need to re-add it. For more information, enter `eksctl create iamidentitymapping --help` in your terminal. You can view your current `aws-auth` `ConfigMap` entries by replacing [.replaceable]`my-cluster` in the following command with the name of your cluster and then running the modified command: ``eksctl get iamidentitymapping --cluster [.replaceable]`my-cluster```. The ARN of the role that you specify can't include a  link:IAM/latest/UserGuide/reference_identifiers.html#identifiers-friendly-names[path,type="documentation"] other than `/`. For example, if the name of your role is `development/apps/my-role`, you'd need to change it to `my-role` when specifying the ARN for the role. Make sure that you specify the node IAM role ARN (not the instance profile ARN).
+* If the nodes are managed nodes, Amazon EKS adds entries to the `aws-auth` `ConfigMap` when you create the node group. If the entry was removed or modified, then you need to re-add it. For more information, enter `eksctl create iamidentitymapping --help` in your terminal. You can view your current `aws-auth` `ConfigMap` entries by replacing [.replaceable]`my-cluster` in the following command with the name of your cluster and then running the modified command: `eksctl get iamidentitymapping --cluster [.replaceable]``my-cluster```. The ARN of the role that you specify can't include a  link:IAM/latest/UserGuide/reference_identifiers.html#identifiers-friendly-names[path,type="documentation"] other than `/`. For example, if the name of your role is `development/apps/my-role`, you'd need to change it to `my-role` when specifying the ARN for the role. Make sure that you specify the node IAM role ARN (not the instance profile ARN).
 +
-If the nodes are self-managed, and you haven't created link:/eks/latest/userguide/access-entries.html[access entries,type="documentation"] for the ARN of the node's IAM role, then run the same commands listed for managed nodes. If you have created an access entry for the ARN for your node IAM role, then it might not be configured properly in the access entry. Make sure that the node IAM role ARN (not the instance profile ARN) is specified as the principal ARN in your `aws-auth` `ConfigMap` entry or access entry. For more information about access entries, see <<access-entries>>.
+If the nodes are self-managed, and you haven't created <<access-entries,access entries>> for the ARN of the node's IAM role, then run the same commands listed for managed nodes. If you have created an access entry for the ARN for your node IAM role, then it might not be configured properly in the access entry. Make sure that the node IAM role ARN (not the instance profile ARN) is specified as the principal ARN in your `aws-auth` `ConfigMap` entry or access entry. For more information about access entries, see <<access-entries>>.
 * The *ClusterName* in your node {aws} CloudFormation template doesn't exactly match the name of the cluster you want your nodes to join. Passing an incorrect value to this field results in an incorrect configuration of the node's `/var/lib/kubelet/kubeconfig` file, and the nodes will not join the cluster.
 * The node is not tagged as being _owned_ by the cluster. Your nodes must have the following tag applied to them, where [.replaceable]`my-cluster` is replaced with the name of your cluster.
 +
@@ -83,8 +83,8 @@ This could be due to one of the following reasons:
 
 
 * The cluster was created with credentials for one IAM principal and `kubectl` is configured to use credentials for a different IAM principal. To resolve this, update your `kube config` file to use the credentials that created the cluster. For more information, see <<create-kubeconfig>>.
-* If your cluster meets the minimum platform requirements in the prerequisites section of link:/eks/latest/userguide/access-entries.html[Grant IAM users access to Kubernetes with EKS access entries,type="documentation"], an access entry doesn't exist with your IAM principal. If it exists, it doesn't have the necessary [.noloc]`Kubernetes` group names defined for it, or doesn't have the proper access policy associated to it. For more information, see <<access-entries>>.
-* If your cluster doesn't meet the minimum platform requirements in link:/eks/latest/userguide/access-entries.html[Grant IAM users access to Kubernetes with EKS access entries,type="documentation"], an entry with your IAM principal doesn't exist in the `aws-auth` `ConfigMap`. If it exists, it's not mapped to [.noloc]`Kubernetes` group names that are bound to a [.noloc]`Kubernetes` `Role` or `ClusterRole` with the necessary permissions. For more information about [.noloc]`Kubernetes` role-based authorization (RBAC) objects, see https://kubernetes.io/docs/reference/access-authn-authz/rbac/[Using RBAC authorization] in the [.noloc]`Kubernetes` documentation. You can view your current `aws-auth` `ConfigMap` entries by replacing [.replaceable]`my-cluster` in the following command with the name of your cluster and then running the modified command: ``eksctl get iamidentitymapping --cluster [.replaceable]`my-cluster```. If an entry for with the ARN of your IAM principal isn't in the `ConfigMap`, enter `eksctl create iamidentitymapping --help` in your terminal to learn how to create one. 
+* If your cluster meets the minimum platform requirements in the prerequisites section of <<access-entries,Grant IAM users access to Kubernetes with EKS access entries>>, an access entry doesn't exist with your IAM principal. If it exists, it doesn't have the necessary [.noloc]`Kubernetes` group names defined for it, or doesn't have the proper access policy associated to it. For more information, see <<access-entries>>.
+* If your cluster doesn't meet the minimum platform requirements in <<access-entries,Grant IAM users access to Kubernetes with EKS access entries>>, an entry with your IAM principal doesn't exist in the `aws-auth` `ConfigMap`. If it exists, it's not mapped to [.noloc]`Kubernetes` group names that are bound to a [.noloc]`Kubernetes` `Role` or `ClusterRole` with the necessary permissions. For more information about [.noloc]`Kubernetes` role-based authorization (RBAC) objects, see https://kubernetes.io/docs/reference/access-authn-authz/rbac/[Using RBAC authorization] in the [.noloc]`Kubernetes` documentation. You can view your current `aws-auth` `ConfigMap` entries by replacing [.replaceable]`my-cluster` in the following command with the name of your cluster and then running the modified command: `eksctl get iamidentitymapping --cluster [.replaceable]``my-cluster```. If an entry for with the ARN of your IAM principal isn't in the `ConfigMap`, enter `eksctl create iamidentitymapping --help` in your terminal to learn how to create one. 
 
 If you install and configure the {aws} CLI, you can configure the IAM credentials that you use. For more information, see link:cli/latest/userguide/cli-chap-getting-started.html[Configuring the {aws} CLI,type="documentation"] in the _{aws} Command Line Interface User Guide_. You can also configure `kubectl` to use an IAM role, if you assume an IAM role to access [.noloc]`Kubernetes` objects on your cluster. For more information, see <<create-kubeconfig>>.
 
@@ -164,7 +164,7 @@ Your Auto Scaling group is experiencing failures while attempting to launch inst
 Your launched instances are unable to register with your Amazon EKS cluster. Common causes of this failure are insufficient <<create-node-role,node IAM role>> permissions or lack of outbound internet access for the nodes. Your nodes must meet either of the following requirements:
 +
 ** Able to access the internet using a public IP address. The security group associated to the subnet the node is in must allow the communication. For more information, see <<network-requirements-subnets>> and <<sec-group-reqs>>.
-** Your nodes and VPC must meet the requirements in link:/eks/latest/userguide/private-clusters.html[Deploy private clusters with limited internet access,type="documentation"]. 
+** Your nodes and VPC must meet the requirements in <<private-clusters,Deploy private clusters with limited internet access>>. 
 
 
 *InstanceLimitExceeded*::
@@ -319,7 +319,7 @@ Retry the node group operation to see if that resolved your issue.
 [[not-authorized-for-images,not-authorized-for-images.title]]
 == `Not authorized for images`
 
-One potential cause of a `Not authorized for images` error message is using a private Amazon EKS [.noloc]`Windows` AMI to launch [.noloc]`Windows` managed node groups. After releasing new [.noloc]`Windows` AMIs, {aws} makes AMIs that are older than 4 months private, which makes them no longer accessible. If your managed node group is using a private [.noloc]`Windows` AMI, consider link:/eks/latest/userguide/update-managed-node-group.html[updating your Windows managed node group,type="documentation"]. While we can't guarantee that we can provide access to AMIs that have been made private, you can request access by filing a ticket with {aws} Support. For more information, see  link:AWSEC2/latest/WindowsGuide/aws-windows-ami.html#ami-patches-security-ID[Patches, security updates, and AMI IDs,type="documentation"] in the _Amazon EC2 User Guide_.
+One potential cause of a `Not authorized for images` error message is using a private Amazon EKS [.noloc]`Windows` AMI to launch [.noloc]`Windows` managed node groups. After releasing new [.noloc]`Windows` AMIs, {aws} makes AMIs that are older than 4 months private, which makes them no longer accessible. If your managed node group is using a private [.noloc]`Windows` AMI, consider  <<update-managed-node-group,updating your Windows managed node group>>. While we can't guarantee that we can provide access to AMIs that have been made private, you can request access by filing a ticket with {aws} Support. For more information, see  link:AWSEC2/latest/WindowsGuide/aws-windows-ami.html#ami-patches-security-ID[Patches, security updates, and AMI IDs,type="documentation"] in the _Amazon EC2 User Guide_.
 
 [[not-ready,not-ready.title]]
 == Node is in `NotReady` state
@@ -404,7 +404,7 @@ This can happen due to one of the following reasons:
 
 . You either don't have an `aws-auth` `ConfigMap` on your cluster or it doesn't include entries for the IAM role that you configured your nodes with.
 +
-To resolve the issue, view the existing entries in your `ConfigMap` by replacing [.replaceable]`my-cluster` in the following command with the name of your cluster and then running the modified command: ``eksctl get iamidentitymapping --cluster [.replaceable]`my-cluster```. If you receive an error message from the command, it might be because your cluster doesn't have an `aws-auth` `ConfigMap`. The following command adds an entry to the `ConfigMap`. If the `ConfigMap` doesn't exist, the command also creates it. Replace [.replaceable]`111122223333` with the {aws} account ID for the IAM role and [.replaceable]`myAmazonEKSNodeRole` with the name of your node's role.
+To resolve the issue, view the existing entries in your `ConfigMap` by replacing [.replaceable]`my-cluster` in the following command with the name of your cluster and then running the modified command: `eksctl get iamidentitymapping --cluster [.replaceable]``my-cluster```. If you receive an error message from the command, it might be because your cluster doesn't have an `aws-auth` `ConfigMap`. The following command adds an entry to the `ConfigMap`. If the `ConfigMap` doesn't exist, the command also creates it. Replace [.replaceable]`111122223333` with the {aws} account ID for the IAM role and [.replaceable]`myAmazonEKSNodeRole` with the name of your node's role.
 +
 [source,bash,subs="verbatim,attributes"]
 ----
@@ -414,7 +414,7 @@ eksctl create iamidentitymapping --cluster my-cluster \
 ----
 +
 The ARN of the role that you specify can't include a   link:IAM/latest/UserGuide/reference_identifiers.html#identifiers-friendly-names[path,type="documentation"] other than `/`. For example, if the name of your role is `development/apps/my-role`, you'd need to change it to `my-role` when specifying the ARN of the role. Make sure that you specify the node IAM role ARN (not the instance profile ARN).
-. Your self-managed nodes are in a cluster with a platform version at the minimum version listed in the prerequisites in the link:/eks/latest/userguide/access-entries.html[Grant IAM users access to Kubernetes with EKS access entries,type="documentation"] topic, but an entry isn't listed in the `aws-auth` `ConfigMap` (see previous item) for the node's IAM role or an access entry doesn't exist for the role. To resolve the issue, view your existing access entries by replacing [.replaceable]`my-cluster` in the following command with the name of your cluster and then running the modified command: ``aws eks list-access-entries --cluster-name [.replaceable]`my-cluster```. The following command adds an access entry for the node's IAM role. Replace [.replaceable]`111122223333` with the {aws} account ID for the IAM role and [.replaceable]`myAmazonEKSNodeRole` with the name of your node's role. If you have a Windows node, replace [.replaceable]`EC2_Linux` with `EC2_Windows`. Make sure that you specify the node IAM role ARN (not the instance profile ARN).
+. Your self-managed nodes are in a cluster with a platform version at the minimum version listed in the prerequisites in the <<access-entries,Grant IAM users access to Kubernetes with EKS access entries>> topic, but an entry isn't listed in the `aws-auth` `ConfigMap` (see previous item) for the node's IAM role or an access entry doesn't exist for the role. To resolve the issue, view your existing access entries by replacing [.replaceable]`my-cluster` in the following command with the name of your cluster and then running the modified command: `aws eks list-access-entries --cluster-name [.replaceable]``my-cluster```. The following command adds an access entry for the node's IAM role. Replace [.replaceable]`111122223333` with the {aws} account ID for the IAM role and [.replaceable]`myAmazonEKSNodeRole` with the name of your node's role. If you have a Windows node, replace [.replaceable]`EC2_Linux` with `EC2_Windows`. Make sure that you specify the node IAM role ARN (not the instance profile ARN).
 +
 [source,bash,subs="verbatim,attributes"]
 ----
@@ -500,10 +500,10 @@ You can identify all existing [.noloc]`Pods` in your cluster that are using stal
 [[troubleshooting-platform-version,troubleshooting-platform-version.title]]
 == Amazon EKS platform version is more than two versions behind the current platform version
 
-This can happen when Amazon EKS isn't able to automatically update your cluster's link:/eks/latest/userguide/platform-versions.html[platform version,type="documentation"]. Though there are many causes for this, some of the common causes follow. If any of these problems apply to your cluster, it may still function, its platform version just won't be updated by Amazon EKS.
+This can happen when Amazon EKS isn't able to automatically update your cluster's  <<platform-versions,platform version>>. Though there are many causes for this, some of the common causes follow. If any of these problems apply to your cluster, it may still function, its platform version just won't be updated by Amazon EKS.
 
 .Problem
-The link:/eks/latest/userguide/cluster-iam-role.html[cluster IAM role,type="documentation"] was deleted – This role was specified when the cluster was created. You can see which role was specified with the following command. Replace [.replaceable]`my-cluster` with the name of your cluster.
+The <<cluster-iam-role,cluster IAM role>> was deleted – This role was specified when the cluster was created. You can see which role was specified with the following command. Replace [.replaceable]`my-cluster` with the name of your cluster.
 
 [source,bash,subs="verbatim,attributes"]
 ----
@@ -518,7 +518,7 @@ eksClusterRole
 ----
 
 .Solution
-Create a new link:/eks/latest/userguide/cluster-iam-role.html[cluster IAM role,type="documentation"] with the same name.
+Create a new <<cluster-iam-role,cluster IAM role>> with the same name.
 
 .Problem
 A subnet specified during cluster creation was deleted – The subnets to use with the cluster were specified during cluster creation. You can see which subnets were specified with the following command. Replace [.replaceable]`my-cluster` with the name of your cluster.
@@ -605,7 +605,7 @@ When you initiate a [.noloc]`Kubernetes` version update for your cluster, the up
 
 
 * You don't have at least six (though we recommend 16) available IP addresses in each of the subnets that you specified when you created your cluster. If you don't have enough available IP addresses in the subnet, you either need to free up IP addresses in the subnet or you need to change the subnets used by the cluster to use subnets with enough available IP addresses.
-* You enabled link:/eks/latest/userguide/enable-kms.html[secrets encryption,type="documentation"] when you created your cluster and the {aws} KMS key that you specified has been deleted. If you want Amazon EKS to update the cluster, you need to create a new cluster
+* You enabled <<enable-kms,secrets encryption>> when you created your cluster and the {aws} KMS key that you specified has been deleted. If you want Amazon EKS to update the cluster, you need to create a new cluster
 
 
 [[cluster-health-status,cluster-health-status.title]]
@@ -720,4 +720,4 @@ The first two columns are what are needed for API response values. The third fie
 |===
 
 
-📝 https://github.com/search?q=repo:awsdocs/amazon-eks-user-guide+&#91;&#91;troubleshooting,&type=code[Edit this page on GitHub]
+📝 https://github.com/search?q=repo:awsdocs/amazon-eks-user-guide+&#91;&#91;troubleshooting,&type=code[Edit this page on GitHub]