Merge pull request #34028 from TinySong/dns-pod-service-en

formatting Pod and Service

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

@@ -8,8 +8,8 @@ weight: 20
 ---
 <!-- overview -->
 
-Kubernetes creates DNS records for services and pods. You can contact
+Kubernetes creates DNS records for Services and Pods. You can contact
-services with consistent DNS names instead of IP addresses. 
+Services with consistent DNS names instead of IP addresses. 
 
 <!-- body -->
 
@@ -25,20 +25,20 @@ Pod's own namespace and the cluster's default domain.
 
 ### Namespaces of Services 
 
-A DNS query may return different results based on the namespace of the pod making 
+A DNS query may return different results based on the namespace of the Pod making 
-it. DNS queries that don't specify a namespace are limited to the pod's 
+it. DNS queries that don't specify a namespace are limited to the Pod's 
-namespace. Access services in other namespaces by specifying it in the DNS query. 
+namespace. Access Services in other namespaces by specifying it in the DNS query. 
 
-For example, consider a pod in a `test` namespace. A `data` service is in 
+For example, consider a Pod in a `test` namespace. A `data` Service is in 
 the `prod` namespace. 
 
-A query for `data` returns no results, because it uses the pod's `test` namespace. 
+A query for `data` returns no results, because it uses the Pod's `test` namespace. 
 
 A query for `data.prod` returns the intended result, because it specifies the 
 namespace. 
 
