Merge pull request #3424 from anupras-mohapatra-arm/servers-and-cloud-computing

Rafay EKS LP review

Author: jasonrandrews

content/learning-paths/servers-and-cloud-computing/rafay-eks/_index.md

@@ -1,30 +1,74 @@
 ---
-title: "Deploy an EKS cluster with Graviton nodes using Rafay"
+title: Deploy an Amazon EKS cluster with AWS Graviton-based nodes using Rafay
 
-description: Use the Rafay Kubernetes Operations Platform to provision an Amazon EKS cluster with an Arm Graviton node group and deploy NGINX to verify the setup.
+description: Use the Rafay Kubernetes Operations Platform to provision an Amazon EKS cluster with an AWS Graviton-based node group and deploy NGINX to verify the setup.
 
-draft: true
-cascade:
-    draft: true
 
 minutes_to_complete: 60
 
 who_is_this_for: >
-    This is an advanced topic for software developers familiar with Kubernetes and AWS who want to learn how to use the Rafay platform to provision and manage EKS clusters backed by Arm Graviton instances.
+    This is an advanced topic for software developers familiar with Kubernetes and AWS who want to learn how to use the Rafay platform to provision and manage EKS clusters backed by AWS Graviton-based instances.
 
 learning_objectives:
     - Connect your AWS account to the Rafay platform using a cross-account IAM role
-    - Provision an Amazon EKS cluster with an Arm Graviton node group using Rafay
-    - Deploy and verify NGINX on Arm nodes and clean up all cloud resources
+    - Provision an Amazon EKS cluster with an AWS Graviton-based node group using Rafay
+    - Deploy and verify workloads on arm64 nodes and clean up all cloud resources
 
 prerequisites:
