openshift-docs/rest_api/operator_apis/ingresscontroller-operator-openshift-io-v1.adoc

// Automatically generated by 'openshift-apidocs-gen'. Do not edit.
:_mod-docs-content-type: ASSEMBLY
[id="ingresscontroller-operator-openshift-io-v1"]
= IngressController [operator.openshift.io/v1]
:toc: macro
:toc-title:

toc::[]


Description::
+
--
IngressController describes a managed ingress controller for the cluster. The
controller can service OpenShift Route and Kubernetes Ingress resources.

When an IngressController is created, a new ingress controller deployment is
created to allow external traffic to reach the services that expose Ingress
or Route resources. Updating this resource may lead to disruption for public
facing network connections as a new ingress controller revision may be rolled
out.

https://kubernetes.io/docs/concepts/services-networking/ingress-controllers

Whenever possible, sensible defaults for the platform are used. See each
field for more details.

Compatibility level 1: Stable within a major release for a minimum of 12 months or 3 minor releases (whichever is longer).
--

Type::
  `object`



== Specification

[cols="1,1,1",options="header"]
|===
| Property | Type | Description

| `apiVersion`
| `string`
| APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources

| `kind`
| `string`
| Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds

| `metadata`
| xref:../objects/index.adoc#io-k8s-apimachinery-pkg-apis-meta-v1-ObjectMeta[`ObjectMeta`]
| Standard object's metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

| `spec`
| `object`
| spec is the specification of the desired behavior of the IngressController.

| `status`
| `object`
| status is the most recently observed status of the IngressController.

|===
=== .spec
Description::
+
--
spec is the specification of the desired behavior of the IngressController.
--

Type::
  `object`




[cols="1,1,1",options="header"]
|===
| Property | Type | Description

| `clientTLS`
| `object`
| clientTLS specifies settings for requesting and verifying client
certificates, which can be used to enable mutual TLS for
edge-terminated and reencrypt routes.

| `closedClientConnectionPolicy`
| `string`
| closedClientConnectionPolicy controls how the IngressController
behaves when the client closes the TCP connection while the TLS
handshake or HTTP request is in progress. This option maps directly
to HAProxy’s "abortonclose" option.

Valid values are: "Abort" and "Continue".
The default value is "Continue".

When set to "Abort", the router will stop processing the TLS handshake
if it is in progress, and it will not send an HTTP request to the backend server
if the request has not yet been sent when the client closes the connection.

When set to "Continue", the router will complete the TLS handshake
if it is in progress, or send an HTTP request to the backend server
and wait for the backend server's response, regardless of
whether the client has closed the connection.

Setting "Abort" can help free CPU resources otherwise spent on TLS computation
for connections the client has already closed, and can reduce request queue
size, thereby reducing the load on saturated backend servers.

Important Considerations:

  - The default policy ("Continue") is HTTP-compliant, and requests
    for aborted client connections will still be served.
    Use the "Continue" policy to allow a client to send a request
    and then immediately close its side of the connection while
    still receiving a response on the half-closed connection.

  - When clients use keep-alive connections, the most common case for premature
    closure is when the user wants to cancel the transfer or when a timeout
    occurs. In that case, the "Abort" policy may be used to reduce resource consumption.

  - Using RSA keys larger than 2048 bits can significantly slow down
    TLS computations. Consider using the "Abort" policy to reduce CPU usage.

| `defaultCertificate`
| `object`
| defaultCertificate is a reference to a secret containing the default
certificate served by the ingress controller. When Routes don't specify
their own certificate, defaultCertificate is used.

The secret must contain the following keys and data:

  tls.crt: certificate file contents
  tls.key: key file contents

If unset, a wildcard certificate is automatically generated and used. The
certificate is valid for the ingress controller domain (and subdomains) and
the generated certificate's CA will be automatically integrated with the
cluster's trust store.

If a wildcard certificate is used and shared by multiple
HTTP/2 enabled routes (which implies ALPN) then clients
(i.e., notably browsers) are at liberty to reuse open
connections. This means a client can reuse a connection to
another route and that is likely to fail. This behaviour is
generally known as connection coalescing.

The in-use certificate (whether generated or user-specified) will be
automatically integrated with OpenShift's built-in OAuth server.

| `domain`
| `string`
| domain is a DNS name serviced by the ingress controller and is used to
configure multiple features:

* For the LoadBalancerService endpoint publishing strategy, domain is
  used to configure DNS records. See endpointPublishingStrategy.

* When using a generated default certificate, the certificate will be valid
  for domain and its subdomains. See defaultCertificate.

* The value is published to individual Route statuses so that end-users
  know where to target external DNS records.

domain must be unique among all IngressControllers, and cannot be
updated.

If empty, defaults to ingress.config.openshift.io/cluster .spec.domain.

The domain value must be a valid DNS name. It must consist of lowercase
alphanumeric characters, '-' or '.', and each label must start and end
with an alphanumeric character and not exceed 63 characters. Maximum
length of a valid DNS domain is 253 characters.

The implementation may add a prefix such as "router-default." to the domain
when constructing the router canonical hostname. To ensure the resulting
hostname does not exceed the DNS maximum length of 253 characters,
the domain length is additionally validated at the IngressController object
level. For the maximum length of the domain value itself, the shortest
possible variant of the prefix and the ingress controller name was considered
for example "router-a."

| `endpointPublishingStrategy`
| `object`
| endpointPublishingStrategy is used to publish the ingress controller
endpoints to other networks, enable load balancer integrations, etc.

If unset, the default is based on
infrastructure.config.openshift.io/cluster .status.platform:

  AWS:          LoadBalancerService (with External scope)
  Azure:        LoadBalancerService (with External scope)
  GCP:          LoadBalancerService (with External scope)
  IBMCloud:     LoadBalancerService (with External scope)
  AlibabaCloud: LoadBalancerService (with External scope)
  Libvirt:      HostNetwork

Any other platform types (including None) default to HostNetwork.

endpointPublishingStrategy cannot be updated.

| `httpCompression`
| `object`
| httpCompression defines a policy for HTTP traffic compression.
By default, there is no HTTP compression.

| `httpEmptyRequestsPolicy`
| `string`
| httpEmptyRequestsPolicy describes how HTTP connections should be
handled if the connection times out before a request is received.
Allowed values for this field are "Respond" and "Ignore".  If the
field is set to "Respond", the ingress controller sends an HTTP 400
or 408 response, logs the connection (if access logging is enabled),
and counts the connection in the appropriate metrics.  If the field
is set to "Ignore", the ingress controller closes the connection
without sending a response, logging the connection, or incrementing
metrics.  The default value is "Respond".

Typically, these connections come from load balancers' health probes
or Web browsers' speculative connections ("preconnect") and can be
safely ignored.  However, these requests may also be caused by
network errors, and so setting this field to "Ignore" may impede
detection and diagnosis of problems.  In addition, these requests may
be caused by port scans, in which case logging empty requests may aid
in detecting intrusion attempts.

| `httpErrorCodePages`
| `object`
| httpErrorCodePages specifies a configmap with custom error pages.
The administrator must create this configmap in the openshift-config namespace.
This configmap should have keys in the format "error-page-<error code>.http",
where <error code> is an HTTP error code.
For example, "error-page-503.http" defines an error page for HTTP 503 responses.
Currently only error pages for 503 and 404 responses can be customized.
Each value in the configmap should be the full response, including HTTP headers.
Eg- https://raw.githubusercontent.com/openshift/router/fadab45747a9b30cc3f0a4b41ad2871f95827a93/images/router/haproxy/conf/error-page-503.http
If this field is empty, the ingress controller uses the default error pages.

| `httpHeaders`
| `object`
| httpHeaders defines policy for HTTP headers.

If this field is empty, the default values are used.

| `idleConnectionTerminationPolicy`
| `string`
| idleConnectionTerminationPolicy maps directly to HAProxy's
idle-close-on-response option and controls whether HAProxy
keeps idle frontend connections open during a soft stop
(router reload).

Allowed values for this field are "Immediate" and
"Deferred". The default value is "Immediate".

When set to "Immediate", idle connections are closed
immediately during router reloads. This ensures immediate
propagation of route changes but may impact clients
sensitive to connection resets.

When set to "Deferred", HAProxy will maintain idle
connections during a soft reload instead of closing them
immediately. These connections remain open until any of the
following occurs:

  - A new request is received on the connection, in which
    case HAProxy handles it in the old process and closes
    the connection after sending the response.

  - HAProxy's `timeout http-keep-alive` duration expires.
    By default this is 300 seconds, but it can be changed
    using httpKeepAliveTimeout tuning option.

  - The client's keep-alive timeout expires, causing the
    client to close the connection.

Setting Deferred can help prevent errors in clients or load
balancers that do not properly handle connection resets.
Additionally, this option allows you to retain the pre-2.4
HAProxy behaviour: in HAProxy version 2.2 (OpenShift
versions < 4.14), maintaining idle connections during a
soft reload was the default behaviour, but starting with
HAProxy 2.4, the default changed to closing idle
connections immediately.

Important Consideration:

  - Using Deferred will result in temporary inconsistencies
    for the first request on each persistent connection
    after a route update and router reload. This request
    will be processed by the old HAProxy process using its
    old configuration. Subsequent requests will use the
    updated configuration.

Operational Considerations:

  - Keeping idle connections open during reloads may lead
    to an accumulation of old HAProxy processes if
    connections remain idle for extended periods,
    especially in environments where frequent reloads
    occur.

  - Consider monitoring the number of HAProxy processes in
    the router pods when Deferred is set.

  - You may need to enable or adjust the
    `ingress.operator.openshift.io/hard-stop-after`
    duration (configured via an annotation on the
    IngressController resource) in environments with
    frequent reloads to prevent resource exhaustion.

| `logging`
| `object`
| logging defines parameters for what should be logged where.  If this
field is empty, operational logs are enabled but access logs are
disabled.

| `namespaceSelector`
| `object`
| namespaceSelector is used to filter the set of namespaces serviced by the
ingress controller. This is useful for implementing shards.

If unset, the default is no filtering.

| `nodePlacement`
| `object`
| nodePlacement enables explicit control over the scheduling of the ingress
controller.

If unset, defaults are used. See NodePlacement for more details.

| `replicas`
| `integer`
| replicas is the desired number of ingress controller replicas. If unset,
the default depends on the value of the defaultPlacement field in the
cluster config.openshift.io/v1/ingresses status.

The value of replicas is set based on the value of a chosen field in the
Infrastructure CR. If defaultPlacement is set to ControlPlane, the
chosen field will be controlPlaneTopology. If it is set to Workers the
chosen field will be infrastructureTopology. Replicas will then be set to 1
or 2 based whether the chosen field's value is SingleReplica or
HighlyAvailable, respectively.

These defaults are subject to change.

| `routeAdmission`
| `object`
| routeAdmission defines a policy for handling new route claims (for example,
to allow or deny claims across namespaces).

If empty, defaults will be applied. See specific routeAdmission fields
for details about their defaults.

| `routeSelector`
| `object`
| routeSelector is used to filter the set of Routes serviced by the ingress
controller. This is useful for implementing shards.

If unset, the default is no filtering.

| `tlsSecurityProfile`
| `object`
| tlsSecurityProfile specifies settings for TLS connections for ingresscontrollers.

If unset, the default is based on the apiservers.config.openshift.io/cluster resource.

Note that when using the Old, Intermediate, and Modern profile types, the effective
profile configuration is subject to change between releases. For example, given
a specification to use the Intermediate profile deployed on release X.Y.Z, an upgrade
to release X.Y.Z+1 may cause a new profile configuration to be applied to the ingress
controller, resulting in a rollout.

| `tuningOptions`
| `object`
| tuningOptions defines parameters for adjusting the performance of
ingress controller pods. All fields are optional and will use their
respective defaults if not set. See specific tuningOptions fields for
more details.

Setting fields within tuningOptions is generally not recommended. The
default values are suitable for most configurations.

| `unsupportedConfigOverrides`
| ``
| unsupportedConfigOverrides allows specifying unsupported
configuration options.  Its use is unsupported.

|===
=== .spec.clientTLS
Description::
+
--
clientTLS specifies settings for requesting and verifying client
certificates, which can be used to enable mutual TLS for
edge-terminated and reencrypt routes.
--

Type::
  `object`

Required::
  - `clientCA`
  - `clientCertificatePolicy`



[cols="1,1,1",options="header"]
|===
| Property | Type | Description

| `allowedSubjectPatterns`
| `array (string)`
| allowedSubjectPatterns specifies a list of regular expressions that
should be matched against the distinguished name on a valid client
certificate to filter requests.  The regular expressions must use
PCRE syntax.  If this list is empty, no filtering is performed.  If
the list is nonempty, then at least one pattern must match a client
certificate's distinguished name or else the ingress controller
rejects the certificate and denies the connection.

| `clientCA`
| `object`
| clientCA specifies a configmap containing the PEM-encoded CA
certificate bundle that should be used to verify a client's
certificate.  The administrator must create this configmap in the
openshift-config namespace.

| `clientCertificatePolicy`
| `string`
| clientCertificatePolicy specifies whether the ingress controller
requires clients to provide certificates.  This field accepts the
values "Required" or "Optional".

Note that the ingress controller only checks client certificates for
edge-terminated and reencrypt TLS routes; it cannot check
certificates for cleartext HTTP or passthrough TLS routes.

|===
=== .spec.clientTLS.clientCA
Description::
+
--
clientCA specifies a configmap containing the PEM-encoded CA
certificate bundle that should be used to verify a client's
certificate.  The administrator must create this configmap in the
openshift-config namespace.
--

Type::
  `object`

Required::
  - `name`



[cols="1,1,1",options="header"]
|===
| Property | Type | Description

| `name`
| `string`
| name is the metadata.name of the referenced config map

|===
=== .spec.defaultCertificate
Description::
+
--
defaultCertificate is a reference to a secret containing the default
certificate served by the ingress controller. When Routes don't specify
their own certificate, defaultCertificate is used.

The secret must contain the following keys and data:

  tls.crt: certificate file contents
  tls.key: key file contents

