Red Hat Summit Red Hat SummitApoyoConsolaDesarrolladoresIniciar una pruebaContacto

Este contenido no está disponible en el idioma seleccionado.

Chapter 5. Using ingress control for a MicroShift node

Use the ingress controller options in the MicroShift configuration file to make pods and services accessible outside the node.

5.1. Using ingress control in MicroShift
Copiar enlace

When you create your MicroShift node, each pod and service running on the node is allocated an IP address. These IP addresses are accessible to other pods and services running nearby by default, but are not accessible to external clients. MicroShift uses a minimal implementation of the OpenShift Container Platform IngressController API to enable external access to node services.

With more configuration options, you can fine-tune ingress to meet your specific needs. To use enhanced ingress control, update the parameters in the MicroShift configuration file and restart the service. Ingress configuration is useful in a variety of ways, for example:

  • If your application starts processing requests from clients but the connection is closed before it can respond, you can set the ingress.tuningOptions.serverTimeout parameter in the configuration file to a higher value to accommodate the speed of the response from the server.
  • If the router has many connections open because an application running on the cluster does not close connections properly, you can set the ingress.tuningOptions.serverTimeout and spec.tuningOptions.serverFinTimeout parameters to a lower value, forcing those connections to close sooner.

5.2. Configuring ingress control in MicroShift
Copiar enlace

To apply detailed ingress control such as timeouts, TLS, and logging in MicroShift, you can update the config.yaml file or add a configuration snippet in the /etc/microshift/config.d/ directory. Replace the default values in the ingress section and restart the service.

Prerequisites

  • You installed the OpenShift CLI (oc).
  • You have root access to the node.
  • Your node uses the OVN-Kubernetes Container Network Interface (CNI) plugin.

Procedure

  1. Apply ingress control settings in one of the two following ways:

    1. Update the MicroShift config.yaml configuration file by making a copy of the provided config.yaml.default file in the /etc/microshift/ directory, naming it config.yaml and keeping it in the source directory.

      • After you create it, the config.yaml file takes precedence over built-in settings. The configuration file is read every time the MicroShift service starts.

    2. Use a configuration snippet to apply the ingress control settings you want. To do this, create a configuration snippet YAML file and put it in the /etc/microshift/config.d/ configuration directory.

      • Configuration snippet YAMLs take precedence over both built-in settings and a config.yaml configuration file. See the Additional resources links for more information.

  2. Replace the default values in the network section of the MicroShift YAML with your valid values, or create a configuration snippet file with the sections you need.

    Ingress controller configuration fields with default values

    apiServer:
# ...
ingress:
    defaultHTTPVersion: 1
    forwardedHeaderPolicy: Append
    httpCompression:
        mimeTypes:
            - ""
    httpEmptyRequestsPolicy: Respond
# ...
    logEmptyRequests: Log
# ...
    tuningOptions:
        clientFinTimeout: 1s
        clientTimeout: 30s
        headerBufferBytes: 0
        headerBufferMaxRewriteBytes: 0
        healthCheckInterval: 5s
        maxConnections: 0
        serverFinTimeout: 1s
        serverTimeout: 30s
        threadCount: 4
        tlsInspectDelay: 5s
        tunnelTimeout: 1h
# ...

    See "Ingress controller configuration fields in MicroShift" for more information about each field.

  3. Complete any other configurations you require, then start or restart MicroShift by running one the following commands: 

    $ sudo systemctl start microshift
     
    $ sudo systemctl restart microshift

Verification

After making ingress configuration changes and restarting MicroShift, you can check the age of the router pod to ensure that changes have been applied.

  • To check the status of the router pod, run the following command: 

    $ oc get pods -n openshift-ingress

    Example output

    NAME                              READY   STATUS    RESTARTS   AGE
router-default-8649b5bf65-w29cn   1/1     Running   0          6m10s

5.2.1. Ingress controller configuration fields in MicroShift
Copiar enlace

The following table lists and defines the ingress controller configuration parameters in the MicroShift config.yaml file. You use these parameters when you configure access logging, TLS, timeouts, route admission, and other ingress options.

Expand
Table 5.1. Ingress controller configuration fields definitions table
ParameterDescription

defaultHTTPVersion

Sets the HTTP version for the ingress controller. Default value is 1 for HTTP 1.1.

forwardedHeaderPolicy

Specifies when and how the ingress controller sets the Forwarded, X-Forwarded-For, X-Forwarded-Host, X-Forwarded-Port, X-Forwarded-Proto, and X-Forwarded-Proto-Version HTTP headers. The following values are valid:

  • Append, preserves any existing headers by specifying that the ingress controller appends them.
  • Replace, removes any existing headers by specifying that the ingress controller sets the headers.
  • IfNone sets the headers set by specifying that the ingress controller sets the headers if they are not already set.
  • Never, preserves any existing headers by specifying that the ingress controller never sets the headers.

httpCompression

