MicroShift is Technology Preview software only.
For more information about the support scope of Red Hat Technology Preview software, see Technology Preview Support Scope.Configuring
Configuring MicroShift
Abstract
Chapter 1. How configuration tools work
A YAML file customizes Red Hat build of MicroShift instances with your preferences, settings, and parameters.
1.1. Using a YAML configuration file
Red Hat build of MicroShift searches for a configuration file in the user-specific directory, ~/.microshift/config.yaml
, then the system-wide /etc/microshift/config.yaml
directory. You must create the configuration file and specify any settings that should override the defaults before starting Red Hat build of MicroShift.
1.1.1. Default settings
If you do not create a config.yaml
file, the default values are used. The following example configuration contains the default settings. You must change any settings that should override the defaults before starting Red Hat build of MicroShift.
Default YAML file example
dns: baseDomain: microshift.example.com 1 network: clusterNetwork: - cidr: 10.42.0.0/16 2 serviceNetwork: - 10.43.0.0/16 3 serviceNodePortRange: 30000-32767 4 node: hostnameOverride: "" 5 nodeIP: "" 6 apiServer: subjectAltNames: [] 7 debugging: logLevel: "Normal" 8
- 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
- Subject Alternative Names for API server certificates.
- 8
- Log verbosity. Valid values for this field are
Normal
,Debug
,Trace
, orTraceAll
.
Restart Red Hat build of MicroShift after changing any configuration settings to have them take effect. Red Hat build of MicroShift reads the configuration file only on start.
1.2. 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 Red Hat build of MicroShift.
Consider the following when configuring the NodePort service ranges:
-
Do not create any NodePort service without an explicit
nodePort
selection. When an explicitnodePort
is not specified, the port is assigned randomly by thekube-apiserver
and cannot be predicted. -
Do not create any NodePort service for any system service port, Red Hat build of 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
Chapter 2. Cluster access with kubeconfig
Learn about how kubeconfig
files are used with Red Hat build of MicroShift deployments. CLI tools use kubeconfig
files to communicate with the API server of a cluster. These files provide cluster details, IP addresses, and other information needed for authentication.
2.1. Kubeconfig files for configuring cluster access
The two categories of kubeconfig
files used in Red Hat build of MicroShift are local access and remote access. Every time Red Hat build of MicroShift starts, a set of kubeconfig
files for local and remote access to the API server are generated. These files are generated in the /var/lib/microshift/resources/kubeadmin/
directory using preexisting configuration information.
Each access type requires a different authentication certificate signed by different Certificate Authorities (CAs). The generation of multiple kubeconfig
files accommodates this need.
You can use the appropriate kubeconfig
file for the access type needed in each case to provide authentication details. The contents of Red Hat build of MicroShift kubeconfig
files are determined by either default built-in values or a config.yaml
file.
A kubeconfig
file must exist for the cluster to be accessible. The values are applied from built-in default values or a config.yaml
, if one was created.
Example contents of the kubeconfig files
/var/lib/microshift/resources/kubeadmin/ ├── kubeconfig 1 ├── alt-name-1 2 │ └── kubeconfig ├── 1.2.3.4 3 │ └── kubeconfig └── microshift-rhel9 4 └── kubeconfig
2.2. Local access kubeconfig file
The local access kubeconfig
file is written to /var/lib/microshift/resources/kubeadmin/kubeconfig
. This kubeconfig
file provides access to the API server using localhost
. Choose this file when you are connecting the cluster locally.
Example contents of kubeconfig
for local access
clusters: - cluster: certificate-authority-data: <base64 CA> server: https://localhost:6443
The localhost
kubeconfig
file can only be used from a client connecting to the API server from the same host. The certificates in the file do not work for remote connections.
2.2.1. Accessing the Red Hat build of MicroShift cluster locally
Use the following procedure to access the Red Hat build of MicroShift cluster locally by using a kubeconfig
file.
Prerequisites
-
You have installed the
oc
binary.
Procedure
Optional: to create a
~/.kube/
folder if your RHEL machine does not have one, run the following command:$ mkdir -p ~/.kube/
Copy the generated local access
kubeconfig
file to the~/.kube/
directory by running the following command:$ sudo cat /var/lib/microshift/resources/kubeadmin/kubeconfig > ~/.kube/config
Update the permissions on your
~/.kube/config
file by running the following command:$ chmod go-r ~/.kube/config
Verification
Verify that Red Hat build of MicroShift is running by entering the following command:
$ oc get all -A
2.3. Remote access kubeconfig files
When a Red Hat build of MicroShift cluster connects to the API server from an external source, a certificate with all of the alternative names in the SAN field is used for validation. Red Hat build of MicroShift generates a default kubeconfig
for external access using the hostname
value. The defaults are set in the <node.hostnameOverride>
, <node.nodeIP>
and api.<dns.baseDomain>
parameter values of the default kubeconfig
file.
The /var/lib/microshift/resources/kubeadmin/<hostname>/kubeconfig
file uses the hostname
of the machine, or node.hostnameOverride
if that option is set, to reach the API server. The CA of the kubeconfig
file is able to validate certificates when accessed externally.
Example contents of a default kubeconfig
file for remote access
clusters: - cluster: certificate-authority-data: <base64 CA> server: https://microshift-rhel9:6443
2.3.1. Remote access customization
Multiple remote access kubeconfig
file values can be generated for accessing the cluster with different IP addresses or host names. An additional kubeconfig
file generates for each entry in the apiServer.subjectAltNames
parameter. You can copy remote access kubeconfig
files from the host during times of IP connectivity and then use them to access the API server from other workstations.
2.4. Generating additional kubeconfig files for remote access
You can generate additional kubeconfig
files to use if you need more host names or IP addresses than the default remote access file provides.
You must restart Red Hat build of MicroShift for configuration changes to be implemented.
Prerequisites
-
You have created a
config.yaml
for Red Hat build of MicroShift.
Procedure
(Optional) You can show the contents of the
config.yaml
by running the following command:$ cat /etc/microshift/config.yaml
(Optional) You can show the contents of the remote-access
kubeconfig
file, by running the following command:$ cat /var/lib/microshift/resources/kubeadmin/<hostname>/kubeconfig
ImportantAdditional remote access
kubeconfig
files must include one of the server names listed in the Red Hat build of MicroShiftconfig.yaml
file. Additionalkubeconfig
files must also use the same CA for validation.To generate additional
kubeconfig
files for additional DNS names SANs or external IP addresses, add the entries you need to theapiServer.subjectAltNames
field. In the following example, the DNS name used isalt-name-1
and the IP address is1.2.3.4
.Example
config.yaml
with additional authentication valuesdns: baseDomain: example.com node: hostnameOverride: "microshift-rhel9" 1 nodeIP: 10.0.0.1 apiServer: subjectAltNames: - alt-name-1 2 - 1.2.3.4 3
Restart Red Hat build of MicroShift to apply configuration changes and auto-generate the
kubeconfig
files you need by running the following command:$ sudo systemctl restart microshift
To check the contents of additional remote-access
kubeconfig
files, insert the name or IP address as listed in theconfig.yaml
into thecat
command. For example,alt-name-1
is used in the following example command:$ cat /var/lib/microshift/resources/kubeadmin/alt-name-1/kubeconfig
Choose the
kubeconfig
file to use that contains the SAN or IP address you want to use to connect your cluster. In this example, thekubeconfig
containing`alt-name-1` in thecluster.server
field is the correct file.Example contents of an additional
kubeconfig
fileclusters: - cluster: certificate-authority-data: <base64 CA> server: https://alt-name-1:6443 1
- 1
- The
/var/lib/microshift/resources/kubeadmin/alt-name-1/kubeconfig
file values are from theapiServer.subjectAltNames
configuration values.
All of these parameters are included as common names (CN) and subject alternative names (SAN) in the external serving certificates for the API server.
2.4.1. Opening the firewall for remote access to the Red Hat build of MicroShift cluster
Use the following procedure to open the firewall so that a remote user can access the Red Hat build of MicroShift cluster. This procedure must be completed before a workstation user can access the cluster remotely.
For this procedure, user@microshift
is the user on the Red Hat build of MicroShift host machine and is responsible for setting up that machine so that it can be accessed by a remote user on a separate workstation.
Prerequisites
-
You have installed the
oc
binary. - Your account has cluster administration privileges.
Procedure
As
user@microshift
on the Red Hat build of MicroShift host, open the firewall port for the Kubernetes API server (6443/tcp
) by running the following command:[user@microshift]$ sudo firewall-cmd --permanent --zone=public --add-port=6443/tcp && sudo firewall-cmd --reload
Verification
As
user@microshift
, verify that Red Hat build of MicroShift is running by entering the following command:[user@microshift]$ oc get all -A
2.4.2. Accessing the Red Hat build of MicroShift cluster remotely
Use the following procedure to access the Red Hat build of MicroShift cluster from a remote workstation by using a kubeconfig
file.
The user@workstation
login is used to access the host machine remotely. The <user>
value in the procedure is the name of the user that user@workstation
logs in with to the Red Hat build of MicroShift host.
Prerequisites
-
You have installed the
oc
binary. -
The
@user@microshift
has opened the firewall from the local host.
Procedure
As
user@workstation
, create a~/.kube/
folder if your RHEL machine does not have one by running the following command:[user@workstation]$ mkdir -p ~/.kube/
As
user@workstation
, set a variable for the hostname of your Red Hat build of MicroShift host by running the following command:[user@workstation]$ MICROSHIFT_MACHINE=<name or IP address of Red Hat build of MicroShift machine>
As
user@workstation
, copy the generatedkubeconfig
file that contains the host name or IP address you want to connect with from the RHEL machine running Red Hat build of MicroShift to your local machine by running the following command:[user@workstation]$ ssh <user>@$MICROSHIFT_MACHINE "sudo cat /var/lib/microshift/resources/kubeadmin/$MICROSHIFT_MACHINE/kubeconfig" > ~/.kube/config
As
user@workstation
, update the permissions on your~/.kube/config
file by running the following command:$ chmod go-r ~/.kube/config
Verification
As
user@workstation
, verify that Red Hat build of MicroShift is running by entering the following command:[user@workstation]$ oc get all -A