If unset, a wildcard certificate is automatically generated and used. The
certificate is valid for the ingress controller domain (and subdomains) and
the generated certificate's CA will be automatically integrated with the
cluster's trust store.

If a wildcard certificate is used and shared by multiple
HTTP/2 enabled routes (which implies ALPN) then clients
(i.e., notably browsers) are at liberty to reuse open
connections. This means a client can reuse a connection to
another route and that is likely to fail. This behaviour is
generally known as connection coalescing.

The in-use certificate (whether generated or user-specified) will be
automatically integrated with OpenShift's built-in OAuth server.
--

Type::
  `object`




[cols="1,1,1",options="header"]
|===
| Property | Type | Description

| `name`
| `string`
| Name of the referent.
This field is effectively required, but due to backwards compatibility is
allowed to be empty. Instances of this type with an empty value here are
almost certainly wrong.
More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names

|===
=== .spec.endpointPublishingStrategy
Description::
+
--
endpointPublishingStrategy is used to publish the ingress controller
endpoints to other networks, enable load balancer integrations, etc.

If unset, the default is based on
infrastructure.config.openshift.io/cluster .status.platform:

  AWS:          LoadBalancerService (with External scope)
  Azure:        LoadBalancerService (with External scope)
  GCP:          LoadBalancerService (with External scope)
  IBMCloud:     LoadBalancerService (with External scope)
  AlibabaCloud: LoadBalancerService (with External scope)
  Libvirt:      HostNetwork

Any other platform types (including None) default to HostNetwork.

endpointPublishingStrategy cannot be updated.
--

Type::
  `object`

Required::
  - `type`



[cols="1,1,1",options="header"]
|===
| Property | Type | Description

| `hostNetwork`
| `object`
| hostNetwork holds parameters for the HostNetwork endpoint publishing
strategy. Present only if type is HostNetwork.

| `loadBalancer`
| `object`
| loadBalancer holds parameters for the load balancer. Present only if
type is LoadBalancerService.

| `nodePort`
| `object`
| nodePort holds parameters for the NodePortService endpoint publishing strategy.
Present only if type is NodePortService.

| `private`
| `object`
| private holds parameters for the Private endpoint publishing
strategy. Present only if type is Private.

| `type`
| `string`
| type is the publishing strategy to use. Valid values are:

* LoadBalancerService

Publishes the ingress controller using a Kubernetes LoadBalancer Service.

In this configuration, the ingress controller deployment uses container
networking. A LoadBalancer Service is created to publish the deployment.

See: https://kubernetes.io/docs/concepts/services-networking/service/#loadbalancer

If domain is set, a wildcard DNS record will be managed to point at the
LoadBalancer Service's external name. DNS records are managed only in DNS
zones defined by dns.config.openshift.io/cluster .spec.publicZone and
.spec.privateZone.

Wildcard DNS management is currently supported only on the AWS, Azure,
and GCP platforms.

* HostNetwork

Publishes the ingress controller on node ports where the ingress controller
is deployed.

In this configuration, the ingress controller deployment uses host
networking, bound to node ports 80 and 443. The user is responsible for
configuring an external load balancer to publish the ingress controller via
the node ports.

* Private

Does not publish the ingress controller.

In this configuration, the ingress controller deployment uses container
networking, and is not explicitly published. The user must manually publish
the ingress controller.

* NodePortService

Publishes the ingress controller using a Kubernetes NodePort Service.

In this configuration, the ingress controller deployment uses container
networking. A NodePort Service is created to publish the deployment. The
specific node ports are dynamically allocated by OpenShift; however, to
support static port allocations, user changes to the node port
field of the managed NodePort Service will preserved.

|===
=== .spec.endpointPublishingStrategy.hostNetwork
Description::
+
--
hostNetwork holds parameters for the HostNetwork endpoint publishing
strategy. Present only if type is HostNetwork.
--

Type::
  `object`




[cols="1,1,1",options="header"]
|===
| Property | Type | Description

| `httpPort`
| `integer`
| httpPort is the port on the host which should be used to listen for
HTTP requests. This field should be set when port 80 is already in use.
The value should not coincide with the NodePort range of the cluster.
When the value is 0 or is not specified it defaults to 80.

| `httpsPort`
| `integer`
| httpsPort is the port on the host which should be used to listen for
HTTPS requests. This field should be set when port 443 is already in use.
The value should not coincide with the NodePort range of the cluster.
When the value is 0 or is not specified it defaults to 443.

| `protocol`
| `string`
| protocol specifies whether the IngressController expects incoming
connections to use plain TCP or whether the IngressController expects
PROXY protocol.

PROXY protocol can be used with load balancers that support it to
communicate the source addresses of client connections when
forwarding those connections to the IngressController.  Using PROXY
protocol enables the IngressController to report those source
addresses instead of reporting the load balancer's address in HTTP
headers and logs.  Note that enabling PROXY protocol on the
IngressController will cause connections to fail if you are not using
a load balancer that uses PROXY protocol to forward connections to
the IngressController.  See
http://www.haproxy.org/download/2.2/doc/proxy-protocol.txt for
information about PROXY protocol.

The following values are valid for this field:

* The empty string.
* "TCP".
* "PROXY".

The empty string specifies the default, which is TCP without PROXY
protocol.  Note that the default is subject to change.

| `statsPort`
| `integer`
| statsPort is the port on the host where the stats from the router are
published. The value should not coincide with the NodePort range of the
cluster. If an external load balancer is configured to forward connections
to this IngressController, the load balancer should use this port for
health checks. The load balancer can send HTTP probes on this port on a
given node, with the path /healthz/ready to determine if the ingress
controller is ready to receive traffic on the node. For proper operation
the load balancer must not forward traffic to a node until the health
check reports ready. The load balancer should also stop forwarding requests
within a maximum of 45 seconds after /healthz/ready starts reporting
not-ready. Probing every 5 to 10 seconds, with a 5-second timeout and with
a threshold of two successful or failed requests to become healthy or
unhealthy respectively, are well-tested values. When the value is 0 or
is not specified it defaults to 1936.

|===
=== .spec.endpointPublishingStrategy.loadBalancer
Description::
+
--
loadBalancer holds parameters for the load balancer. Present only if
type is LoadBalancerService.
--

Type::
  `object`

Required::
  - `dnsManagementPolicy`
  - `scope`



[cols="1,1,1",options="header"]
|===
| Property | Type | Description

| `allowedSourceRanges`
| ``
| allowedSourceRanges specifies an allowlist of IP address ranges to which
access to the load balancer should be restricted.  Each range must be
specified using CIDR notation (e.g. "10.0.0.0/8" or "fd00::/8"). If no range is
specified, "0.0.0.0/0" for IPv4 and "::/0" for IPv6 are used by default,
which allows all source addresses.

To facilitate migration from earlier versions of OpenShift that did
not have the allowedSourceRanges field, you may set the
service.beta.kubernetes.io/load-balancer-source-ranges annotation on
the "router-<ingresscontroller name>" service in the
"openshift-ingress" namespace, and this annotation will take
effect if allowedSourceRanges is empty on OpenShift 4.12.

| `dnsManagementPolicy`
| `string`
| dnsManagementPolicy indicates if the lifecycle of the wildcard DNS record
associated with the load balancer service will be managed by
the ingress operator. It defaults to Managed.
Valid values are: Managed and Unmanaged.

| `providerParameters`
| `object`
| providerParameters holds desired load balancer information specific to
the underlying infrastructure provider.

If empty, defaults will be applied. See specific providerParameters
fields for details about their defaults.

| `scope`
| `string`
| scope indicates the scope at which the load balancer is exposed.
Possible values are "External" and "Internal".

|===
=== .spec.endpointPublishingStrategy.loadBalancer.providerParameters
Description::
+
--
providerParameters holds desired load balancer information specific to
the underlying infrastructure provider.

If empty, defaults will be applied. See specific providerParameters
fields for details about their defaults.
--

Type::
  `object`

Required::
  - `type`



[cols="1,1,1",options="header"]
|===
| Property | Type | Description

| `aws`
| `object`
| aws provides configuration settings that are specific to AWS
load balancers.

If empty, defaults will be applied. See specific aws fields for
details about their defaults.

| `gcp`
| `object`
| gcp provides configuration settings that are specific to GCP
load balancers.

If empty, defaults will be applied. See specific gcp fields for
details about their defaults.

| `ibm`
| `object`
| ibm provides configuration settings that are specific to IBM Cloud
load balancers.

If empty, defaults will be applied. See specific ibm fields for
details about their defaults.

| `openstack`
| `object`
| openstack provides configuration settings that are specific to OpenStack
load balancers.

If empty, defaults will be applied. See specific openstack fields for
details about their defaults.

| `type`
| `string`
| type is the underlying infrastructure provider for the load balancer.
Allowed values are "AWS", "Azure", "BareMetal", "GCP", "IBM", "Nutanix",
"OpenStack", and "VSphere".

|===
=== .spec.endpointPublishingStrategy.loadBalancer.providerParameters.aws
Description::
+
--
aws provides configuration settings that are specific to AWS
load balancers.

If empty, defaults will be applied. See specific aws fields for
details about their defaults.
--

Type::
  `object`

Required::
  - `type`



[cols="1,1,1",options="header"]
|===
| Property | Type | Description

| `classicLoadBalancer`
| `object`
| classicLoadBalancerParameters holds configuration parameters for an AWS
classic load balancer. Present only if type is Classic.

| `networkLoadBalancer`
| `object`
| networkLoadBalancerParameters holds configuration parameters for an AWS
network load balancer. Present only if type is NLB.

| `type`
| `string`
| type is the type of AWS load balancer to instantiate for an ingresscontroller.

Valid values are:

* "Classic": A Classic Load Balancer that makes routing decisions at either
  the transport layer (TCP/SSL) or the application layer (HTTP/HTTPS). See
  the following for additional details:

    https://docs.aws.amazon.com/AmazonECS/latest/developerguide/load-balancer-types.html#clb

* "NLB": A Network Load Balancer that makes routing decisions at the
  transport layer (TCP/SSL). See the following for additional details:

    https://docs.aws.amazon.com/AmazonECS/latest/developerguide/load-balancer-types.html#nlb

|===
=== .spec.endpointPublishingStrategy.loadBalancer.providerParameters.aws.classicLoadBalancer
Description::
+
--
classicLoadBalancerParameters holds configuration parameters for an AWS
classic load balancer. Present only if type is Classic.
--

Type::
  `object`




[cols="1,1,1",options="header"]
|===
| Property | Type | Description

| `connectionIdleTimeout`
| `string`
| connectionIdleTimeout specifies the maximum time period that a
connection may be idle before the load balancer closes the
connection.  The value must be parseable as a time duration value;
see <https://pkg.go.dev/time#ParseDuration>.  A nil or zero value
means no opinion, in which case a default value is used.  The default
value for this field is 60s.  This default is subject to change.

| `subnets`
| `object`
| subnets specifies the subnets to which the load balancer will
attach. The subnets may be specified by either their
ID or name. The total number of subnets is limited to 10.

In order for the load balancer to be provisioned with subnets,
each subnet must exist, each subnet must be from a different
availability zone, and the load balancer service must be
recreated to pick up new values.

When omitted from the spec, the subnets will be auto-discovered
for each availability zone. Auto-discovered subnets are not reported
in the status of the IngressController object.

|===
=== .spec.endpointPublishingStrategy.loadBalancer.providerParameters.aws.classicLoadBalancer.subnets
Description::
+
--
subnets specifies the subnets to which the load balancer will
attach. The subnets may be specified by either their
ID or name. The total number of subnets is limited to 10.

In order for the load balancer to be provisioned with subnets,
each subnet must exist, each subnet must be from a different
availability zone, and the load balancer service must be
recreated to pick up new values.

When omitted from the spec, the subnets will be auto-discovered
for each availability zone. Auto-discovered subnets are not reported
in the status of the IngressController object.
--

Type::
  `object`




[cols="1,1,1",options="header"]
|===
| Property | Type | Description

| `ids`
| `array (string)`
| ids specifies a list of AWS subnets by subnet ID.
Subnet IDs must start with "subnet-", consist only
of alphanumeric characters, must be exactly 24
characters long, must be unique, and the total
number of subnets specified by ids and names
must not exceed 10.

| `names`
| `array (string)`
| names specifies a list of AWS subnets by subnet name.
Subnet names must not start with "subnet-", must not
include commas, must be under 256 characters in length,
must be unique, and the total number of subnets
specified by ids and names must not exceed 10.

|===
=== .spec.endpointPublishingStrategy.loadBalancer.providerParameters.aws.networkLoadBalancer
Description::
+
--
networkLoadBalancerParameters holds configuration parameters for an AWS
network load balancer. Present only if type is NLB.
--

Type::
  `object`




[cols="1,1,1",options="header"]
|===
| Property | Type | Description

| `eipAllocations`
| `array (string)`
| eipAllocations is a list of IDs for Elastic IP (EIP) addresses that
are assigned to the Network Load Balancer.
The following restrictions apply:

eipAllocations can only be used with external scope, not internal.
An EIP can be allocated to only a single IngressController.
The number of EIP allocations must match the number of subnets that are used for the load balancer.
Each EIP allocation must be unique.
A maximum of 10 EIP allocations are permitted.

See https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html for general
information about configuration, characteristics, and limitations of Elastic IP addresses.

| `subnets`
| `object`
| subnets specifies the subnets to which the load balancer will
attach. The subnets may be specified by either their
ID or name. The total number of subnets is limited to 10.

In order for the load balancer to be provisioned with subnets,
each subnet must exist, each subnet must be from a different
availability zone, and the load balancer service must be
recreated to pick up new values.

When omitted from the spec, the subnets will be auto-discovered
for each availability zone. Auto-discovered subnets are not reported
in the status of the IngressController object.

|===
=== .spec.endpointPublishingStrategy.loadBalancer.providerParameters.aws.networkLoadBalancer.subnets
Description::
+
--
subnets specifies the subnets to which the load balancer will
attach. The subnets may be specified by either their
ID or name. The total number of subnets is limited to 10.

