Configuring

Procedure

1. If you have not done so, make a copy of the provided config.yaml.default file in the /etc/microshift/ directory, renaming it config.yaml.

2. Keep the new MicroShift config.yaml in the /etc/microshift/ directory. Your config.yaml file is read every time the MicroShift service starts.

   Note

   After you create it, the config.yaml file takes precedence over built-in settings.

3. Replace the default values in the network section of the MicroShift YAML with your valid values.

   Example single-stack IPv6 networking configuration

   apiServer:
   # ...
   network:
     clusterNetwork:
     - fd01::/48 

   1

   
     serviceNetwork:
     - fd02::/112 

   2

   
   node:
     nodeIP: 2600:1f14:1c48:ee00:2d76:3190:5bc2:5aef 

   3

   
   # ...

   Copy to Clipboard Toggle word wrap

   1

   Specify a clusterNetwork with a CIDR value that is less than 64.

   2

   Specify an IPv6 CIDR with a prefix of 112. Kubernetes uses only the lowest 16 bits. For a prefix of 112, IP addresses are assigned from 112 to 128 bits.

   3

   Example node IP address. Valid values are IP addresses in the IPv6 address family. You must only specify an IPv6 address when an IPv4 network is also present. If an IPv4 network is not present, the MicroShift service automatically fills in this value upon restart.

4. Complete any other configurations you require, then start MicroShift by running the following command:

   $ sudo systemctl start microshift

   Copy to Clipboard Toggle word wrap

Verification

1. Retrieve the networks defined in the node resource by running the following command:

   $ oc get node -o jsonpath='{.items[].spec.podCIDRs[]}'

   Copy to Clipboard Toggle word wrap

   Example output

   fd01::/48

   Copy to Clipboard Toggle word wrap

2. Retrieve the status of the pods by running the following command:

   $ oc get pod -A -o wide

   Copy to Clipboard Toggle word wrap

   Example output

   NAMESPACE                  NAME                                      READY   STATUS    RESTARTS   AGE   IP                      NODE           NOMINATED NODE   READINESS GATES
   kube-system                csi-snapshot-controller-bb7cb654b-rqrt6   1/1     Running   0          65s   fd01:0:0:1::5           microshift-9   <none>           <none>
   openshift-dns              dns-default-cjn66                         2/2     Running   0          62s   fd01:0:0:1::9           microshift-9   <none>           <none>
   openshift-dns              node-resolver-ppnjb                       1/1     Running   0          63s   2001:db9:ca7:ff::1db8   microshift-9   <none>           <none>
   openshift-ingress          router-default-6d97d7b8b6-wdtmg           1/1     Running   0          61s   fd01:0:0:1::8           microshift-9   <none>           <none>
   openshift-ovn-kubernetes   ovnkube-master-gfvp5                      4/4     Running   0          63s   2001:db9:ca7:ff::1db8   microshift-9   <none>           <none>
   openshift-ovn-kubernetes   ovnkube-node-bnpjh                        1/1     Running   0          63s   2001:db9:ca7:ff::1db8   microshift-9   <none>           <none>
   openshift-service-ca       service-ca-5d7bd9db6-j25bd                1/1     Running   0          60s   fd01:0:0:1::4           microshift-9   <none>           <none>
   openshift-storage          lvms-operator-656cd9b59b-bwr47            1/1     Running   0          63s   fd01:0:0:1::7           microshift-9   <none>           <none>
   openshift-storage          vg-manager-f7dmk                          1/1     Running   0          27s   fd01:0:0:1::a           microshift-9   <none>           <none>

   Copy to Clipboard Toggle word wrap

