clean up use of word: simply

content/en/docs/concepts/services-networking/dns-pod-service.md

@@ -25,9 +25,9 @@ assigned a DNS name.  By default, a client Pod's DNS search list will
 include the Pod's own namespace and the cluster's default domain.  This is best
 illustrated by example:
 
-Assume a Service named `foo` in the Kubernetes namespace `bar`.  A Pod running
-in namespace `bar` can look up this service by simply doing a DNS query for
-`foo`.  A Pod running in namespace `quux` can look up this service by doing a
+Assume a Service named `foo` in the Kubernetes namespace `bar`. A Pod running
+in namespace `bar` can look up this service by querying a DNS service for
+`foo`. A Pod running in namespace `quux` can look up this service by doing a
 DNS query for `foo.bar`.
 
 The following sections detail the supported record types and layout that is

content/en/docs/concepts/services-networking/service.md

@@ -430,7 +430,7 @@ Services by their DNS name.
 For example, if you have a Service called `my-service` in a Kubernetes
 namespace `my-ns`, the control plane and the DNS Service acting together
 create a DNS record for `my-service.my-ns`. Pods in the `my-ns` namespace
-should be able to find it by simply doing a name lookup for `my-service`
+should be able to find the service by doing a name lookup for `my-service`
 (`my-service.my-ns` would also work).
 
 Pods in other namespaces must qualify the name as `my-service.my-ns`. These names
@@ -1163,7 +1163,7 @@ rule kicks in, and redirects the packets to the proxy's own port.
 The "Service proxy" chooses a backend, and starts proxying traffic from the client to the backend.
 
 This means that Service owners can choose any port they want without risk of
-collision.  Clients can simply connect to an IP and port, without being aware
+collision.  Clients can connect to an IP and port, without being aware
 of which Pods they are actually accessing.
 
 #### iptables