In order for the load balancer to be provisioned with subnets,
each subnet must exist, each subnet must be from a different
availability zone, and the load balancer service must be
recreated to pick up new values.

When omitted from the spec, the subnets will be auto-discovered
for each availability zone. Auto-discovered subnets are not reported
in the status of the IngressController object.
--

Type::
  `object`




[cols="1,1,1",options="header"]
|===
| Property | Type | Description

| `ids`
| `array (string)`
| ids specifies a list of AWS subnets by subnet ID.
Subnet IDs must start with "subnet-", consist only
of alphanumeric characters, must be exactly 24
characters long, must be unique, and the total
number of subnets specified by ids and names
must not exceed 10.

| `names`
| `array (string)`
| names specifies a list of AWS subnets by subnet name.
Subnet names must not start with "subnet-", must not
include commas, must be under 256 characters in length,
must be unique, and the total number of subnets
specified by ids and names must not exceed 10.

|===
=== .spec.endpointPublishingStrategy.loadBalancer.providerParameters.gcp
Description::
+
--
gcp provides configuration settings that are specific to GCP
load balancers.

If empty, defaults will be applied. See specific gcp fields for
details about their defaults.
--

Type::
  `object`




[cols="1,1,1",options="header"]
|===
| Property | Type | Description

| `clientAccess`
| `string`
| clientAccess describes how client access is restricted for internal
load balancers.

Valid values are:
* "Global": Specifying an internal load balancer with Global client access
  allows clients from any region within the VPC to communicate with the load
  balancer.

    https://cloud.google.com/kubernetes-engine/docs/how-to/internal-load-balancing#global_access

* "Local": Specifying an internal load balancer with Local client access
  means only clients within the same region (and VPC) as the GCP load balancer
  can communicate with the load balancer. Note that this is the default behavior.

    https://cloud.google.com/load-balancing/docs/internal#client_access

|===
=== .spec.endpointPublishingStrategy.loadBalancer.providerParameters.ibm
Description::
+
--
ibm provides configuration settings that are specific to IBM Cloud
load balancers.

If empty, defaults will be applied. See specific ibm fields for
details about their defaults.
--

Type::
  `object`




[cols="1,1,1",options="header"]
|===
| Property | Type | Description

| `protocol`
| `string`
| protocol specifies whether the load balancer uses PROXY protocol to forward connections to
the IngressController. See "service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features:
"proxy-protocol"" at https://cloud.ibm.com/docs/containers?topic=containers-vpc-lbaas"

PROXY protocol can be used with load balancers that support it to
communicate the source addresses of client connections when
forwarding those connections to the IngressController.  Using PROXY
protocol enables the IngressController to report those source
addresses instead of reporting the load balancer's address in HTTP
headers and logs.  Note that enabling PROXY protocol on the
IngressController will cause connections to fail if you are not using
a load balancer that uses PROXY protocol to forward connections to
the IngressController.  See
http://www.haproxy.org/download/2.2/doc/proxy-protocol.txt for
information about PROXY protocol.

Valid values for protocol are TCP, PROXY and omitted.
When omitted, this means no opinion and the platform is left to choose a reasonable default, which is subject to change over time.
The current default is TCP, without the proxy protocol enabled.

|===
=== .spec.endpointPublishingStrategy.loadBalancer.providerParameters.openstack
Description::
+
--
openstack provides configuration settings that are specific to OpenStack
load balancers.

If empty, defaults will be applied. See specific openstack fields for
details about their defaults.
--

Type::
  `object`




[cols="1,1,1",options="header"]
|===
| Property | Type | Description

| `floatingIP`
| `string`
| floatingIP specifies the IP address that the load balancer will use.
When not specified, an IP address will be assigned randomly by the OpenStack cloud provider.
When specified, the floating IP has to be pre-created.  If the
specified value is not a floating IP or is already claimed, the
OpenStack cloud provider won't be able to provision the load
balancer.
This field may only be used if the IngressController has External scope.
This value must be a valid IPv4 or IPv6 address.

|===
=== .spec.endpointPublishingStrategy.nodePort
Description::
+
--
nodePort holds parameters for the NodePortService endpoint publishing strategy.
Present only if type is NodePortService.
--

Type::
  `object`




[cols="1,1,1",options="header"]
|===
| Property | Type | Description

| `protocol`
| `string`
| protocol specifies whether the IngressController expects incoming
connections to use plain TCP or whether the IngressController expects
PROXY protocol.

PROXY protocol can be used with load balancers that support it to
communicate the source addresses of client connections when
forwarding those connections to the IngressController.  Using PROXY
protocol enables the IngressController to report those source
addresses instead of reporting the load balancer's address in HTTP
headers and logs.  Note that enabling PROXY protocol on the
IngressController will cause connections to fail if you are not using
a load balancer that uses PROXY protocol to forward connections to
the IngressController.  See
http://www.haproxy.org/download/2.2/doc/proxy-protocol.txt for
information about PROXY protocol.

The following values are valid for this field:

* The empty string.
* "TCP".
* "PROXY".

The empty string specifies the default, which is TCP without PROXY
protocol.  Note that the default is subject to change.

|===
=== .spec.endpointPublishingStrategy.private
Description::
+
--
private holds parameters for the Private endpoint publishing
strategy. Present only if type is Private.
--

Type::
  `object`




[cols="1,1,1",options="header"]
|===
| Property | Type | Description

| `protocol`
| `string`
| protocol specifies whether the IngressController expects incoming
connections to use plain TCP or whether the IngressController expects
PROXY protocol.

PROXY protocol can be used with load balancers that support it to
communicate the source addresses of client connections when
forwarding those connections to the IngressController.  Using PROXY
protocol enables the IngressController to report those source
addresses instead of reporting the load balancer's address in HTTP
headers and logs.  Note that enabling PROXY protocol on the
IngressController will cause connections to fail if you are not using
a load balancer that uses PROXY protocol to forward connections to
the IngressController.  See
http://www.haproxy.org/download/2.2/doc/proxy-protocol.txt for
information about PROXY protocol.

The following values are valid for this field:

* The empty string.
* "TCP".
* "PROXY".

The empty string specifies the default, which is TCP without PROXY
protocol.  Note that the default is subject to change.

|===
=== .spec.httpCompression
Description::
+
--
httpCompression defines a policy for HTTP traffic compression.
By default, there is no HTTP compression.
--

Type::
  `object`




[cols="1,1,1",options="header"]
|===
| Property | Type | Description

| `mimeTypes`
| `array (string)`
| mimeTypes is a list of MIME types that should have compression applied.
This list can be empty, in which case the ingress controller does not apply compression.

Note: Not all MIME types benefit from compression, but HAProxy will still use resources
to try to compress if instructed to.  Generally speaking, text (html, css, js, etc.)
formats benefit from compression, but formats that are already compressed (image,
audio, video, etc.) benefit little in exchange for the time and cpu spent on compressing
again. See https://joehonton.medium.com/the-gzip-penalty-d31bd697f1a2

|===
=== .spec.httpErrorCodePages
Description::
+
--
httpErrorCodePages specifies a configmap with custom error pages.
The administrator must create this configmap in the openshift-config namespace.
This configmap should have keys in the format "error-page-<error code>.http",
where <error code> is an HTTP error code.
For example, "error-page-503.http" defines an error page for HTTP 503 responses.
Currently only error pages for 503 and 404 responses can be customized.
Each value in the configmap should be the full response, including HTTP headers.
Eg- https://raw.githubusercontent.com/openshift/router/fadab45747a9b30cc3f0a4b41ad2871f95827a93/images/router/haproxy/conf/error-page-503.http
If this field is empty, the ingress controller uses the default error pages.
--

Type::
  `object`

Required::
  - `name`



[cols="1,1,1",options="header"]
|===
| Property | Type | Description

| `name`
| `string`
| name is the metadata.name of the referenced config map

|===
=== .spec.httpHeaders
Description::
+
--
httpHeaders defines policy for HTTP headers.

If this field is empty, the default values are used.
--

Type::
  `object`




[cols="1,1,1",options="header"]
|===
| Property | Type | Description

| `actions`
| `object`
| actions specifies options for modifying headers and their values.
Note that this option only applies to cleartext HTTP connections
and to secure HTTP connections for which the ingress controller
terminates encryption (that is, edge-terminated or reencrypt
connections).  Headers cannot be modified for TLS passthrough
connections.
Setting the HSTS (`Strict-Transport-Security`) header is not supported via actions. `Strict-Transport-Security`
may only be configured using the "haproxy.router.openshift.io/hsts_header" route annotation, and only in
accordance with the policy specified in Ingress.Spec.RequiredHSTSPolicies.
Any actions defined here are applied after any actions related to the following other fields:
cache-control, spec.clientTLS,
spec.httpHeaders.forwardedHeaderPolicy, spec.httpHeaders.uniqueId,
and spec.httpHeaders.headerNameCaseAdjustments.
In case of HTTP request headers, the actions specified in spec.httpHeaders.actions on the Route will be executed after
the actions specified in the IngressController's spec.httpHeaders.actions field.
In case of HTTP response headers, the actions specified in spec.httpHeaders.actions on the IngressController will be
executed after the actions specified in the Route's spec.httpHeaders.actions field.
Headers set using this API cannot be captured for use in access logs.
The following header names are reserved and may not be modified via this API:
Strict-Transport-Security, Proxy, Host, Cookie, Set-Cookie.
Note that the total size of all net added headers *after* interpolating dynamic values
must not exceed the value of spec.tuningOptions.headerBufferMaxRewriteBytes on the
IngressController. Please refer to the documentation
for that API field for more details.

| `forwardedHeaderPolicy`
| `string`
| forwardedHeaderPolicy specifies when and how the IngressController
sets the Forwarded, X-Forwarded-For, X-Forwarded-Host,
X-Forwarded-Port, X-Forwarded-Proto, and X-Forwarded-Proto-Version
HTTP headers.  The value may be one of the following:

* "Append", which specifies that the IngressController appends the
  headers, preserving existing headers.

* "Replace", which specifies that the IngressController sets the
  headers, replacing any existing Forwarded or X-Forwarded-* headers.

* "IfNone", which specifies that the IngressController sets the
  headers if they are not already set.

* "Never", which specifies that the IngressController never sets the
  headers, preserving any existing headers.

By default, the policy is "Append".

| `headerNameCaseAdjustments`
| ``
| headerNameCaseAdjustments specifies case adjustments that can be
applied to HTTP header names.  Each adjustment is specified as an
HTTP header name with the desired capitalization.  For example,
specifying "X-Forwarded-For" indicates that the "x-forwarded-for"
HTTP header should be adjusted to have the specified capitalization.

These adjustments are only applied to cleartext, edge-terminated, and
re-encrypt routes, and only when using HTTP/1.

For request headers, these adjustments are applied only for routes
that have the haproxy.router.openshift.io/h1-adjust-case=true
annotation.  For response headers, these adjustments are applied to
all HTTP responses.

If this field is empty, no request headers are adjusted.

| `uniqueId`
| `object`
| uniqueId describes configuration for a custom HTTP header that the
ingress controller should inject into incoming HTTP requests.
Typically, this header is configured to have a value that is unique
to the HTTP request.  The header can be used by applications or
included in access logs to facilitate tracing individual HTTP
requests.

If this field is empty, no such header is injected into requests.

|===
=== .spec.httpHeaders.actions
Description::
+
--
actions specifies options for modifying headers and their values.
Note that this option only applies to cleartext HTTP connections
and to secure HTTP connections for which the ingress controller
terminates encryption (that is, edge-terminated or reencrypt
connections).  Headers cannot be modified for TLS passthrough
connections.
Setting the HSTS (`Strict-Transport-Security`) header is not supported via actions. `Strict-Transport-Security`
may only be configured using the "haproxy.router.openshift.io/hsts_header" route annotation, and only in
accordance with the policy specified in Ingress.Spec.RequiredHSTSPolicies.
Any actions defined here are applied after any actions related to the following other fields:
cache-control, spec.clientTLS,
spec.httpHeaders.forwardedHeaderPolicy, spec.httpHeaders.uniqueId,
and spec.httpHeaders.headerNameCaseAdjustments.
In case of HTTP request headers, the actions specified in spec.httpHeaders.actions on the Route will be executed after
the actions specified in the IngressController's spec.httpHeaders.actions field.
In case of HTTP response headers, the actions specified in spec.httpHeaders.actions on the IngressController will be
executed after the actions specified in the Route's spec.httpHeaders.actions field.
Headers set using this API cannot be captured for use in access logs.
The following header names are reserved and may not be modified via this API:
Strict-Transport-Security, Proxy, Host, Cookie, Set-Cookie.
Note that the total size of all net added headers *after* interpolating dynamic values
must not exceed the value of spec.tuningOptions.headerBufferMaxRewriteBytes on the
IngressController. Please refer to the documentation
for that API field for more details.
--

Type::
  `object`




[cols="1,1,1",options="header"]
|===
| Property | Type | Description

| `request`
| `array`
| request is a list of HTTP request headers to modify.
Actions defined here will modify the request headers of all requests passing through an ingress controller.
These actions are applied to all Routes i.e. for all connections handled by the ingress controller defined within a cluster.
IngressController actions for request headers will be executed before Route actions.
Currently, actions may define to either `Set` or `Delete` headers values.
Actions are applied in sequence as defined in this list.
A maximum of 20 request header actions may be configured.
Sample fetchers allowed are "req.hdr" and "ssl_c_der".
Converters allowed are "lower" and "base64".
Example header values: "%[req.hdr(X-target),lower]", "%{+Q}[ssl_c_der,base64]".

| `request[]`
| `object`
| IngressControllerHTTPHeader specifies configuration for setting or deleting an HTTP header.

| `response`
| `array`
| response is a list of HTTP response headers to modify.
Actions defined here will modify the response headers of all requests passing through an ingress controller.
These actions are applied to all Routes i.e. for all connections handled by the ingress controller defined within a cluster.
IngressController actions for response headers will be executed after Route actions.
Currently, actions may define to either `Set` or `Delete` headers values.
Actions are applied in sequence as defined in this list.
A maximum of 20 response header actions may be configured.
Sample fetchers allowed are "res.hdr" and "ssl_c_der".
Converters allowed are "lower" and "base64".
Example header values: "%[res.hdr(X-target),lower]", "%{+Q}[ssl_c_der,base64]".