3. Retrieve the status of services by running the following command:

   $ oc get svc -A

   Copy to Clipboard Toggle word wrap

   Example output

   NAMESPACE           NAME                            TYPE           CLUSTER-IP   EXTERNAL-IP                                             PORT(S)                      AGE
   default             kubernetes                      ClusterIP      fd02::1      <none>                                                  443/TCP                      3m42s
   openshift-dns       dns-default                     ClusterIP      fd02::a      <none>                                                  53/UDP,53/TCP,9154/TCP       2m58s
   openshift-ingress   router-default                  LoadBalancer   fd02::f2e6   2001:db9:ca7:ff::1db8,fd01:0:0:1::2,fd02::1:0,fd69::2   80:31133/TCP,443:31996/TCP   2m58s
   openshift-ingress   router-internal-default         ClusterIP      fd02::c55e   <none>                                                  80/TCP,443/TCP,1936/TCP      2m58s
   openshift-storage   lvms-operator-metrics-service   ClusterIP      fd02::7afb   <none>                                                  443/TCP                      2m58s
   openshift-storage   lvms-webhook-service            ClusterIP      fd02::d8dd   <none>                                                  443/TCP                      2m58s
   openshift-storage   vg-manager-metrics-service      ClusterIP      fd02::fc1    <none>                                                  443/TCP                      2m58s

   Copy to Clipboard Toggle word wrap

Procedure

1. If you have not done so, make a copy of the provided config.yaml.default file in the /etc/microshift/ directory, renaming it config.yaml.

2. Keep the new MicroShift config.yaml in the /etc/microshift/ directory. Your config.yaml file is read every time the MicroShift service starts.

   Note

   After you create it, the config.yaml file takes precedence over built-in settings.

3. If you have not started MicroShift, replace the default values in the network section of the MicroShift YAML with your valid values.

   Example dual-stack IPv6 networking configuration with network assignments

   apiServer:
   # ...
   apiServer:
     subjectAltNames:
     - 192.168.113.117
     - 2001:db9:ca7:ff::1db8
   network:
     clusterNetwork:
     - 10.42.0.0/16
     - fd01::/48 

   1

   
     serviceNetwork:
     - 10.43.0.0/16
     - fd02::/112 

   2

   
   node:
     nodeIP: 192.168.113.117 

   3

   
     nodeIPv6: 2001:db9:ca7:ff::1db8 

   4

   
   # ...

   Copy to Clipboard Toggle word wrap

   1

   Specify an IPv6 clusterNetwork with a CIDR value that is less than 64.

   2

   Specify an IPv6 CIDR with a prefix of 112. Kubernetes uses only the lowest 16 bits. For a prefix of 112, IP addresses are assigned from 112 to 128 bits.

   3

   Example node IP address. Must be an IPv4 address family.

   4

   Example node IP address for dual-stack configuration. Must be an IPv6 address family. Configurable only with dual-stack networking.

4. Complete any other MicroShift configurations you require, then start MicroShift by running the following command:

   $ sudo systemctl start microshift

   Copy to Clipboard Toggle word wrap
5. Reset the IP family policy for application pods and services as needed, then restart those application pods and services to enable dual-stack networking. See "Resetting the IP family policy for application pods and services" for a simple example.

Verification

1. You can verify that all of the system services and pods to have two IP addresses, one for each family, by using the following steps:

   1. Retrieve the networks defined in the node resource by running the following command:

      $ oc get pod -n openshift-ingress router-default-5b75594b4-w7w6s -o jsonpath='{.status.podIPs}'

      Copy to Clipboard Toggle word wrap

      Example output

      [{"ip":"10.42.0.4"},{"ip":"fd01:0:0:1::4"}]

      Copy to Clipboard Toggle word wrap

   2. Retrieve the networks defined by the host network pods by running the following command:

      $ oc get pod -n openshift-ovn-kubernetes ovnkube-master-2fm2k -o jsonpath='{.status.podIPs}'

      Copy to Clipboard Toggle word wrap

      Example output

      [{"ip":"192.168.113.117"},{"ip":"2001:db9:ca7:ff::1db8"}]

      Copy to Clipboard Toggle word wrap

Procedure

