Omni Documentation
Try OmniTalos Linux
  • Omni Documentation
  • Omni Support Matrix
  • Tutorials
    • Getting Started with Omni
    • Upgrading Omni Clusters
    • Installing Airgapped Omni
    • Using SAML and ACLs for fine-grained access control
    • Setting Up the Bare-Metal Infrastructure Provider
  • How-to guides
    • Using SAML with Omni
      • Add a User to Omni with SAML Enabled
      • Auto-assign roles to SAML users
      • Configure Workspace ONE Access for Omni
      • Configure Okta for Omni
      • Configure Entra ID AD for Omni
      • Configure Unifi Identity Enterprise for Omni
    • Register machines with Omni
      • Register a Bare Metal Machine (ISO)
      • Register a Bare Metal Machine (PXE/iPXE)
      • Register an AWS EC2 Instance
      • Register an Azure Instance
      • Register a GCP Instance
      • Register a Hetzner Server
    • Create a Cluster
    • Install talosctl
    • Install and Configure Omnictl
    • Use Kubectl With Omni
    • Create a Kubeconfig for a Kubernetes Service Account
    • Create a Patch For Cluster Machines
    • Manage Access Policies (ACLs)
    • Create a Hybrid Cluster
    • Run Omni on your own infrastructure
      • Deploy Omni On-prem
      • Configure Keycloak for Omni
      • Back Up On-prem Omni Database
      • How to expose Omni with Nginx (HTTPS)
    • Install Talos Linux Extensions
    • Scale a Cluster Up or Down
    • Etcd backups
    • Restore Etcd of a Cluster Managed by Cluster Templates
    • Create an Omni Service Account
    • Create a Machine Class
    • Expose an HTTP Service from a Cluster
    • Export a Cluster Template from a Cluster Created in the UI
    • Audit logs
    • Set Initial Machine Labels Using Omnictl or Image Factory
  • Explanation
    • Machine Registration
    • Authentication and Authorization
    • Omni KMS Disk Encryption
    • Infrastructure Providers
  • Reference
    • omnictl CLI
    • Access Policies (ACLs)
    • Generating omnictl CLI reference
    • Cluster Templates
Powered by GitBook
On this page
  • Architecture
  • Static providers
  • Dynamic providers
Edit on GitHub
Export as PDF
  1. Explanation

Infrastructure Providers

Information about what infrastructure providers are and how they work.

PreviousOmni KMS Disk EncryptionNextReference

Last updated 2 months ago

Infrastructure providers are a way to connect compute resources to your Omni instance for automatic management. Providers manage the lifecycle of the machines under their management.

This can replace the traditional "manual" management of machines where an engineer is responsible for downloading installation media and booting a machine to connect to Omni.

There are two types of infrastructure providers: providers that manage static resources, and providers that manage dynamic resources. Static resources are machines you own that are re-used for different clusters. Dynamic resources are VMs that are created and deleted as needed.

Multiple infrastructure providers can be connected to a single Omni instance and be responsible for different sets of machines.

The current infrastructure providers are:

If you would like to build your own provider or request a provider to be created please or open an .

Architecture

Each Omni account (or instance) can have multiple providers connected to it. Each infrastructure provider deployment is intended to manage static or dynamic machines (e.g. bare metal, AWS EC2 instances) in a single location (e.g. dc1, us-east-2). Clusters can be created with a mix of infrastructure from manually provisioned, dynamic, or static machines.

For example, if you have multiple data centers you would run one Bare Metal Infrastructure Provider in each data center with network access to the servers it manages. This would also apply if you have multiple network segments in the same data center.

If you want to run multiple providers connected to on-prem VM providers (e.g. VMware, KubeVirt) you would run one provider per VM management API. So even if all providers can reach all platforms they are segmented per provider credential.

If you want to run machines in multiple regions or accounts in a public cloud provider you would run one provider to create machines in each region/account. It does not matter where you run the public cloud providers, so long as they can reach the public cloud APIs and your Omni instance.

Static providers

Static resource providers manage existing bare metal servers in an environment. Static providers differ from dynamic providers in that they do not create machines, but they manage power management, PXE booting, and OS provisioning.

Dynamic providers

Dynamic providers delete machines when they are not being used in a cluster instead of returning them to a pool of static resources.

When a static machine is not actively being used in a cluster it is turned off to reduce power consumption and heat in a data center. For more information please see the documentation on .

Dynamic providers create and destroy machines as needed. These are created using other VM platforms such as AWS, VMware and OpenStack. They can also use other infrastructure management solutions such as or which have their own APIs and can provision machines out of a pool of resources.

Dynamic providers make a request to a resource API and expect machines to be created dynamically and connected to Omni. A is automatically created for the request which keeps the machines organized and automatically provisioned to a cluster.

how to configure a bare metal provider
Forman
RackN
machine class
Bare metal provider
KubeVirt provider
join our community slack workspace
issue on github