| `response[]`
| `object`
| IngressControllerHTTPHeader specifies configuration for setting or deleting an HTTP header.

|===
=== .spec.httpHeaders.actions.request
Description::
+
--
request is a list of HTTP request headers to modify.
Actions defined here will modify the request headers of all requests passing through an ingress controller.
These actions are applied to all Routes i.e. for all connections handled by the ingress controller defined within a cluster.
IngressController actions for request headers will be executed before Route actions.
Currently, actions may define to either `Set` or `Delete` headers values.
Actions are applied in sequence as defined in this list.
A maximum of 20 request header actions may be configured.
Sample fetchers allowed are "req.hdr" and "ssl_c_der".
Converters allowed are "lower" and "base64".
Example header values: "%[req.hdr(X-target),lower]", "%{+Q}[ssl_c_der,base64]".
--

Type::
  `array`




=== .spec.httpHeaders.actions.request[]
Description::
+
--
IngressControllerHTTPHeader specifies configuration for setting or deleting an HTTP header.
--

Type::
  `object`

Required::
  - `action`
  - `name`



[cols="1,1,1",options="header"]
|===
| Property | Type | Description

| `action`
| `object`
| action specifies actions to perform on headers, such as setting or deleting headers.

| `name`
| `string`
| name specifies the name of a header on which to perform an action. Its value must be a valid HTTP header
name as defined in RFC 2616 section 4.2.
The name must consist only of alphanumeric and the following special characters, "-!#$%&'*+.^_`".
The following header names are reserved and may not be modified via this API:
Strict-Transport-Security, Proxy, Host, Cookie, Set-Cookie.
It must be no more than 255 characters in length.
Header name must be unique.

|===
=== .spec.httpHeaders.actions.request[].action
Description::
+
--
action specifies actions to perform on headers, such as setting or deleting headers.
--

Type::
  `object`

Required::
  - `type`



[cols="1,1,1",options="header"]
|===
| Property | Type | Description

| `set`
| `object`
| set specifies how the HTTP header should be set.
This field is required when type is Set and forbidden otherwise.

| `type`
| `string`
| type defines the type of the action to be applied on the header.
Possible values are Set or Delete.
Set allows you to set HTTP request and response headers.
Delete allows you to delete HTTP request and response headers.

|===
=== .spec.httpHeaders.actions.request[].action.set
Description::
+
--
set specifies how the HTTP header should be set.
This field is required when type is Set and forbidden otherwise.
--

Type::
  `object`

Required::
  - `value`



[cols="1,1,1",options="header"]
|===
| Property | Type | Description

| `value`
| `string`
| value specifies a header value.
Dynamic values can be added. The value will be interpreted as an HAProxy format string as defined in
http://cbonte.github.io/haproxy-dconv/2.6/configuration.html#8.2.6  and may use HAProxy's %[] syntax and
otherwise must be a valid HTTP header value as defined in https://datatracker.ietf.org/doc/html/rfc7230#section-3.2.
The value of this field must be no more than 16384 characters in length.
Note that the total size of all net added headers *after* interpolating dynamic values
must not exceed the value of spec.tuningOptions.headerBufferMaxRewriteBytes on the
IngressController.

|===
=== .spec.httpHeaders.actions.response
Description::
+
--
response is a list of HTTP response headers to modify.
Actions defined here will modify the response headers of all requests passing through an ingress controller.
These actions are applied to all Routes i.e. for all connections handled by the ingress controller defined within a cluster.
IngressController actions for response headers will be executed after Route actions.
Currently, actions may define to either `Set` or `Delete` headers values.
Actions are applied in sequence as defined in this list.
A maximum of 20 response header actions may be configured.
Sample fetchers allowed are "res.hdr" and "ssl_c_der".
Converters allowed are "lower" and "base64".
Example header values: "%[res.hdr(X-target),lower]", "%{+Q}[ssl_c_der,base64]".
--

Type::
  `array`




=== .spec.httpHeaders.actions.response[]
Description::
+
--
IngressControllerHTTPHeader specifies configuration for setting or deleting an HTTP header.
--

Type::
  `object`

Required::
  - `action`
  - `name`



[cols="1,1,1",options="header"]
|===
| Property | Type | Description

| `action`
| `object`
| action specifies actions to perform on headers, such as setting or deleting headers.

| `name`
| `string`
| name specifies the name of a header on which to perform an action. Its value must be a valid HTTP header
name as defined in RFC 2616 section 4.2.
The name must consist only of alphanumeric and the following special characters, "-!#$%&'*+.^_`".
The following header names are reserved and may not be modified via this API:
Strict-Transport-Security, Proxy, Host, Cookie, Set-Cookie.
It must be no more than 255 characters in length.
Header name must be unique.

|===
=== .spec.httpHeaders.actions.response[].action
Description::
+
--
action specifies actions to perform on headers, such as setting or deleting headers.
--

Type::
  `object`

Required::
  - `type`



[cols="1,1,1",options="header"]
|===
| Property | Type | Description

| `set`
| `object`
| set specifies how the HTTP header should be set.
This field is required when type is Set and forbidden otherwise.

| `type`
| `string`
| type defines the type of the action to be applied on the header.
Possible values are Set or Delete.
Set allows you to set HTTP request and response headers.
Delete allows you to delete HTTP request and response headers.

|===
=== .spec.httpHeaders.actions.response[].action.set
Description::
+
--
set specifies how the HTTP header should be set.
This field is required when type is Set and forbidden otherwise.
--

Type::
  `object`

Required::
  - `value`



[cols="1,1,1",options="header"]
|===
| Property | Type | Description

| `value`
| `string`
| value specifies a header value.
Dynamic values can be added. The value will be interpreted as an HAProxy format string as defined in
http://cbonte.github.io/haproxy-dconv/2.6/configuration.html#8.2.6  and may use HAProxy's %[] syntax and
otherwise must be a valid HTTP header value as defined in https://datatracker.ietf.org/doc/html/rfc7230#section-3.2.
The value of this field must be no more than 16384 characters in length.
Note that the total size of all net added headers *after* interpolating dynamic values
must not exceed the value of spec.tuningOptions.headerBufferMaxRewriteBytes on the
IngressController.

|===
=== .spec.httpHeaders.uniqueId
Description::
+
--
uniqueId describes configuration for a custom HTTP header that the
ingress controller should inject into incoming HTTP requests.
Typically, this header is configured to have a value that is unique
to the HTTP request.  The header can be used by applications or
included in access logs to facilitate tracing individual HTTP
requests.

If this field is empty, no such header is injected into requests.
--

Type::
  `object`




[cols="1,1,1",options="header"]
|===
| Property | Type | Description

| `format`
| `string`
| format specifies the format for the injected HTTP header's value.
This field has no effect unless name is specified.  For the
HAProxy-based ingress controller implementation, this format uses the
same syntax as the HTTP log format.  If the field is empty, the
default value is "%{+X}o\\ %ci:%cp_%fi:%fp_%Ts_%rt:%pid"; see the
corresponding HAProxy documentation:
http://cbonte.github.io/haproxy-dconv/2.0/configuration.html#8.2.3

| `name`
| `string`
| name specifies the name of the HTTP header (for example, "unique-id")
that the ingress controller should inject into HTTP requests.  The
field's value must be a valid HTTP header name as defined in RFC 2616
section 4.2.  If the field is empty, no header is injected.

|===
=== .spec.logging
Description::
+
--
logging defines parameters for what should be logged where.  If this
field is empty, operational logs are enabled but access logs are
disabled.
--

Type::
  `object`




[cols="1,1,1",options="header"]
|===
| Property | Type | Description

| `access`
| `object`
| access describes how the client requests should be logged.

If this field is empty, access logging is disabled.

|===
=== .spec.logging.access
Description::
+
--
access describes how the client requests should be logged.

If this field is empty, access logging is disabled.
--

Type::
  `object`

Required::
  - `destination`



[cols="1,1,1",options="header"]
|===
| Property | Type | Description

| `destination`
| `object`
| destination is where access logs go.

| `httpCaptureCookies`
| ``
| httpCaptureCookies specifies HTTP cookies that should be captured in
access logs.  If this field is empty, no cookies are captured.

| `httpCaptureHeaders`
| `object`
| httpCaptureHeaders defines HTTP headers that should be captured in
access logs.  If this field is empty, no headers are captured.

Note that this option only applies to cleartext HTTP connections
and to secure HTTP connections for which the ingress controller
terminates encryption (that is, edge-terminated or reencrypt
connections).  Headers cannot be captured for TLS passthrough
connections.

| `httpLogFormat`
| `string`
| httpLogFormat specifies the format of the log message for an HTTP
request.

If this field is empty, log messages use the implementation's default
HTTP log format.  For HAProxy's default HTTP log format, see the
HAProxy documentation:
http://cbonte.github.io/haproxy-dconv/2.0/configuration.html#8.2.3

Note that this format only applies to cleartext HTTP connections
and to secure HTTP connections for which the ingress controller
terminates encryption (that is, edge-terminated or reencrypt
connections).  It does not affect the log format for TLS passthrough
connections.

| `logEmptyRequests`
| `string`
| logEmptyRequests specifies how connections on which no request is
received should be logged.  Typically, these empty requests come from
load balancers' health probes or Web browsers' speculative
connections ("preconnect"), in which case logging these requests may
be undesirable.  However, these requests may also be caused by
network errors, in which case logging empty requests may be useful
for diagnosing the errors.  In addition, these requests may be caused
by port scans, in which case logging empty requests may aid in
detecting intrusion attempts.  Allowed values for this field are
"Log" and "Ignore".  The default value is "Log".

|===
=== .spec.logging.access.destination
Description::
+
--
destination is where access logs go.
--

Type::
  `object`

Required::
  - `type`



[cols="1,1,1",options="header"]
|===
| Property | Type | Description

| `container`
| `object`
| container holds parameters for the Container logging destination.
Present only if type is Container.

| `syslog`
| `object`
| syslog holds parameters for a syslog endpoint.  Present only if
type is Syslog.

| `type`
| `string`
| type is the type of destination for logs.  It must be one of the
following:

* Container

The ingress operator configures the sidecar container named "logs" on
the ingress controller pod and configures the ingress controller to
write logs to the sidecar.  The logs are then available as container
logs.  The expectation is that the administrator configures a custom
logging solution that reads logs from this sidecar.  Note that using
container logs means that logs may be dropped if the rate of logs
exceeds the container runtime's or the custom logging solution's
capacity.

* Syslog

Logs are sent to a syslog endpoint.  The administrator must specify
an endpoint that can receive syslog messages.  The expectation is
that the administrator has configured a custom syslog instance.

|===
=== .spec.logging.access.destination.container
Description::
+
--
container holds parameters for the Container logging destination.
Present only if type is Container.
--

Type::
  `object`




[cols="1,1,1",options="header"]
|===
| Property | Type | Description

| `maxLength`
| `integer`
| maxLength is the maximum length of the log message.

Valid values are integers in the range 480 to 8192, inclusive.

When omitted, the default value is 1024.

|===
=== .spec.logging.access.destination.syslog
Description::
+
--
syslog holds parameters for a syslog endpoint.  Present only if
type is Syslog.
--

Type::
  `object`

Required::
  - `address`
  - `port`



[cols="1,1,1",options="header"]
|===
| Property | Type | Description

| `address`
| `string`
| address is the IP address of the syslog endpoint that receives log
messages.

| `facility`
| `string`
| facility specifies the syslog facility of log messages.

If this field is empty, the facility is "local1".

| `maxLength`
| `integer`
| maxLength is the maximum length of the log message.

Valid values are integers in the range 480 to 4096, inclusive.

When omitted, the default value is 1024.

| `port`
| `integer`
| port is the UDP port number of the syslog endpoint that receives log
messages.

|===
=== .spec.logging.access.httpCaptureHeaders
Description::
+
--
httpCaptureHeaders defines HTTP headers that should be captured in
access logs.  If this field is empty, no headers are captured.

Note that this option only applies to cleartext HTTP connections
and to secure HTTP connections for which the ingress controller
terminates encryption (that is, edge-terminated or reencrypt
connections).  Headers cannot be captured for TLS passthrough
connections.
--

Type::
  `object`




[cols="1,1,1",options="header"]
|===
| Property | Type | Description

| `request`
| ``
| request specifies which HTTP request headers to capture.

If this field is empty, no request headers are captured.

| `response`
| ``
| response specifies which HTTP response headers to capture.

If this field is empty, no response headers are captured.

|===
=== .spec.namespaceSelector
Description::
+
--
namespaceSelector is used to filter the set of namespaces serviced by the
ingress controller. This is useful for implementing shards.

If unset, the default is no filtering.
--

Type::
  `object`




[cols="1,1,1",options="header"]
|===
| Property | Type | Description

| `matchExpressions`
| `array`
| matchExpressions is a list of label selector requirements. The requirements are ANDed.

| `matchExpressions[]`
| `object`
| A label selector requirement is a selector that contains values, a key, and an operator that
relates the key and values.

| `matchLabels`
| `object (string)`
| matchLabels is a map of {key,value} pairs. A single {key,value} in the matchLabels
map is equivalent to an element of matchExpressions, whose key field is "key", the
operator is "In", and the values array contains only "value". The requirements are ANDed.

|===
=== .spec.namespaceSelector.matchExpressions
Description::
+
--
matchExpressions is a list of label selector requirements. The requirements are ANDed.
--

Type::
  `array`




=== .spec.namespaceSelector.matchExpressions[]
Description::
+
--
A label selector requirement is a selector that contains values, a key, and an operator that
relates the key and values.
--

Type::
  `object`

Required::
  - `key`
  - `operator`



[cols="1,1,1",options="header"]
|===
| Property | Type | Description

| `key`
| `string`
| key is the label key that the selector applies to.