1. If you have not done so, make a copy of the provided config.yaml.default file in the /etc/microshift/ directory, renaming it config.yaml.

2. Keep the new MicroShift config.yaml in the /etc/microshift/ directory. Your config.yaml file is read every time the MicroShift service starts.

   Note

   After you create it, the config.yaml file takes precedence over built-in settings.

3. Add IPv6 configurations to the network section of the MicroShift YAML with your valid values:

   Warning

   You must keep the same first entry across restarts and migrations. This is true for any migration: single-to-dual stack, or dual-to-single stack. A complete wipe of the etcd database is required if a change to the first entry is needed. This might result in application data loss and is not supported.

   1. Add an IPv6 configuration for a second network in the network section of the MicroShift YAML with your valid values.

   2. Add network assignments to the network section of the MicroShift config.yaml to enable dual stack with IPv6 as secondary network.

      Example dual-stack IPv6 configuration with network assignments

      # ...
      apiServer:
        subjectAltNames:
        - 192.168.113.117
        - 2001:db9:ca7:ff::1db8 

      1

      
      network:
        clusterNetwork:
        - 10.42.0.0/16 

      2

      
        - fd01::/48 

      3

      
        serviceNetwork:
        - 10.43.0.0/16
        - fd02::/112 

      4

      
      node:
        nodeIP: 192.168.113.117 

      5

      
        nodeIPv6: 2001:db9:ca7:ff::1db8 

      6

      
      # ...

      Copy to Clipboard Toggle word wrap

      1

      The IPv6 node address.

      2

      IPv4 network. Specify a clusterNetwork with a CIDR value that is less than 24.

      3

      IPv6 network. Specify a clusterNetwork with a CIDR value that is less than 64.

      4

      Specify an IPv6 CIDR with a prefix of 112. Kubernetes uses only the lowest 16 bits. For a prefix of 112, IP addresses are assigned from 112 to 128 bits.

      5

      Example node IP address. Maintain the previous IPv4 IP address.

      6

      Example node IP address. Must be an IPv6 address family.

4. Complete any other configurations you require, then restart MicroShift by running the following command:

   $ sudo systemctl restart microshift

   Copy to Clipboard Toggle word wrap
5. Reset the IP family policy for application pods and services as needed, then restart those application pods and services to enable dual-stack networking. See "Resetting the IP family policy for application pods and services" for a simple example.

1. Retrieve the status of the pods by running the following command:

   $ oc get pod -A -o wide

   Copy to Clipboard Toggle word wrap

   Example output

   NAMESPACE                  NAME                                      READY   STATUS    RESTARTS        AGE     IP                NODE           NOMINATED NODE   READINESS GATES
   kube-system                csi-snapshot-controller-bb7cb654b-7s5ql   1/1     Running   0               46m     10.42.0.6         microshift-9   <none>           <none>
   openshift-dns              dns-default-zxkqn                         2/2     Running   0               46m     10.42.0.5         microshift-9   <none>           <none>
   openshift-dns              node-resolver-r2h5z                       1/1     Running   0               46m     192.168.113.117   microshift-9   <none>           <none>
   openshift-ingress          router-default-5b75594b4-228z7            1/1     Running   0               2m5s    10.42.0.3         microshift-9   <none>           <none>
   openshift-ovn-kubernetes   ovnkube-master-bltk7                      4/4     Running   2 (2m32s ago)   2m36s   192.168.113.117   microshift-9   <none>           <none>
   openshift-ovn-kubernetes   ovnkube-node-9ghgs                        1/1     Running   2 (2m32s ago)   46m     192.168.113.117   microshift-9   <none>           <none>
   openshift-service-ca       service-ca-5d7bd9db6-qgwgw                1/1     Running   0               46m     10.42.0.7         microshift-9   <none>           <none>
   openshift-storage          lvms-operator-656cd9b59b-8rpf4            1/1     Running   0               46m     10.42.0.8         microshift-9   <none>           <none>
   openshift-storage          vg-manager-wqmh4                          1/1     Running   2 (2m39s ago)   46m     10.42.0.10        microshift-9   <none>           <none>

   Copy to Clipboard Toggle word wrap

