Chapter 1. How configuration tools work
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. 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
dns: baseDomain: microshift.example.com 1 network: clusterNetwork: - 10.42.0.0/16 2 serviceNetwork: - 10.43.0.0/16 3 serviceNodePortRange: 30000-32767 4 node: hostnameOverride: "" 5 nodeIP: "" 6 apiServer: advertiseAddress: 10.44.0.0/32 7 subjectAltNames: [] 8 debugging: logLevel: "Normal" 9
- 1
- Base domain of the cluster. All managed DNS records will be subdomains of this base.
- 2
- A block of IP addresses from which Pod IP addresses are allocated.
- 3
- A block of virtual IP addresses for Kubernetes services.
- 4
- The port range allowed for Kubernetes services of type NodePort.
- 5
- The name of the node. The default value is the hostname.
- 6
- The IP address of the node. The default value is the IP address of the default route.
- 7
- 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.
- 8
- Subject Alternative Names for API server certificates.
- 9
- Log verbosity. Valid values for this field are
Normal,Debug,Trace, orTraceAll.
1.2. Using a YAML configuration file
On start up, MicroShift searches the system-wide /etc/microshift/ directory for a configuration file named config.yaml. To use custom configurations, you must create the configuration file and specify any settings that are expected to override the defaults before starting MicroShift.
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.
Restart MicroShift after changing any configuration settings to have them take effect. The config.yaml file is read only when MicroShift starts.
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.
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.
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.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