| `operator`
| `string`
| operator represents a key's relationship to a set of values.
Valid operators are In, NotIn, Exists and DoesNotExist.

| `values`
| `array (string)`
| values is an array of string values. If the operator is In or NotIn,
the values array must be non-empty. If the operator is Exists or DoesNotExist,
the values array must be empty. This array is replaced during a strategic
merge patch.

|===
=== .spec.nodePlacement
Description::
+
--
nodePlacement enables explicit control over the scheduling of the ingress
controller.

If unset, defaults are used. See NodePlacement for more details.
--

Type::
  `object`




[cols="1,1,1",options="header"]
|===
| Property | Type | Description

| `nodeSelector`
| `object`
| nodeSelector is the node selector applied to ingress controller
deployments.

If set, the specified selector is used and replaces the default.

If unset, the default depends on the value of the defaultPlacement
field in the cluster config.openshift.io/v1/ingresses status.

When defaultPlacement is Workers, the default is:

  kubernetes.io/os: linux
  node-role.kubernetes.io/worker: ''

When defaultPlacement is ControlPlane, the default is:

  kubernetes.io/os: linux
  node-role.kubernetes.io/master: ''

These defaults are subject to change.

Note that using nodeSelector.matchExpressions is not supported.  Only
nodeSelector.matchLabels may be used.  This is a limitation of the
Kubernetes API: the pod spec does not allow complex expressions for
node selectors.

| `tolerations`
| `array`
| tolerations is a list of tolerations applied to ingress controller
deployments.

The default is an empty list.

See https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/

| `tolerations[]`
| `object`
| The pod this Toleration is attached to tolerates any taint that matches
the triple <key,value,effect> using the matching operator <operator>.

|===
=== .spec.nodePlacement.nodeSelector
Description::
+
--
nodeSelector is the node selector applied to ingress controller
deployments.

If set, the specified selector is used and replaces the default.

If unset, the default depends on the value of the defaultPlacement
field in the cluster config.openshift.io/v1/ingresses status.

When defaultPlacement is Workers, the default is:

  kubernetes.io/os: linux
  node-role.kubernetes.io/worker: ''

When defaultPlacement is ControlPlane, the default is:

  kubernetes.io/os: linux
  node-role.kubernetes.io/master: ''

These defaults are subject to change.

Note that using nodeSelector.matchExpressions is not supported.  Only
nodeSelector.matchLabels may be used.  This is a limitation of the
Kubernetes API: the pod spec does not allow complex expressions for
node selectors.
--

Type::
  `object`




[cols="1,1,1",options="header"]
|===
| Property | Type | Description

| `matchExpressions`
| `array`
| matchExpressions is a list of label selector requirements. The requirements are ANDed.

| `matchExpressions[]`
| `object`
| A label selector requirement is a selector that contains values, a key, and an operator that
relates the key and values.

| `matchLabels`
| `object (string)`
| matchLabels is a map of {key,value} pairs. A single {key,value} in the matchLabels
map is equivalent to an element of matchExpressions, whose key field is "key", the
operator is "In", and the values array contains only "value". The requirements are ANDed.

|===
=== .spec.nodePlacement.nodeSelector.matchExpressions
Description::
+
--
matchExpressions is a list of label selector requirements. The requirements are ANDed.
--

Type::
  `array`




=== .spec.nodePlacement.nodeSelector.matchExpressions[]
Description::
+
--
A label selector requirement is a selector that contains values, a key, and an operator that
relates the key and values.
--

Type::
  `object`

Required::
  - `key`
  - `operator`



[cols="1,1,1",options="header"]
|===
| Property | Type | Description

| `key`
| `string`
| key is the label key that the selector applies to.

| `operator`
| `string`
| operator represents a key's relationship to a set of values.
Valid operators are In, NotIn, Exists and DoesNotExist.

| `values`
| `array (string)`
| values is an array of string values. If the operator is In or NotIn,
the values array must be non-empty. If the operator is Exists or DoesNotExist,
the values array must be empty. This array is replaced during a strategic
merge patch.

|===
=== .spec.nodePlacement.tolerations
Description::
+
--
tolerations is a list of tolerations applied to ingress controller
deployments.

The default is an empty list.

See https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/
--

Type::
  `array`




=== .spec.nodePlacement.tolerations[]
Description::
+
--
The pod this Toleration is attached to tolerates any taint that matches
the triple <key,value,effect> using the matching operator <operator>.
--

Type::
  `object`




[cols="1,1,1",options="header"]
|===
| Property | Type | Description

| `effect`
| `string`
| Effect indicates the taint effect to match. Empty means match all taint effects.
When specified, allowed values are NoSchedule, PreferNoSchedule and NoExecute.

| `key`
| `string`
| Key is the taint key that the toleration applies to. Empty means match all taint keys.
If the key is empty, operator must be Exists; this combination means to match all values and all keys.

| `operator`
| `string`
| Operator represents a key's relationship to the value.
Valid operators are Exists and Equal. Defaults to Equal.
Exists is equivalent to wildcard for value, so that a pod can
tolerate all taints of a particular category.

| `tolerationSeconds`
| `integer`
| TolerationSeconds represents the period of time the toleration (which must be
of effect NoExecute, otherwise this field is ignored) tolerates the taint. By default,
it is not set, which means tolerate the taint forever (do not evict). Zero and
negative values will be treated as 0 (evict immediately) by the system.

| `value`
| `string`
| Value is the taint value the toleration matches to.
If the operator is Exists, the value should be empty, otherwise just a regular string.

|===
=== .spec.routeAdmission
Description::
+
--
routeAdmission defines a policy for handling new route claims (for example,
to allow or deny claims across namespaces).

If empty, defaults will be applied. See specific routeAdmission fields
for details about their defaults.
--

Type::
  `object`




[cols="1,1,1",options="header"]
|===
| Property | Type | Description

| `namespaceOwnership`
| `string`
| namespaceOwnership describes how host name claims across namespaces should
be handled.

Value must be one of:

- Strict: Do not allow routes in different namespaces to claim the same host.

- InterNamespaceAllowed: Allow routes to claim different paths of the same
  host name across namespaces.

If empty, the default is Strict.

| `wildcardPolicy`
| `string`
| wildcardPolicy describes how routes with wildcard policies should
be handled for the ingress controller. WildcardPolicy controls use
of routes [1] exposed by the ingress controller based on the route's
wildcard policy.

[1] https://github.com/openshift/api/blob/master/route/v1/types.go

Note: Updating WildcardPolicy from WildcardsAllowed to WildcardsDisallowed
will cause admitted routes with a wildcard policy of Subdomain to stop
working. These routes must be updated to a wildcard policy of None to be
readmitted by the ingress controller.

WildcardPolicy supports WildcardsAllowed and WildcardsDisallowed values.

If empty, defaults to "WildcardsDisallowed".

|===
=== .spec.routeSelector
Description::
+
--
routeSelector is used to filter the set of Routes serviced by the ingress
controller. This is useful for implementing shards.

If unset, the default is no filtering.
--

Type::
  `object`




[cols="1,1,1",options="header"]
|===
| Property | Type | Description

| `matchExpressions`
| `array`
| matchExpressions is a list of label selector requirements. The requirements are ANDed.

| `matchExpressions[]`
| `object`
| A label selector requirement is a selector that contains values, a key, and an operator that
relates the key and values.

| `matchLabels`
| `object (string)`
| matchLabels is a map of {key,value} pairs. A single {key,value} in the matchLabels
map is equivalent to an element of matchExpressions, whose key field is "key", the
operator is "In", and the values array contains only "value". The requirements are ANDed.

|===
=== .spec.routeSelector.matchExpressions
Description::
+
--
matchExpressions is a list of label selector requirements. The requirements are ANDed.
--

Type::
  `array`




=== .spec.routeSelector.matchExpressions[]
Description::
+
--
A label selector requirement is a selector that contains values, a key, and an operator that
relates the key and values.
--

Type::
  `object`

Required::
  - `key`
  - `operator`



[cols="1,1,1",options="header"]
|===
| Property | Type | Description

| `key`
| `string`
| key is the label key that the selector applies to.

| `operator`
| `string`
| operator represents a key's relationship to a set of values.
Valid operators are In, NotIn, Exists and DoesNotExist.

| `values`
| `array (string)`
| values is an array of string values. If the operator is In or NotIn,
the values array must be non-empty. If the operator is Exists or DoesNotExist,
the values array must be empty. This array is replaced during a strategic
merge patch.

|===
=== .spec.tlsSecurityProfile
Description::
+
--
tlsSecurityProfile specifies settings for TLS connections for ingresscontrollers.

If unset, the default is based on the apiservers.config.openshift.io/cluster resource.

Note that when using the Old, Intermediate, and Modern profile types, the effective
profile configuration is subject to change between releases. For example, given
a specification to use the Intermediate profile deployed on release X.Y.Z, an upgrade
to release X.Y.Z+1 may cause a new profile configuration to be applied to the ingress
controller, resulting in a rollout.
--

Type::
  `object`




[cols="1,1,1",options="header"]
|===
| Property | Type | Description

| `custom`
| ``
| custom is a user-defined TLS security profile. Be extremely careful using a custom
profile as invalid configurations can be catastrophic. An example custom profile
looks like this:

  ciphers:

    - ECDHE-ECDSA-CHACHA20-POLY1305

    - ECDHE-RSA-CHACHA20-POLY1305

    - ECDHE-RSA-AES128-GCM-SHA256

    - ECDHE-ECDSA-AES128-GCM-SHA256

  minTLSVersion: VersionTLS11

| `intermediate`
| ``
| intermediate is a TLS security profile based on:

https://wiki.mozilla.org/Security/Server_Side_TLS#Intermediate_compatibility_.28recommended.29

and looks like this (yaml):

  ciphers:

    - TLS_AES_128_GCM_SHA256

    - TLS_AES_256_GCM_SHA384

    - TLS_CHACHA20_POLY1305_SHA256

    - ECDHE-ECDSA-AES128-GCM-SHA256

    - ECDHE-RSA-AES128-GCM-SHA256

    - ECDHE-ECDSA-AES256-GCM-SHA384

    - ECDHE-RSA-AES256-GCM-SHA384

    - ECDHE-ECDSA-CHACHA20-POLY1305

    - ECDHE-RSA-CHACHA20-POLY1305

    - DHE-RSA-AES128-GCM-SHA256

    - DHE-RSA-AES256-GCM-SHA384

  minTLSVersion: VersionTLS12

| `modern`
| ``
| modern is a TLS security profile based on:

https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility

and looks like this (yaml):

  ciphers:

    - TLS_AES_128_GCM_SHA256

    - TLS_AES_256_GCM_SHA384

    - TLS_CHACHA20_POLY1305_SHA256

  minTLSVersion: VersionTLS13

| `old`
| ``
| old is a TLS security profile based on:

https://wiki.mozilla.org/Security/Server_Side_TLS#Old_backward_compatibility

and looks like this (yaml):

  ciphers:

    - TLS_AES_128_GCM_SHA256

    - TLS_AES_256_GCM_SHA384

    - TLS_CHACHA20_POLY1305_SHA256

    - ECDHE-ECDSA-AES128-GCM-SHA256

    - ECDHE-RSA-AES128-GCM-SHA256

    - ECDHE-ECDSA-AES256-GCM-SHA384

    - ECDHE-RSA-AES256-GCM-SHA384

    - ECDHE-ECDSA-CHACHA20-POLY1305

    - ECDHE-RSA-CHACHA20-POLY1305

    - DHE-RSA-AES128-GCM-SHA256

    - DHE-RSA-AES256-GCM-SHA384

    - DHE-RSA-CHACHA20-POLY1305

    - ECDHE-ECDSA-AES128-SHA256

    - ECDHE-RSA-AES128-SHA256

    - ECDHE-ECDSA-AES128-SHA

    - ECDHE-RSA-AES128-SHA

    - ECDHE-ECDSA-AES256-SHA384

    - ECDHE-RSA-AES256-SHA384

    - ECDHE-ECDSA-AES256-SHA

    - ECDHE-RSA-AES256-SHA

    - DHE-RSA-AES128-SHA256

    - DHE-RSA-AES256-SHA256

    - AES128-GCM-SHA256

    - AES256-GCM-SHA384

    - AES128-SHA256

    - AES256-SHA256

    - AES128-SHA

    - AES256-SHA

    - DES-CBC3-SHA

  minTLSVersion: VersionTLS10

| `type`
| `string`
| type is one of Old, Intermediate, Modern or Custom. Custom provides
the ability to specify individual TLS security profile parameters.
Old, Intermediate and Modern are TLS security profiles based on:

https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_configurations

The profiles are intent based, so they may change over time as new ciphers are developed and existing ciphers
are found to be insecure.  Depending on precisely which ciphers are available to a process, the list may be
reduced.

Note that the Modern profile is currently not supported because it is not
yet well adopted by common software libraries.

|===
=== .spec.tuningOptions
Description::
+
--
tuningOptions defines parameters for adjusting the performance of
ingress controller pods. All fields are optional and will use their
respective defaults if not set. See specific tuningOptions fields for
more details.

Setting fields within tuningOptions is generally not recommended. The
default values are suitable for most configurations.
--

Type::
  `object`




[cols="1,1,1",options="header"]
|===
| Property | Type | Description

| `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.

| `httpKeepAliveTimeout`
| `string`
| httpKeepAliveTimeout defines the maximum allowed time to wait for
a new HTTP request to appear on a connection from the client to the router.

This field expects an unsigned duration string of a decimal number, with optional
fraction and a unit suffix, e.g. "300ms", "1.5s" or "2m45s".
Valid time units are "ms", "s", "m".
The allowed range is from 1 millisecond to 15 minutes.

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 300s.

Low values (tens of milliseconds or less) can cause clients to close and reopen connections
for each request, leading to reduced connection sharing.
For HTTP/2, special care should be taken with low values.
A few seconds is a reasonable starting point to avoid holding idle connections open
while still allowing subsequent requests to reuse the connection.

High values (minutes or more) favor connection reuse but may cause idle
connections to linger longer.

| `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