2. Retrieve the networks defined by the OVN-K network plugin by running the following command:

   $ oc get pod -n openshift-ovn-kubernetes ovnkube-master-bltk7 -o jsonpath='{.status.podIPs}'

   Copy to Clipboard Toggle word wrap

   Example output

   [{"ip":"192.168.113.117"},{"ip":"2001:db9:ca7:ff::1db8"}]

   Copy to Clipboard Toggle word wrap

3. Retrieve the networks defined in the node resource by running the following command:

   $ oc get pod -n openshift-ingress router-default-5b75594b4-228z7 -o jsonpath='{.status.podIPs}'

   Copy to Clipboard Toggle word wrap

   Example output

   [{"ip":"10.42.0.3"},{"ip":"fd01:0:0:1::3"}]

   Copy to Clipboard Toggle word wrap

   Note

   To return to single-stack networking, you can remove the second entry to the networks and return to the single stack that was configured before migrating to dual-stack.

Procedure

1. Set the spec.ipFamilyPolicy field to a valid value for dual-stack networking in your service or pod by using the following example:

   Example dual-stack network configuration for a service

   kind: Service
   apiVersion: v1
   metadata:
     name: microshift-new-service
     labels: app: microshift-application
   spec:
     type: NodePort
     ipFamilyPolicy: `PreferDualStack` 

   1

   
   # ...

   Copy to Clipboard Toggle word wrap

   1

   Required. Valid values for dual-stack networking are PreferDualStack and RequireDualStack. The value you set depends on the requirements of your application. PreferSingleStack is the default value for the ipFamilyPolicy field.

2. Restart any application pods that do not have a hostNetwork defined. Pods that do have a hostNetwork defined do not need to be restarted to update the ipFamilyPolicy value.

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

