Fix typos

Signed-off-by: Richard Wall <richard.wall@venafi.com>

content/docs/devops-tips/large-clusters.md

@@ -30,13 +30,17 @@ config:
 ```
 
 > ℹ️ This does not technically disable the client-side rate-limiting but configures the QPS and Burst values high enough that they are never reached.
-> See cert-manager issue 6890: [Allow client-side rate-limiting to be disabled](https://github.com/cert-manager/cert-manager/issues/6890).
 >
-> 📖 Read [API documentation for ControllerConfiguration](https://cert-manager.io/docs/reference/api-docs/#controller.config.cert-manager.io%2fv1alpha1).
+> 🔗 Read [`cert-manager#6890`: Allow client-side rate-limiting to be disabled](https://github.com/cert-manager/cert-manager/issues/6890);
+> a proposal for a cert-manager configuration option to disable client-side rate-limiting.
 >
-> 📖 Read Kubernetes issue 111880 [Disable client-side rate-limiting when AP&F is enabled](https://github.com/kubernetes/kubernetes/issues/111880).
+> 🔗 Read [`kubernetes#111880`: Disable client-side rate-limiting when AP&F is enabled](https://github.com/kubernetes/kubernetes/issues/111880);
+> a proposal that the `kubernetes.io/client-go` module should automatically use server-side rate-limiting when it is enabled.
 >
-> 🔗 Examples of other projects that disable client-side rate limiting: [Flux](https://github.com/fluxcd/pkg/issues/269).
+> 🔗 Read about other projects that disable client-side rate limiting: [Flux](https://github.com/fluxcd/pkg/issues/269).
+>
+> 📖 Read [API documentation for ControllerConfiguration](../reference/api-docs.md#controller.config.cert-manager.io/v1alpha1.ControllerConfiguration) for a description of the `kubernetesAPIQPS` and `kubernetesAPIBurst` configuration options.
+
 
 ### Evidence
 
@@ -60,15 +64,15 @@ It takes 22 minutes to reconcile all 2000 Certificate resources.
 
 The following chart demonstrates the CPU advantage of ECDSA certificates.
 It shows the CPU use of the cert-manager controller while reconciling 2000 ECDSA 256 Certificates.
-Note that the CPU usage is significantly lower than with the RSA 4096 experiment above: ~300m vs ~4500m.
-And the rate of reconciliation is significantly higher: 285/min vs 58/min.
+Note that the CPU usage is significantly lower than with the RSA 4096 experiment above: `~300m` vs `~4500m`.
+And the rate of reconciliation is significantly higher: `~285/min` vs `~58/min`.
 (and this is probably limited by the rate at which the benchmark creates the Certificates)
 
 <img src="/docs/devops-tips/large-clusters/cpu-server-side-ecdsa.png" alt="Scatter chart showing cert-manager CPU usage and cluster resource counts over time with server-side rate-limiting and 2000 ECDSA Certificates" />
 
 ## Restrict the use of large RSA keys
 
-Certificates with large RSA keys cause cert-manager to use more CPU resources and when there are insufficient CPU resrouces,
+Certificates with large RSA keys cause cert-manager to use more CPU resources and when there are insufficient CPU resources,
 the reconcile queue length grows, which delays the reconciliation of all Certificates.
 A user who has permission to create a large number of RSA 4096 certificates, might accidentally or maliciously cause a denial of service for other users on the cluster.