|===
=== .status
Description::
+
--
status is the most recently observed status of the IngressController.
--

Type::
  `object`




[cols="1,1,1",options="header"]
|===
| Property | Type | Description

| `availableReplicas`
| `integer`
| availableReplicas is number of observed available replicas according to the
ingress controller deployment.

| `conditions`
| `array`
| conditions is a list of conditions and their status.

Available means the ingress controller deployment is available and
servicing route and ingress resources (i.e, .status.availableReplicas
equals .spec.replicas)

There are additional conditions which indicate the status of other
ingress controller features and capabilities.

  * LoadBalancerManaged
  - True if the following conditions are met:
    * The endpoint publishing strategy requires a service load balancer.
  - False if any of those conditions are unsatisfied.

  * LoadBalancerReady
  - True if the following conditions are met:
    * A load balancer is managed.
    * The load balancer is ready.
  - False if any of those conditions are unsatisfied.

  * DNSManaged
  - True if the following conditions are met:
    * The endpoint publishing strategy and platform support DNS.
    * The ingress controller domain is set.
    * dns.config.openshift.io/cluster configures DNS zones.
  - False if any of those conditions are unsatisfied.

  * DNSReady
  - True if the following conditions are met:
    * DNS is managed.
    * DNS records have been successfully created.
  - False if any of those conditions are unsatisfied.

| `conditions[]`
| `object`
| OperatorCondition is just the standard condition fields.

| `domain`
| `string`
| domain is the actual domain in use.

| `endpointPublishingStrategy`
| `object`
| endpointPublishingStrategy is the actual strategy in use.

| `namespaceSelector`
| `object`
| namespaceSelector is the actual namespaceSelector in use.

| `observedGeneration`
| `integer`
| observedGeneration is the most recent generation observed.

| `routeSelector`
| `object`
| routeSelector is the actual routeSelector in use.

| `selector`
| `string`
| selector is a label selector, in string format, for ingress controller pods
corresponding to the IngressController. The number of matching pods should
equal the value of availableReplicas.

| `tlsProfile`
| `object`
| tlsProfile is the TLS connection configuration that is in effect.

|===
=== .status.conditions
Description::
+
--
conditions is a list of conditions and their status.

Available means the ingress controller deployment is available and
servicing route and ingress resources (i.e, .status.availableReplicas
equals .spec.replicas)

There are additional conditions which indicate the status of other
ingress controller features and capabilities.

  * LoadBalancerManaged
  - True if the following conditions are met:
    * The endpoint publishing strategy requires a service load balancer.
  - False if any of those conditions are unsatisfied.

  * LoadBalancerReady
  - True if the following conditions are met:
    * A load balancer is managed.
    * The load balancer is ready.
  - False if any of those conditions are unsatisfied.

  * DNSManaged
  - True if the following conditions are met:
    * The endpoint publishing strategy and platform support DNS.
    * The ingress controller domain is set.
    * dns.config.openshift.io/cluster configures DNS zones.
  - False if any of those conditions are unsatisfied.

  * DNSReady
  - True if the following conditions are met:
    * DNS is managed.
    * DNS records have been successfully created.
  - False if any of those conditions are unsatisfied.
--

Type::
  `array`




=== .status.conditions[]
Description::
+
--
OperatorCondition is just the standard condition fields.
--

Type::
  `object`

Required::
  - `lastTransitionTime`
  - `status`
  - `type`



[cols="1,1,1",options="header"]
|===
| Property | Type | Description

| `lastTransitionTime`
| `string`
| lastTransitionTime is the last time the condition transitioned from one status to another.
This should be when the underlying condition changed.  If that is not known, then using the time when the API field changed is acceptable.

| `message`
| `string`
| 

| `reason`
| `string`
| 

| `status`
| `string`
| status of the condition, one of True, False, Unknown.

| `type`
| `string`
| type of condition in CamelCase or in foo.example.com/CamelCase.

|===
=== .status.endpointPublishingStrategy
Description::
+
--
endpointPublishingStrategy is the actual strategy in use.
--

Type::
  `object`

Required::
  - `type`



[cols="1,1,1",options="header"]
|===
| Property | Type | Description

| `hostNetwork`
| `object`
| hostNetwork holds parameters for the HostNetwork endpoint publishing
strategy. Present only if type is HostNetwork.

| `loadBalancer`
| `object`
| loadBalancer holds parameters for the load balancer. Present only if
type is LoadBalancerService.

| `nodePort`
| `object`
| nodePort holds parameters for the NodePortService endpoint publishing strategy.
Present only if type is NodePortService.

| `private`
| `object`
| private holds parameters for the Private endpoint publishing
strategy. Present only if type is Private.

| `type`
| `string`
| type is the publishing strategy to use. Valid values are:

* LoadBalancerService

Publishes the ingress controller using a Kubernetes LoadBalancer Service.

In this configuration, the ingress controller deployment uses container
networking. A LoadBalancer Service is created to publish the deployment.

See: https://kubernetes.io/docs/concepts/services-networking/service/#loadbalancer

If domain is set, a wildcard DNS record will be managed to point at the
LoadBalancer Service's external name. DNS records are managed only in DNS
zones defined by dns.config.openshift.io/cluster .spec.publicZone and
.spec.privateZone.

Wildcard DNS management is currently supported only on the AWS, Azure,
and GCP platforms.

* HostNetwork

Publishes the ingress controller on node ports where the ingress controller
is deployed.

In this configuration, the ingress controller deployment uses host
networking, bound to node ports 80 and 443. The user is responsible for
configuring an external load balancer to publish the ingress controller via
the node ports.

* Private

Does not publish the ingress controller.

In this configuration, the ingress controller deployment uses container
networking, and is not explicitly published. The user must manually publish
the ingress controller.

* NodePortService

Publishes the ingress controller using a Kubernetes NodePort Service.

In this configuration, the ingress controller deployment uses container
networking. A NodePort Service is created to publish the deployment. The
specific node ports are dynamically allocated by OpenShift; however, to
support static port allocations, user changes to the node port
field of the managed NodePort Service will preserved.

|===
=== .status.endpointPublishingStrategy.hostNetwork
Description::
+
--
hostNetwork holds parameters for the HostNetwork endpoint publishing
strategy. Present only if type is HostNetwork.
--

Type::
  `object`




[cols="1,1,1",options="header"]
|===
| Property | Type | Description

| `httpPort`
| `integer`
| httpPort is the port on the host which should be used to listen for
HTTP requests. This field should be set when port 80 is already in use.
The value should not coincide with the NodePort range of the cluster.
When the value is 0 or is not specified it defaults to 80.

| `httpsPort`
| `integer`
| httpsPort is the port on the host which should be used to listen for
HTTPS requests. This field should be set when port 443 is already in use.
The value should not coincide with the NodePort range of the cluster.
When the value is 0 or is not specified it defaults to 443.

| `protocol`
| `string`
| protocol specifies whether the IngressController expects incoming
connections to use plain TCP or whether the IngressController expects
PROXY protocol.

PROXY protocol can be used with load balancers that support it to
communicate the source addresses of client connections when
forwarding those connections to the IngressController.  Using PROXY
protocol enables the IngressController to report those source
addresses instead of reporting the load balancer's address in HTTP
headers and logs.  Note that enabling PROXY protocol on the
IngressController will cause connections to fail if you are not using
a load balancer that uses PROXY protocol to forward connections to
the IngressController.  See
http://www.haproxy.org/download/2.2/doc/proxy-protocol.txt for
information about PROXY protocol.

The following values are valid for this field:

* The empty string.
* "TCP".
* "PROXY".

The empty string specifies the default, which is TCP without PROXY
protocol.  Note that the default is subject to change.

| `statsPort`
| `integer`
| statsPort is the port on the host where the stats from the router are
published. The value should not coincide with the NodePort range of the
cluster. If an external load balancer is configured to forward connections
to this IngressController, the load balancer should use this port for
health checks. The load balancer can send HTTP probes on this port on a
given node, with the path /healthz/ready to determine if the ingress
controller is ready to receive traffic on the node. For proper operation
the load balancer must not forward traffic to a node until the health
check reports ready. The load balancer should also stop forwarding requests
within a maximum of 45 seconds after /healthz/ready starts reporting
not-ready. Probing every 5 to 10 seconds, with a 5-second timeout and with
a threshold of two successful or failed requests to become healthy or
unhealthy respectively, are well-tested values. When the value is 0 or
is not specified it defaults to 1936.

|===
=== .status.endpointPublishingStrategy.loadBalancer
Description::
+
--
loadBalancer holds parameters for the load balancer. Present only if
type is LoadBalancerService.
--

Type::
  `object`

Required::
  - `dnsManagementPolicy`
  - `scope`



[cols="1,1,1",options="header"]
|===
| Property | Type | Description

| `allowedSourceRanges`
| ``
| allowedSourceRanges specifies an allowlist of IP address ranges to which
access to the load balancer should be restricted.  Each range must be
specified using CIDR notation (e.g. "10.0.0.0/8" or "fd00::/8"). If no range is
specified, "0.0.0.0/0" for IPv4 and "::/0" for IPv6 are used by default,
which allows all source addresses.

To facilitate migration from earlier versions of OpenShift that did
not have the allowedSourceRanges field, you may set the
service.beta.kubernetes.io/load-balancer-source-ranges annotation on
the "router-<ingresscontroller name>" service in the
"openshift-ingress" namespace, and this annotation will take
effect if allowedSourceRanges is empty on OpenShift 4.12.

| `dnsManagementPolicy`
| `string`
| dnsManagementPolicy indicates if the lifecycle of the wildcard DNS record
associated with the load balancer service will be managed by
the ingress operator. It defaults to Managed.
Valid values are: Managed and Unmanaged.

| `providerParameters`
| `object`
| providerParameters holds desired load balancer information specific to
the underlying infrastructure provider.

If empty, defaults will be applied. See specific providerParameters
fields for details about their defaults.

| `scope`
| `string`
| scope indicates the scope at which the load balancer is exposed.
Possible values are "External" and "Internal".

|===
=== .status.endpointPublishingStrategy.loadBalancer.providerParameters
Description::
+
--
providerParameters holds desired load balancer information specific to
the underlying infrastructure provider.

If empty, defaults will be applied. See specific providerParameters
fields for details about their defaults.
--

Type::
  `object`

Required::
  - `type`



[cols="1,1,1",options="header"]
|===
| Property | Type | Description

| `aws`
| `object`
| aws provides configuration settings that are specific to AWS
load balancers.

If empty, defaults will be applied. See specific aws fields for
details about their defaults.

| `gcp`
| `object`
| gcp provides configuration settings that are specific to GCP
load balancers.

If empty, defaults will be applied. See specific gcp fields for
details about their defaults.

| `ibm`
| `object`
| ibm provides configuration settings that are specific to IBM Cloud
load balancers.

If empty, defaults will be applied. See specific ibm fields for
details about their defaults.

| `openstack`
| `object`
| openstack provides configuration settings that are specific to OpenStack
load balancers.

If empty, defaults will be applied. See specific openstack fields for
details about their defaults.

| `type`
| `string`
| type is the underlying infrastructure provider for the load balancer.
Allowed values are "AWS", "Azure", "BareMetal", "GCP", "IBM", "Nutanix",
"OpenStack", and "VSphere".

|===
=== .status.endpointPublishingStrategy.loadBalancer.providerParameters.aws
Description::
+
--
aws provides configuration settings that are specific to AWS
load balancers.

If empty, defaults will be applied. See specific aws fields for
details about their defaults.
--

Type::
  `object`

Required::
  - `type`



[cols="1,1,1",options="header"]
|===
| Property | Type | Description

| `classicLoadBalancer`
| `object`
| classicLoadBalancerParameters holds configuration parameters for an AWS
classic load balancer. Present only if type is Classic.

| `networkLoadBalancer`
| `object`
| networkLoadBalancerParameters holds configuration parameters for an AWS
network load balancer. Present only if type is NLB.

| `type`
| `string`
| type is the type of AWS load balancer to instantiate for an ingresscontroller.

Valid values are:

* "Classic": A Classic Load Balancer that makes routing decisions at either
  the transport layer (TCP/SSL) or the application layer (HTTP/HTTPS). See
  the following for additional details:

    https://docs.aws.amazon.com/AmazonECS/latest/developerguide/load-balancer-types.html#clb

* "NLB": A Network Load Balancer that makes routing decisions at the
  transport layer (TCP/SSL). See the following for additional details:

    https://docs.aws.amazon.com/AmazonECS/latest/developerguide/load-balancer-types.html#nlb

|===
=== .status.endpointPublishingStrategy.loadBalancer.providerParameters.aws.classicLoadBalancer
Description::
+
--
classicLoadBalancerParameters holds configuration parameters for an AWS
classic load balancer. Present only if type is Classic.
--

Type::
  `object`




[cols="1,1,1",options="header"]
|===
| Property | Type | Description

| `connectionIdleTimeout`
| `string`
| connectionIdleTimeout specifies the maximum time period that a
connection may be idle before the load balancer closes the
connection.  The value must be parseable as a time duration value;
see <https://pkg.go.dev/time#ParseDuration>.  A nil or zero value
means no opinion, in which case a default value is used.  The default
value for this field is 60s.  This default is subject to change.

| `subnets`
| `object`
| subnets specifies the subnets to which the load balancer will
attach. The subnets may be specified by either their
ID or name. The total number of subnets is limited to 10.

In order for the load balancer to be provisioned with subnets,
each subnet must exist, each subnet must be from a different
availability zone, and the load balancer service must be
recreated to pick up new values.

When omitted from the spec, the subnets will be auto-discovered
for each availability zone. Auto-discovered subnets are not reported
in the status of the IngressController object.

|===
=== .status.endpointPublishingStrategy.loadBalancer.providerParameters.aws.classicLoadBalancer.subnets
Description::
+
--
subnets specifies the subnets to which the load balancer will
attach. The subnets may be specified by either their
ID or name. The total number of subnets is limited to 10.

In order for the load balancer to be provisioned with subnets,
each subnet must exist, each subnet must be from a different
availability zone, and the load balancer service must be
recreated to pick up new values.

