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.

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

@@ -206,17 +206,17 @@ 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
-first readiness 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
-will be marked as ready. The kubelet will continue to run this check every 10
+This example uses both readiness and liveness probes. The kubelet will run the 
+first liveness probe 15 seconds after the container starts. This will attempt to 
+connect to the `goproxy` container on port 8080. If the liveness probe fails, the 
+container will be restarted. The kubelet will continue to run this check every 10
 seconds.
 
-In addition to the readiness probe, this configuration includes a liveness probe.
-The kubelet will run the first liveness probe 15 seconds after the container
-starts. Similar to the readiness probe, this will attempt to connect to the
-`goproxy` container on port 8080. If the liveness probe fails, the container
-will be restarted.
+In addition to the liveness probe, this configuration includes a readiness probe.
+The kubelet will run the first readiness probe 15 seconds after the container
+starts. Similar to the liveness probe, this will attempt to connect to the
+`goproxy` container on port 8080. If the readiness probe fails, the container
+will be marked unready and will not receive traffic from any services.
 
 To try the TCP liveness check, create a Pod: