Dieser Inhalt ist in der von Ihnen ausgewählten Sprache nicht verfügbar.

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
Link kopieren

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 node 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.
If you need to configure the ingress controller to verify client certificates, you can use the ingress.clientTLS parameter to set a clientCA value, which is a reference to a config map. The config map contains the PEM-encoded CA certificate bundle that is used to verify a client’s certificate. Optionally, you can also configure a list of certificate subject filters.
If you need to configure a TLS security profile for an ingress controller, you can use the ingress.tlsSecurityProfile parameter to specify a default or custom individual TLS security profiles. The TLS security profile defines the minimum TLS version and the TLS ciphers for TLS connections for the ingress controllers. If a TLS security profile is not configured, the default value is based on the TLS security profile set for the API server.
If you need to define a policy for handling new route claims, you can use the routeAdmission parameter to allow or deny claims across namespaces. You set the routeAdmission parameter to describe how hostname claims across namespaces should be handled and to describe how routes with wildcard policies are handled by the ingress controller.

5.2. Configuring ingress control in MicroShift
Link kopieren

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.

Important

A config.yaml configuration file takes precedence over built-in settings. The config.yaml file is read every time the MicroShift service starts.
Configuration snippet YAMLs take precedence over both built-in settings and the config.yaml configuration file.

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

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

Replace the default values in the ingress 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:
  certificateSecret: router-certs-custom
  clientTLS:
    allowedSubjectPatterns: []
    clientCA:
      name: ""
    clientCertificatePolicy: ""
  defaultHTTPVersion: 1
  forwardedHeaderPolicy: Append
  httpCompression:
    mimeTypes:
      - ""
  httpEmptyRequestsPolicy: Respond
  listenAddress: []
  logEmptyRequests: Log
  ports:
     http: 80
     https: 443
  routeAdmissionPolicy:
    namespaceOwnership: InterNamespaceAllowed
    wildcardPolicy: WildcardsDisallowed
  status: Managed
  tlsSecurityProfile:
    type:
    custom:
      ciphers:[]
      minTLSVersion:""
    intermediate: {}
    old: {}
  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.

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
Link kopieren

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
Parameter	Description
`ingress`	The `ingress` section of the MicroShift `config.yaml` file defines the configurable parameters for the implemented portions of the OpenShift Container Platform Ingress Control Operator. All parameters in the rest of this table are subsections in the `ingress` section of the `config.yaml`.
`certificateSecret`	A reference to a `kubernetes.io/tls` type of secret that contains the default certificate that is served by the MicroShift ingress controller. When routes do not specify their own certificate, the `certificateSecret` parameter is used. All secrets used must contain `tls.key` key file contents and `tls.crt` certificate file contents. When the `certificateSecret` parameter is not set, a wildcard certificate is automatically generated and used. The wildcard certificate is valid for the ingress controller default `domain` and its `subdomains`. The generated certificate authority (CA) is automatically integrated with the truststore of the node. In-use generated and user-specified certificates are automatically integrated with the MicroShift built-in OAuth server.
`clientTLS`	Authenticates client access to the node and services. As a result, mutual TLS authentication is enabled. If not set, then client TLS is not enabled. You must set the `spec.clientTLS.clientCertificatePolicy` and `spec.clientTLS.ClientCA` parameters to use client TLS.
`clientTLS.AllowedSubjectPatterns`	Optional subfield that specifies a list of regular expressions that are matched against the distinguished name on a valid client certificate to filter requests. Use this parameter to cause the ingress controller to reject certificates based on the distinguished name. The Perl Compatible Regular Expressions (PCRE) syntax is required. Important When configured, this field must contain a valid expression or the MicroShift service fails. At least one pattern must match a client certificate’s distinguished name; otherwise, the ingress controller rejects the certificate and denies the connection.
`clientTLS.clientCA`	Specifies a required config map that is in the `openshift-ingress` namespace. Required to enable client TLS. The config map must contain a certificate authority (CA) bundle named `ca-bundle.pem` or the deployment of the default router fails.
`clientTLS.ClientCA.name`	The `metadata.name` of the config map referenced in the `clientTLS.ClientCA` value.
`clientTLS.ClientCertificatePolicy`	`Required` or `Optional` are valid values. Set to `Required` to enable client TLS. The ingress controller only checks client certificates for edge-terminated and re-encrypted TLS routes. The ingress controller cannot check certificates for plain text HTTP or passthrough TLS routes.
`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. 'Append` is the default value. `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 MIME types to which compression should be applied. For example, `text/css; charset=utf-8`, `text/html`, `text/*`, `image/svg+xml`, `application/octet-stream`, `X-custom/customsub`, in the, `type/subtype; [;attribute=value]` format. Valid `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`. Empty requests typically come from load-balancer health probes or preconnects and can often be safely ignored. However, these requests can also be caused by network errors and port scans. Therefore, setting this field to `Ignore` can impede detection or diagnosis of network problems and detecting intrusion attempts. When the policy 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. When the policy is set to `Ignore`, the `http-ignore-probes` parameter is added to the `HAproxy` process configuration. After this parameter is added, the ingress controller closes the connection without sending a response, then either logs the connection or incrementing metrics.
`logEmptyRequests`	Specifies connections for which no request is received and logged. `Log` and `Ignore` are valid values. Empty requests typically come from load-balancer health probes or preconnects and can often be safely ignored. However, these requests can also be caused by network errors and port scans. Therefore, setting this field to `Ignore` can impede detection or diagnosis of network problems and detecting intrusion attempts. The default value is `Log`. Setting this value to `Log` indicates that an event should be logged. Setting this value to `Ignore` sets the `dontlognull` option in the `HAproxy` configuration.
`ports`	Defines default router ports.
`ports.http`	Default router http port. Must be in range 1-65535. Default value is `80`.
`ports.https`	Default router https port. Must be in range 1-65535. Default value is `443`.
`routeAdmission`	Defines a policy for handling new route claims, such as allowing or denying claims across namespaces.
`routeAdmission.namespaceOwnership`	Describes how hostname claims across namespaces should be handled. The default is `InterNamespaceAllowed`. The following are valid values: `Strict` does not allow routes to claim the same hostname across namespaces. `InterNamespaceAllowed` allows routes to claim different paths of the same hostname across namespaces.
`routeAdmission.wildcardPolicy`	Controls how routes with configured wildcard policies are handled by the ingress controller. `WildcardsAllowed` and `WildcardsDisallowed` are valid values. Default value is `WildcardsDisallowed`. `WildcardPolicyAllowed` means that routes with any wildcard policy are admitted by the ingress controller. `WildcardPolicyDisallowed` means that only routes with a wildcard policy of `None` are admitted by the ingress controller. Important Changing the wildcard policy from `WildcardsAllowed` to `WildcardsDisallowed` causes admitted routes with a wildcard policy of `subdomain` to stop working. These routes must be recreated to a wildcard policy of `None` to be readmitted by the ingress controller.
`status`	Default router status. `Managed` or `Removed` are valid values.
`tlsSecurityProfile`	`tlsSecurityProfile` specifies settings for TLS connections for ingress controllers. If not set, the default value is based on the `apiservers.config.openshift.io/cluster` resource. The TLS `1.0` version of an `Old` or `Custom` profile is automatically converted to `1.1` by the ingress controller. `Intermediate` is the default setting. The minimum TLS version for ingress controllers is `1.1`. The maximum TLS version is `1.3`. Note Ciphers and the minimum TLS version of the configured security profile are reflected in the `TLSProfile` status. Profiles are intent-based and change over time when new ciphers are developed and existing ciphers are found to be insecure. The usable list can be reduced depending on which ciphers are available to a specific process.
`tlsSecurityProfile.custom`	User-defined TLS security profile. If you configure this parameter and related parameters, use extreme caution.
`tlsSecurityProfile.custom.ciphers`	Specifies the cipher algorithms that are negotiated during the TLS handshake. Operators might remove entries their operands do not support.
`tlsSecurityProfile.custom.minTLSVersion`	Specifies 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, set the value to `VersionTLS11`. The highest valid value for `minTLSVersion` is `VersionTLS12`.
`tlsSecurityProfile.intermediate`	This TLS profile can be used for a majority of services. Intermediate compatibility (recommended).
`tlsSecurityProfile.old`	Used for backward compatibility. Old backward compatibility.
`tlsSecurityProfile.type`	Valid values are `Intermediate`, `Old`, or `Custom`. The `Modern` value is not supported.
`tuningOptions`	Specifies options for tuning the performance of ingress controller pods.
`tuningOptions.clientFinTimeout`	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`.
`tuningOptions.clientTimeout`	Specifies how long a connection is held open while waiting for a client response. The default timeout is `30s`.
`tuningOptions.headerBufferBytes`	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.
`tuningOptions.headerBufferMaxRewriteBytes`	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`. `headerBufferBytes` 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` values that are too small can break the ingress controller and `headerBufferMaxRewriteBytes` that are too large could cause the ingress controller to use significantly more memory than necessary.
`tuningOptions.healthCheckInterval`	Specifies how long the router waits between health checks, set in seconds. The default is `5s`.
`tuningOptions.maxConnections`	Specifies the maximum number of simultaneous connections that can be established for each `HAProxy` process. Increasing this value allows each ingress controller pod to handle more connections at the cost of additional system resources. Permitted values are `0`, `-1`, any value within the range `2000` and `2000000`, or the field can be left empty. If this field is left empty or has the value `0`, the ingress controller uses the default value of `50000`. If the field has the value of `-1`, then the `HAProxy` process dynamically computes a maximum value based on the available `ulimits` in the running container. This process results in a large computed value that incurs significant memory usage compared to the current default value of `50000`. If the field has a value that is greater than the current operating system limit, the `HAProxy` processes do not start. If you choose a discrete value and the router pod is migrated to a new node, it is possible that the new node does not have an identical `ulimit` configured. In such cases, the pod fails to start. If you have nodes with different `ulimits` configured, and you choose a discrete value, you can use the value of `-1` for this field so that the maximum number of connections is calculated at runtime. You can monitor memory usage for router containers with the `container_memory_working_set_bytes{container="router",namespace="openshift-ingress"}` metric. You can monitor memory usage of individual `HAProxy` processes in router containers with the `container_memory_working_set_bytes{container="router",namespace="openshift-ingress"}/container_processes{container="router",namespace="openshift-ingress"}` metric.
`tuningOptions.serverFinTimeout`	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`.
`tuningOptions.serverTimeout`	Specifies how long a connection is held open while waiting for a server response. The default timeout is `30s`.
`tuningOptions.threadCount`	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. The `HAProxy` load balancer supports up to `64` threads. If this field is empty, the ingress controller uses the default value of `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. Reducing the number of threads can cause the ingress controller to perform poorly.
`tuningOptions.tlsInspectDelay`	Specifies how long the router can hold data to find a matching route. Setting this value too low 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`.
`tuningOptions.tunnelTimeout`	Specifies how long a tunnel connection, including websockets, remains open while the tunnel is idle. The default timeout is `1h`.

5.2.2. Creating a secret for the ingress controller certificateSecret
Link kopieren

To serve a custom default certificate through the ingress controller in MicroShift, you can create a TLS secret containing your certificate chain and private key, then set the certificateSecret value in the configuration file to that secret name.

Note

Any in-use certificates is automatically integrated with the MicroShift built-in OAuth server.

Prerequisites

You have root access to MicroShift.
You installed the OpenShift CLI (oc).
Your private key is not encrypted or you have decrypted it for importing into MicroShift.

Procedure

Create a secret that contains the wildcard certificate chain and key:
```
$ oc create secret tls <secret> \
     --cert=</path/to/cert.crt> \
     --key=</path/to/cert.key> \
     -n openshift-ingress
```
- Replace <secret> with the name of the secret that contains the certificate chain and private key.
- Replace </path/to/cert.crt> with the path to the certificate chain on your local file system.
- Replace </path/to/cert.key> with the path to the private key associated with this certificate.
  Important
  The certificate must include the subjectAltName extension showing *.apps.<nodename>.<domain>.
Update the certificateSecret parameter value in the MicroShift configuration YAML with the newly created secret.
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
```

5.2.3. Configuring the TLS security profile for the ingress controller
Link kopieren

To configure the TLS security profile for the ingress controller in MicroShift, you can add the spec.tlsSecurityProfile field to the configuration YAML and set a value for the appropriate profile. To apply the changes, restart the service.

Prerequisites

You have root access to the MicroShift node.

Procedure

Add the spec.tlsSecurityProfile field to the MicroShift YAML configuration file.
```
 ...
spec:
  tlsSecurityProfile:
    type: Custom
    custom:
      ciphers:
      - ECDHE-ECDSA-CHACHA20-POLY1305
      - ECDHE-RSA-CHACHA20-POLY1305
      - ECDHE-RSA-AES128-GCM-SHA256
      - ECDHE-ECDSA-AES128-GCM-SHA256
      minTLSVersion: VersionTLS11
 ...
```
where:
spec.tlsSecurityProfile.type
Specifies the TLS security profile type (Old, Intermediate, or Custom). The default is Intermediate.
spec.tlsSecurityProfile.custom
Specifies the appropriate field for the selected type:
old: {}
intermediate: {}
custom:
spec.tlsSecurityProfile.custom.ciphers
Specifies a list of TLS ciphers and minimum accepted TLS version.
Warning
If you choose a custom TLS configuration, use extreme caution. Using self-signed TLS certificates can introduce security risks.
Save the file to apply the changes.
Restart MicroShift by running the following command:
```
$ sudo systemctl restart microshift
```

Dieser Inhalt ist in der von Ihnen ausgewählten Sprache nicht verfügbar.

Chapter 5. Using ingress control for a MicroShift node

5.1. Using ingress control in MicroShift
Link kopieren

5.2. Configuring ingress control in MicroShift
Link kopieren

5.2.1. Ingress controller configuration fields in MicroShift
Link kopieren

5.2.2. Creating a secret for the ingress controller certificateSecret
Link kopieren

5.2.3. Configuring the TLS security profile for the ingress controller
Link kopieren

Lernen

Testen, kaufen und verkaufen

Communitys

Über Red Hat Dokumentation

Mehr Inklusion in Open Source

Über Red Hat

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

Dieser Inhalt ist in der von Ihnen ausgewählten Sprache nicht verfügbar.

Chapter 5. Using ingress control for a MicroShift node

5.1. Using ingress control in MicroShiftLink kopierenLink in die Zwischenablage kopiert!

5.2. Configuring ingress control in MicroShiftLink kopierenLink in die Zwischenablage kopiert!

5.2.1. Ingress controller configuration fields in MicroShiftLink kopierenLink in die Zwischenablage kopiert!

5.2.2. Creating a secret for the ingress controller certificateSecretLink kopierenLink in die Zwischenablage kopiert!

5.2.3. Configuring the TLS security profile for the ingress controllerLink kopierenLink in die Zwischenablage kopiert!

Lernen

Testen, kaufen und verkaufen

Communitys

Über Red Hat Dokumentation

Mehr Inklusion in Open Source

Über Red Hat

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

5.1. Using ingress control in MicroShift
Link kopieren

5.2. Configuring ingress control in MicroShift
Link kopieren

5.2.1. Ingress controller configuration fields in MicroShift
Link kopieren

5.2.2. Creating a secret for the ingress controller certificateSecret
Link kopieren

5.2.3. Configuring the TLS security profile for the ingress controller
Link kopieren