Chapter 1. Using the MicroShift configuration file
A YAML file customizes MicroShift instances with your preferences, settings, and parameters.
If you want to make configuration changes or deploy applications through the MicroShift API with tools other than kustomize manifests, you must wait until the greenboot health checks have finished. This ensures that your changes are not lost if greenboot rolls your rpm-ostree system back to an earlier state.
1.1. The MicroShift YAML configuration file
At start up, MicroShift checks the system-wide /etc/microshift/ directory for a configuration file named config.yaml. If the configuration file does not exist in the directory, built-in default values are used to start the service.
The MicroShift configuration file must be used in combination with host and, sometimes, application and service settings. Ensure that each item is configured in tandem when you customize your MicroShift cluster.
1.1.1. Default settings
If you do not create a config.yaml file, default values are used. The following example shows the default configuration settings.
To see the default values, run the following command:
$ microshift show-config
Default values example output in YAML form
apiServer: advertiseAddress: 10.44.0.0/32 1 auditLog: maxFileAge: 0 maxFileSize: 200 maxFiles: 10 profile: Default namedCertificates: - certPath: "" keyPath: "" names: - "" subjectAltNames: [] debugging: logLevel: "Normal" dns: baseDomain: microshift.example.com etcd: memoryLimitMB: 0 ingress: listenAddress: - "" ports: http: 80 https: 443 routeAdmissionPolicy: namespaceOwnership: InterNamespaceAllowed status: Managed kubelet: manifests: kustomizePaths: - /usr/lib/microshift/manifests - /usr/lib/microshift/manifests.d/* - /etc/microshift/manifests - /etc/microshift/manifests.d/* network: clusterNetwork: - 10.42.0.0/16 serviceNetwork: - 10.43.0.0/16 serviceNodePortRange: 30000-32767 node: hostnameOverride: "" nodeIP: "" 2 nodeIPv6: "" storage: driver: "" 3 optionalCsiComponents: 4 - ""
1.2. Using custom settings
To create custom configurations, make a copy of the config.yaml.default file that is provided in the /etc/microshift/ directory, renaming it config.yaml. Keep this file in the /etc/microshift/ directory, and then you can change supported settings that are expected to override the defaults before starting or restarting MicroShift.
Restart MicroShift after changing any configuration settings to have them take effect. The config.yaml file is read only when MicroShift starts.
1.2.1. Separate restarts
Applications and other optional services used with your MicroShift cluster might also need to be restarted separately to apply configuration changes throughout the cluster. For example, when making changes to certain networking settings, you must stop and restart service and application pods to apply those changes. See each procedure for the task you are completing for more information.
If you add all of the configurations you need at the same time, you can minimize system restarts.
1.2.2. Parameters and values for the MicroShift config.yaml file
The following table explains MicroShift configuration YAML parameters and valid values for each:
| Field | Type | Description |
|---|---|---|
|
|
| A string that specifies the IP address from which the API server is advertised to members of the cluster. The default value is calculated based on the address of the service network. |
|
|
|
How long log files are kept before automatic deletion. The default value of |
|
|
|
By default, when the |
|
|
| The total number of log files kept. By default, MicroShift retains 10 log files. The oldest is deleted when an excess file is created. This value can be configured. |
|
|
|
Logs only metadata for read and write requests; does not log request bodies except for OAuth access token requests. If you do not specify this field, the |
|
|
| Defines externally generated certificates and domain names by using custom certificate authorities. |
|
|
| The full path to the certificate. |
|
|
| The full path to the certificate key. |
|
|
| Optional. Add a list of explicit DNS names. Leading wildcards are allowed. If no names are provided, the implicit names are extracted from the certificates. |
|
|
Fully qualified domain names (FQDNs), wildcards such as | Subject Alternative Names for API server certificates. SANs indicate all of the domain names and IP addresses that are secured by a certificate. |
|
|
|
Log verbosity. Default is |
|
|
| Base domain of the cluster. All managed DNS records are subdomains of this base. |
|
|
|
By default, |
|
| IP address, NIC name, or multiple | Value defaults to the entire network of the host. The valid configurable value is a list that can be either a single IP address or NIC name or multiple IP addresses and NIC names. |
|
|
|
Default port shown. Configurable. Valid value is a single, unique port in the 1-65535 range. The values of the |
|
|
|
Default port shown. Configurable. Valid value is a single, unique port in the 1-65535 range. The values of the |
|
|
|
Describes how hostname claims across namespaces are handled. By default, allows routes to claim different paths of the same hostname across namespaces. Specifying |
|
|
|
Router status. Default is |
|
| See the MicroShift low-latency instructions | Parameter for passthrough configuration of the kubelet node agent. Used for low-latency configuration. Default value is null. |
|
|
|
The locations on the file system to scan for |
|
| IP address block |
A block of IP addresses from which pod IP addresses are allocated. IPv4 is the default. Dual-stack entries are supported. The first entry in this field is immutable after MicroShift starts. Default range is |
|
| IP address block |
A block of virtual IP addresses for Kubernetes services. IP address pool for services. IPv4 is the default. Dual-stack entries are supported. The first entry in this field is immutable after MicroShift starts. Default range is |
|
|
|
The port range allowed for Kubernetes services of type |
|
|
| The name of the node. The default value is the hostname. If non-empty, this string is used to identify the node instead of the hostname. This value is immutable after MicroShift starts. |
|
| IPv4 address | The IPv4 address of the node. The default value is the IP address of the default route. |
|
| IPv6 address | The IPv6 address for the node for dual-stack configurations. Cannot be configured in single stack for either IPv4 or IPv6. Default is an empty value or null. |
|
|
| Default value is empty. An empty value or null field defaults to LVMS deployment. |
|
|
|
Default value is null or an empty array. A null or empty array defaults to deploying |
1.2.3. Configuring the advertise address network flag
The apiserver.advertiseAddress flag specifies the IP address on which to advertise the API server to members of the cluster. This address must be reachable by the cluster. You can set a custom IP address here, but you must also add the IP address to a host interface. Customizing this parameter preempts MicroShift from adding a default IP address to the br-ex network interface.
If you customize the advertiseAddress IP address, make sure it is reachable by the cluster when MicroShift starts by adding the IP address to a host interface.
If unset, the default value is set to the next immediate subnet after the service network. For example, when the service network is 10.43.0.0/16, the advertiseAddress is set to 10.44.0.0/32.
1.2.4. Extending the port range for NodePort services
The serviceNodePortRange setting extends the port range available to NodePort services. This option is useful when specific standard ports under the 30000-32767 range need to be exposed. For example, if your device needs to expose the 1883/tcp MQ Telemetry Transport (MQTT) port on the network because client devices cannot use a different port.
NodePorts can overlap with system ports, causing a malfunction of the system or MicroShift.
Consider the following when configuring the NodePort service ranges:
-
Do not create any NodePort service without an explicit
nodePortselection. When an explicitnodePortis not specified, the port is assigned randomly by thekube-apiserverand cannot be predicted. -
Do not create any NodePort service for any system service port, MicroShift port, or other services you expose on your device
HostNetwork. Table one specifies ports to avoid when extending the port range:
Table 1.2. Ports to avoid. Port Description 22/tcp
SSH port
80/tcp
OpenShift Router HTTP endpoint
443/tcp
OpenShift Router HTTPS endpoint
1936/tcp
Metrics service for the openshift-router, not exposed today
2379/tcp
etcd port
2380/tcp
etcd port
6443
kubernetes API
8445/tcp
openshift-route-controller-manager
9537/tcp
cri-o metrics
10250/tcp
kubelet
10248/tcp
kubelet healthz port
10259/tcp
kube scheduler
