minor typo fixes (#631)

* minor typo fixes

* minor fixes

Author: geoffcline

latest/bpg/networking/ipv6.adoc

@@ -38,8 +38,7 @@ image::ipv6_eks-cluster-ipv6-foundation.png[Dual Stack VPC, EKS Cluster in IPv6
 
 == Overview
 
-EKS/IPv6 is only supported in prefix mode (VPC-CNI Plug-in ENI IP assign mode). Learn more on xref:prefix-mode-linux[Prefix
-Mode].
+EKS/IPv6 is only supported in prefix mode (VPC-CNI Plug-in ENI IP assign mode). Learn more on xref:prefix-mode-linux[Prefix Mode].
 
 Prefix assignment only works on Nitro-based EC2 instances, hence EKS/IPv6 is only supported when the cluster data-plane uses EC2 Nitro-based instances.
 

latest/bpg/networking/vpc-cni.adoc

@@ -169,7 +169,7 @@ It is advised that you https://aws.github.io/aws-eks-best-practices/security/doc
 
 === Handle Liveness/Readiness Probe failures
 
-We advise increasing the liveness and readiness probe timeout values (default `timeoutSeconds: 10`) for EKS 1.20 an later clusters to prevent probe failures from causing your application's Pod to become stuck in a containerCreating state. This problem has been seen in data-intensive and batch-processing clusters. High CPU use causes aws-node probe health failures, leading to unfulfilled Pod CPU requests. In addition to modifying the probe timeout, ensure that the CPU resource requests (default `CPU: 25m`) for aws-node are correctly configured. We do not suggest updating the settings unless your node is having issues.
+We advise increasing the liveness and readiness probe timeout values (default `timeoutSeconds: 10`) for EKS 1.20 and later clusters to prevent probe failures from causing your application's Pod to become stuck in a containerCreating state. This problem has been seen in data-intensive and batch-processing clusters. High CPU use causes aws-node probe health failures, leading to unfulfilled Pod CPU requests. In addition to modifying the probe timeout, ensure that the CPU resource requests (default `CPU: 25m`) for aws-node are correctly configured. We do not suggest updating the settings unless your node is having issues.
 
 We highly encourage you to run sudo `bash /opt/cni/bin/aws-cni-support.sh` on a node while you engage Amazon EKS support. The script will assist in evaluating kubelet logs and memory utilization on the node. Please consider installing SSM Agent on Amazon EKS worker nodes to run the script.
 

latest/bpg/reliability/application.adoc

@@ -380,10 +380,8 @@ Deployment and stop sending traffic to the new Deployment.
 
 Although Kubernetes offers no native way to perform canary deployments,
 you can use tools such as https://github.com/weaveworks/flagger[Flagger]
-with
-https://docs.flagger.app/tutorials/istio-progressive-delivery[Istio] or
-https://docs.flagger.app/install/flagger-install-on-eks-appmesh[App
-Mesh].
+with 
+https://docs.flagger.app/tutorials/istio-progressive-delivery[Istio].
 
 == Health checks and self-healing
 

latest/bpg/reliability/controlplane.adoc

@@ -273,7 +273,7 @@ https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-con
 admission webhooks and mutating admission webhooks]. These allow a user
 to extend the kubernetes API and validate or mutate objects before they
 are accepted by the API. Poor configurations of these webhooks can
-distabilize the EKS control plane by blocking cluster critical
+destabilize the EKS control plane by blocking cluster critical
 operations.
 
 In order to avoid impacting cluster critical operations either avoid

latest/bpg/security/index.adoc

@@ -63,7 +63,7 @@ infrastructure/cluster. That can be handled by the
 https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md[cluster-autoscaler]
 or other technologies such as https://karpenter.sh/[Karpenter], native
 AWS autoscaling, SpotInst’s
-https://spot.io/solutions/kubernetes-2/[Ocean], or Atlassian’s
+https://spot.io/product/ocean[Ocean], or Atlassian’s
 https://github.com/atlassian/escalator[Escalator].
 
 .Shared Responsibility Model - MNG