fix: Spelling and grammar errors (#921)

vara-bonthu · web-flow · commit dc9e9e6143f3 · 2025-11-29T17:28:53.000-08:00
Signed-off-by: Vara Bonthu &lt;vara.bonthu@gmail.com&gt;
diff --git a/README.md b/README.md
@@ -38,7 +38,7 @@ Data on EKS(DoEKS) solution is categorized into the following focus areas.
 
 🎯  [Distributed Databases & Query Engine](https://awslabs.github.io/data-on-eks/docs/blueprints/distributed-databases) on EKS
 
-## 🏃‍♀️Getting Started
+## 🏃‍♀️ Getting Started
 In this repository, you'll find a variety of deployment blueprints for creating Data/ML platforms with Amazon EKS clusters. These examples are just a small selection of the available blueprints - visit the [DoEKS website](https://awslabs.github.io/data-on-eks/) for the complete list of options.
 
 
diff --git a/website/docs/bestpractices/analytics/emr-on-eks.md b/website/docs/bestpractices/analytics/emr-on-eks.md
@@ -11,7 +11,7 @@ Amazon EMR on Amazon EKS enables you to submit Apache Spark jobs on demand on Am
 
 This link provides the best practices and templates to get started with Amazon EMR on EKS. We publish this guide on GitHub so we could iterate the content quickly, provide timely and effective recommendations for variety of concerns, and easily incorporate suggestions from the broader community.
 
-Checkout the EMR on EKS Best practices GitHub docs [here](https://aws.github.io/aws-emr-containers-best-practices/)
+Check out the EMR on EKS Best practices GitHub docs [here](https://aws.github.io/aws-emr-containers-best-practices/)
 
 ### Architecture
 The following diagram illustrates the solution architecture Amazon EMR on EKS.
diff --git a/website/docs/bestpractices/eks-best-practices/eks-best-practices.md b/website/docs/bestpractices/eks-best-practices/eks-best-practices.md
@@ -9,4 +9,4 @@ sidebar_label: EKS Best Practices
 
 The primary goal of this EKS Best practices is to offer a set of best practices for day 2 operations for Amazon EKS. We elected to publish this guidance to GitHub so we could iterate quickly, provide timely and effective recommendations for variety of concerns, and easily incorporate suggestions from the broader community.
 
-Checkout the EKS Best practices GitHub docs [here](https://aws.github.io/aws-eks-best-practices/)
+Check out the EKS Best practices GitHub docs [here](https://aws.github.io/aws-eks-best-practices/)
diff --git a/website/docs/blueprints/amazon-emr-on-eks/emr-eks-observability.md b/website/docs/blueprints/amazon-emr-on-eks/emr-eks-observability.md
@@ -9,7 +9,7 @@ sidebar_label: EMR on EKS Observability
 
 In this post, we will learn to build end-to-end observability for EMR on EKS Spark workloads by leveraging Amazon Managed Service for Prometheus to collect and store the metrics generated by Spark Applications. We will then use Amazon Managed Grafana to build dashboards for monitoring use cases
 
-Checkout the full blog [here](https://aws.amazon.com/blogs/mt/monitoring-amazon-emr-on-eks-with-amazon-managed-prometheus-and-amazon-managed-grafana/)
+Check out the full blog [here](https://aws.amazon.com/blogs/mt/monitoring-amazon-emr-on-eks-with-amazon-managed-prometheus-and-amazon-managed-grafana/)
 
 ### Architecture
 The following diagram illustrates the solution architecture for scraping Spark Driver and Executors’ metrics, as well as writing to Amazon Managed Service for Prometheus.
diff --git a/website/docs/blueprints/streaming-platforms/emr-eks-flink.md b/website/docs/blueprints/streaming-platforms/emr-eks-flink.md
@@ -177,7 +177,7 @@ To get the most out of Flink on Kubernetes, here are some best practices to foll
 - **Store checkpoints and savepoints in the right places**: Store checkpoints in distributed file systems or key-value stores like Amazon S3 or another durable external storage. Store savepoints in a durable external storage like Amazon S3.
 
 ## Flink Upgrade
-Flink Operator provides three upgrade modes for Flink jobs. Checkout the [Flink upgrade docs](https://nightlies.apache.org/flink/flink-kubernetes-operator-docs-main/docs/custom-resource/job-management/#stateful-and-stateless-application-upgrades) for up-to-date information.
+Flink Operator provides three upgrade modes for Flink jobs. Check out the [Flink upgrade docs](https://nightlies.apache.org/flink/flink-kubernetes-operator-docs-main/docs/custom-resource/job-management/#stateful-and-stateless-application-upgrades) for up-to-date information.
 
 1. **stateless**: Stateless application upgrades from empty state
 2. **last-state**: Quick upgrades in any application state (even for failing jobs), does not require a healthy job as it always uses the latest checkpoint information. Manual recovery may be necessary if HA metadata is lost.
diff --git a/website/docs/blueprints/streaming-platforms/flink.md b/website/docs/blueprints/streaming-platforms/flink.md
@@ -168,7 +168,7 @@ To get the most out of Flink on Kubernetes, here are some best practices to foll
 - **Store checkpoints and savepoints in the right places**: Store checkpoints in distributed file systems or key-value stores like Amazon S3 or another durable external storage. Store savepoints in a durable external storage like Amazon S3.
 
 ## Flink Upgrade
-Flink Operator provides three upgrade modes for Flink jobs. Checkout the [Flink upgrade docs](https://nightlies.apache.org/flink/flink-kubernetes-operator-docs-main/docs/custom-resource/job-management/#stateful-and-stateless-application-upgrades) for up-to-date information.
+Flink Operator provides three upgrade modes for Flink jobs. Check out the [Flink upgrade docs](https://nightlies.apache.org/flink/flink-kubernetes-operator-docs-main/docs/custom-resource/job-management/#stateful-and-stateless-application-upgrades) for up-to-date information.
 
 1. **stateless**: Stateless application upgrades from empty state
 2. **last-state**: Quick upgrades in any application state (even for failing jobs), does not require a healthy job as it always uses the latest checkpoint information. Manual recovery may be necessary if HA metadata is lost.
diff --git a/website/docs/introduction/intro.md b/website/docs/introduction/intro.md
@@ -4,7 +4,7 @@ sidebar_label: Introduction
 ---
 
 # Introduction
-Data on Amazon EKS(DoEKS) - A tool for building [aws](https://aws.amazon.com/) managed and self-managed scalable data platforms on [Amazon EKS](https://aws.amazon.com/eks/). With DoEKS, You have access to:
+Data on Amazon EKS (DoEKS) - A tool for building [AWS](https://aws.amazon.com/) managed and self-managed scalable data platforms on [Amazon EKS](https://aws.amazon.com/eks/). With DoEKS, you have access to:
 
 1. Robust Deployment Infrastructure as Code (IaC) Templates using [Terraform](https://www.terraform.io/) and [AWS CDK](https://aws.amazon.com/cdk/), among other
 2. Best Practices for Deploying Data Solutions on Amazon EKS
@@ -13,7 +13,7 @@ Data on Amazon EKS(DoEKS) - A tool for building [aws](https://aws.amazon.com/) m
 5. In-depth Reference Architectures and Data Blogs to keep you ahead of the curve
 
 # Architecture
-The diagram displays the open source data tools, k8s operators and frameworks that runs on Kubernetes covered in DoEKS. AWS Data Analytics managed services integration with Data on EKS OSS tools.
+The diagram displays the open source data tools, Kubernetes operators and frameworks that run on Kubernetes covered in DoEKS. AWS Data Analytics managed services integration with Data on EKS OSS tools.
 
 ![Data on EKS.png](doeks.png)
 
@@ -35,4 +35,4 @@ The diagram displays the open source data tools, k8s operators and frameworks th
 
 # Getting Started
 
-Checkout the documentation for each section to deploy infrastructure and run sample Spark/ML jobs.
+Check out the documentation for each section to deploy infrastructure and run sample Spark/ML jobs.
diff --git a/website/docs/resources/binpacking-custom-scheduler-eks.md b/website/docs/resources/binpacking-custom-scheduler-eks.md
@@ -12,7 +12,7 @@ In this post, we will show you how to enable a custom scheduler with Amazon EKS
 ### Why bin packing
 By default, the [scheduling-plugin](https://kubernetes.io/docs/reference/scheduling/config/#scheduling-plugins) NodeResourcesFit use the ```LeastAllocated``` for score strategies. For the long running workloads, that is good because of high availability. But for batch jobs, like Spark workloads, this would lead high cost. By changing the from ```LeastAllocated``` to ```MostAllocated```, it avoids spreading pods across all running nodes, leading to higher resource utilization and better cost efficiency.
 
-Batch jobs like Spark are running on demand with limited or predicted time. With ```MostAllocated``` strategy, Spark executors are always bin packing into one node util the node can not host any pods. You can see the following picture shows the
+Batch jobs like Spark are running on demand with limited or predicted time. With ```MostAllocated``` strategy, Spark executors are always bin packing into one node until the node cannot host any pods. You can see the following picture shows the
 
 ```MostAllocated``` in EMR on EKS.
 

Original file line number	Diff line number	Diff line change
`@@ -9,4 +9,4 @@ sidebar_label: EKS Best Practices`
`9`	`9`
`10`	`10`	`The primary goal of this EKS Best practices is to offer a set of best practices for day 2 operations for Amazon EKS. We elected to publish this guidance to GitHub so we could iterate quickly, provide timely and effective recommendations for variety of concerns, and easily incorporate suggestions from the broader community.`
`11`	`11`
`12`		`-Checkout the EKS Best practices GitHub docs [here](https://aws.github.io/aws-eks-best-practices/)`
	`12`	`+Check out the EKS Best practices GitHub docs [here](https://aws.github.io/aws-eks-best-practices/)`