2. 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:
     accessLogging:
       destination:
         container:
           maxLength: 1024
         syslog:
           address: ""
           facility: ""
           maxLength: 1024
           port: 0
         type: ""
       httpCaptureCookies:
         - matchType: ""
           maxLength: 0
           name: ""
           namePrefix: ""
       httpCaptureHeaders:
         request:
           - maxLength: 0
             name: ""
         response:
           - maxLength: 0
             name: ""
       httpLogFormat: ""
       status: Disabled
     certificateSecret: router-certs-custom
     clientTLS:
       allowedSubjectPatterns: []
       clientCA:
         name: ""
       clientCertificatePolicy: ""
     defaultHTTPVersion: 1
     forwardedHeaderPolicy: Append
     httpCompression:
       mimeTypes:
         - ""
     httpEmptyRequestsPolicy: Respond
     httpErrorCodePages:
         name: ""
     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
   # ...

   Copy to Clipboard Toggle word wrap

   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 implementation of the OpenShift Container Platform IngressController API. All of the following parameters in this table are subsections in the ingress section of the MicroShift config.yaml.
   accessLogging	This ingress subsection describes how client requests are logged. If the status field is empty, access logging is disabled. When the status field is set to Enabled, access requests are logged as configured with the accessLogging parameters and the accessLogging.destination.type is automatically set to Container. When enabled, access logging is part of the openshift-router logs. The sos report procedure for MicroShift captures logs from this pod.
   accessLogging.destination	A destination for logs. The destination for logs can be a local sidecar container or remote. Default value is null.
   accessLogging.destination.type	The type of destination for logs. Valid values are Container or Syslog. Setting this value to Container specifies that logs should go to a sidecar container. When the destination type is set to Container, a container called logs is automatically created. Using container logs means that logs might be dropped if the rate of logs exceeds the container runtime capacity or the custom logging solution capacity. You must have a custom logging solution that reads logs from this sidecar. Setting this value to Syslog specifies that logs are sent to a Syslog endpoint. You must configure a custom Syslog instance and specify an endpoint that can receive Syslog messages. You must have a custom Syslog instance. For example, Getting started with kernel logging.
   accessLogging.destination.container	Describes parameters for the Container logging destination type. You must configure a custom logging solution that reads logs from this sidecar.
   accessLogging.destination.container.maxLength	Optional configuration. The default value is 1024 bytes. Message length must be at least 480 and not greater than 8192 bytes.
   accessLogging.destination.syslog	Describes parameters for the Syslog logging destination type. You must configure a custom Syslog instance with an endpoint that can receive Syslog messages.
   accessLogging.destination.syslog.address	Required configuration when the Syslog destination type is set. Valid value is the IP address of the syslog endpoint that receives log messages.
   accessLogging.destination.syslog.facility	Optional configuration when the Syslog destination type is set. Specifies the syslog facility of log messages. If this field is empty, the facility is local1. Otherwise, the field must specify one of the following valid syslog facilities: kern, user, mail, daemon, auth, syslog, lpr, news, uucp, cron, auth2`, ftp, ntp, audit, alert, cron2, local0, local1, local2, local3, local4, local5, local6, or local7.
   accessLogging.destination.syslog.maxLength	Optional configuration when the Syslog destination type is set. The maximum length of the Syslog message. Message length must be at least 480 and not greater than 4096 bytes. If this field is empty, the maximum length is set to the default value of 1024 bytes.
   accessLogging.destination.syslog.port	Required configuration when the Syslog destination type is set. The UDP port number of the syslog endpoint that receives log messages. The default value is 0.
   httpCaptureCookies	Specifies HTTP cookies that you want to capture in access logs. If the httpCaptureCookies field is empty, access logs do not capture the cookies. Default value is empty. Configuring ingress.accessLogging.httpCaptureCookies automatically enables ingress access logging. For any cookie that you want to capture, you must also set the matchType and maxLength parameters. For example: httpCaptureCookies: - matchType: Exact maxLength: 128 name: MYCOOKIE Copy to Clipboard Toggle word wrap
   httpCaptureCookies.matchType	Specifies whether the field name of the cookie exactly matches the capture cookie setting or is a prefix of the capture cookie setting. Valid values are Exact for an exact string match and Prefix for a string prefix match. If you use the Exact setting, you must also specify a name in the httpCaptureCookies.name field. If you use the Prefix setting, you must also specify a prefix in the httpCaptureCookies.namePrefix field. For example, the settings of matchType: Prefix when the namePrefix is "mush" captures a cookie named "mush" or "mushroom" but not one named "room". The first matching cookie is captured.
   httpCaptureCookies.maxLength	Specifies the maximum length of the cookie that is logged, which includes the cookie name, cookie value, and one-character delimiter. If the log entry exceeds this length, the value is truncated in the log message. The ingress controller might impose a separate bound on the total length of HTTP headers in a request. The minimum value is 1 byte, maximum value is 1024 bytes. The default value is 0.
   httpCaptureCookies.name	Specifies the exact name used for a cookie name match as set in the httpCaptureCookies.matchType parameter. The value must be a valid HTTP cookie name as defined in RFC 6265 section 4.1. The minimum length is 1 byte and the maximum length is 1024 bytes.
   httpCaptureCookies.namePrefix	Specifies the prefix for a cookie name match as set in the httpCaptureCookies.matchType parameter. The value must be a valid HTTP cookie name as defined in RFC 6265 section 4.1. The minimum length is 1 byte and the maximum length is 1024 bytes.
   httpCaptureHeaders	Defines the HTTP headers that should be captured in the access logs. This field is a list and allows capturing request and response headers independently. When this field is empty, headers are not captured. This option only applies to plain text HTTP connections and to secure HTTP connections for which the ingress controller terminates encryption: for example, edge-terminated or reencrypt connections. Headers cannot be captured for TLS passthrough connections. Configuring the ingress.accessLogging.httpCaptureHeaders parameter automatically enables ingress access logging.
   httpCaptureHeaders.request	Specifies which HTTP request headers to capture. When this field is empty, no request headers are captured.
   httpCaptureHeaders.request.maxLength	Specifies a maximum length for the header value. When a header value exceeds this length, the value is truncated in the log message. The minimum required value is 1 byte. The ingress controller might impose a separate bound on the total length of HTTP headers in a request.
   httpCaptureHeaders.request.name	Specifies a header name. The value must be a valid HTTP header name as defined in RFC 2616 section 4.2. If you configure this value, you must specify maxLength and name values.
   httpCaptureHeaders.response	Specifies which HTTP response headers to capture. If this field is empty, no response headers are captured.
   httpCaptureHeaders.response.maxLength	Specifies a maximum length for the header value. If a header value exceeds this length, the value is truncated in the log message. The ingress controller might impose a separate bound on the total length of HTTP headers in a request.
   httpCaptureHeaders.response.name	Specifies a header name. The value must be a valid HTTP header name as defined in RFC 2616 section 4.2.
   httpLogFormat	Specifies the format of the log message for an HTTP request. If this field is empty, log messages use the default HTTP log format. For HAProxy default HTTP log format, see the HAProxy documentation.
   status	Specifies whether access is logged or not. Valid values are Enabled and Disabled. Default value is Disabled. When you configure either ingress.accessLogging.httpCaptureHeaders or ingress.accessLogging.httpCaptureCookies, you must set ingress.accessLogging.status to Enabled. When you set the ingress.status field to Enabled, the accessLogging.destination.type is automatically set to Container and the router logs all requests in the logs container. If you set this value to Disabled, the router does not log any requests in the access log.
   certificateSecret	A reference to a kubernetes.io/tls type of secret that contains the default certificate that the MicroShift ingress controller serves. 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 this parameter is 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. This parameter is useful when you have client authentication. 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. You must set the spec.clientTLS.clientCertificatePolicy and spec.clientTLS.clientCA parameters to use clientTLS.AllowedSubjectPatterns. 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. The default value is 1 for HTTP 1.1. Setting up a load balancer for HTTP 2 and 3 is recommended.
   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, network errors and port scans can also cause these requests. 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, network errors and port scans can also cause these requests. 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.
   httpErrorCodePages	Describes custom error code pages. To use this setting, you must configure the httpErrorCodePages.name parameter.
   httpErrorCodePages.name	Specifies custom error code pages. You can only customize errors for 503 and 404 page codes. To customize error code pages, specify a ConfigMap name. The ConfigMap object must be in the openshift-ingress namespace and contain keys in the error-page-<error code>.http format where <error code> is an HTTP status code. Each value in the ConfigMap must be the full response, including HTTP headers. The default value of this parameter is null.
   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 are 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 the ingress controller handles routes with configured wildcard policies. WildcardsAllowed and WildcardsDisallowed are valid values. Default value is WildcardsDisallowed. WildcardPolicyAllowed means that the ingress controller admits routes with any wildcard policy. WildcardPolicyDisallowed means that the ingress controller admits only routes with a wildcard policy of None. Important Changing the wildcard policy from WildcardsAllowed to WildcardsDisallowed causes admitted routes with a wildcard policy of subdomain to stop working. The ingress controller only readmits these routes after they are recreated with a wildcard policy of None.
   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 The TLSProfile status shows the ciphers and the minimum TLS version of the configured security profile. 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	You can use this TLS profile 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 the ingress controller holds a connection open while waiting for a client response before the server closes the connection. The default timeout is 1s.
   tuningOptions.clientTimeout	Specifies how long the ingress controller holds a connection 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 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. 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 using more system resources. 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.

   Show more

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

   $ sudo systemctl start microshift

   Copy to Clipboard Toggle word wrap

   $ sudo systemctl restart microshift

   Copy to Clipboard Toggle word wrap

Procedure

1. Disable installation of the CSI snapshot controller by entering the optionalCsiComponents value under the storage section of the MicroShift configuration file in /etc/microshift/config.yaml:

   # ...
     storage: {} 

   1

   
   # ...

   Copy to Clipboard Toggle word wrap

   1

   Accepted values are:

   • Not defining optionalCsiComponents.
   • Specifying optionalCsiComponents field with an empty value ([]) or a single empty string element ([""]).

   • Specifying optionalCsiComponents with one of the accepted values which are snapshot-controller, or none. A value of none is mutually exclusive with all other values.

     Note

     If the optionalCsiComponents value is empty or null, MicroShift defaults to deploying snapshot-controller.

2. After the optionalCsiComponents field is specified with a supported value in the config.yaml, start MicroShift by running the following command:

   $ sudo systemctl start microshift

   Copy to Clipboard Toggle word wrap
   Note

   MicroShift does not redeploy the disabled components after a restart.

Procedure

1. Disable installation of the CSI driver by entering the driver value under the storage section of the MicroShift configuration file in /etc/microshift/config.yaml:

   # ...
     storage
      driver:
      - "none" 

   1

   
   # ...

   Copy to Clipboard Toggle word wrap

   1

   Valid values are none or lvms.

   Note

   By default, the driver value is empty or null and LVMS is deployed.

2. Start MicroShift after the driver field is specified with a supported value in the /etc/microshift/config.yaml file by running the following command:

   $ sudo systemctl enable --now microshift

   Copy to Clipboard Toggle word wrap
   Note

   MicroShift does not redeploy the disabled components after a restart operation.

Procedure

1. Optional: You can show the contents of the config.yaml. Run the following command:

   $ cat /etc/microshift/config.yaml

   Copy to Clipboard Toggle word wrap

2. Optional: You can show the contents of the remote-access kubeconfig file. Run the following command:

   $ cat /var/lib/microshift/resources/kubeadmin/<hostname>/kubeconfig

   Copy to Clipboard Toggle word wrap
   Important

   Additional remote access kubeconfig files must include one of the server names listed in the Red Hat build of MicroShift config.yaml file. Additional kubeconfig files must also use the same CA for validation.

3. To generate additional kubeconfig files for additional DNS names SANs or external IP addresses, add the entries you need to the apiServer.subjectAltNames field. In the following example, the DNS name used is alt-name-1 and the IP address is 1.2.3.4.

   Example config.yaml with additional authentication values

   dns:
     baseDomain: example.com
   node:
     hostnameOverride: "microshift-rhel9" 

   1

   
     nodeIP: 10.0.0.1
   apiServer:
     subjectAltNames:
     - alt-name-1 

   2

   
     - 1.2.3.4 

   3

   Copy to Clipboard Toggle word wrap

   1

   Hostname

   2

   DNS name

   3

   IP address or range

4. Restart MicroShift to apply configuration changes and auto-generate the kubeconfig files you need by running the following command:

   $ sudo systemctl restart microshift

   Copy to Clipboard Toggle word wrap

5. To check the contents of additional remote-access kubeconfig files, insert the name or IP address as listed in the config.yaml into the cat command. For example, alt-name-1 is used in the following example command:

   $ cat /var/lib/microshift/resources/kubeadmin/alt-name-1/kubeconfig

   Copy to Clipboard Toggle word wrap

6. Choose the kubeconfig file to use that contains the SAN or IP address you want to use to connect your node. In this example, the kubeconfig containing`alt-name-1` in the cluster.server field is the correct file.

   Example contents of an additional kubeconfig file

   clusters:
   - cluster:
       certificate-authority-data: <base64 CA>
       server: https://alt-name-1:6443 

   1

   Copy to Clipboard Toggle word wrap

   1

   The /var/lib/microshift/resources/kubeadmin/alt-name-1/kubeconfig file values are from the apiServer.subjectAltNames configuration values.

Procedure

1. From your CLI using sudo privileges, open /etc/microshift/config.yaml in a text editor.
2. Locate the genericDevicePlugin section. If it is not present, add it.

3. Set the status parameter to Enabled and define the devices that should be exposed. Each device definition needs a name and one or more groups. Each group can specify devices using paths, for file-based devices, including glob patterns, or usbs, for USB devices using Vendor/Product IDs. You cannot mix paths and usbs within the same device group.

   GDP fields with default values

   apiServer:
   # ...
   genericDevicePlugin:
     devices:
     - groups:
       - paths:
         - path: /dev/ttyUSB* 

   1

   
         - path: /dev/ttyACM* 

   2

   
       name: serial
     - groups:
       - paths:
         - path: /dev/fuse 

   3

   
       name: fuse 

   4

   
     - groups:
       - usbs: 

   5

   
         - product: "0x7523" 

   6

   
           serial: ""
           vendor: "0x1a86" 

   7

   
       name: converter
     domain: device.microshift.io 

   8

   
     status: Enabled

   Copy to Clipboard Toggle word wrap

   1

   Exposes all the USB serial devices that are matched by this glob.

   2

   Exposes all the ACM serial devices that are matched by this glob.

   3

   For example, the file path for a fuse device.

   4

   For example, the name of the device.

   5

   Exposes a specific USB device by Vendor ID and Product ID.

   6

   For example, the Product ID for a CH340 serial converter

   7

   For example, the Vendor ID for a CH340 serial converter.

   8

   Default domain for the GDP.

   Important
   • The output of the microshift show-config parameter might include pre-configured default paths for serial devices even if you have not explicitly configured them in config.yaml. These paths represent the default discovery settings if the Generic Device Plugin is enabled without specific user configuration.
   • For consistency and precise device targeting, especially when dealing with multiple similar devices, consider using stable device paths like /dev/serial/by-id/ or specific USB Vendor, Product, or Serial IDs instead of broad glob patterns like /dev/ttyUSB*.
   • The count parameter in a device group allows a single device, or a set of devices matched by a glob, to be allocated multiple times concurrently to different pods. If omitted, count defaults to 1.
4. Save the config.yaml file.

5. Restart the MicroShift service to apply the changes:

   $ sudo systemctl restart microshift

   Copy to Clipboard Toggle word wrap

   Allow some time for MicroShift to restart and for the GDP to register its devices with the Kubelet.

Procedure

1. Define the device request in your Pod specification:

   apiVersion: v1
   kind: Pod
   metadata:
     name: device-app
   spec:
     containers:
     - name: container
       image: <your_application_image> 

   1

   
       command: ["/path/to/your/app"] 

   2

   
       args: ["--device_path=/dev/video0"] 

   3

   
       resources:
         limits: 

   4

   
           device.microshift.io/video: 1 

   5

   
       securityContext: 

   6

   
         allowPrivilegeEscalation: false
         capabilities:
           drop: ["ALL"]
         runAsNonRoot: true
         seccompProfile:
           type: "RuntimeDefault"

   Copy to Clipboard Toggle word wrap

   1

   Replace with your container image.

   2

   Replace with the command for your application.

   3

   For example, how your application might use the device.

   4

   The resource name must follow the pattern device.microshift.io/<device_name>, where <device_name> matches the name that you specified in your configuration file.

   5

   A request for one instance of the video device.

   6

   Define and configure with the least privilege value to ensure that the container has only required permissions, such as access to the device file, and to restrict other capabilities for the container.

2. Deploy the Kubernetes workload by applying the manifest to the MicroShift node by running the following command:

   $ oc apply -f <your-workload-manifest.yaml> 

   1

   Copy to Clipboard Toggle word wrap

   1

   Replace <your_workload_manifest> with the name of your workload manifest.