Chapter 1. Using the MicroShift config.yaml

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 2
    maxFileSize: 200 3
    maxFiles: 10 4
    profile: Default 5
  namedCertificates:
    - certPath: ""
      keyPath: ""
      names:
        - ""
  subjectAltNames: [] 6
debugging:
  logLevel: "Normal" 7
dns:
  baseDomain: microshift.example.com 8
etcd:
  memoryLimitMB: 0 9
ingress:
  listenAddress:
    - "" 10
  ports: 11
    http: 80
    https: 443
  routeAdmissionPolicy:
    namespaceOwnership: InterNamespaceAllowed 12
  status: Managed 13
manifests: 14
  kustomizePaths:
    - /usr/lib/microshift/manifests
    - /usr/lib/microshift/manifests.d/*
    - /etc/microshift/manifests
    - /etc/microshift/manifests.d/*
network:
  clusterNetwork:
    - 10.42.0.0/16 15
  serviceNetwork:
    - 10.43.0.0/16 16
  serviceNodePortRange: 30000-32767 17
node:
  hostnameOverride: "" 18
  nodeIP: "" 19
```
1
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.
2
How long log files are kept before automatic deletion. The default value of 0 in the maxFileAge parameter means a log file is never deleted based on age. This value can be configured.
3
By default, when the audit.log file reaches the maxFileSize limit, the audit.log file is rotated and MicroShift begins writing to a new audit.log file. This value can be configured.
4
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.
5
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 Default profile is used.
6
Subject Alternative Names for API server certificates.
7
Log verbosity. Valid values for this field are Normal, Debug, Trace, or TraceAll.
8
By default, etcd uses as much memory as needed to handle the load on the system. However, in memory constrained systems, it might be preferred or necessary to limit the amount of memory etcd can to use at a given time.
9
Base domain of the cluster. All managed DNS records are subdomains of this base.
10
The ingress.listenAddress 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.
11
Default ports shown. Configurable. Valid values for both port entries are a single, unique port in the 1-65535 range. The values of the ports.http and ports.https fields cannot be the same.
12
Describes how hostname claims across namespaces are handled. By default, allows routes to claim different paths of the same hostname across namespaces. Valid values are Strict and InterNamespaceAllowed. Specifying Strict prevents routes in different namespaces from claiming the same hostname. If the value is deleted in a customized MicroShift config.yaml, the InterNamespaceAllowed value is automatically set.
13
Default router status, can be Managed or Removed.
14
The locations on the file system to scan for kustomization files to use to load manifests. Set to a list of paths to scan only those paths. Set to an empty list to disable loading manifests. The entries in the list can be glob patterns to match multiple subdirectories.
15
A block of IP addresses from which pod IP addresses are allocated. This field is immutable after installation.
16
A block of virtual IP addresses for Kubernetes services. IP address pool for services. A single entry is supported. This field is immutable after installation.
17
The port range allowed for Kubernetes services of type NodePort. If not specified, the default range of 30000-32767 is used. Services without a NodePort specified are automatically allocated one from this range. This parameter can be updated after the cluster is installed.
18
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. You cannot change this immutable setting after MicroShift starts for the first time.
19
The IP address of the node. The default value is the IP address of the default route.

1.2. Using a 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, the built-in default values are used to start the service.

1.2.1. Custom settings

To create custom configurations, you must create a config.yaml file in the /etc/microshift/ directory, and then change any settings that are expected to override the defaults before starting or restarting MicroShift.

Important

Restart MicroShift after changing any configuration settings to have them take effect. The config.yaml file is read only when MicroShift starts.

Tip

If you add all of the configurations you need at the same time, you can minimize system restarts.

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

Important

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

Important

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 nodePort selection. When an explicit nodePort is not specified, the port is assigned randomly by the kube-apiserver and 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.1. 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

1.3. Additional resources

Checking greenboot status

1.1. Default settings

1.2. Using a YAML configuration file

1.2.1. Custom settings

1.2.2. Configuring the advertise address network flag

1.2.3. Extending the port range for NodePort services

1.3. Additional resources

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

Making open source more inclusive

About Red Hat

Red Hat legal and privacy links

Red Hat legal and privacy links