Install and Configure MicroShift on Package-Based RHEL

Keep SELinux, Firewalld, and Network Manager enabled. The more you diverge from RHEL defaults, the harder it might be to get MicroShift up and running. MicroShift is designed to integrate with other RHEL system services.

The majority of MicroShift instances require logical volume management (LVM) to back persistent storage for Kubernetes persistent volumes. You need a volume group (VG) named rhel with sufficient empty space for MicroShift to create logical volumes (LVs) for each of your application’s persistent volumes.

Unlike Red Hat OpenShift, MicroShift does not place special network requirements on its host. Because it is a single-node cluster, there are no requirements for virtual IP addresses for load balancers to access the Kubernetes API and router pods. MicroShift listens on Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) ports on all network interfaces available to its host, and the set of interfaces or IP addresses can be constrained by editing the MicroShift configuration files.

If your main work machine runs RHEL, you could install and configure MicroShift on it; however, because your work machine likely runs a variety of other system services, Red Hat recommends that you install MicroShift in a dedicated VM or remote system. Local unprivileged session VMs from Libvirt should work well, and also other desktop hypervisors.

To install MicroShift, you need two RPM repositories:

Change the names of the two previously mentioned repositories to align with the RHEL release you are using and the CPU architecture of your target system. The first respository provides the MicroShift RPM packages, which are built together with each release of Red Hat OpenShift. The second repository provides Open Virtual Network (OVN) packages, which are required by MicroShift’s CNI driver for managing Kubernetes pod and service networks.

The microshift RPM package pulls, as dependencies, all required components of MicroShift. A few optional components can be installed as additional RPM packages.

You also need a pull secret, which provides access to container images from Red Hat container registries and Quay.io. It can be an OpenShift installation pull secret from a Red Hat Customer Portal account or from a Red Hat Developer account. The Red Hat Developer Program provides free access to RHEL installation media, RHEL package repositories, and selected Red Hat software, such as Red Hat OpenShift.

You shouldn’t need to make edits to any of the MicroShift configuration files; they have reasonable defaults for starting a MicroShift instance connected to the internet.

If you perform an air-gapped installation of MicroShift, you need a mirror of the Red Hat OpenShift and RHEL 9 Fast Data Path package repositories, in addition to the standard RHEL BaseOS and AppStream repositories, which you need to satisfy package dependencies.

You also need a mirror container registry pre-populated with the container images required by MicroShift and add-on operators that you install, besides a pull secret configured for that mirror registry. The pull secret is just a container tools authentication file, which you can create using the podman login command.

You could use, as installation source for an air-gapped installation, any software capable of serving DNF repositories, such as Red Hat Satellite, in addition to any Open Container Initiative (OCI)-compliant container registry server, such as Red Hat Quay.

If you deploy MicroShift air-gapped, you also need to provide CRI-O an image policy configuration file, which redirects access to MicroShift images from the Red Hat registries and Quay.io to your mirror registry.

MicroShift lacks a graphical web console, which means you need to use the OpenShift CLI. In addition, a number of OpenShift CLI commands do not work with MicroShift instances, for example:

Also, avoid oc commands that require other OpenShift extension APIs missing in MicroShift, such as Image Streams and Build Configs.

Despite the missing extension APIs, the OpenShift CLI still provides a number of niceties for MicroShift users compared with the Kubernetes client, and Red Hat recommends using the oc command with MicroShift. If you prefer not using these niceties, the standard kubectl command is also supported for MicroShift, as well as for all editions of Red Hat OpenShift.

Developers require that cluster administrators provide them with kubeconfig files pre-configured with identities that grant only limited privileges on selected namespaces, for day-to-day usage.

Those unprivileged identities could be configured for any of authentication mechanisms supported by upstream Kubernetes, the most common being:

Red Hat recommends the second because Kubernetes does not include management of certificate revocation lists. That means you cannot revoke authorization from a client certificate that leaks to unauthorized users, but you can delete a service account resource to invalidate its token.

MicroShift is not an application platform; it is merely a Kubernetes engine. It does not provide self-service project creation. Instead, it requires that cluster administrators create and configure namespaces for regular users and grant those users with rights to deploy applications in their namespaces.

MicroShift cluster administrators use standard Kubernetes Role-Based Access Control (RBAC) APIs to grant rights to one or more namespaces. You could use the standard admin, edit, and view cluster roles from Kubernetes, or you could create your own custom cluster roles and namespace roles.

Most developers only need the edit cluster role, which grants permission to manage common application resources, such as deployments and persistent volume claims.

Selected users, such as project administrators and team leaders, may be granted the admin cluster roles, which includes rights to manage policy resources, such as resource quotas and network policies.

The oc project command works with MicroShift because it does not use the Project API; it just sets or queries context information stored in a kubeconfig file. Most other oc commands related to projects, however, will fail on MicroShift.

As a reminder, you can use the -n or --namespace option with most oc and kubectl commands to act on a namespace other than the one set by the current context in the kubeconfig file. Or you can change the current context in your kibneconfig file by using either the oc project command or the kubectl config set-context --current --namespace command.

Because there’s no Projects API, you cannot list the namespaces to which you have access; you must know their names in advance, like with upstream Kubernetes.

OpenShift developers may be used to templates, especially the quick start app templates managed by the OpenShift Samples operator; however, those templates are not available with MicroShift.

Templates are useful because they configure applications and common middleware services with recommended settings such as health probes and resource requests.

If you wish, you can use templates with MicroShift, despite the lack of server-side support, if you have you templates stored as local YAML files and use the oc process command.

Most developers will likely avoid OpenShift templates use regular YAML manifests, with or without Kustomize overlays, or Helm charts, as they would do with upstream Kubernetes.

Kustomize support is included in the oc command, as is everything else from the standard kubectl command, and the helm command works with MicroShift as it would with any other Kubernetes cluster.