fix again (#8941)

content/en/docs/concepts/cluster-administration/networking.md

@@ -172,7 +172,7 @@ DOCKER_OPTS="--bridge=cbr0 --iptables=false --ip-masq=false"
 ```
 
 This bridge is created by Kubelet (controlled by the `--network-plugin=kubenet`
-flag) according to the `Node`'s `spec.podCIDR`.
+flag) according to the `Node`'s `.spec.podCIDR`.
 
 Docker will now allocate IPs from the `cbr-cidr` block.  Containers can reach
 each other and `Nodes` over the `cbr0` bridge.  Those IPs are all routable

content/en/docs/concepts/configuration/secret.md

@@ -174,8 +174,8 @@ systems on your behalf.
 To consume a Secret in a volume in a Pod:
 
 1. Create a secret or use an existing one.  Multiple pods can reference the same secret.
-1. Modify your Pod definition to add a volume under `spec.volumes[]`.  Name the volume anything, and have a `spec.volumes[].secret.secretName` field equal to the name of the secret object.
+1. Modify your Pod definition to add a volume under `.spec.volumes[]`.  Name the volume anything, and have a `.spec.volumes[].secret.secretName` field equal to the name of the secret object.
-1. Add a `spec.containers[].volumeMounts[]` to each container that needs the secret.  Specify `spec.containers[].volumeMounts[].readOnly = true` and `spec.containers[].volumeMounts[].mountPath` to an unused directory name where you would like the secrets to appear.
+1. Add a `.spec.containers[].volumeMounts[]` to each container that needs the secret.  Specify `.spec.containers[].volumeMounts[].readOnly = true` and `.spec.containers[].volumeMounts[].mountPath` to an unused directory name where you would like the secrets to appear.
 1. Modify your image and/or command line so that the program looks for files in that directory.  Each key in the secret `data` map becomes the filename under `mountPath`.
 
 This is an example of a pod that mounts a secret in a volume:
@@ -199,17 +199,17 @@ spec:
       secretName: mysecret
 ```
 
-Each secret you want to use needs to be referred to in `spec.volumes`.
+Each secret you want to use needs to be referred to in `.spec.volumes`.
 
 If there are multiple containers in the pod, then each container needs its
-own `volumeMounts` block, but only one `spec.volumes` is needed per secret.
+own `volumeMounts` block, but only one `.spec.volumes` is needed per secret.
 
 You can package many files into one secret, or use many secrets, whichever is convenient.
 
 **Projection of secret keys to specific paths**
 
 We can also control the paths within the volume where Secret keys are projected.
-You can use `spec.volumes[].secret.items` field to change target path of each key:
+You can use `.spec.volumes[].secret.items` field to change target path of each key:
 
 ```yaml
 apiVersion: v1
@@ -238,7 +238,7 @@ What will happen:
 * `username` secret is stored under `/etc/foo/my-group/my-username` file instead of `/etc/foo/username`.
 * `password` secret is not projected
 
-If `spec.volumes[].secret.items` is used, only keys specified in `items` are projected.
+If `.spec.volumes[].secret.items` is used, only keys specified in `items` are projected.
 To consume all keys from the secret, all of them must be listed in the `items` field.
 All listed keys must exist in the corresponding secret. Otherwise, the volume is not created.
 

content/en/docs/concepts/policy/resource-quotas.md

@@ -143,7 +143,7 @@ The following types are supported:
 | ------------------------------- | ------------------------------------------------- |
 | `configmaps` | The total number of config maps that can exist in the namespace. |
 | `persistentvolumeclaims` | The total number of [persistent volume claims](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) that can exist in the namespace. |
-| `pods` | The total number of pods in a non-terminal state that can exist in the namespace.  A pod is in a terminal state if `status.phase in (Failed, Succeeded)` is true.  |
+| `pods` | The total number of pods in a non-terminal state that can exist in the namespace.  A pod is in a terminal state if `.status.phase in (Failed, Succeeded)` is true.  |
 | `replicationcontrollers` | The total number of replication controllers that can exist in the namespace. |
 | `resourcequotas` | The total number of [resource quotas](/docs/admin/admission-controllers/#resourcequota) that can exist in the namespace. |
 | `services` | The total number of services that can exist in the namespace. |
@@ -166,8 +166,8 @@ Resources specified on the quota outside of the allowed set results in a validat
 
 | Scope | Description |
 | ----- | ----------- |
-| `Terminating` | Match pods where `spec.activeDeadlineSeconds >= 0` |
+| `Terminating` | Match pods where `.spec.activeDeadlineSeconds >= 0` |
-| `NotTerminating` | Match pods where `spec.activeDeadlineSeconds is nil` |
+| `NotTerminating` | Match pods where `.spec.activeDeadlineSeconds is nil` |
 | `BestEffort` | Match pods that have best effort quality of service. |
 | `NotBestEffort` | Match pods that do not have best effort quality of service. |
 

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

@@ -263,7 +263,7 @@ spec:
 ## Choosing your own IP address
 
 You can specify your own cluster IP address as part of a `Service` creation
-request.  To do this, set the `spec.clusterIP` field. For example, if you
+request.  To do this, set the `.spec.clusterIP` field. For example, if you
 already have an existing DNS entry that you wish to replace, or legacy systems
 that are configured for a specific IP address and difficult to re-configure.
 The IP address that a user chooses must be a valid IP address and within the
@@ -345,7 +345,7 @@ The Kubernetes DNS server is the only way to access services of type
 
 Sometimes you don't need or want load-balancing and a single service IP.  In
 this case, you can create "headless" services by specifying `"None"` for the
-cluster IP (`spec.clusterIP`).
+cluster IP (`.spec.clusterIP`).
 
 This option allows developers to reduce coupling to the Kubernetes system by
 allowing them freedom to do discovery their own way.  Applications can still use
@@ -404,7 +404,7 @@ The default is `ClusterIP`.
 If you set the `type` field to `NodePort`, the Kubernetes master will
 allocate a port from a flag-configured range (default: 30000-32767), and each
 Node will proxy that port (the same port number on every Node) into your `Service`.
-That port will be reported in your `Service`'s `spec.ports[*].nodePort` field.
+That port will be reported in your `Service`'s `.spec.ports[*].nodePort` field.
 
 If you want to specify particular IP(s) to proxy the port, you can set the `--nodeport-addresses` flag in kube-proxy to particular IP block(s) (which is supported since Kubernetes v1.10). A comma-delimited list of IP blocks (e.g. 10.0.0.0/8, 1.2.3.4/32) is used to filter addresses local to this node. For example, if you start kube-proxy with flag `--nodeport-addresses=127.0.0.0/8`, kube-proxy will select only the loopback interface for NodePort Services. The `--nodeport-addresses` is defaulted to empty (`[]`), which means select all available interfaces and is in compliance with current NodePort behaviors.
 
@@ -418,7 +418,7 @@ configure environments that are not fully supported by Kubernetes, or
 even to just expose one or more nodes' IPs directly.
 
 Note that this Service will be visible as both `<NodeIP>:spec.ports[*].nodePort`
-and `spec.clusterIP:spec.ports[*].port`. (If the `--nodeport-addresses` flag in kube-proxy is set, <NodeIP> would be filtered NodeIP(s).)
+and `.spec.clusterIP:spec.ports[*].port`. (If the `--nodeport-addresses` flag in kube-proxy is set, <NodeIP> would be filtered NodeIP(s).)
 
 ### Type LoadBalancer
 
@@ -426,7 +426,7 @@ On cloud providers which support external load balancers, setting the `type`
 field to `LoadBalancer` will provision a load balancer for your `Service`.
 The actual creation of the load balancer happens asynchronously, and
 information about the provisioned balancer will be published in the `Service`'s
-`status.loadBalancer` field.  For example:
+`.status.loadBalancer` field.  For example:
 
 ```yaml
 kind: Service
@@ -704,15 +704,15 @@ with the value set to `nlb`.
 ```
 
 Unlike Classic Elastic Load Balancers, Network Load Balancers (NLBs) forward the
-client's IP through to the node. If a service's `spec.externalTrafficPolicy` is
+client's IP through to the node. If a service's `.spec.externalTrafficPolicy` is
 set to `Cluster`, the client's IP address will not be propagated to the end
 pods.
 
-By setting `spec.externalTrafficPolicy` to `Local`, client IP addresses will be
+By setting `.spec.externalTrafficPolicy` to `Local`, client IP addresses will be
 propagated to the end pods, but this could result in uneven distribution of
 traffic. Nodes without any pods for a particular LoadBalancer service will fail
 the NLB Target Group's health check on the auto-assigned
-`spec.healthCheckNodePort` and not receive any traffic.
+`.spec.healthCheckNodePort` and not receive any traffic.
 
 In order to achieve even traffic, either use a DaemonSet, or specify a
 [pod anti-affinity](/docs/concepts/configuration/assign-pod-node/#inter-pod-affinity-and-anti-affinity-beta-feature)
@@ -726,11 +726,11 @@ groups are modified with the following IP rules:
 
 | Rule | Protocol | Port(s) | IpRange(s) | IpRange Description |
 |------|----------|---------|------------|---------------------|
-| Health Check | TCP | NodePort(s) (`spec.healthCheckNodePort` for `spec.externalTrafficPolicy = Local`) | VPC CIDR | kubernetes.io/rule/nlb/health=\<loadBalancerName\> |
+| Health Check | TCP | NodePort(s) (`.spec.healthCheckNodePort` for `.spec.externalTrafficPolicy = Local`) | VPC CIDR | kubernetes.io/rule/nlb/health=\<loadBalancerName\> |
-| Client Traffic | TCP | NodePort(s) | `spec.loadBalancerSourceRanges` (defaults to `0.0.0.0/0`) | kubernetes.io/rule/nlb/client=\<loadBalancerName\> |
+| Client Traffic | TCP | NodePort(s) | `.spec.loadBalancerSourceRanges` (defaults to `0.0.0.0/0`) | kubernetes.io/rule/nlb/client=\<loadBalancerName\> |
-| MTU Discovery | ICMP | 3,4 | `spec.loadBalancerSourceRanges` (defaults to `0.0.0.0/0`) | kubernetes.io/rule/nlb/mtu=\<loadBalancerName\> |
+| MTU Discovery | ICMP | 3,4 | `.spec.loadBalancerSourceRanges` (defaults to `0.0.0.0/0`) | kubernetes.io/rule/nlb/mtu=\<loadBalancerName\> |
 
-Be aware that if `spec.loadBalancerSourceRanges` is not set, Kubernetes will
+Be aware that if `.spec.loadBalancerSourceRanges` is not set, Kubernetes will
 allow traffic from `0.0.0.0/0` to the Node Security Group(s). If nodes have
 public IP addresses, be aware that non-NLB traffic can also reach all instances
 in those modified security groups.

content/en/docs/concepts/storage/volumes.md

@@ -50,9 +50,9 @@ medium that backs it, and the contents of it are determined by the particular
 volume type used.
 
 To use a volume, a Pod specifies what volumes to provide for the Pod (the
-`spec.volumes`
+`.spec.volumes`
 field) and where to mount those into Containers (the
-`spec.containers.volumeMounts`
+`.spec.containers.volumeMounts`
 field).
 
 A process in a container sees a filesystem view composed from their Docker

content/en/docs/concepts/workloads/controllers/deployment.md

@@ -715,7 +715,7 @@ $ kubectl patch deployment/nginx-deployment -p '{"spec":{"progressDeadlineSecond
 deployment "nginx-deployment" patched
 ```
 Once the deadline has been exceeded, the Deployment controller adds a DeploymentCondition with the following
-attributes to the Deployment's `status.conditions`:
+attributes to the Deployment's `.status.conditions`:
 
 * Type=Progressing
 * Status=False