-DNS queries may be expanded using the pod's `/etc/resolv.conf`. Kubelet 
+DNS queries may be expanded using the Pod's `/etc/resolv.conf`. Kubelet 
-sets this file for each pod. For example, a query for just `data` may be 
+sets this file for each Pod. For example, a query for just `data` may be 
 expanded to `data.test.svc.cluster.local`. The values of the `search` option 
 are used to expand queries. To learn more about DNS queries, see 
 [the `resolv.conf` manual page.](https://www.man7.org/linux/man-pages/man5/resolv.conf.5.html) 
@@ -49,7 +49,7 @@ search <namespace>.svc.cluster.local svc.cluster.local cluster.local
 options ndots:5
 ```
 
-In summary, a pod in the _test_ namespace can successfully resolve either 
+In summary, a Pod in the _test_ namespace can successfully resolve either 
 `data.prod` or `data.prod.svc.cluster.local`.
 
 ### DNS Records
@@ -70,14 +70,14 @@ For more up-to-date specification, see
 ### A/AAAA records
 
 "Normal" (not headless) Services are assigned a DNS A or AAAA record,
-depending on the IP family of the service, for a name of the form
+depending on the IP family of the Service, for a name of the form
 `my-svc.my-namespace.svc.cluster-domain.example`.  This resolves to the cluster IP
 of the Service.
 
 "Headless" (without a cluster IP) Services are also assigned a DNS A or AAAA record,
-depending on the IP family of the service, for a name of the form
+depending on the IP family of the Service, for a name of the form
 `my-svc.my-namespace.svc.cluster-domain.example`.  Unlike normal
-Services, this resolves to the set of IPs of the pods selected by the Service.
+Services, this resolves to the set of IPs of the Pods selected by the Service.
 Clients are expected to consume the set or else use standard round-robin
 selection from the set.
 
@@ -87,36 +87,36 @@ SRV Records are created for named ports that are part of normal or [Headless
 Services](/docs/concepts/services-networking/service/#headless-services).
 For each named port, the SRV record would have the form
 `_my-port-name._my-port-protocol.my-svc.my-namespace.svc.cluster-domain.example`.
-For a regular service, this resolves to the port number and the domain name:
+For a regular Service, this resolves to the port number and the domain name:
 `my-svc.my-namespace.svc.cluster-domain.example`.
-For a headless service, this resolves to multiple answers, one for each pod
+For a headless Service, this resolves to multiple answers, one for each Pod
-that is backing the service, and contains the port number and the domain name of the pod
+that is backing the Service, and contains the port number and the domain name of the Pod
 of the form `auto-generated-name.my-svc.my-namespace.svc.cluster-domain.example`.
 
 ## Pods
 
 ### A/AAAA records
 
-In general a pod has the following DNS resolution:
+In general a Pod has the following DNS resolution:
 
 `pod-ip-address.my-namespace.pod.cluster-domain.example`.
 
-For example, if a pod in the `default` namespace has the IP address 172.17.0.3,
+For example, if a Pod in the `default` namespace has the IP address 172.17.0.3,
 and the domain name for your cluster is `cluster.local`, then the Pod has a DNS name:
 
 `172-17-0-3.default.pod.cluster.local`.
 
-Any pods exposed by a Service have the following DNS resolution available:
+Any Pods exposed by a Service have the following DNS resolution available:
 
 `pod-ip-address.service-name.my-namespace.svc.cluster-domain.example`.
 
 ### Pod's hostname and subdomain fields
 
-Currently when a pod is created, its hostname is the Pod's `metadata.name` value.
+Currently when a Pod is created, its hostname is the Pod's `metadata.name` value.
 
 The Pod spec has an optional `hostname` field, which can be used to specify the
 Pod's hostname. When specified, it takes precedence over the Pod's name to be
-the hostname of the pod. For example, given a Pod with `hostname` set to
+the hostname of the Pod. For example, given a Pod with `hostname` set to
 "`my-host`", the Pod will have its hostname set to "`my-host`".
 
 The Pod spec also has an optional `subdomain` field which can be used to specify
@@ -173,14 +173,14 @@ spec:
     name: busybox
 ```
 
-If there exists a headless service in the same namespace as the pod and with
+If there exists a headless Service in the same namespace as the Pod and with
 the same name as the subdomain, the cluster's DNS Server also returns an A or AAAA
 record for the Pod's fully qualified hostname.
 For example, given a Pod with the hostname set to "`busybox-1`" and the subdomain set to
 "`default-subdomain`", and a headless Service named "`default-subdomain`" in
-the same namespace, the pod will see its own FQDN as
+the same namespace, the Pod will see its own FQDN as
 "`busybox-1.default-subdomain.my-namespace.svc.cluster-domain.example`". DNS serves an
-A or AAAA record at that name, pointing to the Pod's IP. Both pods "`busybox1`" and
+A or AAAA record at that name, pointing to the Pod's IP. Both Pods "`busybox1`" and
 "`busybox2`" can have their distinct A or AAAA records.
 
 The Endpoints object can specify the `hostname` for any endpoint addresses,
@@ -189,7 +189,7 @@ along with its IP.
 {{< note >}}
 Because A or AAAA records are not created for Pod names, `hostname` is required for the Pod's A or AAAA
 record to be created. A Pod with no `hostname` but with `subdomain` will only create the
-A or AAAA record for the headless service (`default-subdomain.my-namespace.svc.cluster-domain.example`),
+A or AAAA record for the headless Service (`default-subdomain.my-namespace.svc.cluster-domain.example`),
 pointing to the Pod's IP address. Also, Pod needs to become ready in order to have a
 record unless `publishNotReadyAddresses=True` is set on the Service.
 {{< /note >}}
@@ -205,17 +205,17 @@ When you set `setHostnameAsFQDN: true` in the Pod spec, the kubelet writes the P
 {{< note >}}
 In Linux, the hostname field of the kernel (the `nodename` field of `struct utsname`) is limited to 64 characters.
 
-If a Pod enables this feature and its FQDN is longer than 64 character, it will fail to start. The Pod will remain in `Pending` status (`ContainerCreating` as seen by `kubectl`) generating error events, such as Failed to construct FQDN from pod hostname and cluster domain, FQDN `long-FQDN` is too long (64 characters is the max, 70 characters requested). One way of improving user experience for this scenario is to create an [admission webhook controller](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks) to control FQDN size when users create top level objects, for example, Deployment.
+If a Pod enables this feature and its FQDN is longer than 64 character, it will fail to start. The Pod will remain in `Pending` status (`ContainerCreating` as seen by `kubectl`) generating error events, such as Failed to construct FQDN from Pod hostname and cluster domain, FQDN `long-FQDN` is too long (64 characters is the max, 70 characters requested). One way of improving user experience for this scenario is to create an [admission webhook controller](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks) to control FQDN size when users create top level objects, for example, Deployment.
 {{< /note >}}
 
 ### Pod's DNS Policy
 
-DNS policies can be set on a per-pod basis. Currently Kubernetes supports the
+DNS policies can be set on a per-Pod basis. Currently Kubernetes supports the
-following pod-specific DNS policies. These policies are specified in the
+following Pod-specific DNS policies. These policies are specified in the
 `dnsPolicy` field of a Pod Spec.
 
 - "`Default`": The Pod inherits the name resolution configuration from the node
-  that the pods run on.
+  that the Pods run on.
   See [related discussion](/docs/tasks/administer-cluster/dns-custom-nameservers)
   for more details.
 - "`ClusterFirst`": Any DNS query that does not match the configured cluster
@@ -326,7 +326,7 @@ a list of search domains of up to 2048 characters.
 
 ## DNS resolution on Windows nodes {#dns-windows}
 
-- ClusterFirstWithHostNet is not supported for pods that run on Windows nodes.
+- ClusterFirstWithHostNet is not supported for Pods that run on Windows nodes.
   Windows treats all names with a `.` as a FQDN and skips FQDN resolution.
 - On Windows, there are multiple DNS resolvers that can be used. As these come with
   slightly different behaviors, using the
@@ -335,10 +335,10 @@ a list of search domains of up to 2048 characters.
 - On Linux, you have a DNS suffix list, which is used after resolution of a name as fully
   qualified has failed.
   On Windows, you can only have 1 DNS suffix, which is the DNS suffix associated with that
-  pod's namespace (example: `mydns.svc.cluster.local`). Windows can resolve FQDNs, services,
+  Pod's namespace (example: `mydns.svc.cluster.local`). Windows can resolve FQDNs, Services,
-  or network name which can be resolved with this single suffix. For example, a pod spawned
+  or network name which can be resolved with this single suffix. For example, a Pod spawned
   in the `default` namespace, will have the DNS suffix `default.svc.cluster.local`.
-  Inside a Windows pod, you can resolve both `kubernetes.default.svc.cluster.local`
+  Inside a Windows Pod, you can resolve both `kubernetes.default.svc.cluster.local`
   and `kubernetes`, but not the partially qualified names (`kubernetes.default` or
   `kubernetes.default.svc`).