clientFinTimeout
|
string
|
clientFinTimeout defines how long a connection will be held open while waiting for the client response to the server/backend closing the connection.
If unset, the default timeout is 1s |
clientTimeout
|
string
|
clientTimeout defines how long a connection will be held open while waiting for a client response.
If unset, the default timeout is 30s |
connectTimeout
|
string
|
ConnectTimeout defines the maximum time to wait for a connection attempt to a server/backend to succeed.
This field expects an unsigned duration string of decimal numbers, each with optional fraction and a unit suffix, e.g. "300ms", "1.5h" or "2h45m". Valid time units are "ns", "us" (or "µs" U+00B5 or "μs" U+03BC), "ms", "s", "m", "h".
When omitted, this means the user has no opinion and the platform is left to choose a reasonable default. This default is subject to change over time. The current default is 5s. |
headerBufferBytes
|
integer
|
headerBufferBytes describes how much memory should be reserved (in bytes) for IngressController connection sessions. Note that this value must be at least 16384 if HTTP/2 is enabled for the IngressController (https://tools.ietf.org/html/rfc7540). If this field is empty, the IngressController will use a default value of 32768 bytes.
Setting this field is generally not recommended as headerBufferBytes values that are too small may break the IngressController and headerBufferBytes values that are too large could cause the IngressController to use significantly more memory than necessary. |
headerBufferMaxRewriteBytes
|
integer
|
headerBufferMaxRewriteBytes describes how much memory should be reserved (in bytes) from headerBufferBytes for HTTP header rewriting and appending for IngressController connection sessions. Note that incoming HTTP requests will be limited to (headerBufferBytes - headerBufferMaxRewriteBytes) bytes, meaning headerBufferBytes must be greater than headerBufferMaxRewriteBytes. If this field is empty, the IngressController will use a default value of 8192 bytes.
Setting this field is generally not recommended as headerBufferMaxRewriteBytes values that are too small may break the IngressController and headerBufferMaxRewriteBytes values that are too large could cause the IngressController to use significantly more memory than necessary. |
healthCheckInterval
|
string
|
healthCheckInterval defines how long the router waits between two consecutive health checks on its configured backends. This value is applied globally as a default for all routes, but may be overridden per-route by the route annotation "router.openshift.io/haproxy.health.check.interval".
Expects an unsigned duration string of decimal numbers, each with optional fraction and a unit suffix, eg "300ms", "1.5h" or "2h45m". Valid time units are "ns", "us" (or "µs" U+00B5 or "μs" U+03BC), "ms", "s", "m", "h".
Setting this to less than 5s can cause excess traffic due to too frequent TCP health checks and accompanying SYN packet storms. Alternatively, setting this too high can result in increased latency, due to backend servers that are no longer available, but haven’t yet been detected as such.
An empty or zero healthCheckInterval means no opinion and IngressController chooses a default, which is subject to change over time. Currently the default healthCheckInterval value is 5s.
Currently the minimum allowed value is 1s and the maximum allowed value is 2147483647ms (24.85 days). Both are subject to change over time. |
maxConnections
|
integer
|
maxConnections defines the maximum number of simultaneous connections that can be established per haproxy process. Increasing this value allows each ingress controller pod to handle more connections but at the cost of additional system resources being consumed.
Permitted values are: empty, 0, -1, and the range 2000-2000000.
If this field is empty or 0, the IngressController will use the default value of 50000, but the default is subject to change in future releases.
If the value is -1 then haproxy will dynamically compute a maximum value based on the available ulimits in the running container. Selecting -1 (i.e., auto) will result in a large value being computed (~520000 on OpenShift >=4.10 clusters) and therefore each haproxy process will incur significant memory usage compared to the current default of 50000.
Setting a value that is greater than the current operating system limit will prevent the haproxy process from starting.
If you choose a discrete value (e.g., 750000) and the router pod is migrated to a new node, there’s no guarantee that that new node has identical ulimits configured. In such a scenario the pod would fail to start. If you have nodes with different ulimits configured (e.g., different tuned profiles) and you choose a discrete value then the guidance is to use -1 and let the value be computed dynamically at runtime.
You can monitor memory usage for router containers with the following metric: 'container_memory_working_set_bytes{container="router",namespace="openshift-ingress"}'.
You can monitor memory usage of individual haproxy processes in router containers with the following metric: 'container_memory_working_set_bytes{container="router",namespace="openshift-ingress"}/container_processes{container="router",namespace="openshift-ingress"}'. |
reloadInterval
|
string
|
reloadInterval defines the minimum interval at which the router is allowed to reload to accept new changes. Increasing this value can prevent the accumulation of haproxy processes, depending on the scenario. Increasing this interval can also lessen load imbalance on a backend’s servers when using the roundrobin balancing algorithm. Alternatively, decreasing this value may decrease latency since updates to haproxy’s configuration can take effect more quickly.
The value must be a time duration value; see https://pkg.go.dev/time#ParseDuration. Currently, the minimum value allowed is 1s, and the maximum allowed value is 120s. Minimum and maximum allowed values may change in future versions of OpenShift. Note that if a duration outside of these bounds is provided, the value of reloadInterval will be capped/floored and not rejected (e.g. a duration of over 120s will be capped to 120s; the IngressController will not reject and replace this disallowed value with the default).
A zero value for reloadInterval tells the IngressController to choose the default, which is currently 5s and subject to change without notice.
This field expects an unsigned duration string of decimal numbers, each with optional fraction and a unit suffix, e.g. "300ms", "1.5h" or "2h45m". Valid time units are "ns", "us" (or "µs" U+00B5 or "μs" U+03BC), "ms", "s", "m", "h".
Note: Setting a value significantly larger than the default of 5s can cause latency in observing updates to routes and their endpoints. haproxy’s configuration will be reloaded less frequently, and newly created routes will not be served until the subsequent reload. |
serverFinTimeout
|
string
|
serverFinTimeout defines how long a connection will be held open while waiting for the server/backend response to the client closing the connection.
If unset, the default timeout is 1s |
serverTimeout
|
string
|
serverTimeout defines how long a connection will be held open while waiting for a server/backend response.
If unset, the default timeout is 30s |
threadCount
|
integer
|
threadCount defines the number of threads created per haproxy process. Creating more threads allows each ingress controller pod to handle more connections, at the cost of more system resources being used. haproxy currently supports up to 64 threads. If this field is empty, the IngressController will use the default value. The current default is 4 threads, but this may change in future releases.
Setting this field is generally not recommended. Increasing the number of haproxy threads allows ingress controller pods to utilize more CPU time under load, potentially starving other pods if set too high. Reducing the number of threads may cause the ingress controller to perform poorly. |
tlsInspectDelay
|
string
|
tlsInspectDelay defines how long the router can hold data to find a matching route.
Setting this too short can cause the router to fall back to the default certificate for edge-terminated or reencrypt routes even when a better matching certificate could be used.
If unset, the default inspect delay is 5s |
tunnelTimeout
|
string
|
tunnelTimeout defines how long a tunnel connection (including websockets) will be held open while the tunnel is idle.
If unset, the default timeout is 1h |