-    - An Amazon Web Services (AWS) [account](https://aws.amazon.com/)
-    - A [Rafay account](https://rafay.co)
-    - The [AWS CLI](/install-guides/aws-cli/) installed and configured
+    - An Amazon Web Services (AWS) [account](https://aws.amazon.com/) with sufficient IAM permissions to create roles, EKS clusters, EC2 instances, CloudFormation stacks, and related resources.
+    - A [Rafay account](https://rafay.co).
+    - The [AWS CLI](/install-guides/aws-cli/) installed and configured.
+
+# START generated_summary_faq
+generated_summary_faq:
+  template_version: summary-faq-v3
+  generated_at: '2026-06-24T20:45:31Z'
+  generator: ai
+  ai_assisted: true
+  ai_review_required: true
+  model: gpt-5
+  prompt_template: summary-faq-v3
+  source_hash: 76cbd5e4b3a61e9604e0df9b3ba2a5e5af4aa9a0c295ece3c4ee5a98ec365630
+  summary_generated_at: '2026-06-24T20:45:31Z'
+  summary_source_hash: 76cbd5e4b3a61e9604e0df9b3ba2a5e5af4aa9a0c295ece3c4ee5a98ec365630
+  faq_generated_at: '2026-06-24T20:45:31Z'
+  faq_source_hash: 76cbd5e4b3a61e9604e0df9b3ba2a5e5af4aa9a0c295ece3c4ee5a98ec365630
+  summary: >-
+    In this Learning Path, you'll provision an Amazon EKS cluster on Arm using
+    the Rafay Kubernetes Operations Platform and validate workloads on AWS Graviton-based nodes.
+    You'll define a declarative cluster manifest in Rafay referencing an existing project,
+    blueprint, and cloud credential. Then, you'll create the EKS cluster and deploy NGINX pinned to arm64 
+    to confirm scheduling on Graviton-based instances. Finally, you'll remove the NGINX workload and deprovision the EKS resources to avoid ongoing cloud costs.
+  faqs:
+  - question: How do I know the AWS connection to Rafay is set up correctly before creating the
+      cluster?
+    answer: >-
+      Ensure the cross-account IAM role is configured in AWS and added to Rafay as a cloud credential.
+      In the cluster manifest, reference this credential by name. If it's missing or has insufficient
+      permissions, cluster creation will fail.
+  - question: Which fields in the Rafay cluster manifest must match existing configuration?
+    answer: >-
+      The project, blueprint name and version, and the cloud credential must already exist in
+      Rafay. If any of these don't match, the cluster won't be created.
+  - question: What result should I expect when the EKS cluster is ready to use?
+    answer: >-
+      A running cluster with a Graviton-based (`arm64`) node group will be available for workloads.
+      Nodes should advertise the label `kubernetes.io/arch=arm64`, indicating they can run `arm64`
+      pods.
+  - question: How do I verify that the NGINX deployment is running on Graviton nodes?
+    answer: >-
+      The provided manifest pins the pods using `nodeSelector: kubernetes.io/arch: arm64`. After
+      deployment, the pod should schedule and run on nodes labeled `arm64`. If it remains `Pending`,
+      verify the node group is active and the selector matches node labels.
+  - question: What should I clean up to avoid ongoing AWS charges?
+    answer: >-
+      Delete the NGINX workload and namespace created for the test, then deprovision the EKS cluster
+      from Rafay. This releases the associated AWS resources.
+# END generated_summary_faq
 
 author: Jason Andrews
 
-generate_summary_faq: true
+generate_summary_faq: false
 rerun_summary: false
 rerun_faqs: false
 
@@ -53,7 +97,7 @@ further_reading:
         type: documentation
     - resource:
         title: Amazon EKS documentation
-        link: https://aws.amazon.com/eks/
+        link: https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html
         type: documentation
     - resource:
         title: AWS Graviton processors
@@ -68,3 +112,4 @@ weight: 1                       # _index.md always has weight of 1 to order corr
 layout: "learningpathall"       # All files under learning paths have this same wrapper
 learning_path_main_page: "yes"  # Indicates this should be surfaced when looking for related content. Only set for _index.md of learning path content.
 ---
+

content/learning-paths/servers-and-cloud-computing/rafay-eks/cluster.md

@@ -1,16 +1,17 @@
 ---
-title: "Create the EKS cluster"
+title: Create an Amazon EKS cluster using a Rafay cluster manifest
+description: Create and apply a Rafay cluster manifest to provision an Amazon EKS cluster with an AWS Graviton-based node group, then download kubeconfig and verify the nodes report arm64.
 weight: 3
 
 ### FIXED, DO NOT MODIFY
 layout: learningpathall
 ---
 
-In this section, you define and provision an EKS cluster with a Graviton-based node group using Rafay's declarative manifest format. You then apply the manifest with RCTL, wait for the cluster to reach a ready state, and download the kubeconfig so you can interact with the cluster.
-
 ## Create the cluster manifest
 
-The Rafay platform uses a declarative YAML manifest to define your EKS cluster. Create a file named `demo-eks-graviton.yaml` with the following content:
+The Rafay platform uses a declarative YAML manifest to define your EKS cluster. 
+
+Create a file named `demo-eks-graviton.yaml` with the following content:
 
 ```yaml
 apiVersion: infra.k8smgmt.io/v3
@@ -48,7 +49,7 @@ spec:
           autoScaler: true
           # Allows for full ECR (Elastic Container Registry) access. This is useful for building, for example, a CI server that needs to push images to ECR
           imageBuilder: true
-      # The AWS EC2 instance type that will be used for the nodes
+      # The Amazon EC2 instance type that will be used for the nodes
       instanceType: m7g.large
       # The maximum number of nodes that can run in the node group
       maxSize: 1
@@ -82,10 +83,10 @@ spec:
 
 Key fields to note:
 
-- `cloudCredentials` — must exactly match the credential name you entered in the Rafay console
-- `project` - must be the project you attached the credential to
-- `instanceType: m7g.large` — a Graviton3 instance with Arm Neoverse processors
-- `publicAccess: false` — the Kubernetes API server has no public endpoint. You reach the cluster exclusively through RCTL, which routes traffic through the Rafay control plane.
+- `cloudCredentials` must exactly match the credential name you entered in the Rafay console.
+- `project` must be the project you attached the credential to.
+- `instanceType` must be a Graviton-based EC2 instance type with Arm Neoverse processors. In this manifest, it's Graviton3-based `m7g.large`.
+- `publicAccess` must be `false`. The Kubernetes API server has no public endpoint. You reach the cluster exclusively through RCTL, which routes traffic through the Rafay control plane.
 
 ## Apply the cluster manifest
 
@@ -126,11 +127,12 @@ The output is similar to:
 
 ## Monitor cluster provisioning
 
-Poll the cluster status until it reports `READY`. Provisioning typically takes 15–20 minutes as Rafay creates the VPC, EKS control plane, and managed node group.
+Poll the cluster status until it reports `READY`: 
 
 ```console
 rctl get cluster demo-eks-graviton 
 ```
+Provisioning typically takes 15–20 minutes as Rafay creates the VPC, EKS control plane, and managed node group.
 
 The output is similar to:
 
@@ -142,11 +144,11 @@ The output is similar to:
 +-------------------+-----------------------------+---------+-----------+-----------+---------------------------+---------------------+
 ```
 
-While waiting, you can run the command again every few minutes. You will see various status values before the status changes to `READY`. You can also check the AWS CloudFormation console to see project and look for any stack errors.
+While waiting, you can run the command again every few minutes. You'll see various status values before the status changes to `READY`. You can also check the AWS CloudFormation console to look for any stack errors.
 
 ## Download the kubeconfig
 
-Once the cluster is `READY`, download the kubeconfig file:
+After the cluster is `READY`, download the kubeconfig file:
 
 ```console
 rctl kubeconfig download --cluster demo-eks-graviton -f ~/.kube/demo-eks-graviton.kubeconfig
@@ -179,4 +181,10 @@ NAME                            STATUS   ROLES    AGE   VERSION               AR
 ip-192-168-13-74.ec2.internal   Ready    <none>   26m   v1.36.2-eks-93b80c6   arm64
 ```
 
-The `arm64` value in the `ARCH` column confirms that the node is running on an AWS Graviton instance. Your EKS cluster is ready to accept workloads. In the next section, you will deploy NGINX to this cluster and verify it runs on the Graviton node.
+The `arm64` value in the `ARCH` column confirms that the node is running on an AWS Graviton-based instance. Your EKS cluster is ready to accept workloads. 
+
+## What you've accomplished and what's next
+
+You've now defined and provisioned an Amazon EKS cluster with a Graviton-based node group using Rafay's declarative manifest format. You then applied the manifest with RCTL, waited for the cluster to reach a ready state, and downloaded the kubeconfig so you can interact with the cluster.
+
+In the next section, you'll deploy NGINX to this cluster and verify it runs on the Graviton-based node.

content/learning-paths/servers-and-cloud-computing/rafay-eks/nginx.md

@@ -1,16 +1,15 @@
 ---
-title: "Deploy NGINX and clean up"
+title: Deploy NGINX to the Amazon EKS cluster and clean up
+description: Deploy NGINX to an Amazon EKS cluster on AWS Graviton-based nodes, test in-cluster connectivity, and clean up the Kubernetes and cloud resources.
 weight: 4
 
 ### FIXED, DO NOT MODIFY
 layout: learningpathall
 ---
 
-With the cluster running, you can now validate it by deploying a workload. In this section, you deploy NGINX using a manifest that pins pods to `arm64` nodes, verify the pod reaches a `Running` state, and test connectivity from inside the cluster. You then clean up all provisioned resources.
-
 ## Deploy NGINX
 
-With the EKS cluster running on Graviton nodes, deploy NGINX to confirm that arm64 workloads schedule and run correctly.
+With the Amazon EKS cluster running on Graviton-based nodes, deploy NGINX to confirm that `arm64` workloads schedule and run correctly.
 
 Create a file named `nginx-graviton.yaml` with the following content:
 
@@ -104,7 +103,9 @@ nginx-arm-svc   ClusterIP   10.100.42.137   <none>        80/TCP    30s
 
 ## Test NGINX connectivity
 
-The NGINX service is type `ClusterIP`, which means it has no external IP and is only reachable from within the cluster network. The cluster also has `publicAccess: false`, so there is no public Kubernetes API endpoint. Both constraints mean you cannot test connectivity from your laptop directly. Instead, run a one-off pod inside the cluster that sends a request to the service and then deletes itself:
+The NGINX service is type `ClusterIP`, which means it has no external IP and is reachable only from within the cluster network. The cluster also has `publicAccess: false`, so there's no public Kubernetes API endpoint. Both constraints mean you can't test connectivity from your local machine directly.
+
+Instead, run a one-off pod inside the cluster that sends a request to the service and then deletes itself:
 
 ```console
 kubectl run curl-test --rm -it --image=curlimages/curl --restart=Never -- curl http://nginx-arm-svc.nginx.svc
@@ -127,9 +128,9 @@ working. Further configuration is required.</p>
 pod "curl-test" deleted
 ```
 
-The NGINX welcome page confirms that the workload is running and reachable on your Graviton-backed EKS cluster.
+The NGINX welcome page confirms that the workload is running and reachable on your Graviton-based EKS cluster.
 
-## Clean up
+## Clean up resources
 
 Remove the NGINX workload and then delete the cluster to avoid ongoing AWS charges.
 
@@ -148,7 +149,7 @@ service "nginx-arm-svc" deleted
 ```
 
 {{< notice warning >}}
-Deleting the cluster through RCTL triggers the removal of the EKS control plane, managed node group, and associated CloudFormation stacks in your AWS account. If you do not run this command, AWS will continue to charge you for the running EC2 instances and EKS control plane.
+Deleting the cluster through RCTL triggers the removal of the EKS control plane, managed node group, and associated CloudFormation stacks in your AWS account. If you don't run this command, AWS will continue to charge you for the running EC2 instances and EKS control plane.
 {{< /notice >}}
 
 Delete the EKS cluster through Rafay:
@@ -157,13 +158,9 @@ Delete the EKS cluster through Rafay:
 rctl delete cluster demo-eks-graviton
 ```
 
-## Summary
+## What you've accomplished
 
-In this Learning Path you:
+You've now deployed NGINX using a manifest that pins pods to `arm64` nodes, verified the pod reaches a `Running` state, and tested connectivity from inside the cluster. You then cleaned up all provisioned resources.
 
-- Connected your AWS account to the Rafay platform using a cross-account IAM role and cloud credential.
-- Provisioned a private Amazon EKS cluster with a Graviton (`m7g.large`) node group using a declarative Rafay manifest and `rctl`.
-- Deployed NGINX with a `nodeSelector` that pins workloads to `arm64` nodes, confirming that Arm-native containers schedule and run correctly.
-- Tested in-cluster connectivity using a one-off curl pod, and cleaned up all AWS and Rafay resources.
+Rafay's control plane handles cluster access without requiring a public Kubernetes API endpoint, so you can use Rafay to run private, Graviton-based EKS clusters at scale.
 
-Rafay's control plane handles cluster access without requiring a public Kubernetes API endpoint, making it straightforward to run private, Graviton-backed EKS clusters at scale.