Skip to content

Infrastructure, Service Configs and Service Platforms

Infrastructures are your organization's own cloud platforms that you provide and register within the system. An Infrastructure represents the physical or virtual resources where managed services will be deployed. Once you register an Infrastructure, you curate a Catalog of compute sizes and images that resources may use, and you create Service Configs that group the Service Platforms which back the platform's managed services (Kubernetes, PostgreSQL, …). This lets you leverage the platform's management capabilities while keeping full control over your underlying infrastructure.

The model

graph TD
    A[Infrastructure] --> B[Catalog<br/>flavors and images]
    A --> C[Service Config<br/>thin grouping: name + description]
    C --> D["Service Platform: MKS<br/>(external network)"]
    C --> E["Service Platform: PostgreSQL<br/>(managed / managed-tools / external)"]
Concept What it is
Infrastructure A registered cloud (today, OpenStack) where services run. Owns a Catalog and one or more Service Configs.
Catalog The set of flavors (compute sizes) and images (OS images) imported from the provider that resources in this infrastructure are allowed to use. Each entry can be enabled/disabled and renamed.
Service Config A lightweight, named grouping (name + description) inside an infrastructure. It holds no configuration of its own — it simply aggregates the Service Platforms below it. This is the unit you select when deploying a managed service.
Service Platform The actual configuration for one supported managed service inside a Service Config. There is at most one platform per kind per Service Config. Today two kinds exist: MKS and PostgreSQL.

Profiles are gone

Earlier versions used a single concept called a Profile. That has been replaced by the Catalog (which flavors and images are available) plus Service Configs and Service Platforms (how each managed service is wired). If you are looking for "profiles", you now want a Service Config.

Regions and Zones

Every infrastructure lives in a Region and a Zone. These are organization-level groupings you use to describe where your infrastructure sits — for example a Region per geographic area or data center, with one or more Zones inside it. Regions and Zones are a platform-wide concept: they apply to every infrastructure you register, regardless of provider.

  • A Region belongs to your organization (give it a name; a description is optional).
  • A Zone belongs to a Region.

You select a Region and a Zone when registering an infrastructure. If you have not created them yet, you can create them inline from the registration wizard. Other resources — such as PostgreSQL instances and Kubernetes clusters — are placed by narrowing down through Region, Zone and Infrastructure when you deploy them.

How it works

To use the platform's managed services, you must:

  1. Register your infrastructure: Bring your own private cloud environment and connect it to the platform.
  2. Build the catalog: Import the flavors and images from your provider that you want resources to be able to use, and enable the ones teams may select. You can seed the catalog while registering the infrastructure and adjust it any time afterward from the infrastructure's detail page.
  3. Create a Service Config: Add one or more Service Configs to the infrastructure. A Service Config is just a named container — give it a clear name (for example production or team-alpha).
  4. Add Service Platforms: Inside the Service Config, add the platforms for the services you want to offer:
    • An MKS network platform (one per Service Config) that defines the external network MKS clusters attach to. This is the foundation other platforms build on.
    • A PostgreSQL platform to offer managed PostgreSQL databases. It requires an MKS network platform to exist first.
  5. Deploy managed services: When deploying a managed service (such as a Kubernetes cluster or a PostgreSQL database), select the project and the Service Config to use. The platform deploys the service onto the matching Service Platform according to its configuration.

Catalog

The Catalog is the set of flavors (compute sizes) and images (OS images) from your cloud that resources in this infrastructure are allowed to use. Curating it is how you govern what teams can pick.

  • Seed it at registration, manage it later: You can select flavors and images while registering the infrastructure, but that step is optional and only seeds the catalog. Afterward you import, rename, enable/disable and delete entries from the infrastructure's detail page.
  • Import from your cloud (OpenStack today): On OpenStack infrastructures you import entries that reference a flavor or image already in your cloud. Entries already imported are marked and cannot be imported twice. Listing, renaming, enabling/disabling and deleting catalog entries work the same way for any provider.
  • What you can edit: An entry's description and its enabled flag are editable; the name cannot be cleared. Flavor entries show vCPUs, RAM and disk; image entries show minimum RAM and disk.

Disable vs delete

Disabling an entry removes it from new deployments while existing resources keep working. Deleting an entry removes it permanently (cannot be undone); existing resources that already use it keep working. Disable when you want to retire a size or image safely.

Service Platform kinds

MKS network platform

A data-only platform that carries the external network that Managed Kubernetes (MKS) clusters in this Service Config attach to. It runs no operations and becomes available immediately on creation. At most one MKS platform exists per Service Config, and it is the single source of the external network — both user clusters and the backing clusters of other platforms read it. When you create the MKS platform you select an existing external network from your cloud.

PostgreSQL platform

Offers managed PostgreSQL (backed by the CloudNativePG operator) in one of three modes, chosen when the platform is created:

Mode What it means
Managed The platform provisions and owns a backing Kubernetes cluster for you, then installs PostgreSQL on it. Requires an enabled MKS network platform in the same Service Config.
Managed tools You bring your own Kubernetes cluster (by providing a kubeconfig); the platform installs and manages PostgreSQL on it.
External Record-only. The platform tracks an external database you manage yourself and deploys nothing, but you connect the cluster it runs on by providing a kubeconfig.

A PostgreSQL platform of any mode requires an MKS network platform to already exist on the Service Config.

Enabling and disabling platforms

Each Service Platform has an enabled flag that gates new use without touching what is already deployed:

  • Disabling an MKS platform stops new clusters (and new managed PostgreSQL platforms) from being created against it. Existing clusters keep running.
  • Disabling never tears down anything already deployed. Deletion does — and deletion is ordered: you delete the PostgreSQL platform first, then the MKS platform, then the Service Config. The platform blocks deletion while dependent resources still exist, so remove what builds on a platform before deleting it.

Day-2 management of a platform — enable/disable, upgrade (for tool platforms like PostgreSQL), delete and action history — lives on the platform's own detail page in the console.

Supported Infrastructures

Currently, the platform supports OpenStack-based private clouds as the primary infrastructure type. This means not only your private OpenStack clouds but also public OpenStack-based cloud providers can be registered as Infrastructures. Support for additional infrastructure types (such as AWS, Azure, GCP, VMware, etc.) is planned for future releases.

Setup Instructions

For step-by-step instructions on preparing your infrastructure to work with the platform, refer to the setup guides:

Best Practices

  • Start with a single infrastructure: If you're new to the platform, start by registering one infrastructure to get familiar with how it works. This lets you learn the ropes without juggling multiple environments.
  • Principle of least privilege: When registering an infrastructure, use credentials with the least privileges necessary for the platform to manage resources.
  • Curate the catalog for governance: Import and enable only the flavors and images you want teams to use. Disabling an entry removes it from new deployments while leaving existing resources untouched — a safe way to retire a size or image.
  • Use Service Configs to organize and govern: Service Configs are how you separate concerns — for example a production config with stricter settings and a development config for dev/test. Teams pick a Service Config when deploying, so they stay within the platforms (and networks) you have curated for them.
  • Lay the foundation first: Always add the MKS network platform before PostgreSQL (or other MKS-dependent) platforms, since they build on it.