resolving conflicts

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

@@ -1068,7 +1068,7 @@ allowed, which is the default if not specified.
 
 ### Selector
 
-`.spec.selector` is an required field that specifies a [label selector](/docs/concepts/overview/working-with-objects/labels/)
+`.spec.selector` is a required field that specifies a [label selector](/docs/concepts/overview/working-with-objects/labels/)
 for the Pods targeted by this Deployment.
 
 `.spec.selector` must match `.spec.template.metadata.labels`, or it will be rejected by the API.

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

@@ -215,8 +215,8 @@ To do so, set `.spec.backoffLimit` to specify the number of retries before
 considering a Job as failed. The back-off limit is set by default to 6. Failed
 Pods associated with the Job are recreated by the Job controller with an
 exponential back-off delay (10s, 20s, 40s ...) capped at six minutes. The
-back-off count is reset if no new failed Pods appear before the Job's next
-status check.
+back-off count is reset when a Job's Pod is deleted or successful without any
+other Pods for the Job failing around that time.
 
 {{< note >}}
 If your job has `restartPolicy = "OnFailure"`, keep in mind that your container running the Job
@@ -474,4 +474,3 @@ object, but maintains complete control over what Pods are created and how work i
 ## Cron Jobs {#cron-jobs}
 
 You can use a [`CronJob`](/docs/concepts/workloads/controllers/cron-jobs/) to create a Job that will run at specified times/dates, similar to the Unix tool `cron`.
-

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

@@ -141,6 +141,18 @@ As each Pod is created, it gets a matching DNS subdomain, taking the form:
 `$(podname).$(governing service domain)`, where the governing service is defined
 by the `serviceName` field on the StatefulSet.
 
+Depending on how DNS is configured in your cluster, you may not be able to look up the DNS
+name for a newly-run Pod immediately. This behavior can occur when other clients in the
+cluster have already sent queries for the hostname of the Pod before it was created.
+Negative caching (normal in DNS) means that the results of previous failed lookups are
+remembered and reused, even after the Pod is running, for at least a few seconds.
+
+If you need to discover Pods promptly after they are created, you have a few options:
+
+- Query the Kubernetes API directly (for example, using a watch) rather than relying on DNS lookups.
+- Decrease the time of caching in your Kubernetes DNS provider (tpyically this means editing the config map for CoreDNS, which currently caches for 30 seconds).
+
+
 As mentioned in the [limitations](#limitations) section, you are responsible for
 creating the [Headless Service](/docs/concepts/services-networking/service/#headless-services)
 responsible for the network identity of the pods.
@@ -278,5 +290,3 @@ StatefulSet will then begin to recreate the Pods using the reverted template.
 * Follow an example of [deploying Cassandra with Stateful Sets](/docs/tutorials/stateful-application/cassandra/).
 * Follow an example of [running a replicated stateful application](/docs/tasks/run-application/run-replicated-stateful-application/).
 
-
-