Defines the policy for HTTP traffic compression.

  • httpCompression.mimeTypes defines a list of or a single MIME type to which compression is applied. For example, text/css; charset=utf-8, text/html, text/*, image/svg+xml, application/octet-stream, X-custom/customsub, using the format pattern, type/subtype; [;attribute=value]. The types are: application, image, message, multipart, text, video, or a custom type prefaced by X-. To see the full notation for MIME types and subtypes, see RFC1341 (IETF Datatracker documentation).

httpEmptyRequestsPolicy

Describes how HTTP connections are handled if the connection times out before a request is received. Allowed values for this field are Respond and Ignore. The default value is Respond. The following are valid values:

  • Respond, causes the ingress controller to send an HTTP 400 or 408 response, logs the connection if access logging is enabled, and counts the connection in the appropriate metrics.
  • Ignore, adds the http-ignore-probes parameter in the HAproxy configuration. If the field is set to Ignore, the ingress controller closes the connection without sending a response, then logs the connection or incrementing metrics.

Usually, empty request connections come from load balancer health probes or web browser preconnects and can be safely ignored. However, network errors and port scans can also create these empty requests, so setting this field to Ignore can impede detecting or diagnosing problems and also impede the detection of intrusion attempts.

logEmptyRequests

Specifies connections for which no request is received and logged. Usually, these empty requests come from load balancer health probes or web browser speculative connections such as preconnects. Logging these types of empty requests can be undesirable. However, network errors and port scans can also create empty requests, so setting this field to Ignore can impede detecting or diagnosing problems and also impede the detection of intrusion attempts.

The following are valid values:

  • Log, which indicates that an event should be logged.
  • Ignore, which sets the dontlognull option in the HAproxy configuration.

tuningOptions

Specifies options for tuning the performance of ingress controller pods.

  • The tuningOptions.clientFinTimeout parameter specifies how long a connection is held open while waiting for the client response to the server closing the connection. The default timeout is 1s.
  • The tuningOptions.clientTimeout parameter specifies how long a connection is held open while waiting for a client response. The default timeout is 30s.

  • The tuningOptions.headerBufferBytes parameter specifies how much memory is reserved, in bytes, for Ingress Controller connection sessions. This value must be at least 16384 if HTTP/2 is enabled for the Ingress Controller. If not set, the default value is 32768 bytes.

    Important

    Setting this field not recommended because headerBufferMaxRewriteBytes parameter values that are too small can break the ingress controller. Conversely, values for headerBufferMaxRewriteBytes that are too large could cause the ingress controller to use significantly more memory than necessary.

  • The tuningOptions.headerBufferMaxRewriteBytes parameter specifies how much memory should be reserved, in bytes, from headerBufferBytes for HTTP header rewriting and appending for Ingress Controller connection sessions. The minimum value for headerBufferMaxRewriteBytes is 4096. The headerBufferBytes value must be greater than the headerBufferMaxRewriteBytes value for incoming HTTP requests.

  • If not set, the default value is 8192 bytes.

    Important

    Setting this field is not recommended because headerBufferMaxRewriteBytes parameter values that are too small can break the ingress controller. Conversely, values for headerBufferMaxRewriteBytes that are too large could cause the ingress controller to use significantly more memory than necessary.

  • The tuningOptions.healthCheckInterval parameter specifies how long the router waits between health checks. The default is 5s.
  • The tuningOptions.serverFinTimeout parameter specifies how long a connection is held open while waiting for the server response to the client that is closing the connection. The default timeout is 1s.
  • The tuningOptions.serverTimeout parameter specifies how long a connection is held open while waiting for a server response. The default timeout is 30s.

  • The tuningOptions.threadCount parameter specifies the number of threads to create 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 supports up to 64 threads. If this field is empty, default value is 4 threads.

    Important

    Setting this field is not recommended because increasing the number of HAProxy threads allows ingress controller pods to use more CPU time under load, and prevent other pods from receiving the CPU resources they need to perform.

  • The tuningOptions.tlsInspectDelay parameter specifies how long the router can hold data to find a matching route. Setting this value too short can cause the router to fall back to the default certificate for edge-terminated, re-encrypted, or passthrough routes, even when using a better-matched certificate. The default inspect delay is 5s.
  • The tuningOptions.tunnelTimeout parameter specifies how long a tunnel connection, including websockets, remains open while the tunnel is idle. The default timeout is 1h.
Red Hat logoGithubredditYoutubeTwitter

Aprender

Pruebe, compre y venda

Comunidades

Acerca de Red Hat

Ofrecemos soluciones reforzadas que facilitan a las empresas trabajar en plataformas y entornos, desde el centro de datos central hasta el perímetro de la red.

Hacer que el código abierto sea más inclusivo

Red Hat se compromete a reemplazar el lenguaje problemático en nuestro código, documentación y propiedades web. Para más detalles, consulte el Blog de Red Hat.

Acerca de la documentación de Red Hat

Ayudamos a los usuarios de Red Hat a innovar y alcanzar sus objetivos con nuestros productos y servicios con contenido en el que pueden confiar. Explore nuestras recientes actualizaciones.

Legal Notice

Theme

© 2026 Red HatVolver arriba