Update configure-liveness-readiness-startup-probes.md (#47098)

* Update configure-liveness-readiness-startup-probes.md

Flip the order in which liveness and readiness probes are discussed in the TCP liveness probe section, because that makes more sense.

* Some updates

* More updates

Some more edits as I read through the page...

content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md

@@ -208,17 +208,19 @@ can't it is considered a failure.
 {{% code_sample file="pods/probe/tcp-liveness-readiness.yaml" %}}
 
 As you can see, configuration for a TCP check is quite similar to an HTTP check.
-This example uses both readiness and liveness probes. The kubelet will send the
+This example uses both readiness and liveness probes. The kubelet will run the
-first readiness probe 15 seconds after the container starts. This will attempt to
+first liveness probe 15 seconds after the container starts. This will attempt to
-connect to the `goproxy` container on port 8080. If the probe succeeds, the Pod
+connect to the `goproxy` container on port 8080. If the liveness probe fails,
-will be marked as ready. The kubelet will continue to run this check every 10
+the container will be restarted. The kubelet will continue to run this check
-seconds.
+every 10 seconds.
 
-In addition to the readiness probe, this configuration includes a liveness probe.
+In addition to the liveness probe, this configuration includes a readiness
-The kubelet will run the first liveness probe 15 seconds after the container
+probe. The kubelet will run the first readiness probe 15 seconds after the
-starts. Similar to the readiness probe, this will attempt to connect to the
+container starts. Similar to the liveness probe, this will attempt to connect to
-`goproxy` container on port 8080. If the liveness probe fails, the container
+the `goproxy` container on port 8080. If the probe succeeds, the Pod will be
-will be restarted.
+marked as ready and will receive traffic from services. If the readiness probe
+fails, the pod will be marked unready and will not receive traffic from any
+services.
 
 To try the TCP liveness check, create a Pod:
 
@@ -305,13 +307,12 @@ livenessProbe:
 
 ## Protect slow starting containers with startup probes {#define-startup-probes}
 
-Sometimes, you have to deal with legacy applications that might require
+Sometimes, you have to deal with applications that require additional startup
-an additional startup time on their first initialization.
+time on their first initialization. In such cases, it can be tricky to set up
-In such cases, it can be tricky to set up liveness probe parameters without
+liveness probe parameters without compromising the fast response to deadlocks
-compromising the fast response to deadlocks that motivated such a probe.
+that motivated such a probe. The solution is to set up a startup probe with the
-The trick is to set up a startup probe with the same command, HTTP or TCP
+same command, HTTP or TCP check, with a `failureThreshold * periodSeconds` long
-check, with a `failureThreshold * periodSeconds` long enough to cover the
+enough to cover the worst case startup time.
-worst case startup time.
 
 So, the previous example would become:
 
@@ -394,7 +395,7 @@ liveness and readiness checks:
 * `initialDelaySeconds`: Number of seconds after the container has started before startup,
   liveness or readiness probes are initiated. If a startup  probe is defined, liveness and
   readiness probe delays do not begin until the startup probe has succeeded. If the value of
-  `periodSeconds` is greater than `initialDelaySeconds` then the `initialDelaySeconds` would be
+  `periodSeconds` is greater than `initialDelaySeconds` then the `initialDelaySeconds` will be
   ignored. Defaults to 0 seconds. Minimum value is 0.
 * `periodSeconds`: How often (in seconds) to perform the probe. Default to 10 seconds.
   The minimum value is 1.