Installing on a single node OpenShift (SNO) cluster

Implications of using SNO

The implications of running on a single node include:

• More limited options for workload availability. For example, the redundancy in multi-node clusters that allows workloads to failover to other workers is not present. Rolling upgrades for pods and multi-replica deployments can mitigate this limitation.
• Downtime in any deployed instance caused by any Red Hat OpenShift configuration change that requires the node to reboot or drain, such as Red Hat OpenShift upgrades.
• Limited choices of storage providers. A number of the supported storage providers for WebSphere Automation cannot run in a SNO cluster. It is possible to use Network File System (NFS) in an SNO cluster, but NFS is not a supported storage provider for WebSphere Automation production environments. You can only use NFS as a storage provider for WebSphere Automation in test or proof-of-concept (POC) environments.
  If you choose to set up a POC WebSphere Automation environment with NFS as a storage provider, refer to the following information.

  • Deploying an NFS server
  • NFS Subdir External Provisioner (Follow Red Hat OpenShift installation instructions).

Advantages of using SNO

Using SNO clusters can be an advantage in these scenarios:

• A resource-constrained environment. For more information on installing instances with minimal footprint, see Starter profile configuration.
• Edge sites where Red Hat OpenShift Container Platform is required and node failure can be mitigated.
• A proof-of-concept (POC) environment.

For more information, see Meet single node OpenShift: Our newest small OpenShift footprint for edge architectures .