Dedicated clusters run omega-ml in a customer-owned cloud account (AWS, Azure, Exoscale, any other cloud provider or on-premise). Each cluster is a fully deployed kubernetes cluster with the following Rancher projects and namespaces:
- omegaml-services - runs all the basic services like mongodb, rabbitmq, apphub, juypterhub and related pods
- omegaml-runtime - runs omega-ml runtime worker pods, jupyter notebook services and deployed apps. These pods are deployed in user-named namespaces (e.g. user foxbar = namespace foxbar)
A dedicated cluster can serve multiple users, managed by the account management pane. In hosted deployments, the cluster uses hub.omegaml.io as the account management pane. In on-premise deployments, the cluster provides the account management pane itself, hosted at a customer-specified URL.
Each cluster is set up with at least two nodepools:
- k8s-system (label: system/role=k8s)
- omega-system (label: omegaml.io/role=system)
In a minimal configuration, these nodepools are scaled to 1 node each. To support production and high-availability workloads, these should be scaled to 3 nodes or more. The storage in the minimal configuration is using the local-path-provisioner, meaning that each nodes' local disk storage is used.
The omegam-ml standard services are provided at the cluster's URL as follows:
- /hub - the jupyterhub service, to run user-launched jupyter notebook sessions
- /apps - the omega-ml apphub, to run custom deployed apps
- /rmq - the rabbitmq service, to monitor and control rabbitmq
In addition, each cluster provides mongodb and omega-ml runtime services. The respective configuration and URIs are provided to omega-ml clients, upon login, by the account management pane.
The user can deploy additional nodepools for deployment of omega-ml worker, applications and custom services. Each such nodepool is deployed according to the node type specification provided by the user, and is named according to the nodepool's user designation and role:
- <cluster-name>-<userid>-<nodetype>-<noderole> (label: omegaml.io/role=worker)
Any services deployed by the user will be automatically dispatched according to the role designation of each service (default: worker).
omega-ml clusters come with built-in support for clustered and scalable virutal storage managed by the kubernetes longhorn storage manager, supporting dynamic volume provisioning and replication across across the nodes of the cluster. In this configuration, the cluster has an additional nodepool:
- <cluster-name>-storage (label: system/role=storage)
This nodepool is predicated on running longhorn's volume services. All omegaml services are built to be opaque to the underlying storage system, that is they run the same and independent of the type of storage used. This is achieved by leveraging the abstractions of the kubernetes volume provisioning system, namely persistent volume claims (PVCs).
In cross-cloud runtimes the omega-ml runtime distributes work across many nodepools deployed in different clusters deployed to any number of cloud vendors or on-premise resources. In such deployments, each instance of the omega-ml runtime in a given cluster is configured to rely on the account management pane to provide the required configuration that interconnects all runtime instances. This is achieved by leveraging omega-ml's runtime reliance on celery for task distribution, and on mongodb for distributed storage.