When omitted from the spec, the subnets will be auto-discovered
for each availability zone. Auto-discovered subnets are not reported
in the status of the IngressController object.
--

Type::
  `object`




[cols="1,1,1",options="header"]
|===
| Property | Type | Description

| `ids`
| `array (string)`
| ids specifies a list of AWS subnets by subnet ID.
Subnet IDs must start with "subnet-", consist only
of alphanumeric characters, must be exactly 24
characters long, must be unique, and the total
number of subnets specified by ids and names
must not exceed 10.

| `names`
| `array (string)`
| names specifies a list of AWS subnets by subnet name.
Subnet names must not start with "subnet-", must not
include commas, must be under 256 characters in length,
must be unique, and the total number of subnets
specified by ids and names must not exceed 10.

|===
=== .status.endpointPublishingStrategy.loadBalancer.providerParameters.aws.networkLoadBalancer
Description::
+
--
networkLoadBalancerParameters holds configuration parameters for an AWS
network load balancer. Present only if type is NLB.
--

Type::
  `object`




[cols="1,1,1",options="header"]
|===
| Property | Type | Description

| `eipAllocations`
| `array (string)`
| eipAllocations is a list of IDs for Elastic IP (EIP) addresses that
are assigned to the Network Load Balancer.
The following restrictions apply:

eipAllocations can only be used with external scope, not internal.
An EIP can be allocated to only a single IngressController.
The number of EIP allocations must match the number of subnets that are used for the load balancer.
Each EIP allocation must be unique.
A maximum of 10 EIP allocations are permitted.

See https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html for general
information about configuration, characteristics, and limitations of Elastic IP addresses.

| `subnets`
| `object`
| subnets specifies the subnets to which the load balancer will
attach. The subnets may be specified by either their
ID or name. The total number of subnets is limited to 10.

In order for the load balancer to be provisioned with subnets,
each subnet must exist, each subnet must be from a different
availability zone, and the load balancer service must be
recreated to pick up new values.

When omitted from the spec, the subnets will be auto-discovered
for each availability zone. Auto-discovered subnets are not reported
in the status of the IngressController object.

|===
=== .status.endpointPublishingStrategy.loadBalancer.providerParameters.aws.networkLoadBalancer.subnets
Description::
+
--
subnets specifies the subnets to which the load balancer will
attach. The subnets may be specified by either their
ID or name. The total number of subnets is limited to 10.

In order for the load balancer to be provisioned with subnets,
each subnet must exist, each subnet must be from a different
availability zone, and the load balancer service must be
recreated to pick up new values.

When omitted from the spec, the subnets will be auto-discovered
for each availability zone. Auto-discovered subnets are not reported
in the status of the IngressController object.
--

Type::
  `object`




[cols="1,1,1",options="header"]
|===
| Property | Type | Description

| `ids`
| `array (string)`
| ids specifies a list of AWS subnets by subnet ID.
Subnet IDs must start with "subnet-", consist only
of alphanumeric characters, must be exactly 24
characters long, must be unique, and the total
number of subnets specified by ids and names
must not exceed 10.

| `names`
| `array (string)`
| names specifies a list of AWS subnets by subnet name.
Subnet names must not start with "subnet-", must not
include commas, must be under 256 characters in length,
must be unique, and the total number of subnets
specified by ids and names must not exceed 10.

|===
=== .status.endpointPublishingStrategy.loadBalancer.providerParameters.gcp
Description::
+
--
gcp provides configuration settings that are specific to GCP
load balancers.

If empty, defaults will be applied. See specific gcp fields for
details about their defaults.
--

Type::
  `object`




[cols="1,1,1",options="header"]
|===
| Property | Type | Description

| `clientAccess`
| `string`
| clientAccess describes how client access is restricted for internal
load balancers.

Valid values are:
* "Global": Specifying an internal load balancer with Global client access
  allows clients from any region within the VPC to communicate with the load
  balancer.

    https://cloud.google.com/kubernetes-engine/docs/how-to/internal-load-balancing#global_access

* "Local": Specifying an internal load balancer with Local client access
  means only clients within the same region (and VPC) as the GCP load balancer
  can communicate with the load balancer. Note that this is the default behavior.

    https://cloud.google.com/load-balancing/docs/internal#client_access

|===
=== .status.endpointPublishingStrategy.loadBalancer.providerParameters.ibm
Description::
+
--
ibm provides configuration settings that are specific to IBM Cloud
load balancers.

If empty, defaults will be applied. See specific ibm fields for
details about their defaults.
--

Type::
  `object`




[cols="1,1,1",options="header"]
|===
| Property | Type | Description

| `protocol`
| `string`
| protocol specifies whether the load balancer uses PROXY protocol to forward connections to
the IngressController. See "service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features:
"proxy-protocol"" at https://cloud.ibm.com/docs/containers?topic=containers-vpc-lbaas"

PROXY protocol can be used with load balancers that support it to
communicate the source addresses of client connections when
forwarding those connections to the IngressController.  Using PROXY
protocol enables the IngressController to report those source
addresses instead of reporting the load balancer's address in HTTP
headers and logs.  Note that enabling PROXY protocol on the
IngressController will cause connections to fail if you are not using
a load balancer that uses PROXY protocol to forward connections to
the IngressController.  See
http://www.haproxy.org/download/2.2/doc/proxy-protocol.txt for
information about PROXY protocol.

Valid values for protocol are TCP, PROXY and omitted.
When omitted, this means no opinion and the platform is left to choose a reasonable default, which is subject to change over time.
The current default is TCP, without the proxy protocol enabled.

|===
=== .status.endpointPublishingStrategy.loadBalancer.providerParameters.openstack
Description::
+
--
openstack provides configuration settings that are specific to OpenStack
load balancers.

If empty, defaults will be applied. See specific openstack fields for
details about their defaults.
--

Type::
  `object`




[cols="1,1,1",options="header"]
|===
| Property | Type | Description

| `floatingIP`
| `string`
| floatingIP specifies the IP address that the load balancer will use.
When not specified, an IP address will be assigned randomly by the OpenStack cloud provider.
When specified, the floating IP has to be pre-created.  If the
specified value is not a floating IP or is already claimed, the
OpenStack cloud provider won't be able to provision the load
balancer.
This field may only be used if the IngressController has External scope.
This value must be a valid IPv4 or IPv6 address.

|===
=== .status.endpointPublishingStrategy.nodePort
Description::
+
--
nodePort holds parameters for the NodePortService endpoint publishing strategy.
Present only if type is NodePortService.
--

Type::
  `object`




[cols="1,1,1",options="header"]
|===
| Property | Type | Description

| `protocol`
| `string`
| protocol specifies whether the IngressController expects incoming
connections to use plain TCP or whether the IngressController expects
PROXY protocol.

PROXY protocol can be used with load balancers that support it to
communicate the source addresses of client connections when
forwarding those connections to the IngressController.  Using PROXY
protocol enables the IngressController to report those source
addresses instead of reporting the load balancer's address in HTTP
headers and logs.  Note that enabling PROXY protocol on the
IngressController will cause connections to fail if you are not using
a load balancer that uses PROXY protocol to forward connections to
the IngressController.  See
http://www.haproxy.org/download/2.2/doc/proxy-protocol.txt for
information about PROXY protocol.

The following values are valid for this field:

* The empty string.
* "TCP".
* "PROXY".

The empty string specifies the default, which is TCP without PROXY
protocol.  Note that the default is subject to change.

|===
=== .status.endpointPublishingStrategy.private
Description::
+
--
private holds parameters for the Private endpoint publishing
strategy. Present only if type is Private.
--

Type::
  `object`




[cols="1,1,1",options="header"]
|===
| Property | Type | Description

| `protocol`
| `string`
| protocol specifies whether the IngressController expects incoming
connections to use plain TCP or whether the IngressController expects
PROXY protocol.

PROXY protocol can be used with load balancers that support it to
communicate the source addresses of client connections when
forwarding those connections to the IngressController.  Using PROXY
protocol enables the IngressController to report those source
addresses instead of reporting the load balancer's address in HTTP
headers and logs.  Note that enabling PROXY protocol on the
IngressController will cause connections to fail if you are not using
a load balancer that uses PROXY protocol to forward connections to
the IngressController.  See
http://www.haproxy.org/download/2.2/doc/proxy-protocol.txt for
information about PROXY protocol.

The following values are valid for this field:

* The empty string.
* "TCP".
* "PROXY".

The empty string specifies the default, which is TCP without PROXY
protocol.  Note that the default is subject to change.

|===
=== .status.namespaceSelector
Description::
+
--
namespaceSelector is the actual namespaceSelector in use.
--

Type::
  `object`




[cols="1,1,1",options="header"]
|===
| Property | Type | Description

| `matchExpressions`
| `array`
| matchExpressions is a list of label selector requirements. The requirements are ANDed.

| `matchExpressions[]`
| `object`
| A label selector requirement is a selector that contains values, a key, and an operator that
relates the key and values.

| `matchLabels`
| `object (string)`
| matchLabels is a map of {key,value} pairs. A single {key,value} in the matchLabels
map is equivalent to an element of matchExpressions, whose key field is "key", the
operator is "In", and the values array contains only "value". The requirements are ANDed.

|===
=== .status.namespaceSelector.matchExpressions
Description::
+
--
matchExpressions is a list of label selector requirements. The requirements are ANDed.
--

Type::
  `array`




=== .status.namespaceSelector.matchExpressions[]
Description::
+
--
A label selector requirement is a selector that contains values, a key, and an operator that
relates the key and values.
--

Type::
  `object`

Required::
  - `key`
  - `operator`



[cols="1,1,1",options="header"]
|===
| Property | Type | Description

| `key`
| `string`
| key is the label key that the selector applies to.

| `operator`
| `string`
| operator represents a key's relationship to a set of values.
Valid operators are In, NotIn, Exists and DoesNotExist.

| `values`
| `array (string)`
| values is an array of string values. If the operator is In or NotIn,
the values array must be non-empty. If the operator is Exists or DoesNotExist,
the values array must be empty. This array is replaced during a strategic
merge patch.

|===
=== .status.routeSelector
Description::
+
--
routeSelector is the actual routeSelector in use.
--

Type::
  `object`




[cols="1,1,1",options="header"]
|===
| Property | Type | Description

| `matchExpressions`
| `array`
| matchExpressions is a list of label selector requirements. The requirements are ANDed.

| `matchExpressions[]`
| `object`
| A label selector requirement is a selector that contains values, a key, and an operator that
relates the key and values.

| `matchLabels`
| `object (string)`
| matchLabels is a map of {key,value} pairs. A single {key,value} in the matchLabels
map is equivalent to an element of matchExpressions, whose key field is "key", the
operator is "In", and the values array contains only "value". The requirements are ANDed.

|===
=== .status.routeSelector.matchExpressions
Description::
+
--
matchExpressions is a list of label selector requirements. The requirements are ANDed.
--

Type::
  `array`




=== .status.routeSelector.matchExpressions[]
Description::
+
--
A label selector requirement is a selector that contains values, a key, and an operator that
relates the key and values.
--

Type::
  `object`

Required::
  - `key`
  - `operator`



[cols="1,1,1",options="header"]
|===
| Property | Type | Description

| `key`
| `string`
| key is the label key that the selector applies to.

| `operator`
| `string`
| operator represents a key's relationship to a set of values.
Valid operators are In, NotIn, Exists and DoesNotExist.

| `values`
| `array (string)`
| values is an array of string values. If the operator is In or NotIn,
the values array must be non-empty. If the operator is Exists or DoesNotExist,
the values array must be empty. This array is replaced during a strategic
merge patch.

|===
=== .status.tlsProfile
Description::
+
--
tlsProfile is the TLS connection configuration that is in effect.
--

Type::
  `object`




[cols="1,1,1",options="header"]
|===
| Property | Type | Description

| `ciphers`
| `array (string)`
| ciphers is used to specify the cipher algorithms that are negotiated
during the TLS handshake.  Operators may remove entries their operands
do not support.  For example, to use DES-CBC3-SHA  (yaml):

  ciphers:
    - DES-CBC3-SHA

| `minTLSVersion`
| `string`
| minTLSVersion is used to specify the minimal version of the TLS protocol
that is negotiated during the TLS handshake. For example, to use TLS
versions 1.1, 1.2 and 1.3 (yaml):

  minTLSVersion: VersionTLS11

NOTE: currently the highest minTLSVersion allowed is VersionTLS12

|===

== API endpoints

The following API endpoints are available:

* `/apis/operator.openshift.io/v1/ingresscontrollers`
- `GET`: list objects of kind IngressController
* `/apis/operator.openshift.io/v1/namespaces/{namespace}/ingresscontrollers`
- `DELETE`: delete collection of IngressController
- `GET`: list objects of kind IngressController
- `POST`: create an IngressController
* `/apis/operator.openshift.io/v1/namespaces/{namespace}/ingresscontrollers/{name}`
- `DELETE`: delete an IngressController
- `GET`: read the specified IngressController
- `PATCH`: partially update the specified IngressController
- `PUT`: replace the specified IngressController
* `/apis/operator.openshift.io/v1/namespaces/{namespace}/ingresscontrollers/{name}/scale`
- `GET`: read scale of the specified IngressController
- `PATCH`: partially update scale of the specified IngressController
- `PUT`: replace scale of the specified IngressController
* `/apis/operator.openshift.io/v1/namespaces/{namespace}/ingresscontrollers/{name}/status`
- `GET`: read status of the specified IngressController
- `PATCH`: partially update status of the specified IngressController
- `PUT`: replace status of the specified IngressController


=== /apis/operator.openshift.io/v1/ingresscontrollers



HTTP method::
  `GET`

Description::
  list objects of kind IngressController


.HTTP responses
[cols="1,1",options="header"]
|===
| HTTP code | Reponse body
| 200 - OK
| xref:../objects/index.adoc#io-openshift-operator-v1-IngressControllerList[`IngressControllerList`] schema
| 401 - Unauthorized
| Empty
|===


=== /apis/operator.openshift.io/v1/namespaces/{namespace}/ingresscontrollers



