From 41f6edfe19f761f4a0259e91cd756392bcff5ebe Mon Sep 17 00:00:00 2001 From: EricPonvelle Date: Thu, 9 Jul 2026 14:07:02 -0500 Subject: [PATCH] OSDOC-20065: AutoNode Post-GA Updates --- _topic_maps/_topic_map_rosa_hcp.yml | 2 + modules/autonode-troubleshooting.adoc | 45 ++++++ modules/karpenter-resource-readiness.adoc | 59 ++++++++ .../query-ec2nodeclass-condition-status.adoc | 31 ++++ modules/resolve-ec2nodeclass-not-ready.adoc | 139 ++++++++++++++++++ modules/resolve-iam-permissions-tagging.adoc | 91 ++++++++++++ modules/verify-karpenter-crds.adoc | 57 +++++++ modules/verify-ocm-capabilities.adoc | 53 +++++++ .../rosa-nodes-managing-karpenter.adoc | 5 +- .../rosa-troubleshooting-autonode.adoc | 58 ++++++++ 10 files changed, 538 insertions(+), 2 deletions(-) create mode 100644 modules/autonode-troubleshooting.adoc create mode 100644 modules/karpenter-resource-readiness.adoc create mode 100644 modules/query-ec2nodeclass-condition-status.adoc create mode 100644 modules/resolve-ec2nodeclass-not-ready.adoc create mode 100644 modules/resolve-iam-permissions-tagging.adoc create mode 100644 modules/verify-karpenter-crds.adoc create mode 100644 modules/verify-ocm-capabilities.adoc create mode 100644 support/troubleshooting/rosa-troubleshooting-autonode.adoc diff --git a/_topic_maps/_topic_map_rosa_hcp.yml b/_topic_maps/_topic_map_rosa_hcp.yml index 8cfea8251c56..30f2dad1121e 100644 --- a/_topic_maps/_topic_map_rosa_hcp.yml +++ b/_topic_maps/_topic_map_rosa_hcp.yml @@ -401,6 +401,8 @@ Topics: File: rosa-troubleshooting-networking - Name: Verifying node health File: verifying-node-health + - Name: Troubleshooting Red Hat build of Karpenter + File: rosa-troubleshooting-autonode # cannot create resource "namespaces", cannot patch resource "nodes" # - Name: Troubleshooting CRI-O container runtime issues # File: troubleshooting-crio-issues diff --git a/modules/autonode-troubleshooting.adoc b/modules/autonode-troubleshooting.adoc new file mode 100644 index 000000000000..f94c12be85ed --- /dev/null +++ b/modules/autonode-troubleshooting.adoc @@ -0,0 +1,45 @@ +:_mod-docs-content-type: CONCEPT +[id="autonode-troubleshooting-overview_{context}"] += About {autonode} troubleshooting + +[role="_abstract"] +The {autonode} uses the Karpenter controller to provide automated node provisioning in OpenShift clusters. When the {autonode} fails to provision nodes or reports configuration errors, you can diagnose and resolve issues by examining Karpenter resource status, AWS infrastructure tags, and AWS Identity and and Access Management (IAM) permissions. + +{autonode} troubleshooting addresses four main failure categories: + +Controller deployment issues:: Karpenter Custom Resource Definitions (CRDs) do not appear after enabling the {autonode}, preventing you from creating or managing Karpenter resources. + +AWS resource discovery failures:: The EC2NodeClass resource cannot discover AWS subnets or security groups because required discovery tags are missing or incorrect. + +IAM permission issues:: The control plane operator lacks authorization to create tags on AWS resources, preventing Karpenter from properly configuring security groups. + +{cluster-manager} capability requirements:: Your organization does not have the required {cluster-manager-first} capabilities to create {autonode} clusters on the designated provision shard. + +[id="autonode-troubleshooting-diagnostic-workflow_{context}"] +== General diagnostic workflow + +Follow this workflow to diagnose and resolve {autonode} issues: + +. Identify the symptom by checking which Karpenter resources are missing or not ready. +. Gather diagnostic data using `oc` commands to inspect custom resource status and AWS CLI commands to verify infrastructure configuration. +. Analyze the root cause by comparing observed resource state with expected configuration. +. Apply the resolution by adding missing tags, updating IAM policies, or verifying capabilities. +. Verify the fix by confirming that Karpenter resources reach ready status and automatic scaling functions correctly. + +[id="autonode-troubleshooting-escalating_{context}"] +== When to escalate to Red{nbsp}Hat Support + +Escalate to Red{nbsp}Hat Support in these situations: + +* Karpenter CRDs do not appear after 5 minutes and the Karpenter controller pod is not running. +* EC2NodeClass remains not ready after adding all required discovery tags and waiting 60 seconds. +* IAM policies are correctly attached but CloudTrail continues showing authorization errors. +* You have verified {cluster-manager} capabilities but cluster creation on the designated provision shard still fails. + +When escalating, provide: + +* Cluster ID +* Output of `rosa describe cluster -c $CLUSTER_ID -o json` +* Output of `oc get ec2nodeclass/default -o json` +* Output of `oc get pods -n kube-system` +* CloudTrail event details for authorization errors diff --git a/modules/karpenter-resource-readiness.adoc b/modules/karpenter-resource-readiness.adoc new file mode 100644 index 000000000000..4e2bc0fae511 --- /dev/null +++ b/modules/karpenter-resource-readiness.adoc @@ -0,0 +1,59 @@ +:_mod-docs-content-type: REFERENCE +[id="karpenter-resource-readiness-conditions_{context}"] += Karpenter resource readiness conditions + +[role="_abstract"] +The EC2NodeClass resource reports readiness through status conditions that indicate whether Karpenter successfully discovered and validated AWS resources. Each condition reports a boolean status and explains why the condition is true or false. Understanding these conditions helps you identify which AWS resources require configuration changes. + +.EC2NodeClass status conditions +[cols="1,1,3", options="header"] +|=== +|Condition +|Status values +|Meaning + +|`AMIsReady` +|`True` or `False` +|The Amazon Machine Images (AMI) selector matched available AMIs in the AWS region. +If `False`, the specified AMI selector did not match any AMIs accessible to your AWS account. + +|`SubnetsReady` +|`True` or `False` +|The subnet selector matched private subnets with the required Karpenter discovery tag. +If `False`, no subnets in your VPC have the `karpenter.sh/discovery` tag with the value expected by the EC2NodeClass. + +|`SecurityGroupsReady` +|`True` or `False` +|The security group selector matched security groups with the required Karpenter discovery tag. +If `False`, no security groups have the `karpenter.sh/discovery` tag with the value expected by the EC2NodeClass. + +|`InstanceProfileReady` +|`True` or `False` +|The IAM instance profile exists and is accessible to Karpenter. +If `False`, the specified instance profile name is incorrect or the profile does not exist in your AWS account. + +|`ValidationSucceeded` +|`True` or `False` +|The EC2NodeClass specification passed validation. +If `False`, the EC2NodeClass contains invalid configuration values or references non-existent resources. + +|`Ready` +|`True` or `False` +|Overall readiness status. +This condition is `True` only when all dependent conditions (`AMIsReady`, `SubnetsReady`, `SecurityGroupsReady`, `InstanceProfileReady`, `ValidationSucceeded`) are `True`. +If `False`, the message field lists which conditions are not ready. +|=== + +[id="karpenter-resource-readiness-conditions-common-failures_{context}"] +== Common failure messages + +When EC2NodeClass conditions report `False` status, the message field provides details about the failure: + +SubnetSelector did not match any Subnets:: No subnets in your VPC have the required `karpenter.sh/discovery` tag. +Add the tag to all private subnets where Karpenter should provision nodes. + +SecurityGroupSelector did not match any SecurityGroups:: No security groups have the required `karpenter.sh/discovery` tag. +Add the tag to the default security group and any additional security groups Karpenter should use. + +UnhealthyDependents:: The `Ready` condition shows this message when one or more dependent conditions are `False`. +The message lists which specific conditions are not ready, for example: `SecurityGroupsReady=False, SubnetsReady=False`. diff --git a/modules/query-ec2nodeclass-condition-status.adoc b/modules/query-ec2nodeclass-condition-status.adoc new file mode 100644 index 000000000000..1ba732a80fc4 --- /dev/null +++ b/modules/query-ec2nodeclass-condition-status.adoc @@ -0,0 +1,31 @@ +:_mod-docs-content-type: PROCEDURE +[id="query-ec2nodeclass-condition-status_{context}"] += Query EC2NodeClass condition status + +[role="_abstract"] +Use the `oc` command-line interface to inspect EC2NodeClass status conditions and identify which AWS resources require configuration changes. + +.Procedure + +. To view the full condition status for an EC2NodeClass, run: ++ +[source,terminal] +---- +$ oc get ec2nodeclass/default -o json | jq .status.conditions +---- ++ +The output displays all condition types with their status, reason, and explanatory message. + +. Optional: To view only the overall `Ready` condition, run: ++ +[source,terminal] +---- +$ oc get ec2nodeclass/default -o json | jq '.status.conditions[] | select(.type=="Ready")' +---- ++ +The output shows the `Ready` condition type, status, reason, and message explaining why the condition is in that state. + +.Verification + +* Review the output to identify which conditions show `"status": "False"`. +* Check the `message` field for each failed condition to determine what AWS resources need configuration changes. diff --git a/modules/resolve-ec2nodeclass-not-ready.adoc b/modules/resolve-ec2nodeclass-not-ready.adoc new file mode 100644 index 000000000000..00b731b36590 --- /dev/null +++ b/modules/resolve-ec2nodeclass-not-ready.adoc @@ -0,0 +1,139 @@ +:_mod-docs-content-type: PROCEDURE +[id="resolve-ec2nodeclass-not-ready-status_{context}"] += Resolve EC2NodeClass not ready status + +[role="_abstract"] +Karpenter discovers AWS subnets and security groups by searching for resources tagged with a cluster-specific discovery tag. When the EC2NodeClass resource reports `SubnetsReady` or `SecurityGroupsReady` conditions as `False`, you need to add the required discovery tag to your AWS VPC resources. + +.Procedure + +. Check the EC2NodeClass status: ++ +[source,terminal] +---- +$ oc get ec2nodeclass/default -o json | jq .status.conditions +---- ++ +This command displays all status conditions for the default EC2NodeClass. + +. Identify which conditions are not ready by looking for entries with `"status": "False"`. ++ +Common failures are `SubnetsReady` and `SecurityGroupsReady`. + +. If `SubnetsReady` shows `False` with message "SubnetSelector did not match any Subnets", private subnets in your VPC are missing the required discovery tag. +Continue to the next step. + +. If `SecurityGroupsReady` shows `False` with message "SecurityGroupSelector did not match any SecurityGroups", security groups are missing the required discovery tag. +The same resolution process applies for both subnets and security groups. + +. Get the Karpenter discovery tag value from the EC2NodeClass specification: ++ +[source,terminal] +---- +$ oc get ec2nodeclass/default -o json | jq -r '.spec.subnetSelectorTerms[0].tags["karpenter.sh/discovery"]' +---- ++ +.Example output +[source,terminal] +---- +2m46sfl77ldkukbskhhs8uk5or2gm2p8 +---- ++ +This cluster-specific value must be added as a tag to AWS resources. + +. List private subnets in your cluster VPC: ++ +[source,terminal] +---- +$ aws ec2 describe-subnets --filters "Name=vpc-id,Values=" \ + --query 'Subnets[?MapPublicIpOnLaunch==`false`].[SubnetId,Tags]' --output table +---- ++ +Replace `` with your cluster's VPC ID. + +. For each private subnet, verify whether the Karpenter discovery tag is present: ++ +[source,terminal] +---- +$ aws ec2 describe-subnets --subnet-ids \ + --query 'Subnets[0].Tags[?Key==`karpenter.sh/discovery`].Value' --output text +---- ++ +Replace `` with the subnet ID to check. + +. If the discovery tag is missing, add it to the subnet: ++ +[source,terminal] +---- +$ aws ec2 create-tags --resources \ + --tags Key=karpenter.sh/discovery,Value= +---- ++ +Replace `` with the subnet ID and `` with the value from step 5. + +. Repeat steps 7 and 8 for all private subnets in your VPC. + +. Verify that the default security group has the discovery tag: ++ +[source,terminal] +---- +$ aws ec2 describe-security-groups --group-ids \ + --query 'SecurityGroups[0].Tags[?Key==`karpenter.sh/discovery`].Value' --output text +---- ++ +Replace `` with your cluster's default security group ID. + +. If the discovery tag is missing from the security group, add it: ++ +[source,terminal] +---- +$ aws ec2 create-tags --resources \ + --tags Key=karpenter.sh/discovery,Value= +---- ++ +Replace `` with the security group ID and `` with the value from step 5. + +. Wait 30 to 60 seconds for Karpenter to re-scan AWS resources. + +. Verify that the EC2NodeClass Ready condition is now `True`: ++ +[source,terminal] +---- +$ oc get ec2nodeclass/default -o json | jq '.status.conditions[] | select(.type=="Ready")' +---- ++ +The output should show `"status": "True"`. + +. If the Ready condition is still `False`, check for other condition failures in the output and repeat the appropriate steps. + +.Verification + +* The EC2NodeClass Ready condition reports `True` status: ++ +[source,terminal] +---- +$ oc get ec2nodeclass/default -o json | jq '.status.conditions[] | select(.type=="Ready")' +---- + +* The SubnetsReady and SecurityGroupsReady conditions report `True` status: ++ +[source,terminal] +---- +$ oc get ec2nodeclass/default -o json | jq '.status.conditions[] | select(.type=="SubnetsReady" or .type=="SecurityGroupsReady")' +---- + +* All required AWS resources have the correct `karpenter.sh/discovery` tag: ++ +[source,terminal] +---- +$ aws ec2 describe-subnets --subnet-ids \ + --query 'Subnets[0].Tags[?Key==`karpenter.sh/discovery`].Value' --output text +---- + +.Troubleshooting + +If adding tags fails with authorization errors:: You need to update IAM permissions for the control plane operator. +See "Resolve IAM permissions for AWS resource tagging". + +If the EC2NodeClass remains not ready after adding tags:: Verify that the tag value exactly matches the value in the EC2NodeClass specification. +Tag values are case-sensitive and must match character-for-character. diff --git a/modules/resolve-iam-permissions-tagging.adoc b/modules/resolve-iam-permissions-tagging.adoc new file mode 100644 index 000000000000..99486e763021 --- /dev/null +++ b/modules/resolve-iam-permissions-tagging.adoc @@ -0,0 +1,91 @@ +:_mod-docs-content-type: PROCEDURE +[id="resolve-iam-permissions-for-tagging_{context}"] += Resolve IAM permissions for AWS resource tagging + +[role="_abstract"] +The Karpenter controller requires permission to create tags on AWS security groups. When the control plane operator IAM role lacks the `ec2:CreateTags` permission, Karpenter cannot automatically tag security groups with the discovery tag. + +.Procedure + +. Identify the IAM role used by the control plane operator: ++ +[source,terminal] +---- +$ aws iam list-roles | grep kube-system-control-plane-operator +---- ++ +The role name follows the pattern `-kube-system-control-plane-operator`. + +. Optional: Verify the authorization error in AWS CloudTrail: +.. Navigate to the AWS CloudTrail console. +.. Search for events matching these criteria: ++ +-- +* Event name: `CreateTags` +* Error code: `Client.UnauthorizedOperation` +* User identity: Contains `control-plane-operator` +-- ++ +If you find matching events, the error message confirms that the IAM role lacks `ec2:CreateTags` permission. + +. Create an IAM policy document that allows creating tags: ++ +[source,terminal] +---- +$ cat > /tmp/create-tags-policy.json << 'POLICY_EOF' +{ + "Version": "2012-10-17", + "Statement": [ + { + "Sid": "AllowCreateTags", + "Effect": "Allow", + "Action": [ + "ec2:CreateTags" + ], + "Resource": "*" + } + ] +} +POLICY_EOF +---- + +. Attach the policy to the control plane operator IAM role: ++ +[source,terminal] +---- +$ aws iam put-role-policy \ + --role-name -kube-system-control-plane-operator \ + --policy-name KarpenterCreateTags \ + --policy-document file:///tmp/create-tags-policy.json +---- ++ +Replace `` with your cluster's prefix from step 1. + +. Verify that the policy is attached to the role: ++ +[source,terminal] +---- +$ aws iam get-role-policy \ + --role-name -kube-system-control-plane-operator \ + --policy-name KarpenterCreateTags +---- ++ +The output shows the policy document you attached. + +.Verification + +* The IAM policy is successfully attached to the control plane operator role: ++ +[source,terminal] +---- +$ aws iam get-role-policy \ + --role-name -kube-system-control-plane-operator \ + --policy-name KarpenterCreateTags +---- ++ +This command returns the policy document without errors. + +* AWS CloudTrail no longer shows `Client.UnauthorizedOperation` errors for CreateTags operations performed by the control plane operator. + +* If your EC2NodeClass previously showed `SecurityGroupsReady = False`, you can now manually add the Karpenter discovery tag to the default security group. +After you add the tag, the authorization error will not recur because the IAM role now has the required permissions. diff --git a/modules/verify-karpenter-crds.adoc b/modules/verify-karpenter-crds.adoc new file mode 100644 index 000000000000..ea104f0a1106 --- /dev/null +++ b/modules/verify-karpenter-crds.adoc @@ -0,0 +1,57 @@ +:_mod-docs-content-type: PROCEDURE +[id="verify-karpenter-crds-installed_{context}"] += Verify Karpenter CRDs are installed + +[role="_abstract"] +After enabling the {autonode} on a {product-title} cluster, the Karpenter controller automatically creates Custom Resource Definitions (CRDs) in your cluster. If Karpenter CRDs do not appear within several minutes, you can verify that your cluster is deployed to the correct provision shard and check the controller deployment status. + +.Procedure + +. Verify that your cluster is deployed to the correct provision shard for the {autonode} private preview: ++ +[source,terminal] +---- +$ rosa describe cluster -c $CLUSTER_ID -o json | jq -r .properties.provision_shard_id +---- ++ +.Example output +[source,terminal] +---- +9f11dd2b-98c1-11f0-8fe5-0a580a830a08 +---- + +. If the shard ID does not match `9f11dd2b-98c1-11f0-8fe5-0a580a830a08`, your cluster is deployed to the wrong provision shard and the {autonode} is not available. Contact Red{nbsp}Hat Support or create a new cluster on the correct shard. + +. If the shard ID matches, check for Karpenter CRDs: ++ +[source,terminal] +---- +$ oc get crd | grep karpenter +---- ++ +.Example output +[source,terminal] +---- +ec2nodeclasses.karpenter.k8s.aws +nodeclaims.karpenter.sh +nodepools.karpenter.sh +---- + +. If CRDs are not present, wait 5 minutes for the Karpenter controller to create them. The controller deployment may take several minutes to complete after enabling the {autonode}. + +. After 5 minutes, if CRDs are still not present, check whether the Karpenter controller pod is running: ++ +[source,terminal] +---- +$ oc get pods -n kube-system | grep karpenter +---- ++ +The output should show a Karpenter controller pod in `Running` status. + +. If the controller pod is not running or CRDs are still missing after 5 minutes, escalate to Red{nbsp}Hat Support. Provide the following diagnostic information: ++ +-- +* Your cluster ID +* Output of `rosa describe cluster -c $CLUSTER_ID -o json` +* Output of `oc get pods -n kube-system` +-- diff --git a/modules/verify-ocm-capabilities.adoc b/modules/verify-ocm-capabilities.adoc new file mode 100644 index 000000000000..900377768518 --- /dev/null +++ b/modules/verify-ocm-capabilities.adoc @@ -0,0 +1,53 @@ +:_mod-docs-content-type: PROCEDURE +[id="verify-ocm-capabilities-for-autonode_{context}"] += Verify {cluster-manager} capabilities for {autonode} + +[role="_abstract"] +The {autonode} is available as a private preview and requires specific {cluster-manager-first} capabilities in your organization. If cluster creation fails when you specify the {autonode} provision shard, your organization may lack the required capabilities. + +.Procedure + +* If cluster creation fails with an error indicating that the provision shard is unavailable, verify that the shard ID is correct: ++ +[source,terminal] +---- +$ rosa describe cluster -c $CLUSTER_ID -o json | jq -r .properties.provision_shard_id +---- ++ +.Example output +[source,terminal] +---- +9f11dd2b-98c1-11f0-8fe5-0a580a830a08 +---- ++ +The {autonode} private preview provision shard ID is `9f11dd2b-98c1-11f0-8fe5-0a580a830a08`. + +* Confirm that your organization has the "pin clusters to shard" capability. ++ +[source,terminal] +---- +HOW +---- ++ +This capability allows you to create clusters on a specific provision shard. + +* If you lack this capability, contact your Red{nbsp}Hat account team or Technical Account Manager to request it. When requesting the capability, provide your OCM organization ID. + +* If cluster creation succeeds but the {autonode} features are unavailable after enabling the {autonode}, verify that your organization has the "AutoNode private preview" capability. + +* If you lack the {autonode} capability, contact your Red{nbsp}Hat account team or Technical Account Manager to request it. When requesting the capability, provide your OCM organization ID. + +.Verification + +* Cluster creation succeeds when you specify the {autonode} provision shard: ++ +[source,terminal] +---- +$ rosa describe cluster -c $CLUSTER_ID -o json | jq -r .properties.provision_shard_id +---- ++ +The output shows `9f11dd2b-98c1-11f0-8fe5-0a580a830a08`. + +* You can enable the {autonode} during or after cluster creation. + +* Karpenter CRDs appear in your cluster after enabling the {autonode}. diff --git a/rosa_cluster_admin/rosa-nodes-managing-karpenter.adoc b/rosa_cluster_admin/rosa-nodes-managing-karpenter.adoc index b7ee6433343c..a3c2e740636b 100644 --- a/rosa_cluster_admin/rosa-nodes-managing-karpenter.adoc +++ b/rosa_cluster_admin/rosa-nodes-managing-karpenter.adoc @@ -1,9 +1,9 @@ :_mod-docs-content-type: ASSEMBLY -include::_attributes/attributes-openshift-dedicated.adoc[] [id="rosa-nodes-autonode-managing"] -= Manage compute nodes using {autonode} += Manage compute nodes using Red{nbsp}Hat build of Karpenter :context: rosa-nodes-autonode-managing +include::_attributes/attributes-openshift-dedicated.adoc[] toc::[] [role="_abstract"] @@ -36,3 +36,4 @@ include::modules/rosa-nodes-autonode-managing-create-nodepool.adoc[leveloffset=+ * link:https://karpenter.sh/docs/concepts/nodepools/[`NodePools` reference] * xref:../authentication/sd-configuring-identity-providers.adoc#sd-configuring-identity-providers[Identity providers overview] * xref:../upgrading/rosa-hcp-upgrading.adoc#rosa-upgrade-options_rosa-hcp-upgrading[Update options for {product-title} clusters configured with {autonode}] +* xref:../support/troubleshooting/rosa-troubleshooting-autonode.adoc#rosa-troubleshooting-autonode[Troubleshoot {autonode} configuration and operational issues] diff --git a/support/troubleshooting/rosa-troubleshooting-autonode.adoc b/support/troubleshooting/rosa-troubleshooting-autonode.adoc new file mode 100644 index 000000000000..2b34a5500e17 --- /dev/null +++ b/support/troubleshooting/rosa-troubleshooting-autonode.adoc @@ -0,0 +1,58 @@ +:_mod-docs-content-type: ASSEMBLY +[id="rosa-troubleshooting-autonode"] += Troubleshoot Red{nbsp}Hat build of Karpenter configuration and operational issues + +include::_attributes/attributes-openshift-dedicated.adoc[] +:context: rosa-troubleshooting-autonode +toc::[] + +[role="_abstract"] +Understanding common failure categories for the {autonode} helps you quickly identify the root cause and restore automatic scaling capabilities. Use the following table to identify which procedure addresses your symptom: + +.Symptom-to-procedure mapping +[cols="2,3", options="header"] +|=== +|Symptom +|Procedure + +|Karpenter Custom Resource Definitions (CRDs) are not visible after enabling the {autonode} +|Verify Karpenter CRDs are installed + +|EC2NodeClass shows `SubnetsReady` or `SecurityGroupsReady` = `False` +|Resolve EC2NodeClass not ready status + +|CloudTrail shows `Client.UnauthorizedOperation` for `ec2:CreateTags` +|Resolve AWS Identity and and Access Management (IAM) permissions for AWS resource tagging + +|Cannot create cluster on the designated provision shard +|Verify {cluster-manager} capabilities for the {autonode} +|=== + +[id="rosa-troubleshooting-autonode-prereqs"] +== Prerequisites + +* You have enabled the {autonode} on your {product-title} cluster. +* You have `cluster-admin` privileges. +* You have installed the `oc` CLI and authenticated to your cluster. +* You have installed the `rosa` CLI and authenticated. +* You have installed the `jq` command-line JSON processor. + +include::modules/autonode-troubleshooting.adoc[leveloffset=+1] + +include::modules/karpenter-resource-readiness.adoc[leveloffset=+1] + +include::modules/query-ec2nodeclass-condition-status.adoc[leveloffset=+2] + +include::modules/verify-karpenter-crds.adoc[leveloffset=+1] + +include::modules/resolve-ec2nodeclass-not-ready.adoc[leveloffset=+1] + +include::modules/resolve-iam-permissions-tagging.adoc[leveloffset=+1] + +include::modules/verify-ocm-capabilities.adoc[leveloffset=+1] + +[role="_additional-resources"] +[id="additional-resources_rosa-troubleshooting-autonode_{context}"] +== Additional resources + +* xref:../../rosa_cluster_admin/rosa-nodes-managing-karpenter.adoc#rosa-nodes-autonode-managing[Manage compute nodes using {autonode}] \ No newline at end of file