Fix broken link and typos (#1462)

website/content/en/preview/concepts/_index.md

@@ -24,7 +24,7 @@ Concepts associated with this role are described below.
 Karpenter is designed to run on a node in your Kubernetes cluster.
 As part of the installation process, you need credentials from the underlying cloud provider to allow nodes to be started up and added to the cluster as they are needed.
 
-[Getting Started with Karpenter on AWS]{{< ref "../getting-started" >}})
+[Getting Started with Karpenter on AWS]({{< ref "../getting-started" >}})
 describes the process of installing Karpenter on an AWS cloud provider.
 Because requests to add and delete nodes and schedule pods are made through Kubernetes, AWS IAM Roles for Service Accounts (IRSA) are needed by your Kubernetes cluster to make privileged requests to AWS.
 For example, Karpenter uses AWS IRSA roles to grant the permissions needed to describe EC2 instance types and create EC2 instances.
@@ -52,7 +52,7 @@ Keep in mind that only a subset of these labels are supported in Karpenter, as d
 
 * **Multiple provisioners**: Multiple provisioners can be configured on the same cluster.
 For example, you might want to configure different teams on the same cluster to run on completely separate capacity.
-One team could run on nodes nodes using BottleRocket, while another uses EKSOptimizedAMI.
+One team could run on nodes using BottleRocket, while another uses EKSOptimizedAMI.
 
 Although most use cases are addressed with a single provisioner for multiple teams, multiple provisioners are useful to isolate nodes for billing, use different node constraints (such as no GPUs for a team), or use different deprovisioning settings.
 

website/content/en/preview/provisioner.md

@@ -84,7 +84,7 @@ Note that Karpenter does not automatically add jitter to this value. If multiple
 
 Kubernetes defines the following [Well-Known Labels](https://kubernetes.io/docs/reference/labels-annotations-taints/), and cloud providers (e.g., AWS) implement them. They are defined at the "spec.requirements" section of the Provisioner API. 
 
-These well known labels may be specified at the provisioner level, or in a workload definition (e.g., nodeSelector on a pod.spec). Nodes are chosen using the both the provisioner's and pod's requirements. If there is no overlap, nodes will not be launched. In other words, a pod's requirements must be within the provisioner's requirements. If a requirement is not defined for a well known label, any value available to the cloud provider may be chosen.
+These well known labels may be specified at the provisioner level, or in a workload definition (e.g., nodeSelector on a pod.spec). Nodes are chosen using both the provisioner's and pod's requirements. If there is no overlap, nodes will not be launched. In other words, a pod's requirements must be within the provisioner's requirements. If a requirement is not defined for a well known label, any value available to the cloud provider may be chosen.
 
 For example, an instance type may be specified using a nodeSelector in a pod spec. If the instance type requested is not included in the provisioner list and the provisioner has instance type requirements, Karpenter will not create a node or schedule the pod. 
 
@@ -198,6 +198,3 @@ Review the [resource limit task](../tasks/set-resource-limits) for more informat
 This section is cloud provider specific. Reference the appropriate documentation:
 
 - [AWS](../aws/provisioning/)
-
-
-