HTTP method::
  `DELETE`

Description::
  delete collection of IngressController




.HTTP responses
[cols="1,1",options="header"]
|===
| HTTP code | Reponse body
| 200 - OK
| xref:../objects/index.adoc#io-k8s-apimachinery-pkg-apis-meta-v1-Status[`Status`] schema
| 401 - Unauthorized
| Empty
|===

HTTP method::
  `GET`

Description::
  list objects of kind IngressController




.HTTP responses
[cols="1,1",options="header"]
|===
| HTTP code | Reponse body
| 200 - OK
| xref:../objects/index.adoc#io-openshift-operator-v1-IngressControllerList[`IngressControllerList`] schema
| 401 - Unauthorized
| Empty
|===

HTTP method::
  `POST`

Description::
  create an IngressController


.Query parameters
[cols="1,1,2",options="header"]
|===
| Parameter | Type | Description
| `dryRun`
| `string`
| When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed
| `fieldValidation`
| `string`
| fieldValidation instructs the server on how to handle objects in the request (POST/PUT/PATCH) containing unknown or duplicate fields. Valid values are: - Ignore: This will ignore any unknown fields that are silently dropped from the object, and will ignore all but the last duplicate field that the decoder encounters. This is the default behavior prior to v1.23. - Warn: This will send a warning via the standard warning response header for each unknown field that is dropped from the object, and for each duplicate field that is encountered. The request will still succeed if there are no other errors, and will only persist the last of any duplicate fields. This is the default in v1.23+ - Strict: This will fail the request with a BadRequest error if any unknown fields would be dropped from the object, or if any duplicate fields are present. The error returned from the server will contain all unknown and duplicate fields encountered.
|===

.Body parameters
[cols="1,1,2",options="header"]
|===
| Parameter | Type | Description
| `body`
| xref:../operator_apis/ingresscontroller-operator-openshift-io-v1.adoc#ingresscontroller-operator-openshift-io-v1[`IngressController`] schema
| 
|===

.HTTP responses
[cols="1,1",options="header"]
|===
| HTTP code | Reponse body
| 200 - OK
| xref:../operator_apis/ingresscontroller-operator-openshift-io-v1.adoc#ingresscontroller-operator-openshift-io-v1[`IngressController`] schema
| 201 - Created
| xref:../operator_apis/ingresscontroller-operator-openshift-io-v1.adoc#ingresscontroller-operator-openshift-io-v1[`IngressController`] schema
| 202 - Accepted
| xref:../operator_apis/ingresscontroller-operator-openshift-io-v1.adoc#ingresscontroller-operator-openshift-io-v1[`IngressController`] schema
| 401 - Unauthorized
| Empty
|===


=== /apis/operator.openshift.io/v1/namespaces/{namespace}/ingresscontrollers/{name}

.Global path parameters
[cols="1,1,2",options="header"]
|===
| Parameter | Type | Description
| `name`
| `string`
| name of the IngressController
|===


HTTP method::
  `DELETE`

Description::
  delete an IngressController


.Query parameters
[cols="1,1,2",options="header"]
|===
| Parameter | Type | Description
| `dryRun`
| `string`
| When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed
|===


.HTTP responses
[cols="1,1",options="header"]
|===
| HTTP code | Reponse body
| 200 - OK
| xref:../objects/index.adoc#io-k8s-apimachinery-pkg-apis-meta-v1-Status[`Status`] schema
| 202 - Accepted
| xref:../objects/index.adoc#io-k8s-apimachinery-pkg-apis-meta-v1-Status[`Status`] schema
| 401 - Unauthorized
| Empty
|===

HTTP method::
  `GET`

Description::
  read the specified IngressController




.HTTP responses
[cols="1,1",options="header"]
|===
| HTTP code | Reponse body
| 200 - OK
| xref:../operator_apis/ingresscontroller-operator-openshift-io-v1.adoc#ingresscontroller-operator-openshift-io-v1[`IngressController`] schema
| 401 - Unauthorized
| Empty
|===

HTTP method::
  `PATCH`

Description::
  partially update the specified IngressController


.Query parameters
[cols="1,1,2",options="header"]
|===
| Parameter | Type | Description
| `dryRun`
| `string`
| When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed
| `fieldValidation`
| `string`
| fieldValidation instructs the server on how to handle objects in the request (POST/PUT/PATCH) containing unknown or duplicate fields. Valid values are: - Ignore: This will ignore any unknown fields that are silently dropped from the object, and will ignore all but the last duplicate field that the decoder encounters. This is the default behavior prior to v1.23. - Warn: This will send a warning via the standard warning response header for each unknown field that is dropped from the object, and for each duplicate field that is encountered. The request will still succeed if there are no other errors, and will only persist the last of any duplicate fields. This is the default in v1.23+ - Strict: This will fail the request with a BadRequest error if any unknown fields would be dropped from the object, or if any duplicate fields are present. The error returned from the server will contain all unknown and duplicate fields encountered.
|===


.HTTP responses
[cols="1,1",options="header"]
|===
| HTTP code | Reponse body
| 200 - OK
| xref:../operator_apis/ingresscontroller-operator-openshift-io-v1.adoc#ingresscontroller-operator-openshift-io-v1[`IngressController`] schema
| 401 - Unauthorized
| Empty
|===

HTTP method::
  `PUT`

Description::
  replace the specified IngressController


.Query parameters
[cols="1,1,2",options="header"]
|===
| Parameter | Type | Description
| `dryRun`
| `string`
| When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed
| `fieldValidation`
| `string`
| fieldValidation instructs the server on how to handle objects in the request (POST/PUT/PATCH) containing unknown or duplicate fields. Valid values are: - Ignore: This will ignore any unknown fields that are silently dropped from the object, and will ignore all but the last duplicate field that the decoder encounters. This is the default behavior prior to v1.23. - Warn: This will send a warning via the standard warning response header for each unknown field that is dropped from the object, and for each duplicate field that is encountered. The request will still succeed if there are no other errors, and will only persist the last of any duplicate fields. This is the default in v1.23+ - Strict: This will fail the request with a BadRequest error if any unknown fields would be dropped from the object, or if any duplicate fields are present. The error returned from the server will contain all unknown and duplicate fields encountered.
|===

.Body parameters
[cols="1,1,2",options="header"]
|===
| Parameter | Type | Description
| `body`
| xref:../operator_apis/ingresscontroller-operator-openshift-io-v1.adoc#ingresscontroller-operator-openshift-io-v1[`IngressController`] schema
| 
|===

.HTTP responses
[cols="1,1",options="header"]
|===
| HTTP code | Reponse body
| 200 - OK
| xref:../operator_apis/ingresscontroller-operator-openshift-io-v1.adoc#ingresscontroller-operator-openshift-io-v1[`IngressController`] schema
| 201 - Created
| xref:../operator_apis/ingresscontroller-operator-openshift-io-v1.adoc#ingresscontroller-operator-openshift-io-v1[`IngressController`] schema
| 401 - Unauthorized
| Empty
|===


=== /apis/operator.openshift.io/v1/namespaces/{namespace}/ingresscontrollers/{name}/scale

.Global path parameters
[cols="1,1,2",options="header"]
|===
| Parameter | Type | Description
| `name`
| `string`
| name of the IngressController
|===


HTTP method::
  `GET`

Description::
  read scale of the specified IngressController




.HTTP responses
[cols="1,1",options="header"]
|===
| HTTP code | Reponse body
| 200 - OK
| xref:../autoscale_apis/scale-autoscaling-v1.adoc#scale-autoscaling-v1[`Scale`] schema
| 401 - Unauthorized
| Empty
|===

HTTP method::
  `PATCH`

Description::
  partially update scale of the specified IngressController


.Query parameters
[cols="1,1,2",options="header"]
|===
| Parameter | Type | Description
| `dryRun`
| `string`
| When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed
| `fieldValidation`
| `string`
| fieldValidation instructs the server on how to handle objects in the request (POST/PUT/PATCH) containing unknown or duplicate fields. Valid values are: - Ignore: This will ignore any unknown fields that are silently dropped from the object, and will ignore all but the last duplicate field that the decoder encounters. This is the default behavior prior to v1.23. - Warn: This will send a warning via the standard warning response header for each unknown field that is dropped from the object, and for each duplicate field that is encountered. The request will still succeed if there are no other errors, and will only persist the last of any duplicate fields. This is the default in v1.23+ - Strict: This will fail the request with a BadRequest error if any unknown fields would be dropped from the object, or if any duplicate fields are present. The error returned from the server will contain all unknown and duplicate fields encountered.
|===


.HTTP responses
[cols="1,1",options="header"]
|===
| HTTP code | Reponse body
| 200 - OK
| xref:../autoscale_apis/scale-autoscaling-v1.adoc#scale-autoscaling-v1[`Scale`] schema
| 401 - Unauthorized
| Empty
|===

HTTP method::
  `PUT`

Description::
  replace scale of the specified IngressController


.Query parameters
[cols="1,1,2",options="header"]
|===
| Parameter | Type | Description
| `dryRun`
| `string`
| When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed
| `fieldValidation`
| `string`
| fieldValidation instructs the server on how to handle objects in the request (POST/PUT/PATCH) containing unknown or duplicate fields. Valid values are: - Ignore: This will ignore any unknown fields that are silently dropped from the object, and will ignore all but the last duplicate field that the decoder encounters. This is the default behavior prior to v1.23. - Warn: This will send a warning via the standard warning response header for each unknown field that is dropped from the object, and for each duplicate field that is encountered. The request will still succeed if there are no other errors, and will only persist the last of any duplicate fields. This is the default in v1.23+ - Strict: This will fail the request with a BadRequest error if any unknown fields would be dropped from the object, or if any duplicate fields are present. The error returned from the server will contain all unknown and duplicate fields encountered.
|===

.Body parameters
[cols="1,1,2",options="header"]
|===
| Parameter | Type | Description
| `body`
| xref:../autoscale_apis/scale-autoscaling-v1.adoc#scale-autoscaling-v1[`Scale`] schema
| 
|===

.HTTP responses
[cols="1,1",options="header"]
|===
| HTTP code | Reponse body
| 200 - OK
| xref:../autoscale_apis/scale-autoscaling-v1.adoc#scale-autoscaling-v1[`Scale`] schema
| 201 - Created
| xref:../autoscale_apis/scale-autoscaling-v1.adoc#scale-autoscaling-v1[`Scale`] schema
| 401 - Unauthorized
| Empty
|===


=== /apis/operator.openshift.io/v1/namespaces/{namespace}/ingresscontrollers/{name}/status

.Global path parameters
[cols="1,1,2",options="header"]
|===
| Parameter | Type | Description
| `name`
| `string`
| name of the IngressController
|===


HTTP method::
  `GET`

Description::
  read status of the specified IngressController




.HTTP responses
[cols="1,1",options="header"]
|===
| HTTP code | Reponse body
| 200 - OK
| xref:../operator_apis/ingresscontroller-operator-openshift-io-v1.adoc#ingresscontroller-operator-openshift-io-v1[`IngressController`] schema
| 401 - Unauthorized
| Empty
|===

HTTP method::
  `PATCH`

Description::
  partially update status of the specified IngressController


.Query parameters
[cols="1,1,2",options="header"]
|===
| Parameter | Type | Description
| `dryRun`
| `string`
| When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed
| `fieldValidation`
| `string`
| fieldValidation instructs the server on how to handle objects in the request (POST/PUT/PATCH) containing unknown or duplicate fields. Valid values are: - Ignore: This will ignore any unknown fields that are silently dropped from the object, and will ignore all but the last duplicate field that the decoder encounters. This is the default behavior prior to v1.23. - Warn: This will send a warning via the standard warning response header for each unknown field that is dropped from the object, and for each duplicate field that is encountered. The request will still succeed if there are no other errors, and will only persist the last of any duplicate fields. This is the default in v1.23+ - Strict: This will fail the request with a BadRequest error if any unknown fields would be dropped from the object, or if any duplicate fields are present. The error returned from the server will contain all unknown and duplicate fields encountered.
|===


.HTTP responses
[cols="1,1",options="header"]
|===
| HTTP code | Reponse body
| 200 - OK
| xref:../operator_apis/ingresscontroller-operator-openshift-io-v1.adoc#ingresscontroller-operator-openshift-io-v1[`IngressController`] schema
| 401 - Unauthorized
| Empty
|===

HTTP method::
  `PUT`

Description::
  replace status of the specified IngressController


.Query parameters
[cols="1,1,2",options="header"]
|===
| Parameter | Type | Description
| `dryRun`
| `string`
| When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed
| `fieldValidation`
| `string`
| fieldValidation instructs the server on how to handle objects in the request (POST/PUT/PATCH) containing unknown or duplicate fields. Valid values are: - Ignore: This will ignore any unknown fields that are silently dropped from the object, and will ignore all but the last duplicate field that the decoder encounters. This is the default behavior prior to v1.23. - Warn: This will send a warning via the standard warning response header for each unknown field that is dropped from the object, and for each duplicate field that is encountered. The request will still succeed if there are no other errors, and will only persist the last of any duplicate fields. This is the default in v1.23+ - Strict: This will fail the request with a BadRequest error if any unknown fields would be dropped from the object, or if any duplicate fields are present. The error returned from the server will contain all unknown and duplicate fields encountered.
|===

.Body parameters
[cols="1,1,2",options="header"]
|===
| Parameter | Type | Description
| `body`
| xref:../operator_apis/ingresscontroller-operator-openshift-io-v1.adoc#ingresscontroller-operator-openshift-io-v1[`IngressController`] schema
| 
|===

.HTTP responses
[cols="1,1",options="header"]
|===
| HTTP code | Reponse body
| 200 - OK
| xref:../operator_apis/ingresscontroller-operator-openshift-io-v1.adoc#ingresscontroller-operator-openshift-io-v1[`IngressController`] schema
| 201 - Created
| xref:../operator_apis/ingresscontroller-operator-openshift-io-v1.adoc#ingresscontroller-operator-openshift-io-v1[`IngressController`] schema
| 401 - Unauthorized
| Empty
|===