PR feedback

Signed-off-by: Donny Yung <[email protected]>

install/helm.md

@@ -4,7 +4,7 @@
 
 **Note** that installing the Traffic Manager through Helm will prevent `telepresence connect` from ever upgrading it. If you wish to upgrade a Traffic Manager that was installed via the Helm chart, please see the steps [below](#upgrading-the-traffic-manager)
 
-For more details on what the Helm chart installs and what can be configured, take a look at the Helm chart [README](https://github.com/telepresenceio/telepresence/tree/release/v2/charts/telepresence).
+For more details on what the Helm chart installs and what can be configured, see the Helm chart [README](https://github.com/telepresenceio/telepresence/tree/release/v2/charts/telepresence).
 
 ## Before you begin
 

reference/cluster-config.md

@@ -216,7 +216,6 @@ workload template's annotations:
        containers:
 ```
 
-
 ### Service Port Annotation
 
 A service port annotation can be added to the workload to make the Mutating Webhook select a specific port
@@ -235,9 +234,9 @@ in the service. This is necessary when the service has multiple ports.
        containers:
 ```
 
-### Note on numeric ports
+### Note on Numeric Ports
 
-If the <code>targetPort</code> of your intercepted Service is pointing at a port number, in addition to
+If the <code>targetPort</code> of your intercepted service is pointing at a port number, in addition to
 injecting the Traffic Agent sidecar, Telepresence will also inject an <code>initContainer</code> that will
 reconfigure the pod's firewall rules to redirect traffic to the Traffic Agent.
 
@@ -246,7 +245,7 @@ Note that this <code>initContainer</code> requires `NET_ADMIN` capabilities.
 If your cluster administrator has disabled them, you will be unable to use numeric ports with the agent injector.
 </Alert>
 
-For example, the following service is using a numeric port, and so Telepresence would inject an initContainer into it:
+For example, the following service is using a numeric port, so Telepresence would inject an initContainer into it:
 ```yaml
 apiVersion: v1
 kind: Service

reference/routing.md

@@ -21,7 +21,7 @@ Linux systems that aren't configured with `systemd-resolved` will use this resol
 ### Routing
 
 #### Subnets
-The Telepresence `traffic-manager` service is responsible for discovering the cluster's Service subnet and all subnets used by the pods. In order to do this, it needs permission to create a dummy service[<sup>[2](#servicesubnet)</sup>] in its own namespace, and the ability to list, get, and watch nodes and pods. Some clusters will expose the pod subnets as `podCIDR` in the `Node` but some, like Amazon EKS, typically don't. Telepresence will then fall back to deriving the subnets from the IPs of all pods. If you'd like to choose a specific method for discovering subnets, or want to provide the list yourself, you can use the `podCIDRStrategy` configuration value in the [helm](../install/helm) chart to do that.
+The Telepresence `traffic-manager` service is responsible for discovering the cluster's service subnet and all subnets used by the pods. In order to do this, it needs permission to create a dummy service[<sup>[2](#servicesubnet)</sup>] in its own namespace, and the ability to list, get, and watch nodes and pods. Most clusters will expose the pod subnets as `podCIDR` in the `Node` while others, like Amazon EKS, don't. Telepresence will then fall back to deriving the subnets from the IPs of all pods. If you'd like to choose a specific method for discovering subnets, or want to provide the list yourself, you can use the `podCIDRStrategy` configuration value in the [helm](../install/helm) chart to do that.
 
 The complete set of subnets that the [VIF](../tun-device) will be configured with is dynamic and may change during a connection's life cycle as new nodes arrive or disappear from the cluster. The set consists of what that the traffic-manager finds in the cluster, and the subnets configured using the [also-proxy](../config#alsoproxy) configuration option. Telepresence will remove subnets that are equal to, or completely covered by, other subnets.
 

releaseNotes.yml

@@ -67,14 +67,14 @@ items:
         title: Compute pod CIDRs more efficiently
         body: >-
           When computing subnets using the pod CIDRs, the traffic-manager
-          now uses less CPU-cycles.
+          now uses less CPU cycles.
         docs: reference/routing/#subnets
 
       - type: bugfix
         title: Prevent busy loop in traffic-manager
         body: >-
           In some circumstances, the <code>traffic-manager</code>'s CPU
-          would max out and get pinned at its limit. This then required a
+          would max out and get pinned at its limit. This required a
           shutdown or pod restart to fix. We've added some fixes
           to prevent the traffic-manager from getting into this state.