OSDOCS-3418: Adding timeout configuration for Ingress Controller router

Author: skrthomas

modules/router-performance-optimizations.adoc

@@ -2,9 +2,53 @@
 // * scalability_and_performance/routing-optimization.adoc
 // * post_installation_configuration/network-configuration.adoc
 
+:_content-type: Procedure
 [id="router-performance-optimizations_{context}"]
 = Ingress Controller (router) performance optimizations
 
 {product-title} no longer supports modifying Ingress Controller deployments by setting environment variables such as `ROUTER_THREADS`, `ROUTER_DEFAULT_TUNNEL_TIMEOUT`, `ROUTER_DEFAULT_CLIENT_TIMEOUT`, `ROUTER_DEFAULT_SERVER_TIMEOUT`, and `RELOAD_INTERVAL`.
 
 You can modify the Ingress Controller deployment, but if the Ingress Operator is enabled, the configuration is overwritten.
+
+== Configuring Ingress Controller liveness, readiness, and startup probes
+
+Cluster administrators can configure the timeout values for the kubelet's liveness, readiness, and startup probes for router deployments that are managed by the {product-title} Ingress Controller (router). The liveness and readiness probes of the router use the default timeout value
+of 1 second, which is too short for the kubelet's probes to succeed in some scenarios. Probe timeouts can cause unwanted router restarts that interrupt application connections. The ability to set larger timeout values can reduce the risk of unnecessary and unwanted restarts.
+
+You can update the `timeoutSeconds` value on the `livenessProbe`, `readinessProbe`, and `startupProbe` parameters of the router container.
+
+[cols="3a,8a",options="header"]
+|===
+ |Parameter |Description
+
+ |`livenessProbe`
+ |The `livenessProbe` reports to the kubelet whether a pod is dead and needs to be restarted.
+
+ |`readinessProbe`
+ |The `readinessProbe` reports whether a pod is healthy or unhealthy. When the readiness probe reports an unhealthy pod, then the kubelet marks the pod as not ready to accept traffic. Subsequently, the endpoints for that pod are marked as not ready, and this status propogates to the kube-proxy. On cloud platforms with a configured load balancer, the kube-proxy communicates to the cloud load-balancer not to send traffic to the node with that pod.
+
+ |`startupProbe`
+ |The `startupProbe` gives the router pod up to 2 minutes to initialize before the kubelet begins sending the router liveness and readiness probes.  This initialization time can prevent routers with many routes or endpoints from prematurely restarting.
+|===
+
+
+[IMPORTANT]
+====
+The timeout configuration option is an advanced tuning technique that can be used to work around issues. However, these issues should eventually be diagnosed and possibly a support case or Bugzilla report opened for any issues that causes probes to time out.
+====
+
+The following example demonstrates how you can directly patch the default router deployment to set a 5-second timeout for the liveness and readiness probes:
+
+
+[source, terminal]
+----
+$ oc -n openshift-ingress patch deploy/router-default --type=strategic --patch='{"spec":{"template":{"spec":{"containers":[{"name":"router","livenessProbe":{"timeoutSeconds":5},"readinessProbe":{"timeoutSeconds":5}}]}}}}'
+----
+
+.Verification
+[source, terminal]
+----
+$ oc -n openshift-ingress describe deploy/router-default | grep -e Liveness: -e Readiness:
+    Liveness:   http-get http://:1936/healthz delay=0s timeout=5s period=10s #success=1 #failure=3
+    Readiness:  http-get http://:1936/healthz/ready delay=0s timeout=5s period=10s #success=1 #failure=3
+----